Grupo CADOS 09/10

• La tecnología de Agentes es bastante madura, aún así no parece salir de ser “cutting edge”.

• Todo parece apuntar a los artefactos, roles y entornos como futuro próximo y cómo tema de investigación.

• La programación de agentes ha evolucionado en 2 áreas: los agentes móviles que han ganado nivel de abstracción y los agentes de “bajo nivel”.

• F. Bellifemine, G. Caire, A. Poggi, G. Rimassa, Jade Whitepaper, EXP in search of innovation, número 3 - volumen 3, Septiembre 2003

• Matteo Baldoni, Guido Boella, Valerio Genovese, Roberto Grenna, Andrea Mugnaini and Leon van der Torre. A Middleware for modeling Organizations and Roles in Jade, Seventh international Workshop on Programming Multi-Agent Systems, Mayo 2009

• Alessandro Ricci and Mirko Viroli. A Formal Model for Artifact-Based Environments in MAS Programming, Seventh international Workshop on Programming Multi-Agent Systems, Mayo 2009

• Bo Chen, Harry H. Cheng,, and Joe Palen, Mobile-C: a mobile agent platform for mobile C/C++ agents, Wiley Interscience DOI 10.1002/spe 742, 13 de Julio de 2006
  

Actualmente hay diversas lineas de investigación, pero hay una serie de framerworks que son los más utilizados para la programación de SMA, podríamos ver este post como un punto de partida para una visión general del estado del arte:

“Java Agent DEvelopment Framework” (creado por el TILAB) es probablemente el más utilizado para el desarrollo de sistemas multiagente. Sus principales caraterísticas son:

• Se ajusta a las especificaciones del Foundations of Intelligent Physical Agents (FIPA), ya que posee ACC, AMS y DF.
• Comunicación entre agentes usando el lenguaje ACL.
• En cierto modo tiene una arquitectura Peer to Peer.
• Tiene una clara orientación para uso en dispositivos móviles.

Jade es una plataforma madura por lo que no se esperan grandes cambios en un plazo medio, no obstante se encuentran en implementación una característica muy intersante como es el soporte de roles en los agentes, que se podrán definir como una característica adicional. Esto permitiría un comportamiento predefinido (inicialmente) según el rol asignado a un agente.

