Memoria de Título Danilo Solar Donoso 19-05-2010

PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA INFORMÁTICA

DESARROLLO DE UN SISTEMA MULTIAGENTE PARA LA RESERVA DE LIBROS UTILIZANDO DISPOSITIVOS MÓVILES

DANILO ARMANDO SOLAR DONOSO

AGOSTO, 2007

INFORME FINAL DEL PROYECTO PARA OPTAR AL TÍTULO PROFESIONAL DE INGENIERO CIVIL EN INFORMÁTICA

Pontificia Universidad Católica de Valparaíso Facultad de Ingeniería

Escuela de Ingeniería Informática

DESARROLLO DE UN SISTEMA MULTIAGENTE PARA LA RESERVA DE LIBROS UTILIZANDO DISPOSITIVOS MÓVILES

DANILO ARMANDO SOLAR DONOSO

Profesor Guía: Claudio Cubillos Figueroa

Profesor Co-referente: Aldo Migliaro Osorio

Carrera: Ingeniería Civil en Informática

AGOSTO, 2007

iii

Dedicatoria

A mis queridos padres Guillermo Solar e Isabel Donoso, que con su esfuerzo, apoyo y amor incondicional hicieron de mí

todo lo que soy y me regalaron la maravillosa oportunidad de llegar hasta aquí.

iv

Agradecimientos

A mis compañeros, amigos y profesores que me ayudaron a recorrer este largo y difícil camino, a mi Profesor Guía por su

inagotable paciencia y apoyo y a la PUCV por darme los mejores años de mi vida.

v

Resumen

Las actuales tendencias en computación han hecho que la tecnología de agentes se convierta en una novedosa y confiable herramienta para encontrar solución a los problemas del día a día, tratando de mejorar así la calidad de vida de la personas. El paradigma de los agentes nos permite crear sistemas que pueden ofrecer servicios complejos y sofisticados a diferentes tipos de usuarios. Entre las múltiples áreas de aplicación podemos encontrar la educación, el transporte, la salud, las telecomunicaciones, el comercio. Además, el significativo incremento en el uso de dispositivos móviles en nuestra vida diaria, tales como celulares inteligentes o PDA, nos lleva a pensar en el desarrollo de sistemas que complementen y aprovechen ambas tecnologías. Luego, la necesidad actual de solicitar cualquier servicio en cualquier momento y lugar puede ser solucionada mediante el uso de un sistema multiagente como gestor del servicio y el uso de dispositivos móviles como emisores/receptores de información.

Palabras claves: sistemas multiagente, arquitectura, metodología, dispositivos móviles, plataforma.

Abstract

The current trends in computer technology have made the agent to become a new and reliable tool for finding solutions to the day to day problems, trying to improve the quality of life of the people. The paradigm of agents allows us to create systems that can offer sophisticated and complex services to different types of users. Among the many application areas we can find education, transport, health, telecommunications and trade. In addition, the significant increase in the use of mobile devices in our daily lives, such as smartphones or PDA, leads us to think about developing systems that complement and take advantage of both technologies. Then, the current need to apply for any service at any time and place can be solved through the use of a multiagent system as service manager and the use of mobile devices as emitters/receivers of information.

Keywords: multiagent systems, architecture, methodology, mobile devices, platform.

vi

ÍNDICE

Introducción....................................................................................................................... 1

1.1 Introducción....................................................................................................................... 1

1.2 Justificación del Proyecto .................................................................................................. 3

1.3 Objetivo General................................................................................................................ 5

1.4 Objetivos Específicos ........................................................................................................ 6

1.5 Organización del texto....................................................................................................... 6

Agentes y Sistemas Multiagente ....................................................................................... 8

2.1 Concepto de Agente y Características ............................................................................... 8

2.2 Sistema Multiagente ........................................................................................................ 10

2.3 Arquitecturas de Agentes................................................................................................. 12

2.4 Estándar FIPA.................................................................................................................. 16

2.5 Protocolos y Lenguajes de Comunicación....................................................................... 17

2.6 Semántica y Ontologías ................................................................................................... 23

2.7 Plataformas de Agentes ................................................................................................... 25

Dispositivos Móviles ........................................................................................................ 27

3.1 Problemática de los Dispositivos Móviles....................................................................... 27

3.2 Generalidades de los Dispositivos Móviles ..................................................................... 27

3.3 Tipos de Dispositivos Móviles ........................................................................................ 293.3.1 Teléfono móvil ......................................................................................................... 293.3.2 PDA (Personal Digital Assistant) ............................................................................. 293.3.3 Híbridos .................................................................................................................... 30

3.4 Ventajas y Desventajas de los Dispositivos Móviles....................................................... 313.4.1 Ventajas .................................................................................................................... 313.4.2 Desventajas............................................................................................................... 32

3.5 Plataformas de Desarrollo................................................................................................ 333.5.1 J2ME: Java 2 Micro Edition..................................................................................... 33

vii

3.5.2 .Net Compact Framework ........................................................................................ 40

Metodologías de Desarrollo Orientadas a Agentes....................................................... 44

4.1 MaSE ............................................................................................................................... 45

4.2 MAS-CommonKADS...................................................................................................... 47

4.3 GAIA ............................................................................................................................... 48

4.4 Eligiendo una Metodología.............................................................................................. 49

Plataformas Multiagente sobre Dispositivos Móviles .................................................. 51

5.1 LEAP ............................................................................................................................... 52

5.2 MobiAgent....................................................................................................................... 55

5.3 kSACI .............................................................................................................................. 56

5.4 MAE ................................................................................................................................ 56

5.5 AgentLight....................................................................................................................... 57

5.6 MicroFIPA-OS ................................................................................................................ 58

Casos de Estudio .............................................................................................................. 60

6.1 PalliaSys: Sistema Multiagente para Asistencia de Pacientes Terminales ...................... 62

6.2 PUMAS: Framework que Adapta la Información en Ambientes Ubicuos...................... 66

6.3 W-planner: Sistema Multiagente Online Aplicado al Turismo Electrónico .................... 69

6.4 Sistema Multiagente para la Gestión de Taxis en una Ciudad......................................... 72

Desarrollo del Sistema..................................................................................................... 76

7.1 Elecciones de Diseño....................................................................................................... 767.1.1 Caso de Estudio ........................................................................................................ 767.1.2 Plataforma Multiagente ............................................................................................ 777.1.3 Metodología de Desarrollo Orientada a Agentes ..................................................... 78

7.2 Análisis ............................................................................................................................ 787.2.1 Requerimientos del sistema...................................................................................... 797.2.2 Captura de objetivos ................................................................................................. 807.2.3 Casos de uso ............................................................................................................. 80

viii

7.2.4 Diagramas de secuencia ........................................................................................... 867.2.5 Diagrama de roles..................................................................................................... 887.2.6 Ontología .................................................................................................................. 89

7.3 Diseño.............................................................................................................................. 897.3.1 Diagrama de clases de agentes ................................................................................. 907.3.2 Diagrama de despliegue ........................................................................................... 91

7.4 Implementación ............................................................................................................... 927.4.1 Modelo de la Base de Datos ..................................................................................... 927.4.2 Acceso al Sistema..................................................................................................... 927.4.3 Descripción de las funcionalidades para Perfil Alumno........................................... 957.4.4 Descripción de las funcionalidades para Perfil Encargado....................................... 98

Conclusiones................................................................................................................... 100

Referencias ..................................................................................................................... 102

ix

ÍNDICE DE FIGURAS

Figura 2.1: Arquitectura BDI ........................................................................................ 13 Figura 2.2: Arquitectura de subsunción......................................................................... 14 Figura 2.3: Arquitectura TOURINGMACHINES ........................................................ 15 Figura 2.4: Modelo de referencia FIPA......................................................................... 16 Figura 2.5: Especificaciones de ACL............................................................................ 19 Figura 2.6: Capas del lenguaje KQML.......................................................................... 21 Figura 2.7: Estructura KQML ....................................................................................... 23 Figura 2.8: Plataformas de agentes................................................................................ 26 Figura 4.1: Metodología MaSE ..................................................................................... 46 Figura 4.2: Modelos de GAIA....................................................................................... 49 Figura 5.1: Vista de una plataforma de agentes corriendo en una máquina.................. 51 Figura 5.2: Entorno de ejecución de JADE-LEAP........................................................ 53 Figura 5.3: Modos de ejecución de JADE-LEAP.......................................................... 55 Figura 6.1: Arquitectura del sistema PalliaSys.............................................................. 63 Figura 6.2: Arquitectura de PUMAS............................................................................. 67 Figura 6.3: Agentes del Sistema W-planner.................................................................. 71 Figura 6.4: Arquitectura del sistema multiagente.......................................................... 73 Figura 7.1: Diagrama jerárquico de objetivos ............................................................... 80 Figura 7.2: Casos de uso vista Alumno ......................................................................... 81 Figura 7.3: Casos de uso vista Encargado ..................................................................... 81 Figura 7.4: Diagrama de secuencia: caso de uso Agregar libro .................................... 86 Figura 7.5: Diagrama de secuencia: caso de uso Reservar libro ................................... 86 Figura 7.6: Diagrama de secuencia: caso de uso Consultar reserva.............................. 87 Figura 7.7: Diagrama de roles ....................................................................................... 88 Figura 7.8: Diagrama de clases de agentes.................................................................... 90 Figura 7.9: Diagrama de despliegue .............................................................................. 91 Figura 7.10: Modelo de la Base de Datos........................................................................ 92 Figura 7.11: Inicialización de la aplicación y selección de perfil ................................... 93 Figura 7.12: Esperando conexión con el sistema ............................................................ 94 Figura 7.13: Ingreso de RUT y contraseña...................................................................... 95 Figura 7.14: Operaciones perfil Alumno y búsqueda de libro ........................................ 96 Figura 7.15: Ingreso de datos del libro para su búsqueda ............................................... 97 Figura 7.16: Ingreso del autor del libro para su búsqueda .............................................. 97

x

Figura 7.17: Operaciones perfil Encargado e ingreso de nuevo libro ............................. 98 Figura 7.18: Operaciones para consulta de reserva y búsqueda de alumno .................... 99

xi

ÍNDICE DE TABLAS

Tabla 2.1: Elementos de un mensaje en ACL de FIPA................................................. 19 Tabla 2.2: Parámetros reservados para las performativas KQML................................. 22

1

Capítulo 1

Introducción

1.1 Introducción

Los constantes avances tecnológicos que sufrimos en nuestra llamada sociedad de la información hacen que las realidades de las generaciones sean muy distintas unas de otras debido a la globalización del conocimiento. Hemos alcanzado una total y completa independencia del espacio y del tiempo, lo que se traduce en cambios radicales en la manera de hacer negocios, de brindar educación, entre muchos otros ejemplos de áreas que han sido revolucionadas por la tecnología. Pero no podemos olvidar que las personas somos seres sociales y como tales dependemos del contacto que tengamos con las demás personas que están a nuestro alrededor, por lo tanto la tecnología no podrá cambiarlo todo completamente.

Deseamos que los computadores realicen tareas más y más complejas para poder automatizar funciones y procesos en distintos dominios, lo que implica tener sistemas cada vez más inteligentes y a la vez, como los computadores hacen más por nosotros ya no nos es tan difícil entregarle el control de tareas que incluso son consideradas críticas. Ahora el software se modela e implementa con abstracciones de alto nivel, que reflejan más cercanamente la forma en que nosotros percibimos el mundo, y además somos capaces de colocar procesadores en cualquier aparato, dándole a estos un ilimitado potencial de sofisticación e inteligencia. La interacción se vuelve un concepto fundamental cuando hablamos de sistemas computacionales producto de las grandes ventajas que obtenemos en comparación con sistemas cerrados, pero también se hacen necesarias técnicas y herramientas que nos permitan manejar este tipo de sistemas. Estas grandes tendencias traducidas a conceptos como inteligencia, delegación, orientación a usuarios, ubicuidad, interconexión y computación global, son las que en este último tiempo han establecido los requerimientos de un sistema informático en el futuro, aunque en realidad no estamos hablando de muchos años más.

Capítulo 1: Introducción

2

Debido a lo anterior, en la actualidad nos vemos en la necesidad de construir sistemas de software capaces de efectivamente actuar por nosotros, que representen mejor nuestros intereses y que puedan cooperar y lograr acuerdos o incluso competir para lograr nuestros objetivos; estas tendencias han llevado al nacimiento de un nuevo campo: los sistemas multiagente. Esta tecnología nos permite crear sistemas que pueden ofrecer servicios complejos y sofisticados a diferentes tipos de usuarios. Entre las múltiples áreas de aplicación que podemos encontrar para los sistemas multiagente están la educación [1], el transporte [2], la salud [3], las telecomunicaciones [4], el comercio [5], entre otras.

Un sistema multiagente en términos simples es una sociedad de agentes inteligentes, los cuales interactúan para lograr los objetivos y metas para los que fueron creados. Obviamente la unidad básica de todo sistema multiagente son los agentes inteligentes, que son sistemas de software autónomos que presentan características de reactividad, es decir, capaces de percibir su ambiente y actuar en consecuencia, pro actividad lo que implica mostrar cierta iniciativa ante situaciones y habilidad social, que sería su capacidad de interactuar con los demás agentes o los usuarios. Cabe mencionar, que no existe un consenso a ciencia cierta sobre el concepto de agente, pero si sobre las características básicas anteriormente mencionadas.

En otro orden de cosas, hoy en día los dispositivos móviles como PDA’s y teléfonos celulares han ido disminuyendo sus tamaños y precios, pero incrementado su conectividad inalámbrica, poder de computación y capacidades de identificación de posición. Con mejor conectividad inalámbrica, los usuarios pueden acceder a información en diferentes ambientes. Con más poder de computación, los usuarios pueden procesar más información en sus dispositivos. Y finalmente con capacidades de identificación de posición, los usuarios son capaces de acceder a información de procesos relativa a su localización física. Pero como más y más información y servicios están disponibles, las personas podrían encontrar dificultades para obtener oportunamente la información y servicios de acuerdo a sus gustos y a su localización física. Este problema llega a ser más serio en el caso de dispositivos móviles donde las capacidades de entrada son usualmente limitadas y torpes, y el costo de la conexión es alto.

Debido a lo anterior y al significativo incremento que ha alcanzado el uso de dispositivos móviles en nuestra vida diaria, tales como teléfonos celulares, PDA’s o Smartphones, es lo que nos lleva a pensar en el desarrollo de sistemas que complementen y aprovechen tanto la tecnología de agentes como la de dispositivos móviles. Luego, la


3

necesidad actual de solicitar cualquier servicio en cualquier momento y lugar puede ser solucionada mediante el uso de un sistema multiagente como gestor del servicio y el uso de dispositivos móviles como emisores y/o receptores de información. Es por esto que el presente Proyecto tiene como propuesta el desarrollo de un sistema multiagente en base a un caso de estudio a determinar que permita brindar una serie de servicios relativos al campo de aplicación y que a la vez pueda ser accedido desde dispositivos móviles como teléfonos celulares que posean tecnología Java o PDA’s.

Por otra parte, el desarrollo de este sistema multiagente implica también el uso de una de las diversas metodologías existentes para el desarrollo de sistemas multiagente, en las que no existe un estándar establecido lo que no es un problema menor por lo que será necesario hacer un análisis de las ventajas y desventajas de algunas de éstas para elegir la más conveniente según el problema a resolver, y además no cubren necesariamente todas las etapas del desarrollo de software que conocemos comúnmente. Estas metodologías pasan a formar parte de la llamada Ingeniería de Software Orientada a Agentes (AOSE) que busca la obtención de un estándar en particular para el desarrollo de este tipo de sistemas basados en agentes.

Para el desarrollo e implementación de estos sistemas basados en agentes existen numerosas herramientas, entre las que se encuentra la plataforma JADE-LEAP [6] escrita totalmente en Java. Utilizando una plataforma como JADE-LEAP, podemos tener agentes ejecutándose en nuestro teléfono móvil o PDA que tiene recursos limitados, dándonos la capacidad de implementar sistemas flexibles, autónomos, abiertos, distribuidos y confiables. Esta es una característica importante de la plataforma considerando el uso de dispositivos móviles dentro del acceso al sistema.

1.2 Justificación del Proyecto

En la era en la que vivimos, las personas están exigiendo maneras rápidas, fiables, baratas, amistosas y flexibles de acceder a cualquier tipo de información. Es más, quieren poder conseguir esta información desde cualquier lugar, en cualquier momento, usando las últimas tecnologías desarrolladas en el campo de las TIC’s (Tecnologías de Información y Comunicación), como teléfonos móviles, PC’s portátiles o PDA’s (Personal Digital


4

Assistants). La tendencia actual parece ir en la dirección de unir estas herramientas en una única pieza de hardware con múltiples capacidades.

Se ha argumentado en los últimos años que los agentes inteligentes [7] tienen una serie de propiedades que los hacen muy adecuados para proporcionar servicios a las personas. Entre estas características podemos destacar las siguientes:

Autonomía: pueden realizar sus tareas sin una guía directa y continua del usuario.

Aprendizaje: pueden aplicar técnicas de aprendizaje de máquina para construir automáticamente un perfil del usuario y adaptar sus acciones a las preferencias del usuario.

Pro actividad: un agente personal puede anticiparse a las necesidades del usuario y puede realizar tareas que pueden ser beneficiosas para él, sin una solicitud explícita del usuario.

Habilidad Social: un agente personal puede ponerse en contacto con otros agentes que proporcionan información sobre cualquier dominio en que el usuario pueda estar interesado (restaurantes, cines, eventos turísticos, centros médicos, etc.), pedir la información que el usuario necesita y presentarla de una manera amistosa y personalizada.

Es debido a lo anterior, que nace la idea de realizar el siguiente tema de Proyecto que consiste en implementar un sistema de software basado en agentes que permita el uso de dispositivos móviles, ofreciendo servicios dentro de un cierto dominio a determinar. En particular el dominio a seleccionar será en base a lo investigado sobre agentes y dispositivos móviles, ya sea su uso en conjunto o por separado.

El concepto de agente constituye una potente herramienta de abstracción en el desarrollo de software, que facilita la construcción de sistemas distribuidos, inteligentes y robustos. En general, la solución de problemas complejos se lleva a cabo por un conjunto de agentes que interactúan entre ellos para alcanzar los objetivos del sistema. La utilización de varios agentes representa de forma natural la descentralización del sistema y enfatiza la comunicación para gestionar las dependencias entre ellos.


5

No es ninguna sorpresa entonces que las aplicaciones multiagente intenten resolver los mismos problemas que las aplicaciones para dispositivos móviles. Algunos problemas son cómo realizar la interacción entre las diversas entidades en el sistema, cómo adaptarse a nuevas situaciones. El ambiente de los dispositivos móviles es muy dinámico y abierto, éstos pueden entrar o salir en cualquier momento. La investigación de sistemas multiagente también está interesada en el modelamiento de sistemas abiertos: qué procedimientos de verificación se necesitan, cómo asegurar el descubrimiento de servicios [31].

Está claro que los agentes tienen características deseables para los dispositivos móviles. Claro, una aplicación para dispositivos móviles puede crearse sin la tecnología multiagente, pero usándola, uno puede tomar ventaja de las metodologías y soluciones proporcionadas por el paradigma multiagente. No se debe olvidar la reutilización: un sistema multiagente creado para un problema específico puede ser fácilmente usado para resolver otro. En otras palabras, usar agentes en dispositivos móviles no es la única perspectiva de resolver el problema, pero podría probar ser mejor que otras.

Para finalizar, se debe distinguir entre dos conceptos: agentes para dispositivos móviles y agentes móviles. El Proyecto busca el desarrollo de una aplicación basada en agentes que permita que estos agentes puedan ejecutarse en dispositivos móviles, lo que exige que la correspondiente plataforma de agentes sea desplegada en tales dispositivos con las restricciones que les conocemos. Por otra parte, el paradigma de agentes móviles [8] consiste en utilizar agentes que tienen la capacidad de dejar sus nodos de origen y moverse a través de los distintos nodos intermedios de una red para poder cumplir sus tareas, teniendo la posibilidad de regresar nuevamente a su origen.

1.3 Objetivo General

Desarrollar una aplicación basada en el paradigma de agentes que permita realizar la reserva de libros en una biblioteca y que pueda ser accedida mediante dispositivos móviles.

Para alcanzar este objetivo general será necesario llevar a cabo los objetivos específicos que se presentan a continuación.


6

1.4 Objetivos Específicos

Comprender el paradigma de agentes y su implementación para dispositivos limitados.

Establecer el proceso, las herramientas y las metodologías involucradas en el desarrollo de aplicaciones basadas en agentes y dispositivos móviles.

Diseñar un sistema multiagente de reserva de libros para dispositivos móviles.

Demostrar la viabilidad de la propuesta mediante la implementación de un prototipo usando la plataforma JADE-LEAP.

1.5 Organización del texto

La organización de la presente memoria de título se divide en capítulos de la siguiente manera:

En el CAPÍTULO 2 se presenta una introducción al tema comenzando por una descripción de lo que significan los sistemas multiagente, sus características y los diferentes elementos que los componen.

