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, MAS-
CommonKADS, 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 sub-
objetivos 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. JULIÁN V., B.V., AGENTES INTELIGENTES: EL SIGUIENTE PASO EN LA INTELIGENCIA ARTIFICIAL.
REVISTA NOVATICA, 2000.
2. -, UML SUMMARY VERSION 1.0.1. 1997, RATIONAL SOFTWARE CORPORATION.
3. BERHARD BAUER , J.P.M., JAMES ODELL, AGENT UML: A FORMALISM FOR SPECIFYING
MULTIAGENT INTERACTION. AGENT-ORIENTED SOFTWARE ENGINEERING, 2001(SPRINGER-
VERLAG, BERLIN): P. 91-103.
4. PEÑA J., C.R., TORO M., REPRESENTING COMPLEX MULTI-AGENT ORGANIZATIONS IN UML. 2001.
5. 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.
6. 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.
7. CHELLA A., C.M.S.L.Y.S.V., FROM PASSI TO AGILE PASSI: TAILORING A DESIGN PROCESS TO
MEET NEW NEEDS.
8. EVANS, R. MESSAGE: METHODOLOGY FOR ENGINEERING SYSTEMS OF SOFTWARE AGENTS. IN
EURESCOM PARTICIPANTS IN P907. 2000.
9. 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).
10. 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.
11. ZAMBONELLI F., J.N.Y.W.M., DEVELOPING MULTIAGENT SYSTEM: THE GAIA METHODOLOGY.
ACM TRANSACTIONS ON SOFTWARE ENGINEERING AND METHODOLOGY., 2003. 12(3): P. 317-
370.
12. 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.
13. BRESCIANI P., P.A., GIORGINI P., GIUNCHIGLIA F., MYLOPOULOS J., TROPOS: AN AGENT-
ORIENTED SOFTWARE DEVELOPMENT METHODOLOGY. 2004, NETHERLANDS: KLUWER
ACADEMIC PUBLISHER.
14. QI YAN, L.-J.S., XIN-JUN MAO, ZHI-CHANG QI, ROMAS: A ROLE-BASED MODELING METHOD FOR
MULTI-AGENT SYSTEM. 2002.
15. 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-