Metodologías para el desarrollo de sistemas multiagente (parte#2)

ZEUS
ZEUS consta de una herramienta (ver figura 4) y una metodología, de forma similar a agenTool y MaSE.
Desde su aparición, ZEUS se ha convertido en referencia de cómo debe ser una herramienta para el desarrollo de SMA. Sobre todo, por la forma en que combinan los distintos resultados de investigación en agentes (planificación, ontologías, asignación de responsabilidades, relaciones sociales entre agentes) en un sistema ya ejecutable. De hecho, la aplicación genera incluso programas para arrancar el sistema especificado e incluye herramientas de monitorización como el Visor de Sociedad que muestra los agentes existentes y sus relaciones, la Herramienta de Control para ver o modificar remotamente el estado de los agentes y los Generadores de Informes para obtener estadísticas de funcionamiento e informes de actuación de la sociedad de agentes.


La metodología ZEUS propone un desarrollo en cuatro etapas: el análisis del dominio, el diseño de los agentes, la realización de los agentes y el soporte en tiempo de ejecución. Las etapas soportadas por la herramienta son la de realización de los agentes y la de soporte en tiempo de ejecución. Las etapas anteriores se basan en el uso de roles para analizar el dominio y en su asignación a agentes.

Hay poco que comentar acerca de ZEUS. Hasta la aparición de MaSE, ZEUS era herramienta referencia.

Hoy en día se encuentran muchos más artículos referenciando MaSE que ZEUS. Conceptualmente, ZEUS es superior a MaSE. Si bien la primera está más orientada a la aplicación de tecnología de agentes (planificación, definición de ontologías, secuenciación de tareas), la segunda se orienta más a las prácticas de ingeniería convencional.

GAIA
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.

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.

La principal crítica que se puede hacer a GAIA es que se queda a un nivel de abstracción demasiado alto. Según los autores, con ello se consigue desacoplar GAIA de las distintas soluciones de implementación de agentes. Sin embargo, la utilidad de este desacoplamiento queda por demostrar. Dado el nivel de abstracción en que se queda es de esperar que el esfuerzo a invertir para pasar de una especificación GAIA hasta su implementación sea alto.

INGENIAS
INGENIAS define un conjunto de meta-modelos (una descripción de alto nivel de qué elementos tiene un modelo) con los que hay que describir el sistema. Los meta-modelos indican qué hace falta para describir: agentes aislados, organizaciones de agentes, el entorno, interacciones entre agentes o roles, tareas y objetivos. Estos metamodelos se construyen mediante un lenguaje de meta-modelado, el GOPRR (Graph, Object, Property, Relationship, and Role).

En la construcción de estos meta-modelos se integran resultados de investigación en forma de entidades y relaciones entre entidades. La instanciación de estos meta-modelos produce diagramas, los modelos, similares a los que se usa en UML, con la diferencia de que estos diagramas se han creado exclusivamente para definir el sistema multi-agente.

La ejecución de actividades para producir modelos se basa en la herramienta INGENIAS IDE (figura 5), una herramienta para modelado visual. Esta herramienta almacena la especificación del sistema utilizando XML.


Desde la especificación en XML, se plantea el procesarla :

• Para generar código. Genera código rellenando plantillas de código con información de la especificación.
• Para generar la documentación. De una forma similar a la generación de código, se parte de plantillas de documentación que se completan utilizando información de los modelos.

El proceso de desarrollo que propone INGENIAS es excesivo cuando se trata de desarrollos reducidos. A diferencia de MAS-CommonKADS que dota de procesos de desarrollo adaptados al tamaño del problema, INGENIAS da la impresión de dedicarse exclusivamente a desarrollos de gran tamaño.

INGENIAS dispone de una cantidad ingente de entidades y relaciones. Su uso mediante la herramienta de soporte INGENIAS IDE, se facilita pero se sigue requiriendo que el desarrollador revise la documentación de la tesis para entender qué hace cada entidad y cuál es el propósito de cada relación.

• utilización de diferentes vistas para la especificación del sistema,
• incorporar la idea de proceso de desarrollo,
• e integrar técnicas de ingeniería y teoría de agentes.

1. La primera es la ingeniería de vocales (vowel engineering) [Demazeau 95] que fue una de las primeras en considerar diferentes aspectos (agentes, entorno, interacciones y organización) en el desarrollo de SMA.
2. La segunda es MAS-CommonKADS [Iglesias 98][Iglesias et al. 98b] que, debido a su origen (CommonKADS [Tansley et al. 93]), se trata de una metodología orientada al desarrollo utilizando experiencia en sistemas expertos.
3. A continuación el diseño basado en BDI [Kinny et al. 97] que ha influido notablemente en la forma de concebir el control de los agentes.
4. Después, se estudian dos metodologías soportadas por herramientas: ZEUS [Nwana et al. 99]
5. y MaSE [DeLoach 01].
6. Seguidamente, se estudia GAIA [Wooldridge al. 00], de gran influencia, que estudia la definición de vistas en una metodología y trata de integrarse en un ciclo de vida de software tipo cascada.
7. Por último, INGENIAS [Gomez et al. 02][Gomez 02], creada a partir del trabajo de MESSAGE [Caire et al. 02] en la que el autor de este trabajo participó activamente.

vowel engineering
Se trata de la metodología seguida en el grupo MAGMA [MAGMA 03]. El término vowel engineering viene de que el sistema final depende de la ordenación y agrupamiento de aspectos identificados por cuatro vocales: A (por agentes), E(por entorno), I (por interacciones) y O (por organización). Para cada aspecto, se utilizan componentes y técnicas específicas. Para representar agentes se u desde simples autómatas hasta complejos sistemas basados en conocimiento.

El propósito de Vowel engineering es lograr librerías de componentes que den soluciones al diseño de cada uno de estos aspectos, para que posteriormente, el diseñador seleccione un modelo de agente, un modelo de entorno, un modelo de interacciones y modelos de organización a instanciar (ver figura 1).

El proceso de desarrollo es el punto debil de esta metodología. Vowel Enginering solo proporciona las vocales como resumen de elementos a considerar en el desarrollo y un conjunto de tecnologías aplicadas.


MAS-CommonKADS
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 ha sido la primera en plantear un desarrollo de SMA integrado con un ciclo de vida de software, concretamente el espiral dirigido por riesgos [Pressman 82]. 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.

Es exhaustiva como pocas a la hora de detallar el sistema y además es consecuente con que el proceso de desarrollo en la mayoría de los casos es más complejo que un conjunto de pasos.

Esta metodología ha sido la primera en incorporar la idea de proceso de ingeniería en el sentido de Pressman [Pressman 82]. De hecho, describe con bastante detalle cómo se debe definir el sistema teniendo en cuenta las dependencias entre los modelos.


BDI
Las arquitecturas BDI se inspiran en un modelo cognitivo del ser humano [Bratman 87]. Según esta teoría, los agentes utilizan un modelo del mundo, una representación de cómo se les muestra el entorno. El agente recibe estímulos a través de sensores ubicados en el mundo. Estos estímulos modifican el modelo del mundo que tiene el agente (representado por un conjunto de creencias). Para guiar sus acciones, el agente tiene Deseos. Un deseo es un estado que el agente quiere alcanzar a través de intenciones. Éstas son acciones especiales que pueden abortarse debido a cambios en el modelo del mundo.

En esta metodología, la integración con el ciclo de vida de software es reducida. Los autores proponen una serie concreta de pasos para generar los modelos. Estos pasos se repiten haciendo que los modelos, que capturan los resultados del análisis, sean progresivamente elaborados, revisados y refinados.


Existen dependencias entre los diferentes modelos que dificultan el proceso de generación de los modelos que describen el SMA. Como solución proponen un proceso iterativo e incremental (idea también reflejada en el Proceso Racional Unificado [Jacobson et al. 99]) con realimentaciones. Sin embargo, la forma en que tienen lugar estas realimentaciones no se llega a mostrar con detalle.

Como en las anteriores metodologías, se echa de menos la presencia de herramientas de soporte. Sin embargo, los modelos formales que se pueden encontrar tras esta metodología constituyen una referencia obligada para aquellos interesados en la integración de teorías de agentes y las prácticas de ingeniería.


MaSE (Multi-agent systems Software Engineering)
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 proactivamente para alcanzar metas individuales y del sistema.

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. 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.

La herramienta de soporte, agentTool [DeLoach 01], 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.

Hasta ahora se han tratado la programación desde el punto de vista de agentes como entes, sus comunicaciones e interacciones. Los SMA intentan plasmar en cierto modo el mundo real, y en el los humanos interactuamos a diario con artefactos, lo que se podría denotar como un signo de inteligencia, por esto se han introcido en el mundo de los agentes para que estos puedan también trabajar con ellos (aprovechando su "inteligencia").

Desde el punto de vista de los agentes un artefacto es un "objeto virtual" (abstracción del real) que puede ser explotado (sus cualidades) para conseguir sus objetivos. Con ellos se pueden realizar 3 acciones básicas:

• Creación y eliminación dinámica
• Descubrimiento de artefactos
  
• Compartición
• Uso
• Manipulación

Los artefactos en los SMA se componen básicamente de:

• Cualidades
• Interfaz de uso
• Estados
• Eventos

Denotar que los artefactos requieren del conocimiento del uso de los mismos y cierto punto de inteligencia por parte del agente manipulador.

Framework CARTAGO

Para la introducción de los artefactos en los SMA se ha creado el framework programado en Java "CARTAGO".

Se encuentran disponibles funciones:

• Creación de artefacto: createArtifact(Name,TypeID,Conf,WspID)
• Descubrimiento de artefactos disponibles: getArtifactID(Name,WspID):AID
• Eliminar instancia de artefacto: disposeArtifact(AID)

Uso de artefactos:

• Uso del objeto enfocado: execOp(AID,Op(Name,Params),SID)
• "Enfocar": focus(AID,SID)
• "Desenfocar": unfocus(AID,ID)

• Visualizar estado del artefacto: getObsState(AID):ObsState

El framework se puede descargar de http://alice.unibo.it/xwiki/bin/view/CARTAGO/ y actualmente es compatible con Jason, Jadex, simpA - 2AP y se encuentra en desarollo el de JADE.