En el CAPÍTULO 3 se realiza un estudio teórico para conocer y entender cada una de las ventajas y características que poseen los dispositivos móviles, además de sus requerimientos de implementación para idear un buen funcionamiento en una aplicación.

El uso de metodologías de desarrollo orientado a agentes junto con sus respectivos alcances es abordado en el CAPÍTULO 4. En este capítulo también se describe la forma de elegir una metodología que sirva de guía para una futura implementación.

En el CAPÍTULO 5 se ahonda en las plataformas multiagente que permiten la ejecución de los agentes en los distintos dispositivos móviles disponibles, además de identificar las características más relevantes de cada una.


7

En el CAPÍTULO 6 se detallan diferentes casos de estudio que involucran la tecnología multiagente y el uso de dispositivos móviles para la entrega de servicios en diferentes áreas de aplicación.

Finalmente en el CAPÍTULO 7 se presenta en detalle la implementación realizada y las decisiones adoptadas para la creación de la aplicación presentada. Se especifica el desarrollo del prototipo implementado en base a la metodología y plataforma seleccionadas.

8

Capítulo 2

Agentes y Sistemas Multiagente

2.1 Concepto de Agente y Características

El término agente es cada vez más conocido y se emplea en campos tan diversos como Internet, sistemas distribuidos o inteligencia artificial. El campo de los agentes ha atraído a personas procedentes de áreas muy dispares: psicología, sociología, ingeniería del software, inteligencia artificial, etc. y cada una de ellas tiende a ver el problema desde su perspectiva [21]. Por lo tanto, realizar una definición de agente es complicado, debido a la diversidad de opiniones que existen en la comunidad científica sobre este tema [22]. En las varias definiciones encontradas, podemos identificar similitud de conceptos entre ellas, ya que algunas enfatizan las mismas características; sin embargo, otras agregan nuevas características o extienden definiciones anteriores.

Definición de Maes: “Los Agentes autónomos son sistemas computacionales que habitan en algún ambiente dinámico complejo, monitorean y actúan de forma autónoma en este ambiente, y realizando esto logran un conjunto de objetivos o tareas para los cuales están diseñados”. En esta definición el ambiente tiene características de dinamismo y complejidad, el agente actúa en forma autónoma y mantiene una serie de propósitos (tareas y objetivos).

Definición de Hayes-Roth: “Los agentes inteligentes continuamente realizan tres funciones: percepción de condiciones dinámicas en el ambiente; acción para afectar condiciones en el ambiente; y razonamiento para interpretar las percepciones, resolver problemas, realizar inferencias, y determinar acciones”. En esta definición el comportamiento del agente para lograr acciones se presenta con mayor detalle, como una serie de pasos a seguir: monitorear eventos, razonar sobre los mismos, inferir posibles acciones y finalmente ejecución de la acción.

Capítulo 2: Agentes y Sistemas Multiagente

9

Por último, la definición de Smith (el agente KidSim), introduce un nuevo componente: la persistencia. “Definamos un agente como una entidad software persistente dedicada a un propósito específico. ‘Persistente’ distingue a un agente de las subrutinas; los agentes tienen sus propias ideas acerca de cómo cumplir las tareas, su propia agenda. ‘Propósito específico’ los distingue de todas las aplicaciones multifunción; los agentes son típicamente más pequeños”.

Luego de la revisión de varias de definiciones existentes, nos quedaremos con la que puede ser considerada como la más clara y completa. Un agente es un sistema informático, situado en algún entorno, dentro del cual actúa de forma autónoma y flexible para así cumplir sus objetivos. Además de la interacción con el medio, un agente se caracteriza, utilizando la definición de [23], por las siguientes propiedades:

Autonomía: tiene la capacidad de actuar sin intervención humana directa o de otros agentes. Habilidad Social: capacidad de interactuar con otros agentes, utilizando como medio algún lenguaje de comunicación entre agentes. Reactividad: un agente está inmerso en un determinado entorno (hábitat), del que percibe estímulos y ante los que debe reaccionar en un tiempo preestablecido. Pro actividad: un agente no sólo debe reaccionar a los cambios que se produzcan en su entorno, sino que ha de tener un carácter emprendedor y tomar la iniciativa para actuar guiado por los objetivos que debe satisfacer.

La cuestión de qué es un agente, como hemos dicho, está aún siendo debatida, corriendo el riesgo de que cualquier programa sea denominado agente. Se pueden distinguir dos nociones extremas de agentes:

Una noción débil de agente consiste en definir un agente como a una entidad que es capaz de intercambiar mensajes utilizando un lenguaje de comunicación de agentes. Esta definición es la más utilizada dentro de la ingeniería software basada en agentes, cuyo fin es conseguir la interoperabilidad entre aplicaciones a nivel semántico utilizando la emergente tecnología de agentes. Esta noción propone las características anteriormente mencionadas. Una noción más fuerte o restrictiva de agente es la enunciada por Shoham [24] en su propuesta de programación orientada a agentes (AOP), donde un agente se define como una entidad cuyo estado es visto como un conjunto de componentes mentales,


10

tales como creencias, capacidades, elecciones y acuerdos. Las características añadidas son las siguientes:

Movilidad: capacidad del agente para moverse a través de una red electrónica. Veracidad: la seguridad de que el agente no transmitirá información falsa conscientemente. Benevolencia: se asume que el agente hará aquello para lo que se creó. Racionalidad: se asume que el agente intentará alcanzar las metas que le fueron asignadas de la mejor forma posible, basándose en la información que posee del mundo exterior.

La noción fuerte de agente está más cercana al mundo de la Ingeniería del Conocimiento, y es por tanto la más aceptada dentro de dicho campo.

2.2 Sistema Multiagente

La Inteligencia Artificial (IA) se ocupa de la creación de sistemas computacionales aislados capaces de resolver un problema por métodos basados en el conocimiento, en la planificación, en algoritmos de búsqueda, en el aprendizaje, etc. En estos sistemas la solución se alcanza con poca o ninguna interacción con otros sistemas. Sin embargo, los grandes avances en la tecnología tanto del hardware como del software abrieron una nueva perspectiva a los investigadores de la IA [25]. Estos avances incluyen la introducción de concurrencia en máquinas paralelas y la posibilidad de distribuir los recursos computacionales a través de redes de computadores. Estos avances tecnológicos, apoyados por la observación de que los problemas del mundo real implican colaboración entre personas, permitieron la expansión de una nueva "y más poderosa, estrategia extensible para sobrepasar los límites inherentes a la inteligencia presente en cualquier sistema individual de IA o en cualquier sistema natural" [26]. Esto significó la aparición en los años 80 de la Inteligencia Artificial Distribuida (IAD) [27].

La IAD se encarga del estudio y la definición de sistemas computacionales semi-autónomos así como de las técnicas para su coordinación inteligente. La IAD se preocupa de formar un grupo de sistemas/agentes que permita superar las limitaciones individuales


11

de recursos y conocimientos. Más aún, bajo ciertas condiciones particulares, el rendimiento resultante del grupo puede ser mayor que la suma de los rendimientos individuales, por lo que un grupo de sistemas/agentes puede realizar tareas que un sistema individual no podría. La IAD es en realidad una disciplina diversa y cambiante, quizá por su naturaleza multidisciplinaria.

Es importante distinguir la diferencia entre un sistema basado en agentes y un sistema multiagente [28]. Un sistema basado en agentes es aquel que utiliza el concepto de agente como mecanismo de abstracción, pero aunque sea modelado en términos de agentes podría ser implementado sin ninguna estructura de software correspondiente a éstos. Por otro lado, un sistema multiagente es aquel que se diseña e implementa pensando en que estará compuesto por varios agentes que interactuarán entre sí, de forma que juntos permitan alcanzar la funcionalidad deseada [29]. Los sistemas multiagente son adecuados para solucionar problemas para los que hay múltiples métodos de resolución y/o múltiples entidades capaces de trabajar conjuntamente para solucionarlos. Por ello, uno de los aspectos básicos en estos sistemas es la interacción entre los diferentes agentes que los forman, la definición de modelos concretos de cooperación, coordinación o negociación entre los agentes.

Pero, ¿cuáles son las razones que han despertado tanto interés por los sistemas multiagente? En primer lugar, los sistemas multiagente son una metáfora natural para el modelado de gran cantidad de dominios, donde aparecen una serie de componentes que interaccionan. En segundo lugar, los sistemas multiagente permiten la distribución de forma natural tanto de los datos como del control de ejecución. En tercer lugar, los sistemas multiagente permiten integrar de forma sencilla sistemas heredados (legacy systems), es decir, sistemas que aún siendo obsoletos, deben seguir funcionando por razones de necesidad. Dichos sistemas pueden ser encapsulados dentro de un agente, e integrados dentro del sistema multiagente manteniendo toda la funcionalidad necesaria. Finalmente, este tipo de sistemas permiten crear sistemas abiertos donde no se conozca en tiempo de diseño los componentes exactos que tendrá el sistema, sino que éstos se unirán al sistema en tiempo de ejecución interactuando con el sistema.


12

2.3 Arquitecturas de Agentes

Una arquitectura define los mecanismos que permiten interconectar los componentes tanto software como hardware, que hacen que un agente se comporte como tal. En este sentido, un hecho evidente hoy en día es que existen infinidad de propuestas, casi tantas como equipos de investigación centrados en el tema.

Las arquitecturas utilizadas para construir agentes, especifican como se descomponen los agentes en un conjunto de módulos que interactúan entre sí para lograr la funcionalidad requerida. Uno de los aspectos básicos que diferencia una arquitectura de otra es el método de descomposición del trabajo en tareas particulares. La planificación es un área fuertemente ligada a los agentes. Esta área se centra en el estudio de mecanismos que permitan organizar la ejecución de acciones, y un agente no es más que un sistema que ejecuta acciones en un entorno determinado.

Los sistemas de planificación utilizan modelos de representación del conocimiento y razonamiento de tipo simbólico, y su modo de actuación está definido por la necesidad de satisfacer unos objetivos básicos, para lo que elaboran un plan. Estos sistemas presentan la desventaja de que tienen un elevado tiempo de respuesta. Éste es un gran inconveniente cuando se utilizan en problemas de tiempo real, ya que los algoritmos de planificación no siempre responden en un tiempo prudencial a las demandas del sistema, lo que hace que no constituyan una opción del todo viable para los agentes. Dichas críticas, dirigidas fundamentalmente hacia el modelo simbólico utilizado, llevaron a la búsqueda de alternativas que utilizasen otro modelo de representación o razonamiento, como los reactivos o híbridos.

A continuación se presentan tres arquitecturas diferentes que se diferencian en el modelo de razonamiento que utilizan [23]:

Deliberativas. Son aquellas arquitecturas que utilizan modelos de representación simbólica del conocimiento. Suelen estar basadas en la teoría clásica de planificación, se parte de un estado inicial, existe un conjunto de planes y un estado objetivo a satisfacer. En estos sistemas parece aceptada la idea de que es necesario dotar a los agentes de un sistema de planificación que se encargue de determinar qué pasos se deben llevar a cabo para conseguir sus objetivos. Por tanto, un agente


13

deliberativo (o con una arquitectura deliberativa) es aquél que contiene un modelo simbólico del mundo, explícitamente representado, en donde las decisiones se toman utilizando mecanismos de razonamiento lógico basados en la concordancia de patrones y la manipulación simbólica. Cuando se decide implantar una arquitectura deliberativa hay que buscar, en primer lugar, una descripción simbólica adecuada del problema, e integrarla en el agente, para que éste pueda razonar y llevar a cabo las tareas encomendadas en el tiempo preestablecido. Aunque parece una cuestión trivial, debido a la complejidad de los algoritmos de manipulación simbólica, es un aspecto al que hay que prestar mucha atención, especialmente si se tiene en cuenta que los agentes se desenvuelven en dominios reales, en los que tienen que responder a los estímulos en tiempo real. Por ejemplo, un agente intencional puede implementarse utilizando una arquitectura deliberativa. Los agentes intencionales son sistemas de planificación en los que para definir los planes se tienen en cuenta sus creencias e intenciones, de forma que el agente puede utilizar sus creencias e intenciones para razonar. Dentro de estas arquitecturas intencionales cabe destacar aquéllas que basan su implementación en el modelo BDI (Belief, Desire, Intention). Éste es uno de los modelos más utilizados hoy en día, véase figura 2.1.

Figura 2.1: Arquitectura BDI

Reactivas. Los numerosos problemas que lleva asociado utilizar una representación simbólica del conocimiento, han conducido al estudio de modelos más efectivos de representación del conocimiento. Las arquitecturas reactivas se caracterizan por no tener como elemento central de razonamiento un modelo simbólico, y por no utilizar razonamiento simbólico complejo. Un ejemplo típico de estas arquitecturas es la propuesta de Roodney Brooks, conocida como arquitectura de subsunción,


14

véase figura 2.2. Esta arquitectura se basa en el hecho de que se puede generar un comportamiento inteligente sin utilizar propuestas del modelo simbólico, y en el hecho de que la inteligencia es una propiedad emergente de ciertos sistemas complejos. Las arquitecturas de subsunción manejan jerarquías de tareas que definen un comportamiento. Suelen estar organizadas en jerarquías de capas, de menor a mayor nivel de abstracción. La mayor aplicación de este tipo de arquitecturas se ha centrado en el desarrollo de controladores en robótica. Los robots se pueden considerar como agentes reales (no software) que actúan en un entorno cambiante. Precisamente, la necesidad de actuar en un entorno impredecible y altamente cambiante dificulta la adopción de una arquitectura deliberativa, ya que las necesidades de replanificación y de continua adaptación del plan a la realidad hace inútil dicha arquitectura.

Figura 2.2: Arquitectura de subsunción

Híbridas. Dado que algunos investigadores opinan que para la construcción de agentes no es del todo acertado utilizar una arquitectura totalmente deliberativa, o totalmente reactiva, se han propuesto sistemas híbridos que pretenden combinar aspectos de ambos modelos. Una primera propuesta puede ser construir un agente compuesto de dos subsistemas: uno deliberativo, que utilice un modelo simbólico y que genere planes en el sentido expuesto anteriormente, y otro reactivo, centrado en reaccionar a los eventos que tengan lugar en el entorno y que no requiera un mecanismo de razonamiento complejo. Por su propia naturaleza, estas arquitecturas son propicias para una estructuración por capas, que puede ser: (a) vertical, sólo una capa tiene acceso a los sensores y actuadores; (b) horizontal, todas las capas tienen acceso a los sensores y a los actuadores. De la misma forma que las arquitecturas de


15

subsunción, las capas se organizan jerárquicamente con información sobre el entorno a diferentes niveles de abstracción. La mayoría de las arquitecturas encuentran suficiente tres niveles: (a) reactivo o de más bajo nivel, se toman decisiones acerca de que hacer en base a los estímulos recibidos del entorno en tiempo real. Suele estar implementado como arquitecturas de subsunción; (b) conocimiento: nivel intermedio, se olvida de los datos que recopila el agente y se centra en el conocimiento que él posee del medio, normalmente con la ayuda de una representación simbólica del medio; y (c) social: la capa de más alto nivel, maneja aspectos sociales del entorno, incluyendo tanto información de otros agentes, como deseos, intenciones, etc. El comportamiento global del agente viene definido por la interacción entre estos niveles. Esta interacción cambia de una arquitectura a otra. Uno de estos ejemplos es la arquitectura TOURINGMACHINES, donde cada nivel está continuamente sugiriendo qué acción realizar y existe un sistema de control para garantizar el correcto funcionamiento del agente, véase figura 2.3. La arquitectura INTERRAP también actúa del mismo modo.

Figura 2.3: Arquitectura TOURINGMACHINES

La arquitectura BDI (Belief, Desire, Intention) en la cual los agentes que la implementan poseen estados mentales de Creencias, Deseos e Intenciones ha sido el modelo más difundido y estudiado dentro de los modelos de razonamiento de agentes. Hay varias razones para esto, pero la más convincente es que el modelo BDI combina elementos interesantes: un apreciable modelo filosófico de razonamiento humano fácil de comprender,


16

un número considerable de implementaciones, como por ejemplo sistemas de control de procesos, procesos de decisión en negocios, etc. y el desarrollo de una semántica lógica abstracta y elegante, la cual ha sido aceptada por la comunidad científica.

2.4 Estándar FIPA

Foundation for Intelligent Physical Agents (FIPA) comenzó sus actividades en 1995 con el objetivo de estandarizar aspectos relacionados con la tecnología de agentes y sistemas multiagente. En la actualidad se puede considerar el estándar mas ampliamente reconocido y extendido internacionalmente, y se ha convertido en un referente a seguir a la hora de realizar desarrollos basados en agentes.

Las especificaciones FIPA se han agrupado en tres tipos: component, que se encargan de estandarizar todas las tecnologías básicas relacionadas con agentes, informative que describen posibles soluciones en aplicaciones realizadas con agentes en un determinado dominio y profiles que son conjuntos de especificaciones de tipo component que permiten validar cuando una implementación está conforme al estándar.

Figura 2.4: Modelo de referencia FIPA

En FIPA Agent Management Specification se describe el modelo de referencia FIPA de plataforma de agentes y se describe la funcionalidad de cada uno de sus componentes, ver figura 2.4. Estos componentes son:


17

Agent Management System (AMS): que gestiona el ciclo de vida de los agentes, los recursos locales, y los canales de comunicación y proporciona un servicio de páginas blancas, que permite localizar agentes por su nombre. Directory Facilitator (DF): que proporciona un servicio de páginas amarillas, que permite localizar agentes por sus capacidades y no por su nombre. Message Transport System (MTS): que gestiona el envío de mensajes entre agentes de la misma plataforma o de plataformas distintas, y permite la migración de agentes.

2.5 Protocolos y Lenguajes de Comunicación

Los protocolos de comunicación están normalmente especificados en diferentes niveles. El nivel inferior del protocolo especifica el método de interconexión; el nivel medio especifica el formato o sintaxis de la información que es transferida; el nivel superior especifica el significado o semántica de la información. La semántica no solo se refiere a la esencia del mensaje, sino también al tipo de mensaje.

Existen protocolos de comunicación binarios y n-arios. Un protocolo binario involucra a un único emisor y a un único receptor, mientras que un protocolo n-ario involucra a un único emisor y a múltiples receptores (llamado “broadcasting” o “multicasting”). Un protocolo está especificado por una estructura de datos con los siguientes cinco campos: Emisor, Receptor (o receptores), Lenguaje en el protocolo, Funciones de codificación y decodificación, Acciones realizadas por el receptor o los receptores.

Una decisión fundamental para la interacción de agentes es separar la semántica del protocolo de comunicación (independiente del dominio) de la semántica del mensaje encapsulado (dependiente del dominio). El protocolo de comunicaciones debe ser conocido por todos los agentes. Debe ser conciso y tener un número limitado de actos de comunicación primitivos.

Lo anterior sugiere la necesidad de un lenguaje que permita la intercomunicación entre nuestros agentes autónomos distribuidos (ACL “Agent Communication Language”). Existen principalmente dos propuestas que se están convirtiendo en especificaciones


18

estándares que siguen la mayoría de sistemas de desarrollo de agentes. Una de ellas está basada en la utilización del lenguaje de comunicación KQML. Por otro lado hay otro grupo de investigadores que siguen las descripciones dadas por la organización FIPA. Veamos con más detalle estas propuestas.

Especificaciones FIPA

FIPA (“Foundation for Intelligent Physical Agents”) fue creada para producir software estándar para sistemas basados en agentes, heterogéneos e interactuando entre ellos. FIPA ha elaborado una serie de especificaciones que pueden ser usadas para el desarrollo de sistemas basados en agentes.

Las distintas especificaciones FIPA van progresando a través de un ciclo de vida, desde un estado preliminar (borrador en construcción cuyo identificador empieza por P), experimental (especificación estable que sólo admite pequeños cambios, cuyo identificador empieza por X) hasta el estado estándar (especificación implementada con éxito en varias plataformas; su identificador empieza por S). Cualquier especificación puede ser reprobada (el identificador empieza con D), previo al estado de obsoleta (su identificador empieza por O), cuando se considera innecesaria por cambios en la tecnología o en otras especificaciones y ha quedado por tanto obsoleta.

Las especificaciones FIPA se pueden organizar en cinco materias, según el dominio de agentes al que va dirigido: Aplicaciones, Arquitecturas Abstractas, Comunicación entre Agentes, Gestión de Agentes, Transporte de Mensajes de los Agentes.

Nos centramos únicamente en las especificaciones referentes a los mensajes escritos en un Lenguaje de Comunicación entre Agentes. Estas a su vez están organizadas en Protocolos de Interacción para el intercambio de mensajes, Actos Comunicativos basados en la teoría de los actos de habla y Lenguajes de Contenido, ver figura 2.5.


19

Figura 2.5: Especificaciones de ACL

Cada mensaje tiene una estructura prefijada que está formada de una serie de parámetros. La utilización de estos parámetros está sujeta a las necesidades requeridas por el mensaje. Los parámetros o campos (slots) se han clasificado en diferentes categorías según su función. Ver tabla 2.1, allí se describen cuales son y a que categoría pertenecen:

Tabla 2.1: Elementos de un mensaje en ACL de FIPA

