En INGENIAS se toma la definición de Newell [Newell 82], una definición de agente influenciada por la IA. Newell asume que existen diferentes niveles de abstracción en el diseño de sistemas, entre ellos el nivel de símbolos y el nivel de conocimiento. Del mismo modo que un programa convencional maneja símbolos (e.g. expresiones, variables) en el nivel de símbolos, un agente, que equivale a un programa en el nivel del conocimiento, maneja únicamente conocimiento y se comporta de acuerdo con el principio de racionalidad. Este principio estipula que un agente emprende acciones porque está buscando satisfacer un objetivo.
Se ha tomado esta definición porque establece que el concepto de agente es simplemente una forma de ver un sistema, como también indica Shoham [Shoham 93], que luego puede reflejarse a nivel de simbolos, con un programa tradicional. Esta concepción es compatible con el ciclo de vida del software. De forma general, se pensaría en el agente como un ente que se comporta de acuerdo con el principio de racionalidad. Cuando hubiese que desarrollar físicamente el agente, se atendería a su arquitectura y componentes, lo cual entraría dentro del nivel simbólico.
El diseño de agentes aislados ha sido estudiado en profundidad en la IA. Como resultado, se tienen las arquitecturas de subsunción (Brooks [Brooks 91b]), arquitecturas de pizarra (Hearsay II [Carver y Lesser 92]), arquitecturas BDI (IRMA [Bratman, Israel y Pollack 88]) y arquitecturas para la resolución genérica de problemas (SOAR [Laird, Newell y Rosenbloom 87] [Laird, Bates Congdom y Coulter 99]).
Teniendo en cuenta el carácter distribuido de los entornos de aplicación de agentes (especialmente tratamiento de información en internet) es normal concebir la colaboración de varios agentes. En tales casos, la atención se centra en cómo construir Sistema Multi-Agentes (SMA) que pueden entenderse como grupos de agentes que interaccionan entre sí para conseguir objetivos comunes. La definición de un SMA se puede encontrar en [Ferber 99], donde un SMA es un sistema que reúne los elementos de la Ilustración 1
Ilustración 1. Elementos requeridos en un SMA.
Según esta definición, la influencia de unos agentes en otros viene dada no solo por la comunicación explícita sino también por la actuación sobre el entorno. Este hecho aumenta la complejidad del desarrollo de SMA enormemente, ya que obliga a estudiar el entorno con detalle para detectar qué acciones realizadas por un agente pueden afectar a otro agente.
En el desarrollo de SMA existen dos filosofías distinguidas por la carga de componente práctica. La primera ve el SMA como el resultado de utilizar un lenguaje de especificación de agentes. Para generar SMA de esta manera, se parte de principios basados en modelos operacionales y modelos formales de SMA. La segunda estudia el SMA como un sistema software que hay que construir. El desarrollo no parte de cero, sino que utiliza plataformas de desarrollo de agentes que proporcionan servicios básicos de comunicación, gestión de agentes y una arquitectura de agente. En cualquiera de los dos casos, y sobre todo cuando el sistema a desarrollar es grande, se necesitan metodologías que estructuren el desarrollo de acuerdo con las prácticas de ingeniería del software. Para ilustrar ambas filosofías y entender el lugar de esta metodología dentro de la investigación en Ingeniería del Software Orientada a Agentes, se ha dividido este capítulo en varias secciones. El objetivo de las dos primeras es mostrar que disponer de plataformas de desarrollo o lenguajes de agentes no es suficiente para generar SMA.
La primera sección estudia la relación de este trabajo con los lenguajes de descripción de agentes. Se presta atención a lenguajes de agentes basados en teorías de agentes y lenguajes basados en especificaciones operaciones de cómo son sus intérpretes. Como representativos de los primeros, se introduce brevemente ConGOLOG [Lespérance et al. 96] [De Giacomo, Lespérance y Levesque 00], basado en demostradores automáticos, y como representante de los segundos, Agent0 [Shoham 93] el lenguaje de agentes más referenciado en la literatura.
La segunda muestra plataformas de desarrollo centrándose en aquellas que implementan estándares de desarrollo de SMA (JADE [Bellifemine, Poggi y Rimassa 01] y Grasshopper [Baümer et al. 00]) y plataformas para el desarrollo rápido de SMA (ABLE [IBM 02] y ZEUS [Nwana et al. 99]).
El resto del capítulo se centra en el aspecto de más interés en metodologías para el desarrollo de SMA. Se ha seleccionado un conjunto de metodologías para determinar qué ofrecen frente a este trabajo. En la elección de las metodologías han sido determinantes dos aspectos: utilización de diferentes vistas para la especificación del sistema y la voluntad de integración de técnicas de ingeniería y teoría de agentes. De acuerdo con estos criterios, se han identificado siete metodologías relevantes. 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. La segunda es MAS-CommonKADS [Iglesias et al. 98] que, debido a su origen (CommonKADS [Tansley y Hayball 93]), se trata de una metodología orientada al desarrollo utilizando experiencia práctica en sistemas expertos. A continuación el diseño basado en BDI [Kinny y Georgeff 97] que ha influido notablemente en la forma de concebir el control de los agentes. Después, se estudian dos metodologías que son las únicas que están soportadas por herramientas: ZEUS [Nwana et al. 99] y MaSE [DeLoach 01]. Seguidamente, se estudia GAIA [Wooldridge, Jennings y Kinny 00], de gran influencia en el mundo anglo-sajón, que estudia la definición de vistas en una metodología y trata de integrarse en un ciclo de vida de software tipo cascada. Por último, MESSAGE [Caire et al. 02], en la que los directores de este trabajo y el autor participaron activamente, que define los elementos que se tienen que considerar para desarrollar un SMA, mediante la especificación de meta-modelos, y propone la adopción de un proceso de desarrollo estándar, el RUP.
Los lenguajes de agentes parten, en su mayoría, de modelos operacionales que definen la semántica de sus instrucciones. Estos modelos se suelen describir informalmente, aunque también existen trabajos que primero parten de un modelo operacional expresado como arquitectura software que luego es formalizado, como es el caso de AgentSpeak(L) [Rao 96].
El trabajo más referenciado en lenguajes de agentes es Agent0 [Shoham 93] que acuñó el término programación orientada a agentes. Agent0 propone un nuevo paradigma de programación en el que la entidad principal es el agente. En Agent0, un agente es una entidad cuyo estado se ve como un conjunto de componentes mentales tales como creencias, habilidades, elecciones y compromisos. Con estas entidades y un conjunto de primitivas, como enviar mensaje, comprometerse o solicitar la ejecución de una tarea, se elabora un lenguaje de descripción de agentes. Exiten otros lenguajes que siguen el modelo de Shoham como CASA [Flake y Geiger 99] o PLACA. Estos lenguajes añaden principalmente la capacidad de planificar acciones de los agentes en el SMA.
Como alternativa a Agent0, se tienen enfoques orientados a teorías de agentes, donde se enuncian definiciones formales con las que se construye el SMA para a continuación demostrar propiedades del mismo. Ejemplos de tales propiedades son la viveza del sistema, pensando en el SMA como un sistema concurrente, o que los agentes no necesiten considerar como logros intencionados los efectos secundarios de sus acciones, desde el punto de vista de la teoría de la intención [Wooldridge y Jennings 95]. El interés de las teorías de agentes en INGENIAS, no consiste en las propiedades que se enuncian, sino en su implementación ya que dan lugar a lenguajes de agentes. El problema de este otro tipo de lenguajes de agentes, es que dependen fuertemente de métodos de demostración automática [Davila Quintero 97]. Para dar idea de cómo son estos lenguajes se ha elegido ConGOLOG [Lespérance et al. 96] [De Giacomo, Lespérance y Levesque 00]. ConGOLOG se centra en modelar la ejecución de tareas asignadas a varios agentes y su efecto en el entorno. Habla de entidades de conocimiento modificables por las tareas, a las que denomina fluents, define axiomas de ejecución de tareas, axiomas de precondición de tareas y axiomas de marco para especificar a qué fluents afecta la ejecución de tareas. La ejecución del SMA consiste en descubrir qué acciones se pueden ejecutar en el SMA que no creen inconsistencias en el conjunto de axiomas acumulados, que son el conjunto de precondiciones asociadas a las acciones posibles de los agentes, los efectos de las tareas que hayan ejecutado más las precondiciones asociadas al estado inicial. Si se descubren estas acciones, se puede hablar de un estado siguiente al actual añadiendo el efecto de las acciones seleccionadas a los axiomas acumulados.
Existen más lenguajes de alto nivel con los que se pueden construir agentes, sin embargo, no se trata de lenguajes de agentes en el sentido de Shoham o ConGOLOG, sino de lenguajes donde se proporcionan medios para tratar la concurrencia, como April [McCabe y Clark 95] o Concurrent Metamem [Fisher 91] [Fisher 95].
De los dos enfoques mostrados, los representados por Agent0 y los basados en teorías de agentes, en este trabajo se ha dado más relevancia los primeros. El motivo es que INGENIAS se centra en el desarrollo de SMA partiendo de modelos cercanos a las prácticas de ingeniería. Los desarrollos basados en teorías de agentes son más cercanos a la lógica matemática y requieren esfuerzos en su aplicación que todavía no son aceptables. Por ejemplo, para aplicar ConGOLOG, hay que predecir el efecto de las acciones sobre el entorno, lo cual no siempre es posible. Sin embargo, los lenguajes como Agent0 no requieren grandes conocimientos de lógica y, además, se basan en modelos operacionales de los agentes. La descripción de estos modelos va desde algoritmos descritos utilizando pseudo-código, como en AgentSpeak(L), hasta la enumeración de los componentes del agente, su función y cómo fluye la información de un componente a otro, como en Agent0 y CASA.
Desde un punto de vista metodológico, el principal problema de estos lenguajes es su aplicación a desarrollos de complejidad media. Los lenguajes de agentes pueden verse como lenguajes de implementación de más alto nivel que otros más convencionales como C++ o JAVA, pero con una particularidad: son muy pobres en mecanismos de abstracción y encapsulación. Los programas o especificaciones generados con ellos tienen como unidad principal de encapsulación el agente y de abstracción procedimental la tarea, lo cual limita su aplicación. Así pues, a los problemas de desarrollar un sistema directamente con un lenguaje de implementación se une la falta de medios para realizar esta tarea incrementalmente.
Entonces, la necesidad de metodologías es doblemente justificable. Por un lado, para cubrir las deficiencias de los lenguajes de agentes en cuanto a mecanismos de encapsulación y abstracción. En este sentido, las metodologías actuales definen elementos que les sirven para agrupar las distintas funcionalidades asociadas a un agente o a un grupo de agentes. Así aparecen conceptos como rol o servicio. Y por otro lado, para facilitar la comprensión de sistemas complejos tal y como ocurre con los lenguajes convencionales de implementación. Este aspecto, como se verá en las secciones posteriores, no se haya resuelto completamente en las metodologías existentes, ya que la idea de desarrollo incremental no aparece de forma explícita.
El desarrollo de SMA hoy en día es más proclive a la utilización de plataformas de desarrollo que a la aplicación de lenguajes de agentes. Esto se debe en gran parte al nivel de conocimientos necesarios que generalmente implica programar con un lenguaje de agentes. Por ello, han proliferado por un lado armazones software de SMA adaptables a diferentes dominios de aplicación y por otro plataformas de desarrollo de ámbito genérico que son implementaciones de estándares de agentes. Aunque el desarrollo con los armazones es más sencillo, hoy en día predominan los segundos.
Las plataformas de desarrollo más extendidas son JADE [Bellifemine, Poggi y Rimassa 01] y Grasshopper [Breugst y Magedanz 98]. JADE es la implementación oficial del estándar FIPA [FIPA 95], y soporta todos los servicios básicos de infraestructura especificados en FIPA (comunicaciones, movilidad, gestión de agentes y localización de agentes), a los que añade algunas utilidades gráficas para facilitar la administración de las plataformas y la depuración de los mensajes intercambiados por agentes en tiempo de ejecución. Grasshopper es la implementación del estándar MASIF [Baümer et al. 00], que soporta la movilidad de agentes en un entorno distribuido utilizando comunicación y servicios CORBA [OMG 00a]. En JADE y Grasshopper existe una arquitectura básica de agente que hay que utilizar para acceder a los servicios de la plataforma correspondiente.
El diseño de agentes con estas plataformas significa atenerse a unos estándares de comunicación y de gestión de agentes. El resto, como la especificación del control del agente, su inteligencia o las relaciones entre las tareas del sistema, se deja al criterio del desarrollador. La aportación de una metodología a desarrollos basados en este tipo de plataformas consistiría en organizar el proceso de generación del SMA y en proporcionar elementos para el diseñador pueda describir estos aspectos teniendo en cuenta las restricciones de la plataforma destino.
En cuanto a los armazones software, la aportación de las metodologías varía según el caso. ZEUS [Nwana et al. 99], por ejemplo, presenta un entorno de desarrollo con el que se programa visualmente el SMA. Las posibilidades de configuración del SMA a través de este entorno son muy variadas. Entre otros, hay que suministrar una ontología, reglas de comportamiento, planes de ejecución de tareas y mensajes a enviar a otros agentes.
Debido a esta versatilidad en su configuración, el diseño con ZEUS se hace tan complejo como programar con lenguajes de agentes. Aunque se facilita el desarrollo de aspectos como la coordinación, quedan pendientes decisiones como qué hay que coordinar y para qué. Por ello, la aportación de una metodología en este caso consistiría en proporcionar un ciclo de desarrollo, actividades y elementos conceptuales que ayudasen al descubrimiento incremental de los elementos requeridos por ZEUS. Un ejemplo, aunque limitado, de metodología para ZEUS se tiene de mano de sus propios desarrolladores [Collis y Ndumu 99], donde se aplica la idea de rol para guiar el descubrimiento de funciones del sistema.
ABLE (Agent Building and Learning Environment) [IBM 02] aunque también permite el prototipado rápido de SMA, no llega al nivel de ZEUS. ABLE es una herramienta de IBM para la construcción de sistemas de agentes inteligentes donde todos sus elementos, incluso los agentes, se construyen por composición de AbleBeans, una extensión de los JavaBeans1. Son de interés un conjunto de AbleBeans especializados que implementan sistemas de aprendizaje estadísticos (mapas autoorganizativos, redes neuronales, mapas de conexión) y control simbólico (razonamiento por encadenamiento hacia delante y lógica de predicados). ABLE incorpora también un entorno visual de desarrollo donde se interconectan AbleBeans. El interés de esta plataforma es que soluciona visualmente la construcción y comunicación de los agentes.
ABLE no llega a detallar cómo se obtiene la funcionalidad de los agentes y cómo deben actuar en cada situación. La aportación de una metodología a ABLE sería más amplia que en el caso de ZEUS. Se trataría de dar medios para detallar aspectos de control del agente teniendo en cuenta los elementos de control que vienen predefinidos en ABLE. Sería útil, por ejemplo, la idea de casos de uso [Jacobson, Booch y Rumbaugh 00] para identificar conjuntos de funciones a proporcionar por el sistema y escenarios para describir cómo se espera que se realice el proceso de aprendizaje de los agentes.
Se trata de la metodología seguida en el grupo MAGMA [MAGMA 02]. El término vowel engineering viene de que el sistema final depende de la ordenación y agrupamiento de cuatro vocales A (por agentes), E(por entorno), I (por interacciones) y O (por organización). Los modelos de agente abarcan desde simples autómatas hasta complejos sistemas basados en conocimiento. La forma de ver las interacciones van desde modelos físicos (propagación de onda en el medio físico) hasta los actos del habla (speech acts). Las organizaciones van desde aquellas inspiradas en modelos biológicos hasta las gobernadas por leyes sociales basadas en modelos sociológicos.
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.
Ilustración 2. Arquitectura de capas del Sistema Multi-Agente propuesto
Como ejemplo, [Demazeau 95] propone para aspectos de interacción un lenguaje para la descripción de protocolos de interacción basados en procesos de comunicación síncronos o asíncronos donde la semántica es muy similar a la de los actos del habla. La representación en sí se hace mediante redes de transición en las que los arcos se corresponden con los mensajes intercambiados y los estados reflejan la situación global (i.e. no hay posibilidad de que un estado se refiera al estado de un agente concreto).
Una de las más recientes publicaciones [Ricordel 01] de Vowel Engineering propone la implementación mediante la plataforma Volcano. La plataforma utiliza el ensamblaje de componentes utilizando lenguajes de composición arquitecturas, concretamente UniCon [Carnegie Mellon 02]. El desarrollo consiste en ensamblar componentes que pueden ser desarrolladas ad-hoc o proceder de una librería. Cada componente pertenece a una categoría concreta de las cuatro consideradas.
Pese a que en la literatura se indica que existe un entorno de desarrollo basado en estas ideas, este no es público. De todas formas, el trabajo desarrollado dentro de MAGMA con esta metodología es reseñable debido a su variedad en los dominios de aplicación (Sistemas de información geográfica, Robocup, simulaciones de mercados o agentes en tiempo real).
Vowel Engineering ha sido una de las primeras metodologías en modelar sistemas utilizando diferentes vistas. Aunque es prometedor, el trabajo en Vowel Engineering está incompleto ya que no termina de estabilizarse con herramientas de soporte. Además, no existen instrucciones acerca de cómo describir cada uno de los aspectos considerados.
A favor de esta metodología está la visión del modelado de sistemas como composición de elementos. Esta composición se define con un lenguaje apropiado para el problema como es un lenguaje de descripción de arquitecturas, Unicon en este caso. Como consecuencia de esta forma de desarrollo, hay que señalar que facilita la reutilización de código. Metodológicamente es mejorable. Se ha incluido aquí por ser un pionero en la definición de sistemas mediante vistas, pero necesita de más trabajo sobre todo en el estudio de cómo especificar el sistema y cómo esta especificación evoluciona a lo largo del desarrollo.
Esta metodología extiende CommonKADS [Tansley y Hayball 93] aplicando ideas de metodologías orientadas a objetos y metodologías de diseño de protocolos para su aplicación a la producción de SMAs [Iglesias 98;Iglesias et al. 98]. La metodología CommonKADS gira en torno del modelo de experiencia (explicado más tarde) y está pensada para desarrollar sistemas expertos que interactúan con el usuario. De hecho considera sólo dos agentes básicos: el usuario y el sistema. Este hecho influye en el modelo de comunicación que, consecuentemente, trata de interacciones hombre-máquina.
Esta metodología ha sido la primera en hacer un planteamiento 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 una reseña 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 [Iglesias 98] en lenguaje natural, complementándose con otras notaciones como SDL (Specification and Description Language) [International Telecommunication Union 99 A.D.b] o MSC (Message Sequence Chart) [International Telecommunication Union 99 A.D.a] para describir el comportamiento de los agentes cuando interaccionan.
MAS-CommonKADS es la metodología más cercana a las líneas principales de INGENIAS. Incorpora la idea de proceso de ingeniería en el sentido de Pressman [Pressman 82] y describe con bastante detalle cómo se debe definir el sistema teniendo en cuenta las dependencias entre los modelos. En contra hay que decir que no tiene herramientas de soporte específicas y que presenta problemas a la hora de razonar sobre la especificación de forma automática. Por otro lado, se aprecia en este trabajo el esfuerzo de cubrir todo el ciclo de vida de la aplicación, llegando hasta la implementación del sistema, lo cual no es frecuente.
La especificación de SMA que proporciona MAS-CommonKADS detalla la mayoría de aspectos en lenguaje natural. Esta particularidad dificulta el análisis automático de la especificación generada y supone una gran desventaja frente a semi-formalismos como UML, soportado por muchas herramientas y con la posibilidad de hacer chequeos para verificar el desarrollo (¿Existen elementos no utilizados? ¿Se ha asociado especificaciones de comportamiento a los casos de uso?). Para lograr lo mismo en MAS-CommonKADS habría que restringir el uso de lenguaje natural o bien incluir formalismos que logren una definición más precisa y menos ambigua del SMA.
En INGENIAS, el problema se salva utilizando meta-modelos como mecanismo de especificación. El desarrollo de meta-modelos está soportado por herramientas que permite el procesamiento automático de los modelos generados. Los meta-modelos en algunos casos profundizan más en el detalle que MAS-CommonKADS. Tal es el caso del meta-modelo de organización, el de tareas y objetivos, o el de agentes.
Las arquitecturas BDI se inspiran en un modelo cognitivo del ser humano [Bratman 87]. 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. Aunque la formulación inicial es de Bratman, fueron Georgeff, Rao y Kinny [Kinny y Georgeff 97] quienes formalizaron este modelo y le dieron visos de metodología, de hecho es su trabajo lo que aquí se comenta.
Para especificar el sistema de agentes, se emplean un conjunto de modelos que operan a dos niveles de abstracción: externo e interno. Primero, desde un punto de vista externo, un sistema se modela como una jerarquía de herencia de clases de agentes, de la que los agentes individuales son instancias. Las clases de agente se caracterizan por su propósito, sus responsabilidades, los servicios que ejecutan, la información acerca del mundo que necesitan y las interacciones externas. Segundo, desde un punto de vista interno, se emplean un conjunto de modelos (modelos internos) que permiten imponer una estructura sobre el estado de información y motivación de los agentes y las estructuras de control que determinan su comportamiento (creencias, objetivos y planes en este caso).
En esta metodología, la integración con el ciclo de vida de software es muy reducida. Los autores proponen una serie muy reducida 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. Además, el refinamiento de los modelos internos conlleva la realimentación de los modelos externos. Por ejemplo, el construir los planes y creencias de una clase de agente clarifica qué nivel de detalle se requiere en la representación del mundo que posee el agente.
Además, sobre la arquitectura que soporte estos modelos se imponen varias restricciones: que asegure que los eventos se responden en su momento, que las creencias se mantengan consistentemente, y que la selección de planes y ejecución se desarrolle de manera que refleje ciertas nociones de racionalidad.
El modelo BDI ha sido importante para este trabajo, como aplicación del principio de racionalidad. Proporciona una definición, basada en elementos intuitivos, de cómo actúan los agentes. Esta definición es lo suficientemente genérica como para permitir múltiples implementaciones sobre diferentes plataformas.
Metodológicamente, la propuesta de Georgeff, Kinny y Rao es consecuente con la dificultad de generar los modelos que proponen. Como ellos admiten, 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 (como el Proceso Racional Unificado [Jacobson, Booch y Rumbaugh 00]) con realimentaciones. Sin embargo, la forma en que tienen lugar estas realimentaciones no queda completamente definida.
En INGENIAS, los principios del BDI se hallan presentes de diferentes formas. Los planes, entendidos como secuenciación de tareas, aparecen como flujos de trabajo. Los objetivos han sido introducidos explícitamente, incluyendo su refinamiento en subobjetivos, el establecimiento de dependencias entre objetivos (inicialmente árboles Y/O [Rich y Knight 90]) y dependencias con tareas. Su uso se ha extendido a otros modelos como el de organización y el de interacciones, vertebrando la ejecución de tareas e iniciación de interacciones a lo largo de toda la metodología. Por lo tanto, el grado de integración del modelo BDI en la metodología es superior al logrado en la propuesta de [Kinny y Georgeff 97]. Y todo ello dentro de un ciclo de vida de software complejo, como es el RUP. Además, se ha logrado la independencia total de implementación dotando a la metodología de un procedimiento para parametrizar con los modelos generados armazones software escritos en cualquier lenguaje.
MaSE (Multi-agent systems Software Engineering) [DeLoach 01] se concibe como una abstracción del paradigma orientado a objetos donde los agentes son especializaciones de objetos. En lugar de simples objetos, con métodos que pueden invocarse desde otros objetos, los agentes se coordinan unos con otros vía conversaciones y actúan proactivamente para alcanzar metas individuales y del sistema.
En MaSE los agentes son simplemente 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 armazón. Dado el enfoque inicial, los agentes se ven como especializaciones de objetos. De hecho, el sistema se construye sobre técnología orientada a objetos y su aplicación a la especificación y diseño de sistemas multi-agente.
El análisis en MaSE consta de tres pasos: capturar los objetivos, aplicar los casos de uso y refinar roles. El diseño consta de cuatro pasos: crear clases de agentes, construir conversaciones, ensamblar clases de agentes y diseño del sistema. La mayoría de estos pasos se ejecutan dentro de la herramienta que soporta MaSE, AgentTool [DeLoach 01]. Como productos de estas etapas, MaSE espera: diagramas de secuencia para especificar interacciones, diagramas de estados para representar procesos internos a las tareas y modelar interacciones, descomposición del sistema (agente) en subsistemas (componentes del agente) e interconexión de los mismos (definición de la arquitectura del agente). Estos elementos son característicos del UML, de hecho su uso recuerda mucho a SDL [International Telecommunication Union 99 A.D.b]. Está por ver si las especificaciones resultantes, como las mostradas en [MultiAgent and Cooperative Robotics Lab 02], son capaces de expresar elementos característicos como razonamiento de los agentes, organización de los agentes o caracterización de su estado mental.
Además, la integración de estos diagramas en el proceso de desarrollo parece demasiado simple. Al final, la metodología podría traducirse como tome la herramienta de soporte y rellene los diferentes apartados. Esto supone ignorar que, como en el modelo BDI, se tienen dependencias entre los diagramas propuestos (como entre los diagramas de secuencia y las conversaciones) y que no es tan sencillo el saber qué máquinas de estados definen la ejecución de una tarea en el contexto de una interacción.
La herramienta de soporte permite generar código automáticamente a partir de la especificación. 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. No obstante, el proceso de generación de código es mejorable, ya que el código de los componentes a generar está entremezclado con el código que lee la especificación.
En INGENIAS, se persigue un proceso de desarrollo similar al seguido mediante otras herramientas, como Rational Rose, TogetherJ o Paradigm+. En estas herramientas, el usuario tiene libertad para elaborar diagramas incompletos o generar sus propias vistas del sistema, tomando elementos de diferentes modelos e incorporándolos a un nuevo diagrama. También se intenta separar de UML en el sentido de no repetir las mismas soluciones. La forma en que se tratan las interacciones en INGENIAS es un buen ejemplo de ello. Las interacciones buscan generalizar diferentes alternativas existentes, como los MSC [International Telecommunication Union 99 A.D.a], diagramas de secuencia o colaboración [Jacobson, Booch y Rumbaugh 00], y diagramas de protocolo (AUML [Bauer, Müller y Odell 01]). Aparte de la generalización, las interacciones se integran completamente dentro de otros modelos como un elemento más. De hecho, la iniciación de interacciones se representa como el producto de ejecutar una tarea.
Otro aspecto tenido en cuenta en INGENIAS es el proceso de generación de los modelos, esto es, qué actividades están involucradas en su producción. El resultado es un conjunto estructurado de actividades detalladas que guiarán a futuros usuarios de la metodología en su utilización. Las actividades se enmarcan en diferentes flujos de trabajo para cada modelo, con lo que se facilita una futura integración de la metodología en entornos automatizados de gestión de proyectos software como el Entorno de Creación de Servicios [Eurescom P815 99] de Telefónica I+D.
ZEUS consta de una herramienta y una metodología [Collis y Ndumu 99], de forma similar a AgentTool 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 completamente funcional. 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 [Collis y Ndumu 99]: 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.
Ante la similitud de enfoques, se impone una breve comparativa entre ZEUS y MaSE. 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. Metodológicamente, ZEUS es más pobre que MaSE. El modelado de roles, propuesto en [Collis y Ndumu 99], no profundiza en la aplicación de la herramienta dentro del proceso de desarrollo. El ámbito de la metodología se limita a estudiar cómo agrupar la funcionalidad del sistema dentro de cada rol, dejando aparte consideraciones acerca de cómo organizar las tareas, definir las ontologías y las dependencias sociales, aspectos que son modelables dentro de la herramienta.
La cuestión que se plantea al estudiar ZEUS y MaSE es si hay que tener una buena herramienta o una buena metodología. La postura de INGENIAS es que las herramientas de soporte no tienen que condicionar la metodología y que de hecho han de ser independientes. La independencia en este trabajo se consigue usando meta-modelos como elemento de construcción. Ello facilita el portar la metodología a diferentes herramientas, ya que cualquier herramienta que soporte meta-modelado podría servir como herramienta soporte de desarrollo.
Otra ventaja de los meta-modelos es que facilitan la evolución de la metodología. Tanto ZEUS como MaSE tendrían que cambiar en gran medida sus herramientas asociadas, para, por ejemplo, incluir el meta-modelo de organización de este trabajo. Sin embargo, el paso inverso, incluir elementos de MaSE o ZEUS en meta-modelos, no supone un gran esfuerzo.
Este trabajo y ZEUS tienen objetivos similares. ZEUS demuestra la aplicación de diferentes técnicas en la producción de SMA, mientras que en este trabajo se busca integrar diferentes técnicas para la especificación de SMA. Estas técnicas se hacen explícitas en este trabajo, mientras que en ZEUS eran implícitas en la construcción de la aplicación. En cuanto a la integración de la especificación en el ciclo de vida de software, ya se ha comentado en la sección anterior las aportaciones en este sentido.
GAIA [Wooldridge, Jennings y Kinny 00] [Zambonelly, Wooldridge M. y Jennings N.R. 00] 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 cual). 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. 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 [FIPA 01]. Tras esta etapa, se entraría en lo que GAIA considera diseño a alto nivel. 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 conocidos, que define los enlaces de comunicaciones que existen entre los agentes.
A partir de aquí se aplicarían técnicas clásicas de diseño orientado a objetos. Sin embargo, esto queda fuera del ámbito de GAIA. Esta metodología sólo buscar 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 desacoplarse de las distintas soluciones de implementación de agentes. Sin embargo, es cuestionable la utilidad de una metodología que genera especificaciones cuya implementación no se llega siquiera a considerar cuando en principio se pretendía llegar a un nivel de detalle fácilmente implementable.
Como solución genérica, en INGENIAS, se proporciona un procedimiento con el que se facilita el salto a la implementación del sistema. La implementación se plantea como la parametrización de un armazón software utilizando los modelos que componen la especificación.
Otro aspecto discutible es el uso combinado de fórmulas lógicas con fichas de documentación clásicas en ingeniería del software [Pressman 82]. En GAIA parece asumirse que poniendo fórmulas lógicas se consigue una mejor comprensión del problema y una mayor exactitud. El problema de estas fórmulas, aparte de su comprensión, es su definición. ¿De qué sirve establecer las precondiciones de una tarea con un conjunto de predicados cuya semántica y existencia no está definida en ningún sitio?
Para salvar este problema, en este trabajo, aparte de dejar libertad al que quiera utilizar fórmulas lógicas, se ofrecen representaciones donde los términos que componen la representación son los propios elementos del meta-modelo. Por ejemplo, se puede hablar de las cualidades de un agente con el que se quiere interactuar utilizando un modelo de agente que represente los roles que debe tener, los objetivos asociados y estado mental en el que se supone que debe estar el agente colaborador.
Como en MaSE, además, se comete el error de obviar las distintas dependencias entre los modelos propuestos, lo cual es fundamental a la hora de proponer un proceso que dé cómo salida la especificación del sistema.
En INGENIAS las dependencias entre los distintos meta-modelos se revisan independientemente. La mayoría se refiere a que al introducir ciertas entidades, hay que definir aspectos adicionales en otros modelos. Por ejemplo, al crear un objetivo, siempre hay que asociar una tarea o tareas que permiten alcanzarlo. Si el objetivo se identifica dentro de un modelo de agente, entonces, se necesita que en un modelo de objetivos y tareas se indique qué tarea o tareas deben ejecutarse.
Para terminar, el modelo de organización en GAIA es superficial ya que no se tienen en cuenta las relaciones estructurales. En la extensión de GAIA comentada en [Zambonelly, Wooldridge M. y Jennings N.R. 00] y supuestamente dedicada a cubrir este hueco, se habla más de restricciones sociales respecto a uso de roles que de la organización en sí.
En INGENIAS el meta-modelo de organización se ve respecto del SMA como el equivalente a la arquitectura del sistema de un sistema convencional. Sirve para definir a alto nivel cómo se organizan los elementos del sistema para hacer posible los objetivos comunes a los agentes que participan en la organización.
MESSAGE [Caire et al. 02] es la metodología más reciente de las estudiadas y por tanto trata de integrar resultados de las anteriores. Propone el análisis y diseño del SMA desde cinco puntos de vista para capturar los diferentes aspectos de un SMA: el de Organización, que captura la estructura global del sistema; el de Tareas/Objetivos, que determina qué hace el SMA y sus agentes constituyentes en términos de los objetivos que persiguen y las tareas implicadas en el proceso; el de Agente, que contiene una descripción detallada y extensa de cada agente y rol dentro del SMA; el de Dominio que actúa como repositorio de información (para entidades y relaciones) concernientes al dominio del problema; y el de Interacción, que trata las interacciones a distintos niveles de abstracción.
Estos elementos están presentes en los dos modelos fundamentales que propone MESSAGE: el modelo de análisis y el modelo de diseño. El modelo de análisis se limita a generar modelos a partir de los meta-modelos. El modelo de diseño no llegó a concretarse completamente. Se decidió que el propósito del diseño sería producir entidades computacionales que representen el SMA descrito en el análisis. Por ello, cada artefacto producido en el análisis debería transformarse en una entidad computacional o varias cuyo comportamiento fuera el que se esperaba en el análisis. Esto significa que las entidades del análisis se deberían traducir a subsistemas, interfaces, clases, signaturas de operaciones, algoritmos, objetos, diagramas de objetos y otros.
MESSAGE aporta mejoras en cuanto a conceptos de ingeniería respecto de las alternativas existentes, entre ellas el desarrollo dentro de un paradigma de ingeniería del software (el Proceso Racional Unificado), aportación de métodos para la traducción de entidades de análisis a entidades de diseño y guías para la generación de los modelos.
Sin embargo, los objetivos de MESSAGE no se completaron totalmente. La integración con el Proceso Racional Unificado no fue total, ya que las actividades definidas no se adecuaban a las necesidades reales y no se indicó cómo encajaban dentro de este proceso. Además, faltó trabajo en el estudio de las interdependencias entre los distintos modelos propuestos.
A favor de MESSAGE hay que destacar que ha sido la primera metodología en utilizar una herramienta para soporte del proceso de especificación de SMA de forma visual, como en UML [OMG 00d]. En cuanto a la implementación, MESSAGE provee guías en cuanto a posibles arquitecturas y componentes a utilizar en esta etapa. Basándose en estas guías y los modelos de análisis y diseño, se realizó manualmente la implementación, lo cual hizo que se detectaran incorrecciones en las definiciones iniciales de los modelos. Esta experiencia es la base de la crítica realizada con anterioridad a ZEUS.
En INGENIAS, se plantea la evolución a lo largo del ciclo de vida del software de los modelos generados. El paso de una etapa a otra está marcado por el nivel de detalle alcanzado en cada modelo. Así, las interacciones inicialmente pueden detallarse con diagramas de colaboración para luego concretarse en el diseño con otros tipos de diagramas que alcancen más detalle en aspectos como la motivación de la interacción o actos del habla [Singh 91] empleados durante el proceso. El paso a implementación, como se ha comentado antes, se ha generalizado en forma de proceso de parametrización de armazones software. Esta forma de implementación es una evolución del trabajo de MESSAGE, donde se proponían arquitecturas y componentes adecuados para esta tarea.
Los meta-modelos en general se han modificado para integrar resultados de investigación tales como planificación de tareas, el modelo BDI, la estructuración de elementos de la comunidad o el uso de tareas. De forma similar a MAS-CommonKADS se ha estudiado el dominio de aplicación de cada meta-modelo para que se puedan aplicar los resultados correspondientes.
También se ha incluido un nuevo meta-modelo, el de entorno. MESSAGE no tenía en cuenta lo que rodeaba la aplicación, por lo cual la inclusión de elementos como servicios del sistema, recursos o aplicaciones que no fueran agentes, eran difíciles de tratar. En INGENIAS, el meta-modelo de entorno permite incluir este tipo de elementos de forma coherente. De hecho, la percepción de los agentes se expresa en función de estos elementos. Así, se puede representar que un agente de interfaz se conecte a una aplicación existente.
Partiendo de la definición de agente de Newell, se ha hecho un breve recorrido por arquitecturas de agentes, definición de SMAs con lenguajes de agentes y plataformas de desarrollo para la implementación de SMA. Durante este recorrido, se ha mostrado la necesidad de aplicar metodologías para estructurar el desarrollo de SMAs. Saber diseñar agentes y encajarlos en un sistema no es suficiente. Un sistema debe satisfacer las necesidades del cliente que lo solicitó. Hay que tomar decisiones fundamentales como elegir las cualidades que se quieren presentes en los agentes (utilizando las diferentes arquitecturas), decidir qué entidades del sistema van a ser agentes o no (utilizando la definición de Newell) y organizarlo todo según un armazón software o utilizando una plataforma de desarrollo. Debido a que este proceso no es trivial, se necesitan metodologías que guíen al ingeniero a lo largo del camino.
Se ha dedicado la mayoría de las secciones a estudiar qué metodologías son más relevantes en relación con la línea de trabajo seguida en INGENIAS y qué mejoras se aportan respecto de lo que hay hecho. Es importante reseñar que el trabajo de INGENIAS parte del trabajo realizado en MESSAGE. Esta es la primera metodología en utilizar herramientas de meta-modelado para reflejar los resultados del análisis. Este hecho permite trabajar directamente con los conceptos que intervienen en el desarrollo de SMA y probarlos in situ en casos reales. Otra ventaja de la utilización de este tipo de herramientas es que permiten asegurar que se están siguiendo los modelos indicados en la metodología en la forma prevista.
La experiencia de MESSAGE, ZEUS y MaSE ha demostrado la importancia de trabajar con herramientas que soporten el proceso de desarrollo. Metodologías como GAIA no pueden afirmar su efectividad a la hora de resolver problemas porque no hay nada que asegure que los productos de la metodología se adecúan a lo que está especificado en la misma. Por ello, muchas de las metodologías existentes precisan de sensibles mejoras antes de poder ser aplicadas a problemas reales.
Otro elemento importante a la hora de desarrollar una metodología es la idea de proceso. La generación de un SMA sigue una serie de pasos predefinidos y, generalmente, incrementales. Metodologías que siguen esta idea son MAS-CommonKADS, BDI, GAIA y, especialmente, MESSAGE. MESSAGE es más avanzada que GAIA en el sentido de que no se queda en el nivel conceptual cuando desarrolla el SMA, como hace GAIA. MESSAGE plantea transformaciones de entidades conceptuales en entidades computacionales para completar la generación del SMA.
Relacionada con la idea de proceso está la posibilidad de realizar el desarrollo de forma incremental. Las especificaciones generadas dentro del ciclo de vida del software no se desechan, sino que se reutilizan para ir ahondando en el detalle según aumenta la comprensión del sistema. De las metodologías vistas, las que mejor soportan este tipo de desarrollo son MESSAGE y MaSE. En MESSAGE, al utilizar meta-modelos, la adición de nuevos elementos y relaciones resulta algo natural. En el caso de MaSE, los diagramas utilizados para describir el sistema han sido diseñados para soportar este tipo de uso. En ambos, al disponer de una herramienta de soporte, se puede aprovechar de forma muy sencilla las especificaciones generadas en otras actividades. En las otras metodologías, esto no es tan sencillo porque no existen herramientas de soporte o bien la especificación se hace utilizando documentos de difícil reaprovechamiento, como los propuestos por GAIA o MAS-COMMONKADS.
Subyacente a todas las metodologías revisadas existe una teoría de cómo es el sistema multi-agente. Existen modelos puramente formales, como el que subyace a ConGOLOG y otros que utilizan modelos operacionales, como Agent0. De cualquier forma, en base a esta teoría es posible razonar acerca del comportamiento del sistema. Este tipo de razonamientos es más complicado con los modelos semi-formales, como los generados con UML. Sin embargo, los modelos semi-formales posibilitan que el ingeniero pueda jugar con el sistema y trabajar con problemas más complejos. Para compensar esta semi-formalidad, existen procedimientos de verificación de la especificación. Un ingeniero establece, dentro de los modelos semi-formales planteados, restricciones acerca de qué está permitido y qué no. La expresión de tales restricciones se realiza mediante lenguajes específicos, como el lenguaje Object Constraint Language (OCL) de UML.
Después de ver el trabajo de ZEUS y MaSE se puede argumentar que ya existen metodologías junto con herramientas capaces de desarrollar SMAs. Sin embargo, esto no es del todo cierto, lo que han demostrado es que se pueden desarrollar SMAs de una forma muy concreta. Estas metodologías están fuertemente restringidas por la herramienta en la que se basan ya que la herramienta se encarga al fin y al cabo de obtener parámetros de configuración para un armazón de SMA que ya existe. Además, están orientadas al desarrollo rápido con decisiones de diseño fijas más que a un desarrollo personalizado. AgentTool, por ejemplo, tiene fijas restricciones de diseño fundamentales, como el asimilar cada objetivo con requisitos y transformar estos requisitos en roles, o establecer protocolos de comunicación entre tareas internas del agente.
La aportación de INGENIAS es una metodología que extiende MESSAGE y que ofrece mejoras frente a metodologías existentes. Como ya se ha mostrado en las secciones anteriores, las propuestas existentes dejan abiertos aspectos referentes a la forma en que se modela el SMA y a la integración del desarrollo del SMA con las prácticas habituales de ingeniería.
En INGENIAS, la línea que se sigue es la de una ingeniería del software orientada a agentes según las ideas de [Pressman 82]. Pressman concibe tres elementos en una ingeniería del software: herramientas, métodos y procedimientos. En este trabajo, se proporcionan meta-modelos para definir el SMA, herramientas de soporte para generarlos y hacerlos progresar en las distintas etapas del ciclo de vida (análisis, diseño e implementación) y un conjunto de actividades que estructuran el desarrollo del SMA.
[1] Adaptative Ltd.DSTC Gazebo Software Solutions:Common Enterprise Models Domain Task Force: Proposal on Organizational structure submitted. Informe. OMG TC Work in Progress. 2000
[2] Ambvroszkiewizcz, S., K., C., O., M. y B., R.: Modelling Virtual Enterprise: agent-based approach. Actas de conferencia. Proceedings of II Iberoamerican Workshop on DAI and MAS. 1998.
[3] Barber, F., Botti, V., and Onaindia, E., Temporal Data Representation and Reasoning in REAKT, AI Communications, vol. 7, no. 3, pp. 175-202, 1994.
[4] Bauer, B., Müller, J. P., and Odell, J., Agent UML:A Formalism for Specifying Multiagent Interaction, International Journal of Software Engineering and Knowledge Engineering (IJSEKE), vol. 11, no. 3, 2001.
[5] Baümer, G., Breugst, M., Choy, S., and Magedanz, T.:Grasshopper: a universal agent platform based on OMG MASIF and FIPA standards. Informe. IKV ++ Technologies. 2000
[6] Bellifemine, F., Poggi, A. y Rimassa, G.: JADE: a FIPA2000 compliant agent development environment. Actas de conferencia. Proceedings of the fifth international conference on Autonomous agents, ACM. 2001.
[7] Bradshaw, J. M.: KAoS: An Open Agent Architecture Supporting Reuse, Interoperabiliby, and Extensibility. Actas de conferencia. Knowledge Acquisition Workshop (KAW). 1996.
[8] Bratman, M. E.: Intentions, Plans, and Practical Reason. Libro completo. Harvard University Press. 1987.
[9] Bratman, M. E., Israel, D., and Pollack, M., Plans and Resource-bounded Practical Reasoning, Journal of Computational Intelligence, vol. 4, no. 4, pp. 349-355, 1988.
[10] Brazier, F. M. T., Dunin-Keplicz, B. M., Jennings, N. R., and Treur, J., DESIRE: Modelling Multi-Agent Systems in a Compositional Formal Framework, International Journal of Cooperative Information Systems, special issue on Formal Methods in Cooperative Information Systems: Multi-Agent Systems, 1997.
[11] Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F. y Mylopoulos, J.: A Knowledge Level Software Engineering Methodology for Agent Oriented Programming. Actas de conferencia. Proceedings of the fifth international conference on Autonomous agents, ACM. 2001.
[12] Breugst, M. y Magedanz, T.: On the Usage of Standard Mobile Agent Platforms in Telecommunication Environments . Actas de conferencia. 5th Int. Conference on Intelligence in Services and Networks, Springer Verlag. LNCS 1430. 275-286.1998.
[13] Brooks, R. A., How to build complete creatures rather than isolated cognitive simulators, en Architectures for Intelligence. Lawrence Erlbaum Associates, 1991a, pp. 225-239.
[14] Brooks, R. A.:Intelligence Without Reason. Informe. Massachusets Institute of Technology, Artificial Ingelligence Laboratory. 1991b
[15] Caire, G., Leal, F., Chainho, P., Evans, R., Garijo, F., Gomez-Sanz, J. J., Pavon, J., Kerney, P., Stark, J. y Massonet, P.: Agent Oriented Analysis using MESSAGE/UML. Actas de conferencia. Springer Verlag. LNCS 2222. 2001. pp. 119-135
[16] Caire, G., Leal, F., Chainho, P., Evans, R., Garijo, F., Gomez-Sanz, J. J., Pavon, J., Kerney, P., Stark, J., and Massonet, P.:Eurescom P907: MESSAGE - Methodology for Engineering Systems of Software Agents. http://www.eurescom.de/~public-webspace/P900-series/P907/index.htm
[17] Carnegie Mellon:Unicon. http://www-2.cs.cmu.edu/People/UniCon/
[18] Carriero, N. and Gelernter, D., Linda in Context, Communications of the ACM, vol. Volume 32, no. Issue 4, pp. 444-458, 1989.
[19] Carver, N. and Lesser, V. R.:The Evolution of Blackboard Control Architectures. Informe. Department of Computer Science, University Massachusetts. 1992
[20] Chang, K.-H., Day, W. B. y Phiphobmongkol, S.: An agent-oriented multiagent planning system. Actas de conferencia. ACM conference on Computer Science, ACM Press New York, NY, USA. 107-114.1993.
[21] Coffman, E. G., Elphick, M. J., and Shoshani, A., System deadlocks, ACM Computing Surveys, vol. 3, no. 2, 1971.
[22] Collis, J. C. and Ndumu, D. T.:The Role Modelling Guide. Informe. Applied Research and Technology, BT Labs. 1999
[23] Corkill, D. D., Blackboard Systems, AI Expert, vol. 6, no. 9, pp. 40-47, 1991.
[24] Cost, R. S., Chen, Y., Finin, T., Labrou, Y., and Peng, Y., Using Colored Petri Nets for Conversation Modeling, en Issues in Agent Communication. Springer Verlag, 2000.
[25] Davila Quintero, J. A.: Agents in Logic Programming. Tesis doctoral. University of London. 1997.
[26] De Giacomo, G., Lespérance, Y. y Levesque, H. J.: ConGolog, a concurrent programming language based on the situation calculus. Artificial Intelligence. Vol. 121 pp. 109-169.2000.
[27] Decker, K. S., Task Environment Centered Simulation, en Simulating Organizations: Computational Models of Institutions and Groups. AAAI Press/MIT Press, 1996.
[28] Decker, Keith S. and Lesser, Victor R.:Designing a Family of Coordination Algorithms. Informe. Department of Computer Science, University of Massachusetts. 1995
[29] Decker, S. Keith:Environment Centered Analysis and Design of Coordination Mechanisms. Informe. Department of Computer Science, University of Massachusetts. 1995
[30] DeLoach, S.: Analysis and Design using MaSE and agentTool. Actas de conferencia. Proceedings of the 12th Midwest Artificial Intelligence and Cognitive Science Conferece (MAICS). 2001.
[31] DeLoach, S. A., Wood, M., and Sparkman, C. H., Multiagent Systems Engineering, The International Journal of Software Engineering and Knowledge Engineering, vol. 11, no. 3, June2001.
[32] Demazeau, Y.: From cognitive interactions to collective behaviour in agent-based systems. Actas de conferencia. European Conference on Cognitive Science. 1995.
[33] Departamento de Inteligencia Artificial (UPM):PILLOW. http://www.clip.dia.fi.upm.es/miscdocs/pillow/pillow.html
[34] Depke, R., Heckel, R. y Küster, J. M.: Improving the Agent-Oriented Modeling Process by Roles. Actas de conferencia. Proceedings of the fifth international conference on Autonomous agents, ACM. 2001.
[35] Durfee, E. H., Lesser, V. R., and Corkill, D., Trends in Cooperative Distributed Problem Solving, IEEE Transactions on Knowledge and Data Engineering, 1989.
[36] Eurescom P815:Communications Management Process Integration Using Software Agents. http://www.eurescom.de/public/projects/P800-series/p815/default.asp
[37] Ferber, J.: Multi-Agent Systems. Libro completo. Addison-Wesley. 1999.
[38] Ferber, J. y Gutknecht, O.: A Meta-Model for the Analysis and Design of Organizations in Multi-Agent Systems. Actas de conferencia. Proceedings of the Third International Conference on Multi-Agent Systems (ICMAS98), IEEE CS Press. 1998.
[39] Fikes, R. y Nilsson, J.: STRIPS: A New Approach to the Application of Theorem Proving to Problem Solving. Artificial Intelligence. Vol. 2 no. 3/4,1971.
[40] Finin, T., Fritzson, R., McKay, D. y McEntire, R.: KQML as an Agent Communication Language. Actas de conferencia. 3rd International Conference on Information and Knowledge Management (CIKM94), ACM Press. 1994.
[41] FIPA:Foundations for Intelligent Physical Agents. http://www.fipa.org
[42] FIPA:ACL Message Structure Specification. http://www.fipa.org
[43] FIPA:Agent Message Transport Service Specification. http://www.fipa.org
[44] Fisher, M.: Concurrent METATEM Processes -- A Language for Distributed AI. Actas de conferencia. Proceedings of European Simulation Multiconference , SCS Press. 1991.
[45] Fisher, M., Representing and Executing Agent-Based Systems, en Intelligent Agents. Springer Verlag, 1995.
[46] Flake, S. y Geiger, C.: CASA - Structured Design of a Specification Language for Intelligent Agents. Actas de conferencia. Asian Computing Science Conference. 1999.
[47] Franklin, S. y Graesser, A.: Is it an Agent, or Just a Program? A Taxonomy for Autonomous Agents. Actas de conferencia. Agent Theories, Architectures, and Languages. 1996.
[48] Gamma, E., Helm, R., Johnson, R. y Vlissides , J.: Design Patterns: Elements of Reusable Object-Oriented Software. Libro completo. Addison Wesley Professional Computing Series. 1995.
[49] Garijo, F., Gomez-Sanz, J. J. y Massonet, P.: Multi-Agent System Organization. An Engineering Perspective. Actas de conferencia. MAAMAW 2001. Por publicar.
[50] Genesereth, M. R., Software Agents, Communications of the ACM, 1994.
[51] Gomez-Sanz, J. J., Garijo, F. y Pavon, J.: Intelligent Interface Agents Behaviour Modelling. Actas de conferencia. Mexican International Congress of Artificial Intelligence 2000, Springer Verlag. LNAI 1793. 2000. pp 598-609.
[52] Gomez-Sanz, J. J., Pavon, J. y Garijo, F.: Meta-modelling of Multi-Agent Systems. Actas de conferencia. ACM. SAC 2002 ACM. 2002. pp. 37 – 41.
[53] Gómez-Sanz, J. J.: Termostatos y Agentes. Actas de conferencia. Simposio Español de Informática Distribuida. 2000. pp. 21- 26.
[54] Hendler, J., Tate, A., and Drummong, M., AI Planning: Systems and Techniques, AI Magazine, vol. 11, no. 2, pp. 61-78, 1990.
[55] Huhns, M. S., Multiagent Systems and Societies of Agents, en Multiagent Systems . MIT Press, 2000.
[56] IBM:Agent Building and Learning Environment (ABLE). http://www.alphaworks.ibm.com/tech/able
[57] Iglesias, C.: Definicion 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.
[58] 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.
[59] International Telecommunication Union:ITU-120: Formal Description Techniques (FDT): Message Sequence Chart. Informe. 99a
[60] International Telecommunication Union:ITU 100:Formal Description Techniques (FDT)- Specification and Description Language (SDL). Informe. 99b
[61] Jacobson, I., Booch, G. y Rumbaugh, J.: El Proceso Unificado de Desarrollo de Software. Libro completo. Addison Wesley. 303-3792000.
[62] Jacobson, I., Rumbaugh, J. y Booch, G.: The Unified Software Development Process. Libro completo. Addison-Wesley. 1999.
[63] Jennings N. and J., C., Towards a Social Level Characterisation of Socially Responsible Agents, IEEE Proceedings on Software Engineering, vol. 144 (1) pp. 11-25, 1997.
[64] Kendall, E.: A Methodology for Developing Agent Based Systems for Enterprise Integration. Actas de conferencia. IFIP Working Conference of TC5 Special Interest Group on Architectures for Enterprise Integration. 1995.
[65] Kendall, E.: Agent Roles and Role Models. Actas de conferencia. Intelligent Agents for Information and Process Management. 1998.
[66] Kinny, D. and Georgeff, M., Modelling and Design of Multi-Agent Systems, Springer Verlag, 1997.
[67] Kinny, D., Georgeff, M., and Rao, A.:A Methodology and Modelling Technique for Systems of BDI Agents. Informe. 1997
[68] Laird, J. E., Bates Congdom, C., and Coulter, K. J.:The SOAR's users manual v.8.2. Informe. 1999
[69] Laird, J. E., Newell, A. y Rosenbloom, P. S.: SOAR: an architecture for general intelligence. Artificial Intelligence. Vol. 33 no. 1, pp. 1-64.1987.
[70] Langley, B., Paolucci, M. y Sycara, K.: Discovery of Infrastructure in Multi-Agent Systems. Actas de conferencia. Agents 2001 Workshop on Infrastructure for Agents, MAS, and Scalable MAS. 2001.
[71] Lespérance, Y., Levesque, H. J., Lin, F. y Marcu, D.: Foundations of a Logical Approach to Agent Programmaing. Actas de conferencia. Springer-Verlag. Lecture Notes in Artificial Intelligence. 1996.
[72] Lyytinen, K. S. y Rossi, M.: METAEDIT+ --- A Fully Configurable Multi-User and Multi-Tool CASE and CAME Environment. Actas de conferencia. Springer-Verlag. LGNS#1080.1999.
[73] MAGMA:MAGMA Research Group. http://www-leibniz.imag.fr/MAGMA/
[74] Malone, T. W. and Crowston, K., The Interdisciplinary Study of Coordination, ACM Computing Survey, vol. 26, no. 1, pp. 87-119, Mar.1994.
[75] Maturana, H.:Autopoiesis, Structural Coupling and Cognition. International Society for the System(s) Science(s) (ISSS). http://www.isss.org/maturana.htm
[76] McCabe, F. G. and Clark, K. L., April - Agent PRocess Interaction Language, en Intelligent Agents. Springer Verlag, 1995.
[77] Microsoft:Distributed Component Object Model. http://www.microsoft.com
[78] MultiAgent and Cooperative Robotics Lab:AgentTool 1.8.3 User's manual. http://www.cis.ksu.edu/~sdeloach/ai/mase.htm
[79] Myers, B. A. y Rosson, M. B.: Survey on user interface programming. Actas de conferencia. ACM. 195-202.1992.
[80] Newell, A., The knowledge level, Artificial Intelligence, vol. 18 pp. 87-127, 1982.
[81] Newell, A. and Simons, H. A., GPS: A program that simulates Human Thought, en Computers and Thought. Mc Graw Hill, 1963.
[82] Nowostawski, M., Purvis, M y Cranefield, S.: Modelling and Visualizing Agent Conversations. Actas de conferencia. 2001.
[83] Nwana, H. S., Ndumu, D. T., Lee, L. C., and Collis, J. C., ZEUS: A Toolkit for Building Distributed Multi-Agent Systems, Applied Artificial Intelligence Journal, vol. 1, no. 13, pp. 129-185, 1999.
[84] OMG:CORBA 2.4.2 Specification . http://www.omg.org
[85] OMG:MOF. Meta Object Facility (specification). Informe. 3-4-2000b
[86] OMG:Task and Session CBOs Specification. Informe. 1-4-2000c
[87] OMG:Unified Modeling Language Specification. Version 1.3. http://www.omg.org
[88] Papadopoulos, G. A. y Arbab, F.: Coordination Models and Languages. Actas de conferencia. Coordination Languages.1998.
[89] Pattison, H. e. a., Instantiating Descriptions of Organizational Structures, Pitman Publishing/Morgan Kaufman Publishers, 1987, pp. 59---96.
[90] Pressman, R. S.: Software Engineering: A Practitioner's Approach. Libro completo. McGraw-Hill Series in Software Engineering and Technology. McGraw-Hill, Inc. 1982.
[91] PSI3:Personalized Service Integration Using Software Agents. http://www.psi3.org/index.htm
[92] Rao, A., AgentSpeak(L): {BDI} Agents Speak Out in a Logical Computable Language, en Agents Breaking Away. Springer Verlag, 1996.
[93] Ribeiro, A. y Demazeau, Y.: A Dynamic Interaction Model for Multi-Agent Systems. Actas de conferencia. II Iberoamerican Workshop on D.A.I. and M.A.S. 1998.
[94] Rich, E. y Knight, K.: Artificial Intelligence. Libro completo. McGraw-Hill. 1990.
[95] Ricordel, P. M.: Programmation Orientée Multi-Agents , Développement et Déploiement de Systèmes Multi-Agents Voyelles. Tesis doctoral. INSTITUT NATIONAL POLYTECHNIQUE DE GRENOBLE. 2001.
[96] Rosenschein, S. J. y Kaelbling, L. P.: A Situated View of Representation and Control. Artificial Intelligence. Vol. 73 no. 1/2, pp. 149-173.1995.
[97] Russell, S. y Norvig, P.: Artificial Intelligence: a modern approach. Libro completo. Prentice Hall. 1995.
[98] Sacerdoti, E.: A Structure for Plans and Behaviours. Artificial Intelligence. 1977.
[99] Shoham, Y., Agent Oriented Programming, Artificial Intelligence, vol. 60 pp. 51-92, 1993.
[100] Shoham, Y. and Tennenholtz, M., On the emergence of social conventions: Modeling, analysis, and simulations, Artificial Intelligence, vol. 94, no. 12, pp. 139-166, 1997.
[101] Sichman, J. S., Conte, R., Demazeau, Y. y Castelfranchi, C.: A social reasoning mechanism based on dependence networks. Actas de conferencia. 1994.
[102] Singh, M. P.: Towards a formal theory of Communication for Multiagent Systems. Actas de conferencia. International Joint Conference on Artificial Intelligence (IJCAI). 1991.
[103] Smith, R. G., The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver, IEEE Transactions on Computers, vol. C-29(12) pp. 1104-1113, 1980.
[104] Spivey, J. M.: The Z Notation: a reference manual. Libro completo. Prentice Hall. 1992.
[105] Sun Microsistems:Remote Method Invocation Specification. http://java.sun.com
[106] Sycara, K., Klusch, M., idof, S., and Lu, J., Dynamic Service Matchmaking among Agents in Open Information Environments, Journal ACM SIGMOD Record , Special Issue on Semantic Interoperability in Global Information Systems, 1999.
[107] Tanenbaum, A. S. y WoodHull, A. S.: Sistemas Operativos: Diseño e implementación. Libro completo. Prentice Hall. 1997.
[108] Tansley, D. S. W. y Hayball, C. C.:
Knowledge Based systems Analysis and Design
a KADS
developer's handbook. Libro completo.
Prentice Hall. 1993.
[109] Van Dyke Parunak, H., Manufacturing experience with the contract net, en Distributed Artificial Intelligence. 1987, pp. 285-310.
[110] Veloso, M., Carbonell, J., Perez, A., Borrajo, D., Fink, E., and Blythe, J., Integrating Planning and Learning: The PRODIGY Architecture, Journal of Experimental and Theoretical Artificial Intelligence, 1995.
[111] Wagner, T. y Horling, B.: The Struggle for Reuse and Domain Independence: Research with TAEMS, DTC and JAF. Actas de conferencia. Proceedings of the 2nd Workshop on Infrastructure for Agents, MAS, and Scalable MAS. 2001.
[112] Walker, A. y Wooldridge, M.: Understanding the emergence of conventions in multi-agent systems. Actas de conferencia. AAAI Press. 1995.
[113] Weld, D. S., Recent Advances in AI Planning, AI Magazine, vol. 20, no. 2, pp. 93-123, 1999.
[114] WHITAKER, R.:Self-Organization, Autopoiesis, and Enterprises. ACM SIGGROUP. http://www.acm.org/siggroup/auto/Main.html
[115] Wood, M. y DeLoach, S.: Developing Multiagent Systems with agentTool. Actas de conferencia. ATAL 2000. LNAI 1986. Castelfranchi, C. and Lespérance, Y.2000.
[116] Wooldridge M. y Jennings N.R.: Pitfalls of Agent-Oriented Development. Actas de conferencia. Proceedings of the Second International Conference on Autonomous Agents. 385-391.1998.
[117] 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.
[118] Wooldridge, M. J. y Jennings, N. R.: Agent Theories, Architectures, and Languages: A Survey. Actas de conferencia. Springer-Verlag. Wooldridge, M. and Jennings, N. R.1995.
[119] Wooldridge, M. J.: The Logical Modelling of Computational Multi-Agent Systems. Libro completo. 1992.
[120] Workflow Management Coalition:The Workflow Management Coalition Specification: Workflow Management Coalition Terminology & Glossary. Informe. 1999
[121] Zambonelly, F., Wooldridge M., and Jennings N.R., Organisational Rules as an Abstraction for the Analysis and Design of Multi-Agent Systems, International Journal of Software Engineering and knowledge Engineering, 2000.
[122] Zilouchian, A., Fundamentals of Neural Networks, en Intelligent Control Systems . CRC Press, 2000, pp. 17-38.
1 Un JavaBean es un componente portable e independiente de la plataforma escrito en Java. Y como componente que es, una JavaBean permite ser inspeccionado, personalizado y maneja una serie de eventos que le permiten comunicarse con el exterior o con otros JavaBeans