Las metodologías para el desarrollo de Sistemas Multi-Agentes y RUP Alfredo Simón, Reinier Valdés, Alejandro Rosete, Mailyn Moreno, Exiquio Leyva, Joaquín Pina, Raisa Socorro, Félix O. Fernández Centro de Estudios de Ingeniería de Sistemas (CEIS), Instituto Superior Politécnico “José Antonio Echeverría” (CUJAE) { asimon, rvaldes, rosete, my, exiquio, jpina, raisa, felix}@ceis.cujae.edu.cu Resumen Dentro del marco de la Inteligencia Artificial, han surgido los Sistemas Multiagentes caracterizados por ofrecer posibles soluciones al desarrollo de problemas complejos con características distribuidas, aumentando de esta forma el grado de complejidad del proceso de desarrollo. Esto se ve más marcado cuando no se cuenta con los métodos y herramientas lo suficientemente preparadas para guiar este proceso. En los últimos años se han desarrollados varios trabajos que abordan esta problemática, algunos que proponen modificaciones a lo que ya existe y otros, estrategias totalmente nuevas. En este trabajo inicialmente se describe cual ha sido el comportamiento y la evolución del Lenguaje Unificado de Modelado (UML, sus siglas en inglés), haciendo esencial énfasis en sus limitaciones para modelar algunos procesos de este tipo de sistemas. Se describen además un conjunto de modificaciones realizadas a un grupo de artefactos de UML recogidas en la propuesta AgenteUML, comúnmente conocido como AUML, así como, las consideraciones fundamentales de algunas metodologías existentes hoy y que utilizan artefactos de ambas propuestas. Por último, se hace un bosquejo de una de las metodologías puras de agentes más conocida: GAIA. Se concluye en la ausencia de un estándar metodológico en este paradigma. 1. Introducción El paradigma de Agentes y Sistemas Multiagentes (SMA) constituye actualmente un área de creciente interés dentro de la Inteligencia Artificial, entre otras razones, por ser aplicable a la resolución de problemas complejos no resueltos de manera satisfactoria mediante técnicas clásicas. Son varias las definiciones que se han publicado sobre el conceptos de agentes, ninguna plenamente aceptada, siendo la más simple la que se planteada por Russell en 1999 [1] que considera como un agente a una entidad que
percibe y actúa sobre un entorno, con una determinada autonomía. Son ya varias las áreas de aplicación de este tipo sistemas, tales como: el control de procesos, procesos de producción, control de tráfico aéreo, aplicaciones comerciales, gestión de información, comercio electrónico, aplicaciones médicas, juegos, etc. Las características inherentes a los agentes, incrementada en los SMA, le aportan una elevada complejidad a su proceso de construcción, sobre todo cuando no se cuentan con los métodos y herramientas lo suficientemente completas y fáciles de utilizar en este sentido. A pesar de que actualmente se pueden encontrar en la literatura muchos trabajos relacionados con el proceso de desarrollo de SMA, es todavía un problema a resolver ya que, cada vez más se está requiriendo de métodos, técnicas y herramientas que faciliten aún más este proceso. La ingeniería de software asociada a los SMA, se ha llevado a cabo en los últimos años a partir del desarrollo de abstracciones del paradigma orientado a objetos, considerando al agente como una especialización de los objetos. Las primeras metodologías que se desarrollaron tuvieron una concepción muy cercana al paradigma orientado a objetos y en algunas de ellas se proponía la utilización de UML. Estas propuestas reportan limitaciones ya que los agentes no son especificaciones de objetos, son mucho más que eso, lo que significa que hay que buscar otras alternativas que contemplen la mayor parte de las características de este nuevo paradigma. En los últimos años han aparecido investigaciones que tratan de presentar metodologías propias para el desarrollo de SMA, a partir de modificaciones de propuestas existentes y otras que presentan concepciones completamente nuevas para desarrollo de software. En este trabajo se describe la evolución de UML, como lenguaje estándar de modelado, haciendo esencial énfasis en sus limitaciones para representar algunos procesos esenciales en este tipo de sistemas. Se describen además un conjunto de modificaciones realizadas a un grupo de artefactos de UML recogidas en la propuesta AgenteUML, comúnmente conocido como AUML, así como. Por último, se describen las consideraciones fundamentales de dos de las metodologías existentes hoy, que utilizan artefactos de UML y de AUML y además su concepción está bastante cerca a la de RUP. Luego se presenta brevemente una de las metodologías puras de agentes: GAIA
-2-
2. UML: Limitaciones y propuestas 2.1 El UML actual y el desarrollo de los SMA. La versión 1.0 de UML fue publicada 1997, a través de ella se unificó y formalizó muchos de los métodos que se habían definido hasta aquel entonces enfocados a la programación orientada a objetos, como es el caso de los trabajos de Booch, Rumbaugh (OMT) y el de Jacobson y Odell [2]. Este leguaje se ha convertido en el transcurso de los años en un estándar de especificación, construcción, visualización y documentación de artefactos, muy útiles en el proceso de desarrollo de software para los sistemas de software. El surgimiento y la propia concepción del mismo, está marcado por el paradigma orientado a objeto, que es el que ha predominado en los últimos años en el desarrollo de software. Sin embargo ha surgido un nuevo paradigma de desarrollo de software, el de los basados en agentes inteligentes. Los SMA tienen sus particularidades con relación al resto de los demás sistemas convencionales que se desarrollan en la actualidad. Estas particularidades provocan que lo definido en UML tenga sus limitaciones para este tipo de sistemas. Básicamente hay dos razones fundamentales que generan esta insuficiencia de UML. En primer lugar, comparado con los objetos, los agentes son más activos ya que ellos pueden tomar la iniciativa y tener el control de todas las peticiones de los procesos externos: cada agente tiene su propio comportamiento. En segundo lugar, los agentes no solo actúan de forma aislada sino en cooperación y coordinación con otros agentes [3], y esto tiene implicaciones fuertes para la flexibilidad que es necesaria en la comunicación entre ellos. Tanto el comportamiento autónomo de los agentes, como los niveles de interacción entre ellos son elementos que le añaden complejidad a este tipo de sistemas según el trabajo descrito en [4]. Estas limitaciones de UML se manifiestan en un plano un poco menos conceptual en algunos artefactos como los Diagramas de Secuencia y los Diagramas de Transición de Estados o de Actividad. Según James Odell hay dos vertientes fundamentales en las que UML puede ser extendido para modelar SMA: ??Soporte para expresar hilos concurrentes de interacción para posibilitar el modelado de protocolos de agentes. ??Una noción de rol que extienda la dada en UML y permita el modelado de agentes ejecutándose en varios roles.
-3-
Con el propósito adaptar lo definido en UML para su aplicación en este ambiente de agentes inteligentes, se realizaron un conjunto de trabajos, a partir de la cooperación establecida entre la Foundation of Intelligent Physical Agents (FIPA) y Object Management Group (OMG). Uno de los primeros resultados de esta cooperación fue la propuesta de AgentUML (AUML) [3] [5].
2.2 AUML. Una alternativa de modelado para SMA. AUML es una alternativa de extensión de un conjunto de artefactos de UML para su utilización en el proceso de desarrollo de los SMA. Esta nueva propuesta intenta unir lo desarrollado en materia de metodologías de desarrollo de software de agentes con los estándares definidos para el desarrollo de software Orientados a Objetos. Los autores (Bauer, Odell y otros) sugieren una representación en tres capas, denominada Agent Interaction Protocol (AIP) [3]: ??1ra: Representa los protocolos de comunicación y se utilizan los Paquetes y los Templates de UML para la especificación de estos protocolos. ??2da: Muestra la interacción de los agentes usando Diagramas de Interacción UML. ??3ra: Muestra el procesamiento interno de los agentes por medio de los Diagramas de Actividad y de Estados. La definición del AIP se describe en dos elementos fundamentales: ??Patrones de comunicación que representan secuencias de mensajes entre agentes que tienen diferentes roles y cuyo contenido de los mensajes es restringido. Según FIPA, existen dos estándares para los tipos de contenidos entre mensajes (ACL y KQML). ??Semántica de las actividades comunicativas dentro de los patrones de comunicación. En AUML se introduce el Diagrama de Protocolo que extiende el Diagrama de Secuencia de varias formas, específicamente en: roles de agentes, hilos de ejecución en la línea de vida, semántica de los mensajes, parametrización anidada de los protocolos y las plantillas de los protocolos. Se combinan los Diagramas de Secuencia con la notación de los diagramas de estados para la especificación de los protocolos de interacción. Los Diagramas de Secuencia son candidatos básicos para modelar la comunicación entre los agentes y han sido los que más han sido objeto de modificación, ya que no describen
-4-
de forma satisfactoria esas complejas interacciones. Son útiles también los Diagramas de Estados pero estos no pueden describir el comportamiento de un grupo de objetos que se encuentran cooperando entre si, característica básica también de los SMA. La incorporación de la representación de diferentes hilos de ejecución en los Diagramas de Interacción (Secuencia), es considerado uno de los aportes más significativos y complejos de extensión en estos artefactos de UML. Esto provoca transformaciones considerables en la línea de vida de los objetos (agentes), a partir del momento en que esa línea de vida depende de los mensajes que van arribando. La figura 1 muestra la representación de las diferentes alternativas para modelar este paralelismo de mensajes.
AND
OR
XOR
Fig. 1 Representación de los hilos de ejecución en los Diagramas de Secuencia [6]. En el AND todo los hilos se envían de manera concurrente, en el OR existe un elemento de decisión ya que pueden ser ennviado uno o varios hilos de ejecución y en el caso del XOR solo se enviará un hilo de ejecución [3] [6]. Todos los elementos descritos sobre las extensiones de los Diagramas de Secuencia son extendidos a los Diagramas de Colaboración.
-5-
Fig. 2 Protocolo DiseminarInformación usando AUML.
En la Fig. 2 se muestra el Paquete DiseminarInformacion en el que se representa un protocolo simple de comunicación entre el agente Coordinador y el agente DSI. Aquí el agente Coordinador envía una “PeticionDiseminacion” y el agente DSI responde con una “RespuestaDiseminacion”. Antes de que el agente DSI le envíe una respuesta al agente Coordinador, previamente debe enviar un mensaje “SolicitudConexion” al agente Correo, quién decidirá si acepta o rechaza la solicitud. Si la respuesta es satisfactoria, entonces el agente DSI transmitirá el correo. Se pueden apreciar las dos primeras capas del AIP, se muestra la comunicación entre los Paquetes (correspondiente a la 1ra Capa) y la interacción entre los agentes por medio de un Diagrama de Secuencia (correspondiente a la 2da Capa). Además se ha mostrado un ejemplo de cómo se utiliza la alternativa de concurrencia de hilos de ejecución del tipo XOR, cuando el Agente Correo tiene que responder si “Rechaza” o “Acepta” al Agente DSI a partir del mensaje emitido por este último de “Solicitud de Conexión”. Los Protocolos de Comunicación se agrupan en los Paquetes puesto que de esta manera se pueden ser convertidos en patrones de interacción, lo que permite que pueda hacerse módulos reutilizables. La semántica asociada al Paquete se corresponde con la semántica del Protocolo. La organización de estos protocolos permite que se pueda intercambiar
-6-
información con otros Protocolos de Comunicación a través de la mensajería entre Paquetes. Cada uno de los Protocolos de Comunicación pueden ser convertidos a su vez en Plantillas para su posterior reutilización. Otra variante de uso de UML, consiste en representar conversaciones entre agentes usando pares de Diagramas de Actividad para modelar las acciones a ambos lados de la conversación. Todas estas extensiones que se proponen en AUML de artefactos definidos en UML y otras que no se han descrito en este trabajo son estudiadas para incorporarse en próximas versiones de UML. Esto quiere decir, que aún no se está cerca de un estándar porque aún no es al máximo de profundidad el estudio hecho de las limitaciones de UML. 3. Metodologías de desarrollo de SMA que utilizan UML y AUML. Las investigaciones relacionadas con el proceso de desarrollo de los SMA han ido en ascenso y a gran velocidad. Esto se ve reflejado en el volumen apreciable de metodologías que se han definido para llevar a cabo el desarrollo de SMA, ejemplo de algunas de ellas están: PASII [7], MESSAGE [8] [9], GAIA [10, 11], ZEUS, MASCommonKADS, Vowel Engineering, MaSE [12] [6], TROPOS[13], RoMAS[14], etc. Estas metodologías siguen de forma general una estrategia de análisis y el diseño, basada en tres modelos fundamentales: el modelo de agentes, que contiene a los agentes y su estructura interna (creencias, planes y metas), el modelo organizacional que describe las relaciones entre los agentes (herencia y roles en la organización) y el modelo de cooperación que describe las interacciones entre los agentes. Independientemente de esto cada una propone un procedimiento particular, para llegar a su objetivo final y usando términos diferentes. Este conjunto de metodologías pueden ser divididos en dos grandes grupos. Un primer grupo que concentraría aquellas metodologías que no utilizan UML, las cuales proponen una concepción totalmente nueva para el desarrollo de sistemas informáticos como GAIA y KINNY, más distantes del paradigma orientado a objetos y un segundo grupo que son las que hacen uso de UML, AUML y en algunos casos KQML, que son diferentes formalismos de representación. Este último grupo en su gran mayoría incluyen todavía muchos criterios devenidos del paradigma orientado a objeto, por lo que su concepción está cercano a metodologías ya existentes, por ejemplo RUP o Proceso Unificado de Rational.
-7-
No es objetivo de este trabajo describir cada una de las metodologías, ni mucho menos compararlas, ya se han publicado varios trabajos con este enfoque [1, 5, 15, 16], solo se profundizará en dos de estas metodologías (MaSE y Tropos) de las que más semejanza tienen con el Proceso Unificado de Racional, con el objetivo de evaluar como es el uso de UML y AUML 3.1 MaSE (Multi-agent systems Software Engineering). Es una metodología desarrollada en el Air Force Institute of Technology [6]. Dicha metodología trata de cubrir todas las etapas en el proceso de construcción de un SMA, partiendo de la especificación del mismo hasta su implementación. Dispone de un lenguaje de especificación basado en UML+OCL (Object Constraint Leguage), lo que evidencia mucho acercamiento a los conceptos orientados a objetos, asumiendo al agente como un objeto (con inteligencia o no).
Fig. 3 Fases de la Metodología MaSE. En la figura 3 se muestran las diferentes fases que propone esta metodología y los diferentes productos que son obtenidos en cada una de ellas, que a su vez son entradas a las siguientes fases (sombreados en azul). Se puede apreciar en la etapa de “Captura de Metas” la identificación de Casos de Uso, creados en este caso para identificar los posibles canales de comunicación y no para representar combinaciones de eventos y datos del sistema. Se maneja el concepto de Caso de Uso Positivo y Negativo, el primero para representar lo que debe pasar durante una operación normal y el segundo para cuando surgen errores o fallas generales. Las metas definidas son transformadas en roles
-8-
y sus tareas asociadas. Cada una de las metas están asociadas a un rol y cada uno de los roles es ejecutado o representado por una clase de agentes. Los roles están compuestos por: responsabilidades, permisos (disponibilidad de recursos de información), actividades (acciones privadas) y protocolos, y tienen la posibilidad de compartir tareas. La tercera fase de “Aplicación de los Casos de Uso”, guarda mucha semejanza con la realización de los Casos de Uso en RUP ya que esta actividad se realiza por medio de los Diagramas de Interacción de UML (con menos detalle). Posteriormente, se “Crean las Clases de Agentes” y se termina la fase de análisis. De esta fase de obtiene el Diagrama de Clases de Agentes que es muy similar al Diagrama de Objetos, aunque las relaciones en el primero se interpretan como conversaciones. Dentro de la etapa de diseño hay dos elementos relevantes a destacar. El primero es dentro de la fase de “Construcción de la Conversación”utilizando Diagrama de Transición de Estados en los que se modelan dos objetos y la conversación entre ellos y no uno. Esto se explica ya que no se modela solo la transición de estado de un objeto sino el estado de la conversación entre dos objetos que provoca sus cambios de estado (está en AUML). El segundo es dentro del “Desarrollo del Sistema”, aquí se elabora un Diagrama de Desarrollo, muy semejante al Diagrama de Despliegue de UML en el que se representan los diferentes agentes, sus comunicaciones y su despliegue físico. Todas estas fases se llevan a cabo de forma iterativa e incremental y se cuenta con una herramienta CASE (AgentTool) que implementa todas estas fases y actualmente se trabaja en la generación de código a partir de estas especificaciones. 3.2 Tropos. Tropos es una metodología de desarrollo de software basado en agentes y sigue tres ideas principales [13]: ??La noción de agente y todo lo relacionado con sus nociones mentales (objetivos, planes) es tenido en cuenta en todas las fases del proceso de desarrollo del sistema. ??Aborda de forma muy temprana una fase de análisis de requerimientos, lo que permite una mayor comprensión del entorno donde debe operar el sistema resultante, incluyendo los tipos de interacción que deben ocurrir entre los usuarios y el sistema. ??Adopta un proceso de refinado de artefactos. Incluye dentro de su propuesta fases de análisis, diseño y de implementación, este último a diferencia de la mayor parte de las metodologías existentes y no presente en la
-9-
metodología descrita anteriormente. Se apoya en la utilización de UML y de extensiones de esta como AUML, así como varios protocolos de comunicación de FIPA. Las fases generales son divididas en cinco [13]: 1. Análisis Temprano de Requerimientos: El principal objetivo de esta fase es entender el problema de la organización. Se identifican las dependencias entre los usuarios, sus objetivos, distinguiendo cuando sea necesario, objetivos fuertes y débiles en dependencia del nivel de importancia. Los objetivos pueden ser divididos en sub-objetivos en dependencia del tipo de análisis que se haga. 2. Análisis Tardío de Requerimientos: A esta fase llegan todos los objetivos y subobjetivos que son identificados en la fase anterior y se comienza a especificar más concretamente que es lo que tienen que hacer el sistema dentro del ambiente operacional, centrándose en las funcionalidades relevantes. El resultado final de esta etapa es la identificación de todos los requerimientos funcionales y no funcionales del sistema. De forma general los requerimientos funcionales salen de los objetivos y los no funcionales de los sub-objetivos. 3. Diseño de la Arquitectura: El objetivo final de esta etapa es la definición de una arquitectura del sistema de objetivos, en términos de sub-sistemas (actores) interconectándolos a través de controles de flujos (dependencias). Aquí se proponen tres pasos fundamentales: o Refinar el diagrama de actores del sistema, introduciendo sub-actores sobre el análisis de los requerimientos funcionales y teniendo en cuenta el diseño de patrones definidos. o Capturar la capacidad del actor, desde el análisis de las tareas que debe realizar cada actor o sub-actor para poder cumplir los requerimientos finales. o Definir un conjunto de tipos de agentes (componentes) y asignar a cada componente uno o varias capacidades diferentes. 4. Diseño de Desarrollo o Detallado: Esta fase está dirigida a la especificación de las capacidades a interrelaciones de los agentes. Generalmente en esta etapa ya se tiene seleccionada la plataforma de desarrollo, por lo que debe ser tomada en cuenta para mejorar dicho diseño detallado. A partir de esta fase se puede realizar una traza hacia atrás hasta el “Análisis Temprano de Requerimientos”. Todas las propiedades que son tratadas en esta fase se modelan usando artefactos AUML
-10-
5. Implementación: Esta actividad sigue paso por paso lo definido en el “Diseño Detallado”, estableciendo un mapeo entre este resultado y la plataforma de construcción seleccionada. Estas fases denotan una concepción lógica del proceso de desarrollo de software muy similar a la concepción adoptada en RUP. Adicionalmente, Tropos utiliza un entorno de modelado denominado i*, que es utilizado sobre todo el “Análisis Temprano de Requerimientos”. Este entorno aporta: actores, objetivos y dependencias entre los actores, en forma de conceptos primitivos y además utiliza los propios diagramas de cada uno de estos elementos que se proponen en la infraestructura de i*. Por ejemplo: Diagramas de Actores y Dependencias y de Objetivos. Otro factor importante de justificación del uso de i* es que en el Análisis Temprano de Requerimientos no solo es útil capturar el “Qué” y el “Cómo” sino también identificar el “Porqué” de las diferentes piezas que conforman el sistema, a la luz de la autonomía característica de los agentes.
4. Gaia. Metodología para el desarrollo de sistemas multiagentes. Existen dos tendencias en el desarrollo de metodologías para modelar los sistemas orientados a agentes. Como se vio antes, algunos investigadores tratan de extender los artefactos que se han utilizado en el desarrollo de sistemas orientados a objetos. Esto no es más que un natural intento de presentar las nuevas metodologías como un incremento o extensión de conocidos y probados métodos. En esta línea dos estándares en particular han sido propiamente adaptados, tal es el caso de UML y SPEM (Software Process Engineering Meta-Model). Por otra parte, existe un segundo grupo de investigadores con tendencias más revolucionarias, que trabajan en nuevas metodologías sin desechar del todo los elementos de las metodologías orientadas a objetos. A continuación se estudia específicamente la metodología Gaia que clasifica en el segundo grupo antes mencionado. En esta metodología lo primero que llama la atención es 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 [11].. El alcance de Gaia está dado principalmente en las fases de análisis y diseño. En esta metodología se trabaja de manera que se transita de lo abstracto a lo concreto de forma
-11-
incremental. Además, impulsa a los desarrolladores a pensar en la construcción del sistema siguiendo diseños organizacionales. Los conceptos principales de Gaia son divididos en dos categorías: abstractos y concretos. Las entidades abstractas son aquellas que se utilizan durante el análisis del sistema pero que no tienen necesariamente una realización directa en el sistema. Dentro de los conceptos abstractos se encuentran los Roles, Permisos, Responsabilidades, Protocolos, Actividades, Propiedades Activas y Propiedades Seguras (estos elementos constituyen una nomenclatura propia del modelo BDI). Las entidades concretas son usadas dentro del proceso de diseño y tienen generalmente una contraparte directa en el sistema en tiempo de ejecución. Como conceptos concretos se encuentran: Tipos de Agentes, Servicios y Relaciones. 4.1 Análisis El objetivo de la etapa de análisis es comprender el sistema y su estructura, sin referenciar ningún detalle de implementación. En Gaia esto se reduce a definir la organización que tendrá el sistema, la cual es vista como un conjunto de Roles que interactúan entre sí [10]. Esto permite pensar en el sistema basado en agentes como si se tratara de una “sociedad artificial” o una organización, dentro de la cual cada agente juega un papel o rol. Este aspecto es de los más atractivos dentro de la metodología porque permite representar los sistemas de manera natural. Es válido aclarar que en los sistemas basados en agentes, un rol puede ser interpretado por varios agentes y un agente puede interpretar varios roles, de manera similar a como ocurre en organizaciones formadas por seres humanos. Un rol esta definido por cuatro atributos [10]: ? ? Responsabilidades. ? ? Permisos. ? ? Actividades. ? ? Protocolos. Las Responsabilidades determinan la funcionalidad que cumplirá el rol, por lo que constituye su principal atributo. Las Responsabilidades se definen a partir de dos propiedades, las activas y las seguras. Las propiedades activas describen estados favorables que un agente mediante sus actividades y protocolos debe alcanzar. Mientras que las propiedades de seguridad describen estados que se deben mantener a través de todo el proceso de ejecución.
-12-
Un rol necesita un conjunto de Permisos que identifique aquellos recursos que puede acceder para poder cumplir con sus responsabilidades. Estos recursos son generalmente fuentes de información en las que puede leer, hacer modificaciones y enriquecer bajo ciertas circunstancias. Las Actividades son acciones privadas que debe realizar un rol sin interactuar con otros agentes. En alguna medida es similar al concepto de “método” en términos de programación orientada a objeto. Además, al rol se le asigna un conjunto de Protocolos para definir la forma en que este interactúa con otros agentes. Los Protocolos especifican patrones para la interacción entre los agentes, los cuales son formalmente definidos de manera que constituyen algo más que una simple secuencia de pasos. Específicamente un protocolo consta de los siguientes atributos: o Propósito: Breve descripción textual de la naturaleza de la interacción (por ejemplo, “solicitud de información”, “asignación de tarea”). o Iniciador: El rol o roles responsables de iniciar la interacción. o Contestador: El rol o roles con el que el iniciador interactúa. o Entradas: Información usada por el rol iniciador mientras utiliza el protocolo. o Salidas: Información suministrada por el contestador durante el curso de la interacción. o Procesamiento: Breve descripción textual de cualquier procesamiento que se ejecute mediante el protocolo durante el curso de la interacción. En la etapa de análisis los conceptos descritos surgen a partir de los siguientes modelos: o Modelo de Roles: En donde se identifican cada uno de los roles presentes en el sistema. o Modelo de Interacción: En donde se representan las relaciones entre los roles. Además, en este se define un protocolo por cada tipo de interacción. 4.2 Diseño El objetivo de la etapa de diseño “clásica”, es a partir de los modelos obtenidos en la etapa de análisis obtener modelos con un suficiente bajo nivel de abstracción para que puedan ser implementados fácilmente. Este concepto cambia un poco en Gaia, debido a que la etapa de
-13-
diseño solo tiene el objetivo de ver como la comunidad de agentes cooperará para cumplir las metas globales del sistema, y que necesita cada agente para sus actividades específicas [10]. En la etapa de diseño en Gaia tiene lugar la creación de tres modelos: Modelo de Agentes: Identifica los Tipos de Agentes que conformarán el sistema, y las instancias de agentes que surgirán a partir de esos tipos. Un Tipo de Agente es definido a partir de un conjunto de Roles. Pude existir una correspondencia de uno a uno, entre los Tipo de Agentes y los Roles, aunque generalmente con el objetivo de optimizar el diseño, se selecciona un grupo de roles que estén relacionados y se asocia a un solo tipo de agente. El modelo de agentes es construido utilizando un árbol de dos niveles en donde los nodos hojas representan roles y los nodos restantes representan tipos de agentes. De esta forma si un nodo N1 tiene hijos N2 y N3, significa que el tipo de agente N1 esta compuesto por los roles N2 y N3. La cantidad de agentes que serán instanciados a partir de un tipo de agente es especificada con una cuota: n (exactamente n instancias), m...n (entre m y n instancias), * (0 o más instancias), + (1 o más instancias). Resulta notable que la herencia no este presente en el modelo de agente. Gaia plantea que un sistema de agentes tendrá un número bajo de roles y tipos. Por esta razón consideran que no es útil utilizar la herencia en esta etapa de diseño a pesar de que en la implementación puede ser utilizada con grandes beneficios. Modelo de Servicios: Identifica los servicios asociados a cada rol, y especifica las propiedades esenciales de estos servicios. Gaia define los Servicios como funciones del agente, conformado por un grupo simple y coherente de actividades que el agente llevará a cabo. Es importante señalar que toda actividad identificada en la fase de análisis estará en algún servicio, aunque no todos los servicios deberán contener alguna de estas actividades. Además, cada Servicio presenta las siguientes propiedades: entradas, salidas, precondiciones y poscondiciones. Las entradas y salidas al servicio, son derivadas de forma lógica de los protocolos asociados al rol. Las precondiciones y poscondiciones representan restricciones en el servicio, estas son derivadas de las propiedades seguras del
rol. De esta forma se
evidencia que cada rol identificado en la etapa de análisis esta asociado con al menos un servicio. Como el alcance de Gaia finaliza en la etapa de diseño, no hace ningún planteamiento acerca de cómo implementar los servicios, por lo que deja a elección de los desarrolladores la manera de implementarlos.
-14-
Modelo de Relación: En este modelo simplemente se definen los enlaces de comunicación que existen entre los tipos de agentes. Aquí no se especifica cuando ni que tipo de mensajes se envían, únicamente indica que existe un canal de comunicación. Este modelo no es más que un grafo en el que los nodos representan tipos de agentes y los arcos indican que existe comunicación entre estos. Con este modelo finaliza el alcance de la metodología Gaia. 4.3 Generalidades La metodología Gaia, en sentido general brinda un marco conceptual bastante amplio para modelar sistemas basados en agentes. La forma en que define los roles y los protocolos y la implicación que estos tienen en un sistema multiagente está en total correspondencia con el nuevo paradigma. Sin embargo presenta limitaciones que son importantes señalar. Primeramente, no parece muy conveniente dejar fuera la etapa de captura de requisitos a pesar de que sugieran utilizar técnicas definidas por otras metodologías para esta tarea. La razón fundamental por lo que esto se considera negativo es que definir bien los requerimientos resulta primordial para después realizar un buen análisis. Aunque es cierto que el nuevo paradigma comienza a tener impacto a partir de la etapa de análisis, si el sistema construido no satisface los requerimientos entonces resultará totalmente inútil. El otro aspecto a señalar es que en el modelo de agentes no argumentan porqué un sistema basado en agentes presenta generalmente un número bajo de roles y tipos de agentes, por lo que no queda claro la inutilidad de la herencia en este modelo del diseño. Finalmente, la metodología termina en la etapa de diseño sin adentrarse en la etapa de implementación donde si influye el nuevo paradigma lo cual es inconsecuente con su filosofía de centrarse sólo en las etapas en donde la tecnología de agente tienen un marcado impacto. No obstante estas deficiencias, se considera relevante el hecho de que plantea una nueva forma de modelar sistemas complejos. Estos son vistos como si se tratara de una organización de seres humanos que interactúan entre ello para cumplir determinado objetivos globales. Actualmente la metodología Gaia se está enriqueciendo, debido a que están incorporando modelos para representar de manera explícita las estructuras organizacionales que siguen los sistemas multiagentes y ha prestado mucho interés al estudio de la forma de reusar las experiencias de las ciencias de la administración para descubrir patrones interesantes para el diseño de sistemas de agentes.
-15-
5. Conclusiones En este trabajo se ha hecho una revisión comentada de algunos ejemplos de metodologías existentes en el paradigma de los agentes inteligentes. A partir de este simple muestreo de tres de las más conocidas, se puede observar la casi total ausencia de uniformidad en la manera de nombrar los conceptos del paradigma, en los pasos a utilizar para el desarrollo de los sistemas, etc. Esto demuestra que aún es lejano el momento en que los agentes alcancen el nivel de estandarización que hoy exhibe el paradigma orientado a objetos que pueda llevar a esta tecnología a una fase industrial de desarrollo de software. Sin embargo, se puede vislumbrar un camino en este sentido, que puede ejemplificarse en los intentos recientes de OMG en este tema. AUML es un ejemplo de lo que ya se viene logrando. 6. Bibliografía 1. 2. 3.
4. 5. 6.
7. 8. 9.
10.
11.
12.
13.
14. 15.
JULIÁN V., B.V., AGENTES INTELIGENTES: EL SIGUIENTE PASO EN LA INTELIGENCIA ARTIFICIAL. REVISTA NOVATICA, 2000. -, UML SUMMARY VERSION 1.0.1. 1997, RATIONAL SOFTWARE CORPORATION. BERHARD BAUER , J.P.M., JAMES ODELL, AGENT UML: A FORMALISM FOR SPECIFYING MULTIAGENT INTERACTION. AGENT-ORIENTED SOFTWARE ENGINEERING, 2001(SPRINGERVERLAG, BERLIN): P. 91-103. PEÑA J., C.R., TORO M., REPRESENTING COMPLEX MULTI-AGENT ORGANIZATIONS IN UML. 2001. JULIÁN V., B.V.J., ESTUDIO DE MÉTODOS DE DESARROLLO DE SISTEMAS MULTIAGENTE. REVISTA IBEROAMERICANA DE INTELIGENCIA ARTIFICIAL, 2003. 18: P. 65-80. SALVADOR, J., ELABORACIÓN DE UNA APROXIMACIÓN METODOLÓGICA PARA EL DESARROLLO DE SOFTWARE ORIENTADO A SISTEMAS MULTIAGENTE, T.D. INVESTIGACIÓN, EDITOR. 2003, FACULTAD DE INFORMÁTICA DE LA UNIVERSIDAD POLITÉCNICA DE MADRID. CHELLA A., C.M.S.L.Y.S.V., FROM PASSI TO AGILE PASSI: TAILORING A DESIGN PROCESS TO MEET NEW NEEDS. EVANS, R. MESSAGE: METHODOLOGY FOR ENGINEERING SYSTEMS OF SOFTWARE AGENTS. IN EURESCOM PARTICIPANTS IN P907. 2000. CAIRE G., C.W., GARIJO F., GOMEZ J., PAVON J., LEAL F., CHAINHO P., KEARNEY P, STARK J., EVANS R., MASSONET P, AGENT ORIENTED ANALYSIS USING MESSAGE/UML. AGENT-ORIENTED SOFTWARE ENGINEERING, 2001(SPRINGER-VERLAG). WOOLDRIDGE M., N.J., D. KINNY, THE GAIA METHODOLOGY FOR AGENT-ORIENTED ANALYSIS AND DESIGN. INTERNATIONAL JOURNAL OF AUTONOMOUS AGENTS AND MULTI-AGENT SYSTEMS, 2000. ZAMBONELLI F., J.N.Y.W.M., DEVELOPING MULTIAGENT SYSTEM: THE GAIA METHODOLOGY. ACM TRANSACTIONS ON SOFTWARE ENGINEERING AND METHODOLOGY., 2003. 12(3): P. 317370. WOOD M., D.S. AN OVERVIEW OF THE MULTIAGENT SYSTEMS ENGINEERING METHODOLOGY. IN FIRST INTERNATIONAL WORKSHOP ON AGENT-ORIENTED SOFTWARE ENGINEERING. 2001: SPRINGER VERLAG, BERLIN. BRESCIANI P., P.A., GIORGINI P., GIUNCHIGLIA F., MYLOPOULOS J., TROPOS: AN AGENTORIENTED SOFTWARE DEVELOPMENT METHODOLOGY. 2004, NETHERLANDS: KLUWER ACADEMIC PUBLISHER. QI YAN, L.-J.S., XIN-JUN MAO, ZHI-CHANG QI, ROMAS: A ROLE-BASED MODELING METHOD FOR MULTI-AGENT SYSTEM. 2002. GÓMEZ, J., METODOLOGÍAS PARA EL DESARROLLO DE SISTEMAS MULTI-AGENTE. REVISTA IBEROAMERICANA DE INTELIGENCIA ARTIFICIAL, 2003. 18: P. 51-63.
-16-
16.
JENNINGS, N.R., ON AGENT-BASED SOFTWARE ENGINEERING. ARTIFICIAL INTELIGENCE, 2000. 117: P. 277-296.
-17-