FIPA propone distintas especificaciones para representar el contenido de los mensajes en distintos lenguajes: SL (“Semantic Language”), CCL (“Constraint Choice Language”), KIF (“Knowledge Interchange Format”) y RDF (“Resource Descripction Framework”).


20

Especificaciones KQML

KQML (“Knowledge Query and Manipulation Language”) es un lenguaje y protocolo para el intercambio de información y conocimiento, surgido de los trabajos para el desarrollo de técnicas y metodologías para la construcción de bases de conocimiento a gran escala que sean compartidas y reusables. La sintaxis de KQML consiste en una notación en forma de listas de paréntesis balanceados (similar a LISP). KQML es un lenguaje basado en la teoría de actos de habla. Fue concebido como un formato de mensajes y como un protocolo que maneja los mensajes para permitir a un programa identificar, conectarse e intercambiar información con otros programas. En términos lingüísticos se puede decir que KQML se enfoca principalmente a la parte pragmática de la comunicación. Puede ser usado como un lenguaje para programas de aplicación que interactúen con un sistema inteligente o para dos o más sistemas inteligentes que compartan conocimiento en la resolución cooperativa de problemas. Y, de momento, es uno de los modelos para comunicaciones entre agentes más usado.

Tres características importantes de KQML son:

Los mensajes de KQML son opacos al contenido de lo que transportan, esto es, los mensajes en KQML no comunican únicamente oraciones en un lenguaje, sino que comunican una actitud acerca del contenido (por ejemplo, afirmación, solicitud, pregunta). Las primitivas del lenguaje, que se llaman performativas, indican las acciones u operaciones permitidas que los agentes pueden utilizar cuando se comunican (actos de habla). El entorno en el que los agentes se comunican con KQML puede ser enriquecido con un tipo de agentes especiales llamados facilitadores, que son una clase especial de agentes que coordinan las interacciones entre los otros agentes.

KQML es un lenguaje que se divide en tres capas o niveles en los cuales codifica la información (ver figura 2.6):

La capa de contenido se relaciona con el contenido real del mensaje escrito en el lenguaje de representación propio de cada agente. Un mensaje en KQML puede tener cualquier lenguaje de representación incluyendo lenguajes expresados como cadenas en ASCII y aquellos expresados utilizando una notación binaria. Cualquier


21

implementación de KQML ignora la parte del contenido del mensaje excepto para determinar dónde termina.

La capa de comunicación codifica un conjunto de características del mensaje, las cuales describen los parámetros de la comunicación de bajo nivel, tales como la identidad del agente que envía el mensaje y la del que lo recibe, así como un identificador único asociado con la comunicación.

La capa de mensaje se utiliza para codificar el mensaje que una aplicación desea transmitir a otra. Esta capa forma el corazón del lenguaje y determina las clases de interacciones que se pueden tener con un agente que hable KQML. La función principal de la capa de mensaje es identificar el protocolo que se va a usar para entregar el mensaje (síncrono o asíncrono) y proporcionar una performativa que el transmisor le agrega al contenido. Además de esto, ya que el contenido es opaco a KQML, en esta capa también se incluyen características opcionales que describen el lenguaje del contenido, la ontología que se está asumiendo y alguna clase de descripción del contenido. Estas características hacen posible que las implementaciones de KQML analicen, redirijan y entreguen el mensaje apropiadamente aún cuando su contenido sea inaccesible.

Figura 2.6: Capas del lenguaje KQML

Todo mensaje en KQML se inicia con una directiva de comunicación (performativa o expresión realizativa) que indica el tipo de comunicación y un conjunto de argumentos


22

opcionales, llamados parámetros, entre los que se encuentra el contenido real del mensaje así como otros que describen el propio contenido.

Existe un conjunto de performativas estándar con un significado al que toda implementación de KQML debe adherirse. Estas performativas estándar se dividen en tres grupos:

Las performativas de discurso (ask-if, ask-all, ask-one, tell, deny, achieve, advertise, subscribe, entre otras), empleadas en el contexto de un intercambio de información y conocimiento entre dos agentes. Las performativas de intervención y mecánica de la conversación (error, sorry, ready, next, discard, rest, standby), cuyo papel es intervenir en el curso normal de una conversación. Las performativas de red y de facilitación (register, forward, broadcast, recommend-one, recruit-all, entre otras), los cuales, estrictamente hablando no son actos del habla, pero permiten a los agentes encontrar otros agentes capaces de procesar sus mensajes.

Los nombres de los parámetros empiezan con ":" y deben estar seguidos por el correspondiente valor del parámetro. Los posibles parámetros con su correspondiente descripción se pueden ver en la tabla 2.2.

Tabla 2.2: Parámetros reservados para las performativas KQML


23

El protocolo básico está definido por la siguiente estructura, ver figura 2.7.

Figura 2.7: Estructura KQML

Intuitivamente, podemos decir que cada mensaje en KQML es una pieza de diálogo entre emisor y receptor, y KQML proporciona el soporte para una amplia variedad de tipos de diálogos. El conjunto de performativas es extensible y no todas son necesarias. Un agente puede elegir manejar sólo unas pocas performativas de las descritas, e incluso implementar algunas adicionales. Sin embargo, cualquier implementación de las performativas reservadas debe ser utilizada de la manera descrita.

2.6 Semántica y Ontologías

El objetivo de la ontología es el estudio de todas las clases de entidades que conforman nuestro mundo, de la existencia en sí. Así, llamaremos una ontología a un catálogo de los tipos de cosas que asumimos que existen en un domino de interés, desde la perspectiva de una persona que usa un lenguaje con el propósito de hablar acerca de ese dominio. Aunque el término procede de la Filosofía (ontología: parte de la filosofía que estudia el ente en cuanto tal), en los últimos tiempos ha sido reutilizado en el campo de la Inteligencia Artificial y en concreto en los Sistemas Multiagente. Así podemos definir la ontología como:

Una ontología define los términos y relaciones básicas que forman parte del vocabulario de una determinada área, así como las reglas para combinar términos y relaciones para definir extensiones del vocabulario


24

Los elementos de una ontología son:

Conceptos: cualquier cosa sobre la que podamos emitir un juicio o comentario. Relaciones: representan diferentes tipos de interacción entre conceptos del dominio. Funciones: son un caso especial de relaciones. Instancias: representan cada uno de los elementos. Axiomas: sentencias que son siempre verdaderas en ese dominio.

Las dos principales fuentes de categorías ontológicas son: la observación, que proporciona conocimiento del mundo físico; y el razonamiento, que da sentido a las observaciones generando un marco de abstracción llamado metafísica.

La ontología define las clases de cosas que existen en el dominio de aplicación, evitando que los términos y símbolos estén mal definidos o sean confusos. La elección de las categorías ontológicas es el primer paso en el diseño de una base de conocimiento. Esta selección de categorías determinará todas las cosas que pueden ser representadas en nuestro sistema de agentes. Un agente debe representar sus conocimientos en el vocabulario de una ontología específica. El creador del agente debe utilizar una ontología específica para representar el conocimiento del agente.

El vocabulario del lenguaje empleado por los agentes para comunicarse consiste en un diccionario de palabras apropiado para áreas de aplicación comunes. Cada palabra en el diccionario tiene una descripción (escrita en lenguaje natural) que es usada por las personas para entender su significado y una anotación formal (por ejemplo, escrita en KIF) que es usada por los programas. El diccionario es abierto, es decir, es posible añadir nuevas palabras dentro de áreas existentes y en nuevas áreas de aplicación. La existencia de este diccionario no significa que solamente hay una manera de describir un área de aplicación. Un diccionario puede contener múltiples ontologías para un área dada y un agente puede utilizar la ontología que le sea más conveniente. Las definiciones formales asociadas con cualquiera de estas ontologías pueden ser utilizadas por los agentes para traducir mensajes que usan una ontología en específico a mensajes que usan otras ontologías. Cuando se comparte información en una comunidad se debe tener un acuerdo sobre el significado de los símbolos. Si esta comunidad es pequeña es posible que todos los objetos que se comunican utilicen un vocabulario único. Sin embargo, si la comunidad es extensa, es muy posible que sea necesario soportar una colección de vocabularios.


25

2.7 Plataformas de Agentes

Los agentes requieren un entorno especial para su ejecución, este entorno es lo que se denomina plataforma. La plataforma además de aportar la capacidad de ejecución, debe proporcionar una serie de servicios básicos:

Comunicaciones: que facilite la comunicación de los agentes con el mundo exterior, principalmente, que le permitan interactuar con otros agentes en tareas cooperativas.

Nombrado: que permite nombrar a los agentes de manera que puedan ser identificados de forma unívoca, y también nombrar a las plataformas a las que migran los agentes.

Descubrimiento y localización: que facilite a los agentes descubrir otros agentes y plataformas con los que puede interactuar, o a las que puede migrar, para alcanzar los objetivos que tiene encomendados.

Movilidad: que facilite la migración de agentes entre plataformas remotas.

Seguridad: que garantice por una parte la protección de los agentes ante ataques del host en el que se ejecuta y por otra, la protección del host ante los ataques de los agentes que se ejecuten en el.

Casi todas las plataformas (ver figura 2.8) desarrolladas recientemente son en Java, debido a las siguientes ventajas aportadas por el lenguaje: independencia de la plataforma, ejecución segura, carga dinámica de clases, programación multihilo, serialización de objetos, y reflexión.


26

Figura 2.8: Plataformas de agentes

27

Capítulo 3

Dispositivos Móviles

3.1 Problemática de los Dispositivos Móviles

Si pensamos en algún dispositivo móvil, lo primero en lo que pensamos es en un teléfono móvil, y como mucho en una PDA. Pero en la actualidad son varios los dispositivos móviles disponibles en el mercado. Este es el caso de los PC's portátiles, de los teléfonos con acceso a Internet, PocketPC's, etc.

Este hecho da lugar a una importante problemática para quien programa tales dispositivos, ya que cada uno de ellos tiene unas características particulares: cada uno dispone de una memoria determinada o ha de soportar un lenguaje y un entorno específicos.

El problema de los programadores de estos dispositivos reside, principalmente, en el momento en el que quieren estandarizar todos los dispositivos. Esto es muy difícil, ya que cada uno de ellos tiene unas aplicaciones diferentes, está implementado en un lenguaje distinto y utiliza técnicas de desarrollo y sistemas operativos dispares.

3.2 Generalidades de los Dispositivos Móviles

Un dispositivo móvil se puede definir como aquel que disfruta de autonomía de movimiento y está libre de cableado.

La principal característica de un dispositivo móvil es su gran capacidad de comunicación, la cual permite tener acceso a información y servicios independientemente del lugar y el momento en el que nos encontremos. Es decir, es una fuente de información fácil de transportar.

Capítulo 3: Dispositivos Móviles

28

La movilidad de un dispositivo móvil esta condicionada por la necesidad de utilizar una batería. Esto representa un inconveniente debido a que la batería necesita recargas periódicas, lo que dificulta en muchos casos la portabilidad del dispositivo móvil.

Un dispositivo móvil se caracteriza, en general, por su reducido tamaño, el cual aporta una ventaja notable: favorece la movilidad de los dispositivos móviles. A su vez, admite una serie de inconvenientes, como son que han de utilizar un procesador más simple y una memoria pequeña. Además, las interfaces con el usuario también son reducidas, ya que la mayor parte de los dispositivos móviles tienen una pantalla reducida, un teclado muy pequeño, o carecen de él, reconocimiento de voz limitado, etc.

Un dispositivo móvil ofrece recursos tanto a nivel personal como a nivel empresarial. Es en este último caso en el que los dispositivos móviles no disponen de la capacidad requerida para sus necesidades (poco espacio de almacenamiento de datos, introducción de datos poco eficaz, visualización limitada, etc.).

Con todo esto, tenemos que las aplicaciones de un dispositivo móvil, a primera vista, son más reducidas y menos potentes que las que podamos desarrollar sobre un PC.

Para intentar solucionar esta problemática y conseguir que los dispositivos móviles tengan más funcionalidad, se ha de aprovechar la gran capacidad de comunicación de la que disponen. De esta manera la "lógica pesada" de las aplicaciones estaría ubicada en un servidor remoto potente y el dispositivo móvil dispondría de ella cuando fuese necesario.

Pero esto no es tan fácil de realizar, ya que el dispositivo consumiría más energía, con lo que la batería debería cargarse más frecuentemente o aumentar el tamaño del dispositivo móvil para llevar una más potente. Si a esto se le añade el hecho de que también aumentaría el precio del dispositivo móvil, estas soluciones, por el momento, no son muy viables aunque sí utilizadas.

Las conclusiones preliminares que podemos obtener de esta información son:

Conseguir que la interfaz de las aplicaciones sea lo más simple posible, para ahorrar memoria. Evitar la introducción masiva de información en el dispositivo móvil, ya que se podría saturar.


29

Estudiar cuidadosamente el diseño de la interfaz. Usar guías de estilo y recomendaciones al respecto.

3.3 Tipos de Dispositivos Móviles

3.3.1 Teléfono móvil

Un teléfono móvil es un teléfono portátil, sin hilos, conectado a una red celular. Este dispositivo permite a los usuarios la conversación telefónica en tiempo real y en ambos sentidos de transmisión en cualquier lugar cubierto por la red. Si la red es digital el teléfono puede enviar y recibir información a través de Internet. Pueden ser utilizados como módem para que tanto PDA’s como computadores portátiles se conecten a la red.

Los teléfonos móviles son adecuados para aplicaciones residenciales sencillas en las que predominan los datos y textos de pequeño tamaño como por ejemplo consultas de información en páginas WAP o a través de mensajes SMS, aunque es previsible la progresiva incorporación de un mayor número de elementos gráficos.

Las ventajas que presentan los teléfonos móviles son varias: muy extendidos, ligeros y transportables, económicos, poseen prestaciones de comunicación innatas.

Por el contrario, también muestran algunos inconvenientes: poca potencia de proceso, poca memoria, capacidades de visualización limitada, interacción avanzada difícil.

3.3.2 PDA (Personal Digital Assistant)

Las PDA son agendas personales electrónicas que tienen capacidad para almacenar datos ya que poseen mayor memoria que los teléfonos móviles. También disponen de una pantalla más grande (visualización mejorada) y tienen una mayor capacidad de proceso.

El mercado al que se dirigen las PDA’s es básicamente profesional o empresarial, ya que es un tipo de terminal muy adecuado para aplicaciones de correo electrónico,


30

gestión personal y comercial. Otra característica es que tienen la capacidad de presentar la información en diversos formatos (WAP, HTML y Windows).

Existe una gran variedad de PDA's en el mercado, debido al éxito que están teniendo en los últimos años. Hay diversas compañías que se dedican a realizar los sistemas operativos de estos dispositivos, siendo los más importantes los que se citan a continuación: Palm Source, Linux, Symbian, Microsoft CE.

Un PDA, con respecto a un teléfono móvil, presenta algunas ventajas en general: las pantallas son más grandes y la visualización se mejora, la interacción con el usuario es más fácil (fundamentalmente por tener una pantalla táctil), más potente desde el punto de vista computacional.

Sin embargo, también presentan algunos problemas: necesita accesorios para comunicarse, el precio, el peso y el tamaño es mayor que el de un teléfono móvil.

3.3.3 Híbridos

Existen dos tipos de híbridos: PDA’s con las propiedades de un teléfono móvil y teléfonos móviles que adoptan las características de los PDA’s. Los dos intentan que cada dispositivo adquiera las ventajas del otro. En el caso de las PDA’s, se ha añadido la capacidad de comunicación con otros usuarios, mientras que los teléfonos móviles han adquirido una pantalla de mayores dimensiones y una capacidad de procesado más elevada.

Uno de los tipos de híbridos más comunes son los llamados Smartphones, los cuales son conocidos como teléfonos móviles inteligentes puesto que poseen un sistema operativo similar al de las PDA. Enfocados principalmente a aplicaciones profesionales o comerciales, cuentan con visores más grandes y teclados alfanuméricos o pantallas táctiles. Además de soportar el formato WAP, en estos dispositivos pueden funcionar aplicaciones ofimáticas como procesadores de textos u hojas de cálculo. Esto los hace adecuados para gestión de equipos de trabajo, recepción de faxes o correo electrónico empresarial.


31

3.4 Ventajas y Desventajas de los Dispositivos Móviles

3.4.1 Ventajas

Las ventajas que suponen los dispositivos móviles son múltiples debido a los propósitos para los que han sido diseñados. Las características de los dispositivos móviles han hecho un mundo en continua evolución y desarrollo y están generando un mercado en expansión donde, en un futuro no muy lejano, se prevé un aumento de la aplicaciones.

La mayor ventaja que supone la utilización de dispositivos móviles es la eliminación del problema de cableado. Este hecho hace que sea más cómodo el uso de los dispositivos porque no tenemos que depender de la existencia de una red eléctrica para su funcionamiento.

Con la nueva generación de dispositivos móviles, y una vez superados los problemas de estandarización, podremos acceder a la red en cualquier lugar y a cualquier hora. Esto supone otra de las grandes ventajas de esta tecnología, ya que era casi impensable hace unos años.

En principio, el dispositivo móvil estará conectado permanentemente a la red, así que en todo momento el usuario podrá recibir cualquier tipo de información siendo procesada por el dispositivo al instante. Los dispositivos tendrán gran flexibilidad dentro del área de cobertura. Será posible conectarse a Internet o interactuar con otros usuarios en cualquier momento y de una forma sencilla.

La competencia entre las diferentes compañías que se dedican al software y hardware de los dispositivos móviles hace que se estén generando gran cantidad de aplicaciones y se mejoren los sistemas operativos. También se consigue que los usuarios ganen en comodidad haciendo la pantalla de mayores dimensiones y que los modos de introducir datos se haga de una manera más cómoda con teclados más grandes y/o con la tecnología tipo Graffiti.

Otra de las ventajas que ofrece la nueva tecnología, será la de poder enviar datos de diferentes clases ya sea voz, datos, imágenes o video. Esto conllevará a que el usuario será


32

capaz en todo momento de enviar cualquiera de estas clases de datos siempre que lo desee, con la comodidad que supone el hecho de poder hacerlo desde el mismo dispositivo.

Para los que les gustan los juegos en línea, tendrán la oportunidad de jugar con cualquier usuario conectado a la red con una mejor resolución, mayores prestaciones y mayores posibilidades a la hora de escoger el juego.

3.4.2 Desventajas

El amplio desarrollo que están sufriendo las comunicaciones móviles, han hecho que se intente consolidar un estándar para la Tercera Generación, ya que será necesario para resolver muchos de los problemas que conlleva esta evolución.

Uno de los mayores inconvenientes que se plantean, es la necesidad de adaptar la interfaz de usuario a cada tipo de dispositivo. Las medidas que se están adoptando son las de separar la lógica de aplicación de la interfaz del usuario. Esto se está llevando a cabo utilizando métodos estándar de comunicación y haciendo uso de herramientas que permitan adaptar rápidamente las aplicaciones a los nuevos tipos de dispositivos que vayan apareciendo.

Otro problema que existe es que la introducción de datos es lenta ya que, en el caso de las PDA, los teclados son muy pequeños o los que escriben directamente en la pantalla (tecnología Graffiti) no son perfectos.

La transferencia de datos es todavía lenta y su uso resulta caro e incómodo. Todavía existen problemas en la facturación, ya que no se ha establecido si será por tiempo de conexión o por el volumen de datos descargados.

El ancho de banda utilizado es otro problema a discutir. Hay en marcha un estándar donde los países intentan ponerse de acuerdo para escoger el ancho de banda que se va a dedicar para la nueva generación de dispositivos móviles, pero existen algunos obstáculos ya que el que se ha propuesto, en algunos países está ocupado por otros sistemas de comunicación.


33

Un punto débil de los dispositivos móviles es la duración de las baterías. Las aplicaciones que más batería gastan son las pantallas a color, los módems, las tarjetas de red, tarjetas de memoria y periféricos. Además, la capacidad de las baterías se va reduciendo con el tiempo.

El tamaño de la pantalla también influye en el software del dispositivo. No es lo mismo programar para una pantalla de un teléfono móvil, que para una pantalla de una PDA, ya que las últimas son más grandes y tiene una mejor resolución. A parte de esto, no hay un estándar de tamaño de pantalla, así que cada compañía programa sus propios dispositivos.

La seguridad es un punto clave para hacer de los dispositivos móviles un modo de conexión a la red confiable y sin problemas.

La compatibilidad con los diferentes dispositivos móviles sigue siendo un obstáculo, porque todavía no existe un software que se pueda utilizar independientemente del hardware que se maneje.

En lo que a sistemas operativos se refiere, hay muchas rivalidades entre las compañías existentes, lo que presenta un inconveniente mayor a la hora de tratar de definir un estándar.

3.5 Plataformas de Desarrollo

3.5.1 J2ME: Java 2 Micro Edition

Java Micro Edition es la versión del lenguaje Java que está orientada al desarrollo de aplicaciones para dispositivos pequeños con capacidades restringidas tanto en pantalla gráfica, como de procesamiento y memoria (teléfonos móviles, PDA`s, Handhelds, etc.).

Los componentes que forman parte de esta tecnología son los siguientes:

Por un lado máquinas virtuales Java con diferentes requisitos, cada una para diferentes tipos de pequeños dispositivos.


34

Configuraciones, que son un conjunto de clases básicas orientadas a conformar el corazón de las implementaciones para dispositivos de características específicas. Perfiles, que son unas bibliotecas Java de clases específicas orientadas a implementar funcionalidades de más alto nivel para familias específicas de dispositivos.

Existen 2 configuraciones definidas en J2ME: Connected Limited Device Configuration (CLDC) enfocada a dispositivos con restricciones de procesamiento y memoria, y Connected Device Configuration (CDC) enfocada a dispositivos con más recursos.

Un entorno de ejecución determinado de J2ME se compone entonces de una selección de: Máquina virtual, Configuración, Perfil y Paquetes Opcionales.

Máquinas Virtuales J2ME

Una máquina virtual de Java (JVM) es un programa encargado de interpretar código intermedio (bytecode) de los programas Java precompilados a código máquina ejecutable por la plataforma, efectuar las llamadas pertinentes al sistema operativo subyacente y observar las reglas de seguridad y corrección de código definidas para el lenguaje Java. De esta forma, la JVM proporciona al programa Java independencia de la plataforma con respecto al hardware y al sistema operativo subyacente. Las implementaciones tradicionales de JVM son, en general, muy pesadas en cuanto a memoria ocupada y requerimientos computacionales. J2ME define varias JVM’s de referencia adecuadas al ámbito de los dispositivos electrónicos que, en algunos casos, suprimen algunas características con el fin de obtener una implementación menos exigente.

Cada una de las configuraciones CLDC y CDC requiere su propia máquina virtual. La VM (Virtual Machine) de la configuración CLDC se denomina KVM y la de la configuración CDC se denomina CVM. Las características principales de cada una de ellas son:

KVM

Se corresponde con la Máquina Virtual más pequeña desarrollada por Sun. Su nombre KVM proviene de Kilobyte (haciendo referencia a la baja ocupación de memoria,


35

entre 40Kb y 80Kb). Se trata de una implementación de Máquina Virtual reducida y especialmente orientada a dispositivos con bajas capacidades computacionales y de memoria. La KVM está escrita en lenguaje C, aproximadamente unas 24000 líneas de código, y fue diseñada para ser:

Pequeña, con una carga de memoria entre los 40Kb y los 80Kb, dependiendo de la plataforma y las opciones de compilación. Alta portabilidad. Modulable. Lo más completa y rápida posible y sin sacrificar características para las que fue diseñada.

Sin embargo, esta baja ocupación de memoria hace que posea algunas limitaciones con respecto a la clásica Java Virtual Machine (JVM):

1. No hay soporte para tipos en coma flotante. No existen por tanto los tipos double ni float. Esta limitación está presente porque los dispositivos carecen del hardware necesario para estas operaciones.

2. No existe soporte para JNI (Java Native Interface) debido a los recursos limitados de memoria.

3. No existen cargadores de clases (class loaders) definidos por el usuario. Sólo existen los predefinidos.

4. No se permiten los grupos de hilos o hilos daemon. Cuándo queramos utilizar grupos de hilos utilizaremos los objetos Colección para almacenar cada hilo en el ámbito de la aplicación.

5. No existe la finalización de instancias de clases. No existe el método Object.finalize().

6. No hay referencias débiles. 7. Limitada capacidad para el manejo de excepciones debido a que el manejo de

éstas depende en gran parte de las API’s de cada dispositivo por lo que son éstos los que controlan la mayoría de las excepciones.

8. Reflexión.

El verificador de clases estándar de Java es demasiado grande para la KVM. De hecho es más grande que la propia KVM y el consumo de memoria es excesivo, más de 100Kb para las aplicaciones típicas. Este verificador de clases es el encargado de rechazar


36

las clases no válidas en tiempo de ejecución. Este mecanismo verifica los bytecodes de las clases Java realizando las siguientes comprobaciones:

Ver que el código no sobrepase los límites de la pila de la VM. Comprobar que no se utilizan las variables locales antes de ser inicializadas. Comprobar que se respetan los campos, métodos y los modificadores de control de acceso a clases.

Por esta razón los dispositivos que usen la configuración CLDC y KVM introducen un algoritmo de verificación de clases en dos pasos.

La KVM puede ser compilada y probada en 3 plataformas distintas: Solaris Operating Environment, Windows y PalmOs.

CVM

La CVM (Compact Virtual Machine) ha sido tomada como Máquina Virtual Java de referencia para la configuración CDC y soporta las mismas características que la Máquina Virtual de J2SE. Está orientada a dispositivos electrónicos con procesadores de 32 bits de gama alta y en torno a 2Mb o más de memoria RAM. Las características que presenta esta Máquina Virtual son:

1. Sistema de memoria avanzado. 2. Tiempo de espera bajo para el recolector de basura. 3. Separación completa de la VM del sistema de memoria. 4. Recolector de basura modularizado. 5. Portabilidad. 6. Rápida sincronización. 7. Ejecución de las clases Java fuera de la memoria de sólo lectura (ROM). 8. Soporte nativo de hilos. 9. Baja ocupación en memoria de las clases. 10. Proporciona soporte e interfaces para servicios en Sistemas Operativos de

Tiempo Real. 11. Conversión de hilos Java a hilos nativos.


37

12. Soporte para todas las características de Java2 v1.3 y biblioteca de seguridad, referencias débiles, Interfaz Nativa de Java (JNI), invocación remota de métodos (RMI), Interfaz de depuración de la Máquina Virtual (JVMDI).

Configuraciones: CLDC

Una configuración es, básicamente, el conjunto mínimo de APIs Java que permiten desarrollar aplicaciones para un grupo de dispositivos. Estas APIs describen las características básicas, comunes a todos los dispositivos.

La configuración conocida por las siglas CLDC (Connected Limited Device Configuration, Configuración de Dispositivo Conectado Limitado) es la única definida hoy en día por Sun para J2ME, contiene las clases e interfaces Java necesarios para desarrollar aplicaciones sobre dispositivos móviles con conexión inalámbrica (wireless), básicamente teléfonos móviles y dispositivos equivalentes (por ejemplo, los sistemas bidireccionales de mensajes, conocidos como pagers en Estados Unidos). En el futuro aparecerán más configuraciones a medida que nuevos tipos de dispositivos adopten el soporte nativo a Java como una de sus funcionalidades.

La configuración CLDC contiene cuatro elementos básicos:

Un subconjunto de los elementos básicos del lenguaje Java. Una parte de la funcionalidad de la máquina virtual Java. Las APIs básicas para el desarrollo de aplicaciones. Requisitos hardware de los dispositivos englobados en el CLDC.

Las limitaciones en el uso del lenguaje Java se centran esencialmente en la ausencia de soporte a operaciones con coma flotante (números reales) debido a que el hardware soportado por CLDC no cuenta con la capacidad de realizar estas operaciones. La única forma de realizarlas sería vía software, lo que supondría obtener un rendimiento muy pobre, por lo que es mejor evitar, en la medida de lo posible este tipo de operaciones.

Otra limitación en el lenguaje es la ausencia del método Object.finalize(), que se invoca cada vez que se elimina un objeto de memoria, con objeto de facilitar la liberación de los recursos asociados. Dado que CLDC no precisa que la máquina virtual dé soporte a la finalización de objetos, este elemento no es necesario.


38

También hay cambios en el manejo de excepciones. Esto se debe a que buena parte de las excepciones dependen de cada dispositivo, por lo que deben ser definidas en cada caso y no de forma genérica. Esto hace que se reduzca mucho el número de errores y excepciones soportados de forma estándar.

Un elemento de cuidado en la redefinición que CLDC hace de Java es la seguridad. Resulta obvio que el esquema de descarga y ejecución de aplicaciones en dispositivos tan personales como puedan ser teléfonos móviles, implica tomar precauciones para garantizar la integridad y confidencialidad de dispositivos, aplicaciones y datos. En realidad no es algo especialmente novedoso, pues el uso de applets (pequeños programas escritos en Java que se descargan y ejecutan sobre un navegador Web) supuso imponer serias restricciones a la funcionalidad disponible en la máquina virtual Java encargada de ejecutarlos, por medio de la creación de una zona segura para hacerlo o sandbox.

Básicamente, hay una serie de funcionalidades sensibles o críticas que quedan fuera del alcance de los programas y una serie de condiciones previas que debe cumplir cualquier aplicación para poder ser utilizada dentro de un dispositivo:

Los ficheros que contienen las clases deben haber sido verificados como una aplicación válida Java en un paso adicional dentro del proceso de desarrollo. Sólo se puede hacer uso del API CLDC predefinido. Por lo que sólo está accesible el código nativo de las funcionalidades de ese API. No se permite el uso de cargadores de clases definidos por el usuario.

Todas estas restricciones de seguridad son de muy bajo nivel, ya que CLDC es en realidad una especificación muy básica. En la especificación de perfil, vista más adelante, se incorporan algunas restricciones adicionales.

Por último, los requisitos mínimos de hardware que definen a un dispositivo englobado en la configuración CLDC son disponer de:

160Kb de memoria disponible para Java. Esta memoria está dividida en dos áreas: 128Kb de memoria no volátil para la máquina virtual Java y las librerías del API CLDC, y 32Kb de memoria volátil para el entorno de ejecución. Un procesador de 16 bits.Bajo consumo, por regla general por medio del uso de baterías.


39

Conexión a red, normalmente con un ancho de banda de 9.600 bps o inferior (típico de conexiones GSM).

Perfiles: MIDP

En la jerarquía definida en J2ME, los perfiles (profiles) se apoyan sobre las configuraciones, CLDC en este caso. Un perfil es una concreción aún más restrictiva de las APIs para centrarse en un conjunto muy reducido de dispositivos (incluso uno solo). Es decir, el perfil añade unas APIs que definen las características de un dispositivo, mientras que la configuración hace lo propio con una familia de ellos. Esto hace que a la hora de construir una aplicación se cuente tanto con las APIs del perfil como con las de la configuración.

CLDC es la primera configuración definida en J2ME. MIDP (de Mobile Information Device Profile, o "Perfil de Dispositivo Móvil de información") es el primer perfil, hecho para describir dispositivos similares a teléfonos móviles o pagers. Estos dispositivos se describen a través de unos requisitos mínimos que se aplican a algunas de sus características como:

Memoria: Al menos 128Kb de memoria no volátil para almacenar el API MIDP. Al menos 32Kb de memoria volátil para el sistema de ejecución Java. Un mínimo de 8Kb de memoria persistente para el almacenamiento de información por parte de los programas. Este es el principal requisito añadido por el perfil.

Entrada de datos: un dispositivo MIDP debe tener un teclado o una pantalla táctil, o ambos. Aunque el ratón no forma parte de los medios de entrada reconocidos, un puntero (como en las PDA’s) sí es un sistema de entrada válido ya que se aplica sobre una pantalla táctil.

Pantalla: al referirse a un tipo de dispositivos con grandes limitaciones de visualización, el perfil MIDP es muy restrictivo al respecto. La pantalla mínima es de 96x54 píxeles, con dos colores (blanco y negro, o activado y desactivado). Además con una relación entre altura y anchura de 1:1, es decir que la pantalla debe parecer cuadrada, lo que supone usar unos píxeles alargados (en un monitor son generalmente cuadrados, no rectangulares). Ello no impide que la mayor parte de los dispositivos rebasen ampliamente estas restricciones tanto en dimensiones como en colores.


40

Red: deben contar con acceso a una red bidireccional (para enviar y recibir) inalámbrica. Las exigencias mínimas de ancho de banda son muy humildes: 9.600 bps.

Plataforma software: los dispositivos MIDP, no importa el hardware o el sistema operativo en el que se basen (uno de los grandes beneficios de Java) requieren la presencia de una serie de elementos en la gestión de la plataforma como son:

La presencia de un kernel (núcleo de sistema operativo) capaz de hacerse cargo de tareas de bajo nivel como la gestión de interrupciones, excepciones y temporizadores. Un mecanismo para leer y escribir en memoria no volátil. Gestión del tiempo para fijar temporizadores y añadir marcas temporales a la información persistente. Acceso de lectura escrita a la conexión inalámbrica del dispositivo. Medios para obtener la información introducida por el usuario a través de los dispositivos de entrada. Soporte a gráficos basados en mapas de bits. Medios para gestionar el ciclo de vida de una aplicación (inicio, interrupción, reactivación y destrucción).

Las aplicaciones realizadas utilizando MIDP reciben el nombre de MIDlets (porsimpatía con APPlets). Decimos así que un MIDlet es una aplicación Java realizada con el perfil MIDP sobre la configuración CLDC.

3.5.2 .Net Compact Framework

.NET Framework ofrece un modo robusto y eficaz de diseño de aplicaciones Windows para PC. Este método reemplaza los anteriores, en los que las API de los sistemas operativos Windows (Win32) se accedían directa o indirectamente a través de bibliotecas específicas al lenguaje utilizadas por desarrolladores de Visual Basic o Visual C++. Existe un gran número de ventajas cruciales en el uso de .NET Framework:

Provee compatibilidad completa para el diseño de suntuosas aplicaciones cliente o basadas en web, al igual que servicios web XML. Ofrece un conjunto de estándares de interfaces u operaciones de programación a través de los cerca de 20 lenguajes admitidos. No obstante, en la práctica la mayoría


41

de las nuevas aplicaciones .NET se escriben ya sea en Visual Basic .NET o C#. Visual Basic .NET está basado en Visual Basic 6 con algunas mejoras importantes como la compatibilidad completa con la programación orientada a objetos y algunos aspectos inevitables de la compatibilidad con versiones anteriores. C#, al igual que Java, está basado en C++ y es bastante similar a Java. .NET Framework incluye un entorno común de tiempo de ejecución que verifica el código de las aplicaciones a medida se cargan y las administra durante su ejecución, controlando los errores, la recopilación de residuos y la seguridad, entre otros. Las aplicaciones se compilan en un lenguaje intermedio y se convierten a un código de máquina ejecutable justo antes de la ejecución por parte del entorno de tiempo de ejecución. En potencia, esto significa que el tiempo de ejecución de .NET Framework se puede transportar a otros sistemas operativos y plataformas de hardware sin tener que volver a escribir o a compilar las aplicaciones existentes.

.NET Compact Framework

.NET Compact Framework es un subconjunto de .NET Framework. Ofrece las ventajas de un entorno robusto y seguro para la ejecución de código cliente y servicios web XML para dispositivos inteligentes, tales como PDA o teléfonos móviles. De forma específica es compatible con:

Pocket PC (y Pocket PC 2002 Phone Edition, para los usuarios que desean hacer llamadas telefónicas con PDA), el cual en la actualidad se basa en el sistema operativo Windows CE 3.0. Las soluciones integradas que se ejecutan en Windows CE .NET, la cual es la última versión del sistema operativo de Microsoft para dispositivos móviles inteligentes. Se espera que sea compatible en un futuro cercano con Microsoft Smartphone 2002, el cual se utiliza principalmente para llamadas de voz pero también ofrece la mayoría de las funciones de PDA.

Características más importantes de .NET Compact Framework

Experiencias Adaptadas a Cada Dispositivo: .NET Compact Framework (al igual que la versión completa de .NET Framework) es una abstracción de las funciones subyacentes del sistema operativo y puede satisfacer una gran mayoría de los


42

requisitos de las aplicaciones a través de su funcionalidad estándar. No obstante, si se requiere el acceso a una función única de dispositivo, se puede admitir ésta con facilidad debido a que .NET Compact Framework está diseñado para ampliarse.

Código Compartido y Eficiencia: como .NET CF entrega el mismo modelo de programación a una gama de dispositivos, simplifica el proceso de desarrollar una aplicación que funcione en los múltiples dispositivos. Mucho código básico de una aplicación, tal como la lógica de negocio, los datos de acceso a la capa, y la capa del servicio Web XML, se pueden compartir en los múltiples dispositivos y escritorios. Esto aumenta mayormente la eficacia del desarrollo de la aplicación.

Características de clases de Negocio para más Dispositivos: el éxito de dispositivos de Microsoft Pocket PC está creciendo, en parte, porque tienen los recursos de computación necesarios para manejar aplicaciones de negocio sofisticadas. El .NET CF se aprovecha de la plataforma de Pocket PC proporcionando los marcos mejorados que simplifican grandemente el proceso de desarrollar aplicaciones de empresa en los dispositivos de Pocket PC.

Código Robusto, Ejecución Segura: .NET CF ofrece un entorno robusto y seguro para el código del lado cliente. El modelo de código manejado soportado por .NET CF aumenta la confiabilidad del código, reduciendo defectos del software. El motor de ejecución del código manejado asegura que una aplicación infecciosa, no podrá "estrellarse" contra el dispositivo. Al mismo tiempo, el modelo de seguridad basado en evidencias construido en el .NET CF se asegura de que código malévolo no se le permite acceder a recursos de sistema. El modelo de seguridad también permite a actualizaciones de software ser entregadas sobre la red inalámbrica de una manera segura, disminuyendo la posibilidad de un costoso “cuelgue” del dispositivo.

Soporte para Aplicaciones Offline: con código seguro del lado cliente, el .NET CF permite a las aplicaciones seguras que se pueden utilizar en modo desconexión. Esto permite una experiencia suave a pesar de cualquier problema de conectividad intermitente que pudiera ocurrir al tener acceso a la red. El programador puede elegir la mezcla correcta de lado cliente y lado servidor de programación para entregar una rica e interactiva experiencia de usuario.


43

Coste reducido de Desarrollo de nuevas Oportunidades: esta nueva facilidad de desarrollo proporcionada con .NET CF conducirá a la creación de una amplia nueva gama de aplicaciones y servicios que ayuden a los fabricantes a ganar mayor aceptación en el mercado de sus dispositivos móviles y a crear nuevas oportunidades para los programadores. Muchos negocios que no podían producir el coste o el entrenamiento especial del programador necesario para el desarrollo móvil, podrá desarrollar las nuevas aplicaciones móviles mucho más eficientemente, que pueden ayudar a reducir sus costes de negocio, y pueden ayudar a aumentar sus oportunidades de mercado.

Experiencias Móviles: .NET CF facilita que los programadores construyan y desplieguen servicios Web XML, así como aplicaciones compactas de cliente, en una amplia gama de dispositivos compactos. Las capacidades para los dispositivos que funcionan con .NET CF incluirán: Servicios Web XML, Acceso corporativo a datos, Comercio, Noticias e información, Juegos y aplicaciones basadas en formularios.

El .NET CF proporciona no sólo el acceso a todos estos servicios, sino que permite que los programadores los combinen para proporcionar aplicaciones y servicios adaptados para requisitos particulares de los usuarios finales.

44

Capítulo 4

Metodologías de Desarrollo Orientadas a Agentes

Los sistemas evolucionan de manera vertiginosa. Surgen nuevas necesidades (requerimientos de usuario), las cuales presentan un nuevo reto en la Ingeniería de Software. Es por ello que académicos e investigadores dan lugar a nuevas metodologías de desarrollo de Software para poder satisfacer dichas necesidades.

Aparece un nuevo paradigma, el de Agentes de Software que va más allá de la orientación a Objetos, pero que lamentablemente no cuenta con un estándar de Metodología de Análisis y Diseño. En la actualidad, existe una amplia selección de Metodologías de Sistemas Multiagente y no se sabe a priori cuál es la más adecuada para acompañar al desarrollo del Software.

Existen dos tipos de metodologías de agentes [9]: aquellas que son totalmente nuevas y aquellas que surgen como extensiones a las metodologías existentes. Las primeras se basan en una teoría de agentes. En general no son suficientemente maduras para aplicarlas y necesitan tiempo para ser probadas. Las segundas intentan aplicar métodos existentes al enfoque de agentes de software. Esto tiene la ventaja de reutilizar modelos ya conocidos e incluso aceptados y estandarizados.

Con respecto al alcance, generalmente las metodologías tienden a cubrir análisis y diseño, excluyendo así a la implementación y mantenimiento. Otra parte que se deja implícita es la captura de requerimientos. Generalmente no queda definido exactamente cómo se debe pasar de la especificación de requerimientos inicial hacia los primeros modelos del análisis. El problema de esto es que no hay una conexión explícita entre los requerimientos y el sistema, con lo cual es difícil darse cuenta cómo se resuelve cada necesidad del usuario.

Capítulo 4: Metodologías de desarrollo orientadas a agentes

45

Las etapas de implementación y mantenimiento no suelen cubrirse por el simple hecho de no existir herramientas productivas y maduras capaces de desarrollar software basado en agentes.

En cuanto a la metodología en sí, algunas son más explícitas que otras, por ejemplo cuando se trata de analizar los requerimientos no funcionales, algunas indican qué estructura de sistema (patrón de diseño) se debe aplicar para satisfacer dichos requerimientos. En cambio otras metodologías directamente no mencionan el tema.

4.1 MaSE

MaSE (Multi-agent systems Software Engineering) [13] parte del paradigma orientado a objetos y asume que un agente es sólo una especialización de un objeto. La especialización consiste en que los agentes se coordinan unos con otros vía conversaciones y actúan pro activamente para alcanzar metas individuales y del sistema.

En MaSE los agentes son procesos de software que interactúan entre si con el fin de alcanzar una meta global, son sólo una abstracción conveniente, que puede o no poseer inteligencia. En este sentido, los componentes inteligentes y no inteligentes se gestionan igualmente dentro del mismo framework. El proceso de desarrollo en MaSE es un conjunto de pasos, la mayoría de los cuales se ejecutan dentro de la herramienta que soporta MaSE, AgentTool [13].

Las distintas fases de MaSE pueden verse en la figura 4.1. La salida de cada una de estas fases sirve como entrada a la siguiente fase. Se puede ver que es una metodología de tipo iterativa y con sucesivas repeticiones del ciclo se puede lograr un mejor nivel de detalle en las especificaciones del proyecto.


46

Figura 4.1: Metodología MaSE

El análisis en MaSE consta de tres pasos: capturar los objetivos, capturar los casos de uso y refinar roles. Como productos de estas etapas se esperan: diagramas de objetivos, que representan los requisitos funcionales del sistema; diagramas de roles, que identifica roles, tareas asociadas a roles y comunicaciones entre roles y entre tareas; y casos de uso, mostrados no como diagrama sino como una enumeración de los casos de uso considerados con la posibilidad de usar diagramas de secuencia para detallarlos.

El diseño consta de cuatro pasos: crear clases de agentes, construir conversaciones, ensamblar clases de agentes y diseño del sistema. Como productos de estas etapas, MaSE espera: diagramas de clases de agentes, que enumeran los agentes del sistema, roles jugados e identifican conversaciones entre los mismos; descomposición del sistema (agente) en subsistemas (componentes del agente) e interconexión de los mismos (definición de la arquitectura del agente mediante componentes); diagramas UML de despliegue para indicar cuántos agentes habrá en el sistema y de qué tipo.

Las comunicaciones entre diferentes elementos (componente-componente, agente-agente, rol-rol, tarea-tarea) se refieren al envío de estímulos desde una máquina de estados a otra. En el caso de las tareas, a estas máquinas las denominan en MaSE diagramas de tareas concurrentes.


47

La herramienta de soporte, agentTool [13], permite generar código automáticamente a partir de la especificación del sistema, que en MaSe es el conjunto final de diagramas. La generación de código es independiente del lenguaje de programación utilizado, ya que se realiza recorriendo las estructuras de datos generadas en la especificación y generando texto como salida.

Dentro de la misma herramienta, MaSE incorpora utilidades para verificar la corrección de los protocolos que utilicen los agentes.

4.2 MAS-CommonKADS

Esta metodología extiende CommonKADS [12] aplicando ideas de metodologías orientadas a objetos para su aplicación a la producción de SMA [10] [11]. La metodología CommonKADS gira alrededor del modelo de experiencia y está pensada para desarrollar sistemas expertos que interactúen con el usuario. De hecho considera sólo dos agentes básicos: el usuario y el sistema. MAS-CommonKADS extiende los modelos de CommonKADS para tener en cuenta la posibilidad de que dos o más componentes del sistema interactúen.

MAS-CommonKADS ha sido la primera en plantear un desarrollo de SMA integrado con un ciclo de vida de software, concretamente el espiral dirigido por riesgos [15]. Propone siete modelos para la definición del sistema: agente, tareas, experiencia, coordinación, comunicación, organización y diseño. Cada modelo presenta referencias a la teoría sobre la que se basa. El modelo en sí parte de una descripción gráfica que luego se complementa con explicaciones en lenguaje natural de cada elemento. Existe por cada modelo una descripción de las dependencias respecto de otros modelos y de las actividades involucradas. Estos modelos se hayan descritos ampliamente en [10] en lenguaje natural, complementándose con otras notaciones como SDL (Specification and Description Language) [16] o MSC (Message Sequence Chart) [17] para describir el comportamiento de los agentes cuando interaccionan.

Según la web de MAS-CommonKADS existen herramientas de soporte desarrolladas dentro del proyecto [18]. Estas herramientas aparecen bajo el título MAST (MultiAgent Systems Tool). Sin embargo, la única que se puede descargar no es una


48

herramienta para apoyo al análisis y diseño, sino un conjunto de arquitecturas y frameworks de agentes.

4.3 GAIA

GAIA [14] [19] es una metodología para el diseño de sistemas basados en agentes cuyo objetivo es obtener un sistema que maximice alguna medida de calidad global (no se llega a detallar cuál). GAIA pretende ayudar al analista a ir sistemáticamente desde unos requisitos iniciales a un diseño que, según los autores, esté lo suficientemente detallado como para ser implementado directamente.

En GAIA se entiende que el objetivo del análisis es conseguir comprender el sistema y su estructura sin referenciar ningún aspecto de implementación. Esto se consigue a través de la idea de organización. Una organización en GAIA es una colección de roles, los cuales mantienen ciertas relaciones con otros y toman parte en patrones institucionalizados de interacción con otros roles. Los roles agrupan cuatro aspectos: responsabilidades del agente, los recursos que se le permite utilizar, las tareas asociadas e interacciones.

GAIA propone trabajar inicialmente con un análisis a alto nivel (ver figura 4.2). En este análisis se usan dos modelos, el modelo de roles para identificar los roles clave en el sistema junto con sus propiedades definitorias y el modelo de interacciones que define las interacciones mediante una referencia a un modelo institucionalizado de intercambio de mensajes, como el FIPA-Request [20]. Tras esta etapa, se entraría en lo que GAIA considera diseño a alto nivel (ver figura 4.2). El objetivo de este diseño es generar tres modelos: el modelo de agentes que define los tipos de agente que existen, cuántas instancias de cada tipo y qué papeles juega cada agente, el modelo de servicios que identifica los servicios (funciones del agente) asociados a cada rol, y un Modelo de comunicación, que define los enlaces de comunicaciones que existen entre los agentes.


49

Figura 4.2: Modelos de GAIA

A partir de aquí, los autores de GAIA proponen aplicar técnicas clásicas de diseño orientado a objetos. Sin embargo, GAIA declara que queda fuera de su ámbito. Esta metodología sólo busca especificar cómo una sociedad de agentes colabora para alcanzar los objetivos del sistema, y qué se requiere de cada uno para lograr esto último.

En esta metodología llama la atención que no se ocupan de la fase de captura de requerimientos pues la consideran independiente del nuevo paradigma usado en las etapas de análisis y diseño. A pesar de que sus desarrolladores están conciente de la importancia de esta actividad en el desarrollo de software, plantean que GAIA puede integrarse fácilmente a los modernos métodos para la captura de requerimientos.

4.4 Eligiendo una Metodología

Una metodología constituye un conjunto de etapas o fases que van guiando a los diseñadores partiendo de una definición de alto nivel hacia una aproximación a una implementación. Si estas etapas son pocas entonces es demasiado general y el salto que existe entre una y otra es muy grande. En el otro extremo están las metodologías con muchas etapas y una granularidad muy fina que puede ser tediosa de usar por aquellas personas con alguna experiencia.

Si hubiera que elegir una metodología, ¿cuál sería la ganadora? Esta pregunta no tiene una respuesta simple. Cada metodología, por el bagaje de sus creadores, se especializa en áreas concretas.


50

Si se está acostumbrado a trabajar con sistemas basados en conocimiento con la metodología CommonKADS, lo lógico es que se elija MAS-CommonKADS. Si la experiencia del usuario está en el área de los objetos, la recomendación sería de MaSE. Si por el contrario está interesado en un enfoque más orientado a agentes, puede seleccionar GAIA. Y si lo que se quiere es tener un soporte de herramientas, la metodología válida seria MaSE.

En los casos en que se requiera un proceso de desarrollo robusto, detallado y ensayado en desarrollos reales, la recomendación sería MAS-CommonKADS.

Si solo interesa una visión superficial del sistema, sin entrar en detalles de diseño e implementación, se recomendaría GAIA.

51

Capítulo 5

Plataformas Multiagente sobre Dispositivos Móviles

Una plataforma multiagente es una infraestructura de software utilizada como ambiente para el despliegue y la ejecución de agentes. Debe proporcionar vías confortables a los programadores de agentes para crear y probar agentes y puede ser vista como una colección de servicios ofrecidos a desarrolladores, pero también a agentes en ejecución.

Como se dijo en el párrafo anterior, la plataforma es un ambiente de ejecución para los agentes en el sentido de que debe permitir crear, ejecutar y borrar agentes. Por otra parte, la plataforma debe actuar como un middleware entre el sistema operativo y las aplicaciones (agentes) corriendo en él, como muestra la figura 5.1. El desarrollador será capaz luego de crear agentes por medio de una plataforma y usarlos en todos los sistemas que soporten la plataforma sin cambiar el código.

Figura 5.1: Vista de una plataforma de agentes corriendo en una máquina

Más que eso, una plataforma debe ocultar al desarrollador los detalles de comunicación entre los agentes. Si, por ejemplo, hay muchos protocolos de comunicación disponibles en el dispositivo (por ejemplo HTTP, RMI, Bluetooth, etc.), la plataforma debe elegir el protocolo apropiado para cada situación y usarlo. Esto permitirá crear agentes que son independientes de los protocolos de comunicación disponibles en la máquina, dejando el actual envió de la información como una tarea para la plataforma.

Capítulo 5: Plataformas multiagente sobre dispositivos móviles

52

Porque la elección de una plataforma de agentes tiene una gran influencia en la manera en que los agentes son diseñados e implementados, FIPA ha producido estándares que hablan sobre cómo una plataforma de agentes debe ser estructurada, es decir cuáles son los servicios básicos que debería ofrecer (por ejemplo un servicio de transporte de mensajes, un servicio de administración de agentes, un servicio de directorio). Estos estándares existen para asegurar un diseño uniforme de los agentes, independiente de la plataforma multiagente.

Debido a los limitados recursos disponibles, las plataformas de agentes para dispositivos móviles necesitan tener una arquitectura liviana. Muchas de estas plataformas son diseñadas para correr completamente (es decir con todos los servicios que proporcionan) en el dispositivo móvil, mientras otras están guardando algunos de los servicios (o a veces todos) en un servidor y son descargados en el dispositivo sólo cuando se necesite [32].

5.1 LEAP

La Lightweight Extensible Agent Platform (LEAP 3.4) probablemente es la plataforma de agentes más conocida para dispositivos móviles. Es el resultado del proyecto LEAP [34] que tenía como objetivo crear una plataforma completamente conforme a FIPA con objetivos similares a la Plataforma AgentLight: ser capaz de despliegue en dispositivos fijos y móviles con varios sistemas operativos y desplegarse en redes fijas o inalámbricas. Desde la versión 3.0, LEAP es un add-on de la plataforma JADE [6] [37] y usa un conjunto de perfiles que permiten configurarlo para la ejecución en varias máquinas, sistemas operativos y Java VM.

La arquitectura de la plataforma es modular y está organizada en términos de módulos entre los que algunos pueden ser obligatorios, requeridos por las especificaciones de FIPA, mientras otros son opcionales. Los obligatorios son el módulo del kernel que maneja tanto la plataforma como el ciclo de vida de los agentes y el módulo de comunicación, que se ocupa de la heterogeneidad de los protocolos de comunicación.

Algunos de los módulos son dependientes del dispositivo (por ejemplo el módulo de comunicación), mientras otros son independientes de las características del dispositivo (por


53

ejemplo un plug-in de seguridad para el módulo de comunicación). La plataforma es agnóstica de sistema operativo y puede correr en dispositivos que van desde teléfonos móviles y PDA’s hasta estaciones de trabajo. Para conseguir tal propósito, LEAP ofrece tres versiones diferentes pensadas para cada uno de los tres tipos posibles de entornos Java disponibles:

J2SE (Simple Edition): la indicada para ejecutarse en PC’s con jdk1.2 o superior. PJAVA (PersonalJava): idónea para dispositivos con PersonalJava como PDA’s. MIDP (Micro Edition): para dispositivos que soportan MIDP1.0 como teléfonos móviles.

Aunque internamente muy diferentes, las tres versiones ofrecen la misma API a los programadores, sólo presentando ciertas diferencias de las versiones J2SE y PJAVA respecto a la MIDP, proporcionando así una capa homogénea para una diversidad de dispositivos y tipos de redes como lo muestra la figura 5.2. Cabe destacar que las incompatibilidades mencionadas están relacionadas con las clases de Java no soportadas por MIDP.

Figura 5.2: Entorno de ejecución de JADE-LEAP

En cuanto a conectividad, JADE-LEAP trabaja a más alto nivel, y simplemente establece conexiones TCP/IP entre los contenedores, sin preocuparse del medio por donde


54

éstas se producen, ya sea GPRS, UMTS, WLAN, Wi-fi, Bluetooth, infrarrojos, entre otras. Por lo tanto al usar JADE-LEAP lo único a tener en cuenta es proporcionar algún tipo de conexión, con la que enlazar los agentes situados en diferentes dispositivos móviles.

La arquitectura de LEAP divide la plataforma en varios contenedores, uno para cada dispositivo o estación de trabajo usado, con uno o varios agentes en cada contenedor. Estos contenedores son responsables de pasar los mensajes entre los agentes escogiendo el protocolo de comunicación apropiado disponible. Uno de estos contenedores tiene un papel especial y es llamado contenedor principal; contiene a dos agentes especiales que implementan las especificaciones de FIPA para proporcionar los servicios de páginas blancas y amarillas, éstos son el AMS (Agent Management System) y el DF (Directory Facilitator), respectivamente. Este contenedor principal no puede ejecutarse en un dispositivo pequeño, sino sólo en un PC. Para permitir la ejecución de contenedores incluso en dispositivos muy limitados, LEAP tiene dos modos de ejecución: stand-alone y split (ver figura 5.3). En el primero, el contenedor es ejecutado completamente en el dispositivo móvil, mientras que en el segundo, el contenedor está dividido en dos partes, un FrontEnd,que se ejecuta dentro del dispositivo con recursos limitados, y un BackEnd que se ejecuta en un PC. En el modo “Split” las dos partes están conectadas entre sí permanentemente. Esta ejecución es particularmente conveniente para este tipo de dispositivos, debido entre otras razones a que:

El FrontEnd necesitará los recursos mínimos. La IP del dispositivo móvil va a permanecer oculta a otros contenedores. Se va a permitir un control en la conexión entre el BackEnd y el FrontEnd, de manera que si se produce una desconexión entre el dispositivo móvil y la red, no se va a producir una pérdida de mensajes. La cantidad de datos transmitidos en la red inalámbrica es menor. El tiempo de carga del programa es menor.

Naturalmente el programador no deberá preocuparse del modo de ejecución que presentará el contenedor donde se ejecute su agente dado que las API’s son exactamente las mismas. No obstante sí tendrá que tener en cuenta que un contenedor principal no puede ser dividido. La movilidad de agentes y la clonación no son soportadas en contenedores divididos y además al ejecutar un contenedor dividido, otro contenedor que puede ser o no el principal tiene que ser ejecutado en el PC donde el BackEnd estará activo.


55

Figura 5.3: Modos de ejecución de JADE-LEAP

5.2 MobiAgent

La arquitectura del sistema MobiAgent consiste en tres componentes principales: un dispositivo inalámbrico móvil portátil, un Agente Gateway y los recursos de la red. El Agente Gateway está ejecutando una plataforma de agentes y los agentes para esa plataforma. Cuando el usuario quiere delegar una tarea a un agente, el dispositivo móvil se conecta al gateway y descarga una interfaz que configurará al agente para ella. El agente realizará su tarea e informará los resultados después a través del mismo mecanismo.

Se debe notar que ni la plataforma, ni los agentes están corriendo en el dispositivo, la única aplicación que está corriendo es un MIDlet que configura al agente. Este acercamiento no impone nada a la plataforma o a los agentes que corren en el Agente Gateway; la plataforma que corre puede ser conforme a FIPA, pero esto no es obligatorio.


56

Esta infraestructura está disponible en cualquier dispositivo que soporte J2ME/CLDC/MIDP, incluyendo los teléfonos móviles. La conexión entre el dispositivo y el gateway se hace vía HTTP sobre una red inalámbrica. Desgraciadamente, ningún enlace para descargar la plataforma está actualmente disponible.

5.3 kSACI

kSACI [36] es una versión más pequeña de la plataforma SACI preparada para la KVM. SACI es una infraestructura para crear agentes que pueden comunicarse usando mensajes KQML. Cada agente de SACI tiene un buzón para intercambiar mensajes con los otros. Su arquitectura también contiene un agente especial, llamado el facilitador, ofreciendo los servicios de páginas blancas y amarillas del sistema. La arquitectura de la plataforma no es conforme a FIPA.

La plataforma kSACI es utilizable en dispositivos pequeños que ejecutan la KVM, pero la plataforma no se sitúa completamente en el dispositivo móvil. De hecho, el facilitador está en un servidor y en cada dispositivo pequeño hay sólo un agente corriendo. Este agente debe contener un buzón usado para intercambio de mensajes, pero no sabe cómo pasar los mensajes a los otros; se comunica vía HTTP con un proxy que corre en una máquina de escritorio que más allá pasa los mensajes hacia y desde otros agentes. Esta solución hace el agente más ligero, así esta plataforma puede usarse con dispositivos tan pequeños como un teléfono móvil.

5.4 MAE

MAE [35] es una plataforma de agentes diseñada para ser independiente del dispositivo y del lenguaje de implementación. Para lograr esto, la plataforma se estructura en tres partes:

Especificación del API de Referencia: proporciona una guía que delinea los componentes principales de la plataforma y su comportamiento. Esta especificación es independiente del lenguaje de programación y las características del dispositivo.


57

Implementación de Referencia: un dispositivo y sistema operativo dependiente de la implementación de la plataforma conforme a la especificación anterior. Se supone que las implementaciones trabajan juntas porque ellas están conformando la especificación del API. Adiciones de implementación no estándares: usadas cuando las características específicas de una aplicación necesitan ser implementadas en la plataforma.

Este acercamiento garantiza independencia del dispositivo y del lenguaje de programación, pero el costo en desarrollo puede ser muy alto, cuando varias implementaciones tienen que ser hechas. Los autores han creado dos de ellas, para dos JavaVM, KVM y SuperWaba que es una versión limitada de Java con algunas funcionalidades no soportadas por la versión oficial de Sun como JNI, y las han probado en PDA basadas en PalmOS. La plataforma no es conforme a FIPA, pero proporciona su propia especificación de las que pueden hacerse diferentes implementaciones, actualmente ninguna implementación está disponible para descargar.

MAE está compuesta por un Device Agent Execution Environment (DAEE) que proporciona un conjunto de servicios a los agentes que se ejecutan en la plataforma. Estos servicios se agrupan en tres tipos: presentación, que proporciona los servicios que permiten a los agentes interactuar con el usuario; agente, que proporciona los servicios que permiten a los agentes interactuar con los servicios de red, entre ellos se encuentra el que permite descubrir y anunciar servicios y el que permite conocer el estado de la red; red, que permite a los agentes comunicarse con otros dispositivos.

5.5 AgentLight

AgentLight es una plataforma de agentes con los objetivos de ser capaz de despliegue en dispositivos fijos y móviles con varios sistemas operativos y que puede operar sobre ambos en una red fija o inalámbrica. Sus autores están usando un conjunto de perfiles que permiten configurar la plataforma para varios dispositivos y/o sistemas operativos. También, esta plataforma apunta a ser conforme a FIPA y agnóstica de sistema operativo.


58

La arquitectura de AgentLight es llamada “half-daisy” y consiste de un agente contenedor que corre en cada dispositivo en los que pueden ponerse varios agentes. Si los dos agentes en el mismo dispositivo se comunican entre sí, el agente contenedor hace la comunicación internamente, pero si los agentes están en dispositivos separados, el agente contenedor actúa como un proxy.

Cada agente se ve como un conjunto de reglas y está usando para la ejecución un motor de inferencia proporcionado por el agente contenedor. Esta arquitectura no está completamente conforme a FIPA (por ejemplo el servicio de directorio está faltando) y es todavía trabajo en progreso. Puede correr en dispositivos con J2ME/CLDC/MIDP y con la KVM y el dispositivo objetivo más pequeño es un teléfono móvil, aunque por el momento no hay ninguna prueba para demostrar que un teléfono móvil puede soportar la plataforma, sobre todo el motor de inferencia que puede ser bastante pesado al momento de la ejecución.

El proyecto AgentLight fue retirado el año 2004. Básicamente, fue un esfuerzo por tomar las actuales teorías de Sistemas Multiagente para así expandirlas al ambiente de los dispositivos portátiles. Con el aumento en el uso de dispositivos móviles poderosos se espera que con el tiempo el mercado exija servicios altamente personalizados y conscientes del contexto que llevarán hacia la pervasive computing.

El objetivo de este proyecto era reunir teoría y práctica, construyendo las bases para

desarrollar sistemas de agentes autónomos basados en reglas para dispositivos pequeños. Fue reemplazado por un nuevo proyecto, el 3APL-M, que permite la creación de Agentes Deliberativos para dispositivos móviles, usando el lenguaje 3APL.

5.6 MicroFIPA-OS

MicroFIPA-OS es un toolkit de agentes para dispositivos pequeños basado en la plataforma de agentes FIPA-OS y se desarrolló en el proyecto CRUMPET [33]. Mantiene un ambiente de ejecución para uno o más agentes y soporta aproximadamente las mismas funcionalidades que el estándar FIPA-OS, pero se ha perfeccionado para ambientes de recursos restringidos.


59

La plataforma puede correr en modo mínimo, dónde los agentes no están usando los administradores de tarea y de conversación. Esto significa que el desarrollador debe hacer alguna programación de bajo nivel, pero los agentes creados son más livianos. Incluso en el modo mínimo, la plataforma está conforme a FIPA.

El ambiente objetivo para MicroFIPA-OS es una PDA de mediano a alto nivel capaz de ejecutar el PersonalJavaVM. La plataforma se ejecuta completamente en el dispositivo, pero se recomienda que sólo un agente se ejecute en cada dispositivo móvil. Sin embargo, las pruebas muestran que es posible correr en un Compaq iPAQ los dos servicios especiales propuestos en los estándares FIPA, los servicios de páginas blancas y amarillas.

Cabe mencionar que solamente existen un par de versiones de la plataforma MicroFIPA-OS, ya que una mayor evolución no fue contemplada fuera del proyecto. No ocurre lo mismo con su plataforma padre FIPA-OS, la que sí presenta más de un par de versiones.

60

Capítulo 6

Casos de Estudio

Hoy, Internet conecta casi todos los computadores del mundo y muchas cosas que se imaginaban imposibles hace poco tiempo, hoy son realidades o se intuye que muy pronto se podrán alcanzar con el uso de la tecnología. Algunos de estos avances tienen que ver con la miniaturización de los computadores aplicada al diseño de procesadores incorporados y de computadores móviles (palm-tops, PDA’s, teléfonos, tarjetas inteligentes, etc.), con los avances de las redes inalámbricas basadas en radiofrecuencia (entre las que destacan Bluetooth e IEEE802.11) o en infrarrojos (tales como IrMC), con los sistemas de localización en interiores y exteriores (como el GPS), etc. Es en este contexto que surgen nuevos términos que merecen ser mencionados, tales como Pervasive Computing, Ubiquitous Computing y Mobile Computing; los que dan origen a nuevos campos de aplicación y con ello a nuevos negocios.

El término Ubiquitous Computing o Computación Ubicua, fue acuñado hace más de diez años por Mark Weiser, un investigador del Palo Alto Research Center de XEROX. Weiser ve la tecnología solamente como un medio para un fin y como algo que debería quedar en segundo plano para permitir al usuario concentrarse completamente en la tarea que está realizando. En este sentido, considerar el computador personal como herramienta universal para la tecnología de la información sería un enfoque equivocado, ya que su complejidad absorbería demasiado la atención del usuario. Según Weiser, el computador como dispositivo dedicado debería desaparecer, mientras que al mismo tiempo debería poner a disposición de todo lo que nos rodea sus capacidades de procesamiento de la información.

Weiser ve el término Computación Ubicua en un sentido más académico e idealista como una visión de tecnología discreta, centrada en la persona, mientras que la industria ha acuñado por eso el término Computación Pervasiva, o también conocida como Pervasive Computing con un enfoque ligeramente diferente.

Capítulo 6: Casos de estudio

61

Aunque su visión siga siendo todavía integrar el procesamiento de la información en objetos cotidianos de forma casi invisible, su objetivo principal es utilizar tales objetos en un futuro próximo en el ámbito del comercio electrónico y para técnicas de negocios basados en la Web.

Por decirlo de otra forma, la expresión Pervasive Computing que en la literatura anglosajona se propone como sinónimo de Ubiquitous Computing, significa la omnipresencia de computadores muy pequeños interconectados sin cables que se incrustan de forma casi invisible en cualquier tipo de objeto cotidiano. Usando pequeños sensores, estos procesadores incrustados pueden detectar el entorno que les rodea y equipar a su objeto con capacidades tanto de procesar información como de comunicación.

Por último, el término Mobile Computing o Computación Móvil se puede definir como la serie de aparatos y equipos portátiles, hardware, que hacen uso de la computación para lograr su funcionamiento, así, se tiene a los computadores portátiles, los teléfonos celulares, los cuadernos de notas computarizados, las calculadoras de bolsillo, etc. Resultaría ilógico pensar en la computación móvil con un largo cable de conexión, así que la comunicación inalámbrica juega un papel preponderante en este concepto, por lo que muchas empresas han realizado esfuerzos por proporcionar los recursos necesarios para hacerlo posible.

Aunque en la actualidad no son muchas las personas que traen su computador bajo el brazo, tampoco son raras, y es que la computación móvil ha dejado de ser un instrumento de presunción, para convertirse en un medio de trabajo. Pero eso no es todo: empieza a transformarse en “el” medio de trabajo. Ya es parte del uniforme de profesionales, de vendedores y hasta de repartidores que con él controlan el inventario de su camión.

Luego de conocer términos como Pervasive Computing o Mobile Computing, a continuación se presentan algunos casos de estudio que involucran tanto la tecnología de agentes como los conceptos presentados anteriormente, entre los cuales interesa destacar aquellos ligados al uso de dispositivos móviles; utilizando estas tecnologías en diferentes áreas de aplicación como lo son la salud, el turismo, el transporte, entre otras. Estos casos de estudio fueron analizados para, entre otras cosas, conocer algunas áreas de aplicación de las tecnologías mencionadas anteriormente, identificar los problemas que se tratan de resolver, revisar las soluciones o arquitecturas implementadas, identificar las pruebas que


62

se realizaron; todo lo anterior nos permite tomar las decisiones necesarias respecto al sistema multiagente a desarrollar en este proyecto.

6.1 PalliaSys: Sistema Multiagente para Asistencia de

Pacientes Terminales

PalliaSys [38] se trata de un sistema en red orientado a la asistencia remota de los pacientes de una Unidad de Cuidados Paliativos (UCP) de un gran hospital. Esta unidad se especializa en tratar a gente con enfermedades terminales, y su objetivo es aliviar su dolor en la fase final de sus vidas. Dependiendo del diagnostico médico inicial, el paciente puede ser tratado en la UCP, en otra unidad del hospital, en un centro socio sanitario asociado al hospital, o en su casa. Debido al carácter altamente distribuido del cuidado paliativo, es particularmente interesante tener un sistema informático que permita el intercambio de la información entre el personal que participa en el tratamiento de un paciente (doctores de la UCP, doctores asociados a otras unidades o a un centro socio sanitario, los equipos médicos que hacen visitas en los hogares de los pacientes, los cuidadores de la persona). El sistema PalliaSys está especialmente dirigido a los pacientes que permanecen en sus hogares, de modo que tengan la posibilidad de tener acceso a algunos servicios sin tener que desplazarse al hospital.

El sistema PalliaSys permite mejorar el proceso de recopilar y de recoger la información de los pacientes paliativos. Los datos se almacenan en una base de datos central situada en la UCP del centro médico. El sistema proporciona a los usuarios que participan en el cuidado de un paciente paliativo un acceso seguro y autenticado a los datos de los pacientes. También permite mejorar la información de la que disponen los doctores sobre los pacientes. Usando un Sistema multiagente es posible supervisar continuamente el estado de cada uno de los pacientes y pro activamente proporcionar información personalizada, detallada y actualizada a los doctores de la UCP. Éste es uno de los aspectos principales del sistema. Finalmente, el sistema PalliaSys permite hacer un análisis inteligente de los datos históricos recopilados en la UCP, aplicando técnicas novedosas de minería de datos y técnicas de aprendizaje. Por ejemplo, es factible definir modelos de pacientes, analizar la evolución médica y los flujos de diversos tipos de pacientes, y crear los modelos de estas evoluciones que permiten hacer predicciones de los estados futuros de pacientes.


63

La arquitectura básica del sistema PalliaSys se muestra de forma simplificada en la figura 6.1.

Figura 6.1: Arquitectura del sistema PalliaSys

Dos partes principales pueden ser distinguidas dentro del sistema:

Tecnologías de la información y las comunicaciones, usadas por los pacientes en sus hogares para proporcionar o consultar sus datos médicos personales, para enviar auto-evaluaciones o para recibir la información de los doctores.

Un sistema multiagente, usado para manejar con seguridad los datos clínicos, sin perder de vista el estado de los pacientes paliativos y analizando su evolución.


64

En el sistema, podemos encontrar seis tipos de agentes:

Agente Wrapper de la Base de datos. Este agente controla el acceso a la base de datos de la UCP. Incluye los mecanismos de autentificación que aseguran que solamente los agentes correctamente autorizados puedan solicitar los datos clínicos para leerlos o modificarlos. En este agente se aplican algunos mecanismos de seguridad, tales como la definición de diversas clases de usuarios, la asignación de diversos permisos a cada uno de ellos, el uso de contraseñas y el cifrado de mensajes usando SSL. Un agente doctor para cada doctor de la UCP. Este agente funciona en el computador personal del doctor. Proporciona una interfaz gráfica que permite que el doctor obtenga fácilmente la información de sus pacientes, controle el horario de visitas, o compruebe si el sistema ha activado alguna alarma con respecto al deterioro de la salud de un paciente. Un agente paciente para cada paciente. Cada uno de estos agentes es responsable de controlar la evolución del paciente. Estos agentes deben comprobar si los pacientes envían los informes periódicos referentes a su estado de salud o no. Una característica interesante es que si el agente paciente detecta cualquier problema (Ej. el grado de dolor ha aumentado desde la auto-evaluación pasada), puede enviar una advertencia al agente doctor responsable de ese paciente, para tomar las medidas apropiadas (Ej. una llamada telefónica o una visita a domicilio del paciente). El sistema multiagente también incluye un agente, el analizador de los datos, especializado en la minería de datos, el descubrimiento del conocimiento y técnicas de aprendizaje automático. Su tarea principal es realizar un análisis inteligente de la evolución de los pacientes y descubrir conocimiento médico interesante y útil. Por otra parte, el jefe de la UCP tiene el deber administrativo de escribir un informe anual que detalla toda la actividad de la unidad en el plazo de los 12 meses pasados. Para facilitar esta tarea, el agente analizador también proporciona una serie de estadísticas básicas sobre los datos de la BD de la UCP. Un agente Socket que permite la comunicación entre las dos partes de la arquitectura del sistema Palliasys. Este agente será el encargado de avisar a los agentes pacientes para que realicen la tarea de chequeo de alarmas con la consiguiente activación si es necesario.


65

Y finalmente un agente que se ejecuta en entornos móviles. Este agente nos permite interactuar con el sistema mediante un aparato de telefonía móvil, pudiendo enviar una auto-evaluación desde cualquier lugar donde se encuentre el paciente.

En la situación actual, todos los pacientes tienen que hacer visitas periódicas al hospital, para ser examinados por los doctores y controlar su evolución. En cada visita los pacientes tienen que completar un formulario de auto-evaluación. En este documento tienen que evaluar (con un valor entre 0 y 10) diez aspectos subjetivos relacionados con su salud: los grados de dolor, debilidad, depresión, ansiedad, vómito, insomnio, hambre, bienestar, problemas de respiración y sequedad de boca. Durante la visita, el doctor comprueba todos los valores y los puntúa según su criterio experto. Además, el doctor también evalúa los criterios de complejidad (características personales del paciente, problemas médicos especiales, estrategias terapéuticas). Finalmente, el doctor puede tomar algunas decisiones referentes al cuidado del paciente, tales como pruebas clínicas que posteriormente ordenan, modificar el tratamiento del paciente, o cambiar la ubicación del paciente (por ejemplo, hospitalizar a un paciente en un centro socio sanitario si su salud se ha deteriorado demasiado).

Uno de los objetivos del sistema PalliaSys es facilitar el proceso de recolección de información de las autoevaluaciones de los pacientes, de modo que puedan enviar esta información periódicamente desde sus hogares (Ej. cada semana) sin tener que ir al hospital tan a menudo. La idea es poner a su disposición las diversas tecnologías de la información y las comunicaciones, tales como la Web, teléfonos móviles o PDA’s, de modo que cada paciente pueda elegir la manera de comunicación que le sea más cómoda o fácil de utilizar. Los mismos canales de comunicaciones se pueden utilizar también para recibir la información del sistema. Hay alrededor de 500 nuevos pacientes en la UCP del Hospital cada año, así que la cantidad de datos generados por auto-evaluaciones semanales es muy grande, y es una tarea muy costosa en tiempo para los doctores estudiar toda esta información y analizar la evolución de cada paciente en las semanas o los meses pasados. Por ello los doctores sugirieron que podría ser muy útil tener una manera de analizar automáticamente toda esta información y ser alertados cuando ocurra una situación anómala. En el sistema PalliaSys, este proceso de recolección de información es posible mediante un teléfono móvil ya que el sistema implementa un agente, capaz de ejecutarse en entornos móviles.


66

6.2 PUMAS: Framework que Adapta la Información en

Ambientes Ubicuos

PUMAS (Peer Ubiquitous Multi-Agent System) [39] es un framework cuyo objetivo principal es el de recuperar de diferentes fuentes, la información que se ajuste tanto al perfil del usuario (el cual contiene sus necesidades, características, preferencias, historia en el sistema, localización actual, etc.), como a las características técnicas del Dispositivo Móvil que el usuario usa para acceder a Sistemas de Información Web (SIW). La arquitectura de PUMAS se compone de cuatro Sistemas multiagente (SMA), cada uno compuesto de uno o más agentes ubicuos (ubiquitous agents) que cooperan con el fin de llevar a cabo los diferentes servicios ofrecidos por PUMAS (tales como conexión/desconexión de los Dispositivos Móviles, búsqueda de información en diferentes fuentes, etc.). En PUMAS se utilizan archivos XML para representar la información manejada por los agentes (datos sobre las características del usuario, sus sesiones, su Dispositivo Móvil y sus preferencias, los roles de los agentes y las reglas que controlan su comportamiento).

Los SIW pueden ejecutarse en uno o más servidores o, en uno o más Dispositivos Móviles. Los agentes de PUMAS están organizados para llevar a cabo una búsqueda inteligente (basada tanto en el conocimiento propio, adquirido e inferido de los agentes, como en su capacidad de razonamiento) y adaptativa (ya que toma en cuenta las características del usuario y las de su Dispositivo Móvil) de la información que el usuario requiere proveniente de uno o más SIW. Cuando un usuario nómada busca información a través de su Dispositivo Móvil, sus consultas se propagan a través de los agentes de PUMAS (que adicionan a estas consultas algunas características del usuario y de su Dispositivo Móvil para ser tomadas en cuenta al adaptar la información) hacia el Router Agent (del SMA de Información). Dicho agente ejecuta el proceso de enrutamiento de consultas (Query Routing) que consiste en la búsqueda de fuentes de información adecuadas que pueden responder las consultas del usuario teniendo en cuenta las preferencias del usuario, las características de su Dispositivo Móvil, su localización, etc. Esta búsqueda se basa en el conocimiento manejado e intercambiado por los agentes de PUMAS (especialmente, aquellos pertenecientes a los SMA de Información y de Adaptación).


67

La arquitectura de PUMAS está compuesta de cuatro Sistemas multiagente como muestra la figura 6.2.

Figura 6.2: Arquitectura de PUMAS

El SMA de Conexión provee los mecanismos que facilitan la conexión de diferentes tipos de Dispositivos Móviles al sistema (plataforma central de PUMAS). Este SMA incluye uno o más Mobile Device Agents y un Connection Controller Agent.

El SMA de Comunicación garantiza una comunicación transparente entre los Dispositivos Móviles y el sistema. También aplica el Filtro de Despliegue (Display Filter) que consiste en mostrar al usuario a través de su Dispositivo Móvil, la información de acuerdo a las restricciones técnicas del mismo. Para hacer esto, este SMA cuenta con la ayuda de los agentes del SMA de Adaptación. Este SMA está compuesto de uno o más Proxy Agents, un MDProfile Agent y un Coordinator Agent. Estos agentes se ejecutan en la plataforma central de PUMAS.

El SMA de Información recibe las consultas (queries) del usuario y las redirecciona hacia el Sistema de Información (SI) más “adecuado” (por ejemplo, el más cercano, o el SI que frecuentemente responde la consulta del usuario, o el más consultado), aplica el Filtro


68

de Contenido (Content Filter), con la ayuda de los agentes del SMA de Adaptación, de acuerdo al perfil de usuario en el sistema (es decir, sus preferencias, su historia) y retorna los resultados “filtrados” al SMA de Comunicación. El SMA de Información está compuesto de un Receptor/Provider Agent, un Router Agent y uno o más ISAgents.

Los agentes del SMA de Adaptación se comunican con los agentes de los otros tres SMA con el fin de intercambiar información acerca del usuario (explícitamente extraída de los archivos XML o inferida de las reglas que administran el sistema), acerca de la conexión y comunicación, sobre las características del Dispositivo Móvil, etc. Los servicios y tareas desempeñados por el SMA de Adaptación consisten esencialmente en el manejo de archivos XML específicos que contienen información sobre el usuario y su Dispositivo Móvil. Los agentes del SMA de Adaptación manejan conocimiento (almacenado en Bases de Conocimiento, BC) que permite filtrar la información a los usuarios. Existe también conocimiento que es inferido a partir del análisis de la historia del usuario en el sistema, incluyendo sus últimas conexiones, consultas, preferencias, etc. El SMA de Adaptación está conformado por uno o más UserAgents, un DisplayFilterAgent y un ContentFilterAgent. Estos agentes se ejecutan en la plataforma central de PUMAS.

El comportamiento de PUMAS es el de un sistema P2P híbrido. El núcleo de PUMAS centraliza las consultas y: i) está a cargo del proceso de obtener la información más relevante, ii) está a cargo de aplicar los filtros de Contenido y de Despliegue para adaptar las respuestas y iii) traduce los archivos XML en “hechos”, piezas fundamentales del conocimiento de los agentes. Las principales características de un sistema P2P que poseen los agentes de PUMAS se ilustran en el hecho de que en primer lugar, los agentes tienen la autonomía de conectarse y desconectarse del sistema. En segundo lugar, un Dispositivo Móvil puede comunicarse con un Sistema de Información específico (localizado en un servidor o en un Dispositivo Móvil) pasando esta información como un parámetro de la consulta; el Router Agent transmite la consulta a este Sistema de Información específico que ejemplifica una comunicación agente-agente.


69

6.3 W-planner: Sistema Multiagente Online Aplicado al

Turismo Electrónico

W-planner [40] es un sistema multiagente que utiliza un mecanismo de razonamiento basado en casos para generar sus planes, y dar solución al problema de planificación de un turista que visita por primera vez una ciudad y que exige condiciones sobre la ruta solución (por ejemplo, lo que debe durar o lo que puede gastar). Este planteamiento se fundamenta en un soporte matemático basado en el cálculo variacional y en técnicas de Campos de Jacobi, que permiten introducir un mecanismo para la planificación y re-planificación del agente en tiempo real.

Se utiliza un modelo de agente conocido como BDI que estructura sus capacidades con base en información diferente, la cual se clasifica en tres tipos de instancias: conocimiento del sistema (Beliefs), objetivos que pretende alcanzar (Desires) y compromisos entre su conocimiento y el modo de alcanzar los objetivos (Intentions).

Mediante la implementación de este sistema, queda demostrado cómo la estructura de agentes a los que se les implementa un motor de razonamiento basado en casos CBR (Case Based Reasoning) puede acelerar sustancialmente el proceso de deliberación y resuelve los problemas relacionados con la capacidad de aprendizaje de los agentes: implementar agentes en la forma de sistemas CBR facilita su aprendizaje y adaptación.

Los sistemas de razonamiento basado en casos (CBR) se usan para resolver problemas mediante la adaptación de soluciones que fueron usadas en la resolución de problemas similares. El proceso de trabajo de un sistema CBR consiste, fundamentalmente, en la adaptación de viejas soluciones para construir planes asociados a nuevas experiencias, usando casos ya validados para plantear nuevas propuestas, para formular nuevas soluciones o para razonar de manera análoga en situaciones similares.

En el desarrollo de este sistema se hace referencia a un problema de planificación turística en el que un usuario (turista) solicita un plan (ruta) de acuerdo con unos requerimientos iniciales (Costo, Tiempo de Visita, Hora de Inicio, etc.) al sistema, el cual tiene almacenado un conjunto de planes que fueron definidos con anterioridad. La solución final planteada por el sistema multiagente debe cumplir con las restricciones impuestas por el usuario.


70

El sistema propuesto está compuesto por múltiples agentes que interactúan, coordinándose y dando una solución acorde con las necesidades del usuario. Esto permite la elaboración de una arquitectura distribuida que presenta propiedades deseables para enfrentarse a entornos típicos de planificación no-clásica como la escalabilidad, fiabilidad y reutilización de soluciones, que produce mejoras en el desempeño de la solución. La arquitectura multiagente se centra en un agente planificador que se comunica con otros agentes para dar soluciones al usuario (representado por medio de un dispositivo inalámbrico). La elección de un CBR como motor de razonamiento no es casual y se debe a las características intrínsecas del problema de planificación analizado ya que, aunque se admiten cambios en el entorno que pueden modificar los planes que ya están en ejecución, la estructura del entorno (como los monumentos a visitar, la distribución de ellos, el costo de la visita, el tiempo promedio de la visita) permanece estática, lo que posibilita aprovechar los planes que en el pasado han sido exitosos para otros turistas con condiciones similares. Este es esencialmente el modo de trabajo de un sistema CBR.

Como se dijo anteriormente, el modelo propuesto está basado en una arquitectura BDI (Beliefs, Desires, Intentions - Deseos, creencias e Intenciones) donde las Creencias del Sistema son los monumentos, plazas, museos o lugares públicos que representan un interés turístico para aquellas personas que desean visitar una ciudad los que están caracterizados por un conjunto de atributos que los identifican (Ej. nombre, horario, costo visita, indicador de calidad, zona, tiempo visita); los Deseos del Sistema son los requerimientos definidos por el turista delimitados por los atributos de las Creencias, los que fueron ingresados a través de su dispositivo móvil; y por último, las Intenciones del Sistema son las rutas o planes posibles que el usuario debe seguir para visitar la ciudad conservando las restricciones impuestas por él mismo anteriormente, las que también serán visualizadas a través del dispositivo móvil.

Este sistema multiagente está formado básicamente por cuatro agentes como muestra la figura 6.3:

Agente Planificador, basado en una arquitectura BDI que permite analizar de las diferentes alternativas tomadas como base en un entorno dinámico, cuál es la ruta más fácilmente replanificable. Esta arquitectura permite que las creencias que representan a los sitios turísticos que se pueden visitar en una ciudad (en este caso Salamanca), se encuentren parametrizadas de manera que puedan ser fácilmente adaptables a otra ciudad, a través de un algoritmo que genera las intenciones


71

(posibles rutas) que son susceptibles de ser visitadas por el usuario. Estas rutas son los casos que se recuperan para analizar cuál es el de mayor expectativa de éxito de acuerdo con las condiciones definidas por el turista a través del dispositivo móvil. Agente Turista, se encuentra instalado en un dispositivo móvil y su objetivo es el de capturar las preferencias del turista de acuerdo con el costo, tiempo de visita y hora de inicio. Debe establecer una comunicación con el Agente Planificador quien, según estas restricciones, le enviará la ruta con mayor probabilidad de éxito. Agente Actualizador, encargado de modificar el estado de las creencias (Monumentos) y las intenciones (rutas), previa solicitud del Agente Rastreador. Como resultado de esta actualización se guarda un registro de los cambios solicitados por los agentes. Agente Rastreador, es un agente que se encuentra en un dispositivo móvil y que permite enviar una solicitud al Agente Actualizador para conocer el estado de las creencias y si lo desea cambiar dicho estado, dando a su vez lugar al cambio de las intenciones que contengan esas creencias.

Figura 6.3: Agentes del Sistema W-planner

Para el desarrollo y prueba de la aplicación se utilizó un teléfono celular Nokia 7650 con Bluetooth y conexión GPRS para poder acceder al computador Host. En el Host se encuentra instalado JADE-LEAP y la versión de Java sdk 1.4.2.


72

6.4 Sistema Multiagente para la Gestión de Taxis en una

Ciudad

El objetivo de este sistema es la utilización de las ventajas que proporciona la implementación de un Sistema Multiagente para optimizar de forma sustancial todo el proceso que conlleva las demandas de taxis en una ciudad [41]. En concreto, el presente sistema se encarga de facilitar la gestión de los taxis de una compañía que opere en una ciudad. Por lo tanto, se gestionan de forma automática las peticiones de taxis de los clientes y se pretende mejorar el proceso de selección de taxis basándose en las propuestas realizadas por los propios taxistas. De este modo, se podría sustituir el sistema actual de radio por un sistema informático que operaría con computadores de abordo.

A continuación se hace una breve descripción del funcionamiento del sistema. El cliente realiza una petición mediante su agente personal que en este caso se estará ejecutando en una PDA, pero que podría adaptarse a un teléfono móvil, simplemente cambiando la interfaz gráfica. Cuando la centralita (mejor conocida como central para nosotros) reciba una petición se pondrá en contacto con todos los taxis que estén trabajando en ese turno. Los taxis que estén realizando su servicio enviarán el recorrido que deben realizar para llegar hasta el cliente junto con más información a la centralita y ésta escogerá al más adecuado teniendo en cuenta el taxi más cercano en términos de tiempo, en otras palabras, el taxi elegido puede no ser el más cercano, pero si será el que tardará menos tiempo en llegar hasta el cliente (esto es debido a que se toma en cuenta el nivel de tráfico de las calles).

Como en toda ciudad, siempre hay alguna calle cortada, ya sea por congestión circulatoria, por accidente o por obras. Para incrementar la eficiencia del sistema fue creado un agente tráfico que se encarga de dar en cada turno laboral, información sobre el estado de las calles. Así, los taxis tomarán siempre en cuenta el estado del tráfico para realizar con mucha más eficacia y anticipación sus propuestas de recorrido.

Una vez escogido el taxi apropiado, la centralita envía una respuesta al cliente dándole una información muy detallada sobre el servicio que le será brindado.

En la figura 6.4 se muestra la arquitectura completa del sistema, representando cada agente y los diferentes mensajes entre ellos. Se debe señalar que al estar trabajando en un


73

entorno distribuido los elementos se reparten entre varias estaciones. Para este caso, el AgenteCliente se encuentra en una PDA y el resto de los agentes en un computador convencional. Para un caso más real, cada AgenteTaxi se encontraría en cada uno de los taxis que recorren la ciudad, el AgenteTrafico se situaría en alguna estación perteneciente a la Dirección de Control de Tránsito, el AgenteCentralita y el AgenteVisualizador se encontrarían en la empresa de taxis, y como ya fue comentado el AgenteCiente se encontraría en la PDA o teléfono móvil del cliente que solicita un taxi.

Figura 6.4: Arquitectura del sistema multiagente

En el sistema se pueden identificar cinco tipos de agentes:

Agente Cliente: El agente CLIENTE representa a una persona que pide un taxi en una ciudad, por lo tanto es el iniciador de todo el proceso. Su función principal es la de proporcionar toda la información necesaria sobre su petición al agente CENTRALITA. Para ello se pone en contacto con el agente CENTRALITA del


74

Sistema multiagente, es decir, la centralita de su ciudad. Una vez enviada la petición, será procesada por la centralita y esta dará una respuesta al Cliente, dándole los datos del taxi que vendrá a recogerlo, junto con el tiempo que tardara el taxi en recoger al cliente, el precio del viaje y el trayecto, que será visualizado en el mapa de la PDA.

Agente Centralita: El agente CENTRALITA es uno de los más importantes del sistema, ya que, es el coordinador de las diferentes peticiones de los clientes. Su funcionamiento es primordial para obtener un resultado adecuado. La función principal es la de coordinar las peticiones y escoger el taxi que mejor se adapte a las necesidades del cliente, aunque también se encarga de actualizar la información de los taxis para saber cuáles están trabajando en el turno actual y avisar al cliente del resultado de su demanda. Una vez recibida la petición, se envía la información recibida a cada taxi y se espera la recepción de sus propuestas. Al recibirlas, se escoge la más adecuada, tomando en cuenta la distancia que separa el taxi del cliente además del costo de circular por los tramo necesarios.

Agente Taxi: El agente TAXI es el que representa a un taxi de la ciudad. La idea es sustituir los sistemas de radiofrecuencia, por computadores de abordo que faciliten la tarea del taxista, ofreciéndole información muy valiosa para su trabajo. La función principal del agente Taxi es la de ofrecer un recorrido, tanto de búsqueda del cliente, como de realización de servicio, lo más óptima posible. En el sistema el taxi calcula siempre el camino más corto desde su posición actual, hasta llegar a la del cliente. Para hacerlo utiliza algoritmos de Inteligencia Artificial basados en búsqueda heurística, en concreto aplica el algoritmo A* con una función heurística basada en la distancia de Manhattan. Una vez ha calculado el recorrido, el agente taxi se lo envía a la Centralita, que posteriormente se encarga de seleccionar el Taxi que sea más idóneo para el servicio requerido.

Agente Visualizador: El agente VISUALIZADOR, sirve para monitorear el sistema y estudiar el prototipo. En un entorno real, podría ser usado por la empresa encargada de la gestión de los taxis, y así llevar un control de los servicios realizados. En el sistema actual, su uso quedó limitado a desplegar el mapa que indica todas las rutas posibles incluyendo los posibles problemas registrados en los caminos. Tanto la interfaz gráfica del Agente Cliente como del Agente Visualizador funcionan de manera similar para dibujar las rutas en pantalla.


75

Agente Tráfico: El agente TRÁFICO es el encargado de informar sobre el estado de las calles. En el sistema actual, indica qué calles son las que están cortadas por una serie de motivos que anteriormente fueron comentados, aunque en un entorno real sería más útil realizar una conexión remota a la Dirección de Control de Tránsito y así poder estar completamente informado en todo momento del estado de las calles. Toda esta información es utilizada por los Agentes Taxi para calcular los recorridos que debieran hacer a la hora de cumplir con una petición.

Para la implementación del sistema se ha utilizado la plataforma JADE-LEAP, además de otros recursos de hardware como una PDA Fujitsu-Siemens Pocket LOOX 600, dotada de Windows PocketPC 2002; un PC con procesador AMD 900 mhz y 256m ram con windows XP; otro PC con procesador intel P4 2.6ghz y 256m ram con windows XP; un teléfono móvil Siemens S55.

76

Capítulo 7

Desarrollo del Sistema

7.1 Elecciones de Diseño

7.1.1 Caso de Estudio

El paradigma de agentes nos permite crear sistemas que pueden ofrecer servicios complejos y sofisticados a diferentes tipos de usuarios. El presente proyecto tiene como objetivo principal el desarrollar un Sistema multiagente que pueda ser accedido desde dispositivos móviles como teléfonos celulares o PDA’s para un cierto dominio dado. En particular el dominio escogido es el de la educación, más específicamente un ambiente universitario. La finalidad del sistema es la utilización de las ventajas que proporciona la implementación de un Sistema multiagente para optimizar de forma sustancial todo el proceso que conlleva la gestión de las reservas de los libros de la biblioteca en una universidad. Este problema fue seleccionado debido a la cercanía que representa para los alumnos de una universidad ya que se trata de un tema que los involucra directamente. Desde el punto de vista de un alumno, sería de gran utilidad poder hacer la reserva de un libro a través de su teléfono celular o PDA para luego dirigirse hasta la biblioteca solamente para retirarlo sin mayor trámite que cumplir debido a que la operación ya fue registrada y validada por el sistema. Otra opción que puede entregar el sistema es la consulta de cierto libro por parte del alumno o las reservas hechas del mismo, ya sea teniendo el título específico del libro o el área temática en especial a la que pertenece para lo cual se entregaría una serie de resultados que cumplen con el área solicitada. Además se podrá permitir que los funcionarios de la biblioteca pudieran agregar o quitar libros del sistema, consultar las reservas hechas de un libro o establecer restricciones en la reserva de cierto libro, todo mediante el uso también de dispositivos móviles o sino a través de computadores fijos.

Capítulo 7: Desarrollo del sistema

77

Cada usuario, tanto los alumnos como los funcionarios de la biblioteca, tienen diferentes necesidades y diferentes características por lo que debieran ser representados a través de agentes diferentes que representen el perfil correspondiente. Puesto que los agentes necesitan comunicarse entre ellos, será necesario establecer un vocabulario conceptual común como una representación de la información para establecer y controlar las tareas. Toda esta información queda representada dentro de una ontología específica que deberá ser desarrollada.

Debido al uso de dispositivos móviles, el acceso a la información del sistema podrá ser realizado en cualquier momento y lugar dentro de la universidad. Se debe señalar que el sistema debe ofrecer los servicios de manera ininterrumpida, lo que implica mantener la información disponible todo el tiempo, para lo cual se necesitaría una arquitectura distribuida y eficiente. En cuanto al acceso al sistema, la idea es que tanto los alumnos como lo funcionarios encargados de la biblioteca puedan establecer la conexión requerida para el sistema usando el acceso WiFi que se encuentra disponible en nuestra universidad. Se pensó en este tipo de conexión debido a que esta cubre por completo la universidad y permite una velocidad de conexión apropiada, además de quedar libre de costo. Cabe mencionar que esta opción es posible únicamente en dispositivos móviles como una PDA con acceso mediante WiFi integrado. En el caso de un teléfono móvil, la conexión puede se establecida mediante GPRS o GSM con el consiguiente costo para el alumno. Es importante aclarar que todo lo anterior depende fundamentalmente del dispositivo móvil que pueda ser conseguido para llevar a cabo las pruebas del sistema en un ambiente real, por lo que en un principio solo se contempla el trabajo mediante emuladores, ya sea de teléfonos móviles o PDA’s.

7.1.2 Plataforma Multiagente

Luego de analizar el conjunto de plataformas multiagente que permiten la implementación de estos sistemas sobre dispositivos móviles y que fueron presentadas en el capítulo 5, la plataforma multiagente elegida para llevar a cabo el proyecto es JADE-LEAP. Entre las razones de esta elección podemos señalar que el ambiente de desarrollo que proporciona JADE es mucho más intuitivo y fácil de utilizar por lo que hace que cualquier persona con una base en programación y conocimientos de Java, pueda empezar a implementar agentes de manera más rápida que utilizando alguna de las otras plataformas indicadas. Además se encuentra administrada por un consorcio internacional sin fines de


78

lucro encargado de promover, guiar e implementar su evolución; por lo que cuenta con un fuerte respaldo técnico y un sitio Web que está totalmente activo y es continuamente actualizado donde se pueden encontrar todas las versiones que han sido liberadas. Otro punto importante es la documentación, JADE proporciona una completa documentación actualizada sobre la plataforma así como una gran cantidad de ejemplos y tutoriales para comenzar la programación con la plataforma. También cuenta con un conjunto de herramientas gráficas que ayudan en la gestión, control, monitoreo y debugging de los agentes programados. Por último, JADE es la plataforma más utilizada en cuanto a proyectos de investigación y desarrollo se refiere, realizados tanto por la comunidad académica como por la industria, lo que permite reutilizar el conocimiento y las experiencias obtenidas por ellos.

7.1.3 Metodología de Desarrollo Orientada a Agentes

Es importante contar con una metodología de desarrollo orientada a agentes que facilite el trabajo en cuanto al análisis, diseño e implementación del sistema multiagente a elaborar durante el proyecto. Debido a lo anterior y luego de analizar una serie de metodologías, entre las que se incluyen las presentadas en el capítulo 4, se llega a la conclusión de que la metodología más completa, debido a que apoya al programador durante todo el ciclo de vida del software a través de la elaboración de diferentes productos a lo largo de distintas fases y a que cuenta con una herramienta que permite generar el código fuente de manera automática llamada AgentTool, es la metodología MaSE. Además, esta metodología tiene un claro acercamiento a los conceptos de orientación a objetos vistos a lo largo de diferentes ramos lo que debería ser una ventaja para el desarrollo.

7.2 Análisis

Tanto el análisis como el diseño del Sistema se han realizado con la metodología orientada a agentes MaSE y mediante la herramienta gráfica agentTool en su versión 1.8.3.

Las fases que se aplican en MaSE son las siguientes:

Captura de objetivos. Aplicar casos de uso y crear diagramas de secuencia.


79

Construir la ontología. Construir el modelo de rol y los diagramas de tareas

7.2.1 Requerimientos del sistema

El proyecto se centra en el desarrollo de un Sistema que pueda ser accedido desde dispositivos móviles como teléfonos celulares o PDA’s para optimizar de forma sustancial todo el proceso que conlleva la gestión de reservas de libros en una biblioteca.

Desde el punto de vista de un alumno, sería de gran utilidad poder hacer la reserva de un libro a través de su teléfono celular o PDA para luego dirigirse hasta la biblioteca solamente para retirarlo sin mayor trámite que cumplir, debido a que la operación ya fue registrada y validada por el sistema. Otra opción que puede entregar el sistema es la consulta de cierto libro por parte del alumno o las reservas hechas del mismo, ya sea teniendo el título específico del libro, el área temática en especial a la que pertenece o el autor del libro, para tales casos se entregaría una serie de resultados que cumplen con el criterio seleccionado.

Por parte de los funcionarios de la biblioteca, el sistema podrá permitir que pudieran agregar o quitar libros del sistema, consultar las reservas hechas de un libro o establecer restricciones en la reserva de cierto libro, todo mediante el uso también de dispositivos móviles. Las consultas sobre libros y reservas pueden ser hechas según los mismos criterios establecidos anteriormente para el caso de un alumno, pero se incluye la opción de hacer una búsqueda a través de un alumno en particular por medio de su RUT o nombre.

La biblioteca dispone de un catálogo de libros para el área de reserva, de los que pueden existir uno o más ejemplares. Los usuarios se encuentran registrados, ya sean alumnos o funcionarios, al igual que los libros. Existen varios responsables de la biblioteca que se encargan de la manipulación de la información de usuarios, libros y reservas. Se debe restringir el acceso al sistema por medio de la identificación del usuario, tanto para alumnos como funcionarios, a través del uso de login y password.

Debido al uso de dispositivos móviles, el acceso a la información del sistema podrá ser realizado en cualquier momento y lugar dentro y fuera de la biblioteca, a través de la conexión disponible. Se debe señalar que el sistema debe ofrecer los servicios de manera


80

ininterrumpida, lo que implica mantener la información disponible y actualizada todo el tiempo.

7.2.2 Captura de objetivos

Para cumplir los requisitos del sistema se deben cumplir los siguientes objetivos:

Gestionar reservas Gestionar libros Informar al usuario Manejar usuarios

Figura 7.1: Diagrama jerárquico de objetivos

7.2.3 Casos de uso

Tenemos dos actores: los alumnos y los funcionarios de la biblioteca. Por un lado, los alumnos realizan todas las operaciones necesarias para reservar libros, consultar las reservas hechas y consultar información sobre los libros; por el otro, los funcionarios de la biblioteca añaden o eliminan libros, además de consultar las reservas hechas.


81

Buscar libro

Buscar por nombre

Buscar por tema

Buscar por autor

<<extend>>

<<extend>>

<<extend>>

Reservar libro

<<include>>

Consultar libro

<<include>>

Consultar reserva

Alumno

Verificar contraseña

<<include>>

<<include>>

<<include>>

<<include>>

Figura 7.2: Casos de uso vista Alumno

Agregar libro

Verificar contraseña

Consultar reservaEncargado

Quitar libro

Buscar alumno

<<extend>>

Buscar por nombre_al

<<extend>>

Buscar por rut

<<extend>>

Buscar libro

<<include>>

<<extend>>

Buscar por nombre

<<extend>>

Buscar por autor

<<extend>>

Buscar por tema

<<extend>>

<<include>>

<<include>>

<<include>>

Figura 7.3: Casos de uso vista Encargado


82

1) Caso de uso “Reservar libro”

Objetivo: Reservar un libro del catálogo de la biblioteca para una fecha dada por el alumno.

Actores: Alumno Precondiciones: Que el alumno haya ingresado al sistema y se haya validado su

acceso. Descripción:

El sistema solicitará el libro que se desea reservar. El alumno realizará una búsqueda del libro dentro del catálogo de la biblioteca. El alumno seleccionará la forma de la búsqueda: por nombre, tema o autor del libro. El sistema mostrará los resultados obtenidos [Excepción: No existe el libro buscado]. El alumno escogerá el libro que desea reservar [Excepción: No hay copias disponibles del libro]. El sistema solicitará la fecha de la reserva. El alumno ingresará la fecha de la reserva [Excepción: Datos incorrectos]. El sistema informará la confirmación de la reserva y los datos correspondientes.

Excepciones:

No existe el libro buscado: si los resultados obtenidos no son los esperados, se cancela la operación y se vuelve al inicio del sistema. No hay copias disponibles del libro: si todas las copias del libro se encuentran reservadas, se cancela la reserva y se vuelve al inicio del sistema. Datos incorrectos: si se introduce un dato incorrecto, se cancela la operación y se vuelven a pedir los datos.


83

2) Caso de uso “Consultar libro”

Objetivo: Consultar los datos de un libro del catálogo de la biblioteca. Actores: Alumno. Precondiciones: Que el alumno haya ingresado al sistema y se haya validado su


El sistema solicitará el libro que se desea consultar. El alumno realizará una búsqueda del libro dentro del catálogo de la biblioteca. El alumno seleccionará la forma de la búsqueda: por nombre, tema o autor del libro. El sistema mostrará los resultados obtenidos [Excepción: No existe el libro buscado]. El alumno escogerá el libro que desea consultar. El sistema entregará los datos del libro consultado.

Excepciones:

No existe el libro buscado: si los resultados obtenidos no son los esperados, se cancela la operación y se vuelve al inicio del sistema.

3) Caso de uso “Consultar reserva”

Objetivo: Consultar los datos de la reserva hecha de un libro del catálogo de la biblioteca.

Actores: Alumno, Encargado. Precondiciones: Que el alumno o el encargado haya ingresado al sistema y se haya

validado su acceso. Descripción:

El sistema solicitará la reserva del libro que se desea consultar. El alumno o encargado realizará una búsqueda de la reserva del libro.


84

El alumno o encargado seleccionará la forma de la búsqueda: por nombre, tema o autor del libro. En el caso del encargado, otra forma de búsqueda es a través del nombre o RUT del alumno. El sistema mostrará los resultados obtenidos [Excepción: No existe el libro buscado] [Excepción: No existe el alumno buscado]. El alumno o encargado escogerá la reserva del libro que desea consultar. El sistema informará los datos de la reserva consultada.

Excepciones:

No existe el libro buscado: si los resultados obtenidos no son los esperados, se cancela la operación y se vuelve al inicio del sistema. No existe el alumno buscado: si ningún alumno coincide con los datos ingresados, se cancela la operación y se vuelve al inicio del sistema.

4) Caso de uso “Agregar libro”

Objetivo: Agregar un libro al catálogo de la biblioteca. Actores: Encargado. Precondiciones: Que el encargado haya ingresado al sistema y se haya validado su


El sistema solicitará los datos del libro que se desea agregar. El encargado ingresará cada uno de los datos solicitados [Excepción: Datos incorrectos]. El sistema informará la confirmación del ingreso y los datos correspondientes [Excepción: Libro ya existe].

Excepciones:

Libro ya existe: si los datos del libro ingresado coinciden con los de otro libro, se cancela la operación y se vuelve al inicio del sistema.


85

Datos incorrectos: si se introduce un dato incorrecto, se cancela la operación y se vuelven a pedir los datos.

5) Caso de uso “Quitar libro”

Objetivo: Eliminar un libro del catálogo de la biblioteca. Actores: Encargado. Precondiciones: Que el encargado haya ingresado al sistema y se haya validado su


El sistema solicitará el libro que se desea eliminar. El encargado realizará una búsqueda del libro dentro del catálogo de la biblioteca. El encargado seleccionará la forma de la búsqueda: por nombre, tema o autor del libro. El sistema mostrará los resultados obtenidos [Excepción: No existe el libro buscado]. El encargado escogerá el libro que desea eliminar. El sistema informará la confirmación de la eliminación del libro del catálogo.

Excepciones:

No existe el libro buscado: si los resultados obtenidos no son los esperados, se cancela la operación y se vuelve al inicio del sistema.


86

7.2.4 Diagramas de secuencia

1) Caso de uso “Agregar libro”

Figura 7.4: Diagrama de secuencia: caso de uso Agregar libro

2) Caso de uso “Reservar libro”

Figura 7.5: Diagrama de secuencia: caso de uso Reservar libro


87

3) Caso de uso “Consultar reserva”

Figura 7.6: Diagrama de secuencia: caso de uso Consultar reserva


88

7.2.5 Diagrama de roles

Figura 7.7: Diagrama de roles


89

7.2.6 Ontología

El sistema debe permitir gestionar alumnos, encargados, reservas y libros, por lo tanto la ontología debe cubrir toda la información relacionada con estos conceptos. Luego, se necesitan los siguientes conceptos:

Alumno: este es un usuario del sistema, que tiene acceso a ciertas funcionalidades del mismo. Posee un RUT, nombre y contraseña.

Encargado: este también es otro usuario del sistema, que tiene acceso a funcionalidades exclusivas del sistema. Posee también un RUT, nombre y contraseña.

Reserva: este concepto se usa para representar las reservas de libros que el sistema va a gestionar. Posee atributos como ISBN del libro, RUT del usuario y fecha.

Libro: se utiliza para representar los libros que se asocian a cada una de las reservas. Posee nombre, autor y tema.

7.3 Diseño

Las fases del diseño en MaSE que se van a utilizar para realizar el diseño del sistema son:

Diagrama de clases de agentes. Construcción de conversaciones. Diagrama de despliegue.


90

7.3.1 Diagrama de clases de agentes

Los roles del diagrama de roles se han agrupado en tres agentes: el Agente Alumno, el Agente Encargado y el Agente Biblioteca.

Figura 7.8: Diagrama de clases de agentes


91

7.3.2 Diagrama de despliegue

Para el caso del sistema, tanto el Agente Alumno como el Agente Encargado se despliegan cada uno sobre dispositivos móviles como teléfonos celulares o PDA´s, mientras el Agente Biblioteca estará en un servidor puesto que debe permanecer siempre en ejecución.

Figura 7.9: Diagrama de despliegue


92

7.4 Implementación

7.4.1 Modelo de la Base de Datos

Alumno<<PK>> rutnombrecontraseñatelefono

Reserva<<PK>> rut<<PK>> isbn<<PK>> fechafecha_reserva

1..n1 1..n1

Libro<<PK>> isbnnombreautortemacantidad<<FK>> rut_encargado

1

1..n

1

1..n

Encargado<<PK>> rut_encargadonombrecontraseñatelefono

1..n1 1..n1

Figura 7.10: Modelo de la Base de Datos

7.4.2 Acceso al Sistema

Para poder ingresar al Sistema de Reserva de libros, se debe estar registrado previamente como Alumno o Encargado, según corresponda. Cada Alumno y Encargado tendrá un registro correspondiente en la Base de Datos, el cual será ingresado por el Administrador de la Base de datos. Esto se debe a que este Sistema de Reserva se alimenta de datos que ya fueron ingresados en un Sistema mayor, el cual sería administrado por una universidad o su biblioteca, por ejemplo. La idea es que este sistema se complemente o utilice información que ya fue adquirida de antemano. El Administrador creará en el registro además de los datos personales del Alumno o Encargado, su RUT que servirá como login de usuario y una contraseña específica para el acceso. El tener identificado al Alumno permitirá llevar un registro de sus operaciones y movimientos al ingresar al sistema, como también de las realizadas por un Encargado. Debemos recordar que las operaciones que


93

puede realizar un Alumno son distintas a las realizadas por un Encargado, de ahí que sea necesaria su identificación.

Una vez instalada la aplicación en el dispositivo móvil, luego de lanzarla se muestra un primer menú en el cual debemos seleccionar el perfil al cual se desea ingresar. Las opciones que se muestran son dos, la primera corresponde al ingreso al sistema por parte de un Alumno, mientras la segunda corresponde al ingreso por parte de un Encargado. Debemos recordar que las operaciones que puede realizar un Alumno son distintas a las realizadas por un Encargado, de ahí que sea necesaria su separación.

Figura 7.11: Inicialización de la aplicación y selección de perfil

Una vez seleccionado el perfil al cual se desea ingresar, ya sea Alumno o Encargado, el dispositivo comienza la conexión con el sistema. Esta conexión puede provocar una pequeña demora en la aparición de la siguiente pantalla, dependiendo de la velocidad de la conexión y del tiempo que pueda requerir el procesamiento de la petición.


94

Figura 7.12: Esperando conexión con el sistema

Luego de establecer la conexión con el Sistema, la siguiente pantalla pide el RUT y la contraseña del usuario. Esta pantalla es la misma para cualquiera de los dos perfiles, Alumno y Encargado. Estos dos datos permitirán el acceso al Sistema por parte de esa persona, siempre y cuando los datos coincidan con los registrados en la Base de Datos. Una vez ingresado al Sistema, este mostrara las correspondientes operaciones que puede realizar el perfil.


95

Figura 7.13: Ingreso de RUT y contraseña

7.4.3 Descripción de las funcionalidades para Perfil Alumno

Luego de seleccionado el perfil, que en este caso corresponde a un Alumno, y haber ingresado al Sistema podemos ver que la siguiente pantalla muestra las operaciones posible a realizar. Para el perfil Alumno tenemos tres posibles operaciones, la primera permite reservar un libro, la segunda permite consultar los datos de un libro, y finalmente, la última opción permite consultar la reserva de un libro en particular.

Para cualquiera de las tres opciones, la siguiente pantalla que viene es la correspondiente a la búsqueda del libro, ya sea que se desee reservar, consultar o ver sus reservas. Luego de elegir una, se muestra una pantalla donde tenemos que ingresar los datos solicitados.


96

Figura 7.14: Operaciones perfil Alumno y búsqueda de libro

A continuación, aparecen las pantallas correspondientes al tipo de búsqueda del libro que se desea llevar a cabo. Ya que se desee una búsqueda del libro a través de su nombre, tema o autor; el sistema despliega pantallas similares para el ingreso de los datos. Luego de un momento, el Sistema procesa la información y entrega las respuestas correspondientes.


97

Figura 7.15: Ingreso de datos del libro para su búsqueda

Figura 7.16: Ingreso del autor del libro para su búsqueda


98

7.4.4 Descripción de las funcionalidades para Perfil Encargado

Luego de seleccionado el perfil, que en este caso corresponde a un Encargado, y haber ingresado al Sistema podemos ver que la siguiente pantalla muestra las operaciones posibles a realizar. Para el perfil Encargado tenemos tres posibles operaciones, la primera permite agregar un libro al inventario, la segunda permite eliminar un libro de la biblioteca, y finalmente, la última opción permite consultar la reserva de un libro en particular.

Al seleccionar la opción de agregar un libro, la siguiente pantalla muestra un formulario en el cual debemos ingresar todos los datos solicitados para poder ingresar un nuevo libro a la biblioteca. Una vez ingresados los datos, se confirma la operación.

Figura 7.17: Operaciones perfil Encargado e ingreso de nuevo libro

La operación de quitar un libro, involucra los mismos pasos vistos en la operación de búsqueda de un libro. Para eliminar un determinado libro, primero debemos buscarlo para luego confirmar la operación de eliminación.

Finalmente la operación de consultar una reserva realizada, involucra una nueva decisión. La siguiente pantalla muestra dos opciones, la primera implica realizar la búsqueda de la reserva a través de un libro en particular para lo cual se desplegarán las


99

pantallas anteriormente vistas sobre búsqueda., y la segunda permite realizar la búsqueda de la reserva a través de un alumno en particular.

Al seleccionar la búsqueda de la reserva a través de un alumno en especial, se despliega la pantalla en la cual se debe decidir si buscar al alumno por su RUT o por su nombre. Una vez ingresados todos los datos pedidos, se comienza a procesar la información para luego de un momento entregar las respuestas requeridas.

Figura 7.18: Operaciones para consulta de reserva y búsqueda de alumno

100

Capítulo 8

Conclusiones

Los agentes de software y el desarrollo de sus sociedades (sistemas multiagente) surgieron debido a la necesidad de implementar sistemas cada vez más inteligentes y con un alto grado de integración a otros sistemas y a su entorno conformando redes. En este contexto, las características que presentan los agentes inteligentes los hacen la tecnología perfecta para el desarrollo de sistemas de software distribuidos que requieren un alto grado de autonomía e inteligencia específica, a la vez de ser lo suficientemente flexibles para interactuar con otros sistemas y adaptarse a nuevos requerimientos.

Es importante señalar que la tecnología multiagente se encuentra en una etapa de maduración en la cual se hace imprescindible contar con experiencias y consensos. De esta manera, es importante el desarrollar conocimientos y el hacer investigación en torno a esta tecnología que se visualiza como nuevo paradigma de desarrollo de software.

Debido a lo anterior, resulta importante probar la tecnología de agentes como paradigma de ingeniería de software válido para el desarrollo de sistemas complejos, gracias a su capacidad de ir incorporando nuevas tecnologías como por ejemplo los dispositivos móviles que es lo que pretende el presente proyecto. El uso de sistemas multiagente se complementa con otras iniciativas como web services, ambient intelligence, pervasive computing por mencionar algunas, sobretodo cuando los requerimientos principales son la integración de sistemas en un ambiente distribuido y heterogéneo y donde se requiere un sistema pro activo más que reactivo.

Los dispositivos móviles, en especial los teléfonos celulares, están penetrando cada vez más fuerte en nuestra sociedad. Pero estos dispositivos no solo sirven para comunicarnos, sino que también permiten ofrecer múltiples servicios además de apoyar nuestras actividades laborales. Es por esto que mediante el empleo de la tecnología de agentes se puede llevar a cabo por ejemplo la personalización de estos servicios y así lograr un mejor aprovechamiento de la tecnología móvil existente.

Capítulo 8: Conclusiones

101

El uso de agentes representa un salto de paradigma en la forma de entender y modelar un sistema de software. En comparación al desarrollo de software orientado a objetos, la tecnología de agentes presenta un nivel de abstracción mayor que le permita reducir complejidad. El desarrollo de software orientado a agentes ha ganado un espacio en el último tiempo, constituyéndose en una alternativa para el modelamiento de software, sobretodo en escenarios complejos.

En este sentido, la inexistencia de un estándar a nivel de metodologías para el desarrollo de sistemas multiagente, implica que a la hora de tomar la importante decisión de cómo voy a hacer el sistema se necesita hacer un análisis de las diferentes metodologías existentes. Esto significa tener que hacer un trabajo extra que sobrecarga el proyecto pues primero se deber tener un panorama claro de todas las opciones para recién poder tomar una decisión lo que deriva en no poder dedicar el valioso tiempo lo más pronto posible en el diseño de la solución. Se espera que mediante el seguimiento paso a paso de una metodología, esto permita reportar las experiencias y poder por fin tender hacia el tan anhelado estándar de desarrollo.

El potencial de la tecnología multiagente es ilimitado puesto que sirve para resolver casi cualquier problema que se presente. En ese sentido vale la pena analizar si el problema a solucionar presenta las características necesarias como para justificar el uso de esta tecnología y así demostrar las verdaderas ventajas de realizar una solución basada en el paradigma de agentes.

102

Capítulo 9

Referencias

[1] M. Ahmadi and T. Takahashi, RoboCupRescue System and Arian: A Flexible Infrastructure for Multi-agent Research and Education, Proceedings of the 15th IEEE International Conference on Tools with Artificial Intelligence (ICTAI’03), 2003.

[2] R. Strahan, C. Muldoon, G. O’Hare, M. Bertolotto and R.W. Collier, An Agent-Based Architecture for Wireless Bus Travel Assistants, University College Dublin, Ireland, 2003.

[3] T. O’Sullivan and R. Studdert, Handheld Medical Devices Negotiating for Reconfigurable Resources using Agents, Proceedings of the 18th IEEE Symposium on Computer-Based Medical Systems (CBMS’05), 2005.

[4] M. Berger, M. Bouzid, M. Buckland, H. Lee, N. Lhuillier, D. Olpp, J. Picault and J. Shepherdson, An Approach to Agent-Based Service Composition and Its Application to Mobile Business Processes, IEEE Transactions on mobile computing, 2003.

[5] H.-W. Tung and V.-W. Soo, A Personalized Restaurant Recommender Agent for Mobile E-Service, Proceedings of the 2004 IEEE International Conference on e-Technology, e-Commerce and e-Service (EEE’04), 2004.

[6] JADE Web Site, http://jade.tilab.com/

[7] M. Wooldridge, An introduction to Multi-Agent Systems, Ed. John Wiley and Sons, ISBN 0-471-49691-X, 2002.

[8] S.Hanna, A. Chehab, A. Kayssi, and H. Artail, Lighter Weight Mobile Agent System,The 2004 International Research Conference on Innovations in Information Technology (IIT'04), 2004.

Capítulo 9: Referencias

103

[9] EURESCOM. Project P907, MESSAGE: Methodology for Engineering Systems of Software Agents, 2001.

[10] Iglesias, C.: Definición de una metodología para el desarrollo de Sistemas Multi-Agente. Tesis doctoral. Departamento de ingeniería de Sistemas Telemáticos, Universidad Politécnica de Madrid. 1998.

[11] Iglesias, C., Mercedes Garijo, M., Gonzalez, J. C., and Velasco, J. R., Analysis and design of multiagent systems using MAS-CommonKADS, en Intelligent Agents IV . LNAI Volume 1365 ed. SpringerVerlag: Berlin, 1998.

[12] Tansley, D. S. W. y Hayball, C. C.: Knowledge Based systems Analysis and Design a KADS developer's handbook. Libro completo. Prentice Hall. 1993.

[13] DeLoach, S.: Analysis and Design using MaSE and agentTool. Actas de conferencia. Proceedings of the 12th Midwest Artificial Intelligence and Cognitive Science Conference (MAICS). 2001.

[14] Wooldridge, M., Jennings, N. R., and Kinny, D., The Gaia Methodology for Agent-Oriented Analysis and Design, Journal of Autonomous Agents and Multi-Agent Systems, vol. 15 2000.

[15] Pressman, R. S.: Software Engineering: A Practitioner's Approach. Libro completo. McGraw-Hill Series in Software Engineering and Technology. McGraw-Hill, Inc. 1982.

[16] International Telecommunication Union:ITU 100:Formal Description Techniques (FDT)-Specification and Description Language (SDL). Informe.

[17] International Telecommunication Union:ITU-120: Formal Description Techniques (FDT): Message Sequence Chart. Informe.

[18] MIX: Modular Integration of Connectionist and Symbolic Processing in Knowledge-based systems. Esprit-9119


104

[19] Zambonelly, F., Wooldridge M., and Jennings N.R., Organizational Rules as an Abstraction for the Analysis and Design of MultiAgent Systems, International Journal of Software Engineering and knowledge Engineering, 2000.

[20] FIPA: ACL Message Structure Specification. http://www.fipa.org

[21] Foner L. N. (1993) “What’s an agent, anyway? A sociological case study”. Agents Memo 93-01, Agents Group, MIT Media Lab. 1993.

[22] Franklin S. y Graesser A. (1996) Is it an Agent, or just a Program?: A Taxonomy for Autonomous Agents. Proceedings of the Third International Workshop on Agent Theories, Architectures, and Languages. Springer-Verlag, 1996.

[23] Wooldridge M. y Jennings N. R. (1995) Intelligent Agents: Theory and Practice. The Knowledge Engineering Review, vol. 10(2) pp. 115-152, 1995.

[24] Shoham Y., (1993) “Agent Oriented Programming”, Artificial Intelligence, vol 60, nº1, pp 51-92.

[25] Bond A.H., Gasser L. (1988) Readings in Distributed Artificial Intelligence. Morgan Kaufman.

[26] Durfee, E. H., “The Distributed Artificial Intelligence Melting Pot”, IEEE Transactions on Systems, Man and Cybernetics, vol 21, nº 6, Noviembre/Diciembre, 1991.

[27] Decker, Keirh S., "Distributed Problem-Solving Techniques: A Survey", IEEE Transactions on Systems, Man, and Cybernetics, Sep/Oct 1987.

[28] Jennings R., Sycara K., Wooldridge M., (1998) “A Roadmap of Agent Research and Development”, Autonomous Agents and Multiagent Systems, vol 1, nº 1 pp 275-306.

[29] Bussman S. Y Müller H. J. (1993) A communication architecture for cooperating agents. Compt. Artif. Intell. 12(1), 37-54.


105

[30] Chu-Carroll C. y Carberry S. (1995) ‘Conflict Detection and Resolution in Collaborative Planning’ INTELLIGENT AGENTS II: Agent Theories, Architectures and Languages, pp 111-127, Wooldridge, Michael J, Mueller, P and Tambe, Milind, (Eds), Springer Verlag, Berlin 1995.

[31] Carabelea C., Boissier B., Ramparany F., Benefits and Requirements of Using Multi-agent Systems on Smart Devices, Lecture Notes in Computer Science - Euro-Par 2003 Parallel Processing: 9th International Euro-Par Conference Klagenfurt, Austria, August 26-29, Proceedings, 2003.

[32] Carabelea C., Boissier B., Multi-Agent Platforms on Smart Devices: Dream or Reality?, In Proc. of the Smart Objects Conference (SOC'03), Grenoble, France (2003), p. 126-129.

[33] Poslad S., Laamanen H., et al, CRUMPET: Creation of User-friendly Mobile Services Personalized for Tourism, Proceedings of 3G 2001 - Second International Conference on 3G Mobile Communication Technologies, London, 2001.

[34] Federico Bergenti, Agostino Poggi, LEAP: A FIPA Platform for Handheld and Mobile Devices, In Proc. Eighth International Workshop on Agent Theories, Architectures, and Languages (ATAL 2001), Seattle, CA, 2001.

[35] Mihailescu P., Kendall E., Binder W., MAE: A Mobile Agent Platform for Building Wireless M-Commerce Applications, In 8th ECOOP Workshop on Mobile Object Systems: Agent Applications and New Frontiers, España, 2002.

[36] R. Albuquerque, J. Hübner, G. de Paula, J. Sichman, G. Ramalho, KSACI: A Handheld Device Infrastructure for Agents Communication, ATAL 2001.

[37] F. Bellifemine, A. Poggi, G. Rimassa, JADE - A FIPA-compliant agent framework, In Proceedings of the 4th International Conference on the Practical Applications of Agents and Multi-Agent Systems (PAAM’99), London, UK, 1999.

[38] A. Valls, A. Moreno, D. Riaño, A. Pascual, Modelo De E-Asistencia Basado En Las Tecnologías De Sistemas Multi-Agente Y Análisis Inteligente De Datos, 2004.


106

[39] A. Carrillo, J. Gensel, M. Villanova-Oliver, H. Martin, PUMAS: Un Framework que Adapta la Información en Ambientes Ubicuos, 2006.

[40] L. Castillo, J. M. Corchado, M. Bedia, Modelo y desarrollo de W-planner: sistema multiagente on-line aplicado al turismo electrónico, 2005.

[41] Alexandre Viejo Galicia, Estudio de la implementación de agentes en dispositivos móviles, Proyecto Final De Carrera, 2003.

Documents

Memoria de Título Danilo Solar Donoso 19-05-2010