Parámetros de Evaluación de Metodologías

Análisis de Metodologías de Diseño de Software
orientado a agentes
Introducción
Para obtener un punto de partida a utilizar en la formulación de nuestra Metodología de
Desarrollo de Software Orientado a Agentes, es necesario partir del análisis realizado a
trabajos realizados previamente. El estudio que se pretende mostrar en el desarrollo de
este documento, se hizo tomando como base algunos de los trabajos que se han
desarrollado en diferentes partes del mundo y que escogimos dada su conveniencia.
En un comienzo, se planeó que el método a seguir sería realizar un análisis
comparativo y detallado de las metodologías seleccionadas, aplicando parámetros de
evaluación establecidos previamente. De esta manera, se debían estudiar ventajas y
desventajas de cada una frente a las demás seleccionadas, e identificar los puntos
fuertes que poseen, para poder así llegar a una metodología que compilara los
resultados más favorables y, en lo posible, fuera un complemento a las otras
metodologías estudiadas.
Durante el proceso de llevar a cabo dicha tarea, nos dimos cuenta que otro método de
trabajo posible sería examinar cada metodología para hallar los criterios que deberían
seguirse en la elaboración de un sistema orientado a agentes. Luego, partiendo de
dicho examen, llegar a un consenso en el que se encuentren enumerados los aspectos
definitivos que contendrá la metodología que se va a elaborar. Se debe dar un
complemento a los mismos, mediante la adición de los puntos que se consideren
faltaron en las metodologías tratadas, y cuya utilización es importante para la
elaboración del sistema.
Para tomar una decisión definitiva acerca de cual de los dos métodos anteriores se va a
utilizar, es necesario que se realice una comparación en la que se evalúen los puntos
positivos y negativos de los dos, de manera que se encuentre cual es el más
conveniente.
Un aspecto positivo del primer método, es el permitir hacer un análisis profundo acerca
de cada una de las metodologías, en el cual se puede evaluar si el proceso que se
plantea en las mismas es bueno o malo. La calificación impuesta, se da teniendo en
cuenta si el resultado obtenido es eficiente o no, respecto a que permita a un
desarrollador hacer el análisis, diseño e implementación de un software, que ante todo
conserve las características que dan su fundamento a un sistema compuesto por
agentes.
Como punto negativo anotamos que establecer criterios de evaluación para las
metodologías, podría ser un proceso en parte largo y difícil, dado que estos deben ser
inferidos a partir del estado del arte que se tiene hasta el momento acerca de SMA y
metodologías de desarrollo orientadas a agentes, y lo que se busca es encontrar
criterios eficientes y exactos sobre los cuales, poder ejecutar una evaluación como la
descrita anteriormente. Vemos que la realización de ese trabajo es en cierta forma
equivalente al proceso que se piensa seguir con el segundo método. El resultado final
obtenido a partir de este último, son los pasos que pensamos deberían ser el
fundamento de nuestra metodología; al ser comparados con el resultado final del
primero, estos bien podrían ser tomados como criterios a seguir para ver si una
metodología evaluada es buena o mala, pensando en el objetivo de crear un sistema
orientado a agentes que cumpla con las características propias de un SMA eficaz.
Teniendo en cuenta que los resultados derivados de ambos métodos se encuentran
relacionados entre sí, es preferible optar por la alternativa ofrecida en el segundo. Así,
se estaría aprovechando la flexibilidad que lo caracteriza, más la posibilidad de alcanzar
de una manera más rápida y directa el objetivo central que se tiene planteado para esta
etapa de trabajo del proyecto de investigación. De la misma manera, se evitaría
desviarse por un camino más largo que aunque ofrece un tipo de análisis diferente,
toma mayor tiempo en permitirnos obtener la base para dar cimientos a nuestra
metodología.
El proceso que se sigue en el segundo método de trabajo es más flexible, en cuanto a
que el mismo tiempo que se va a emplear para hallar parámetros y evaluar
metodologías, como se propuso en el primero, lo utilizaremos para hacer un estudio de
las mismas a partir del cual obtendremos los pasos que serán punto de partida de la
nuestra. Durante este tiempo, el estudio realizado permitirá hacer una comparación de
la forma en la que cada una propone que se deben realizar los diferentes pasos a seguir
para el desarrollo del sistema, y cual de estas vías es la más conveniente. También, de
lo que proponen unas y no proponen otras, y que por lo tanto puede ser un punto de
partida para complementarse entre sí, o para hallar incompatibilidades que den paso a
pensar porque es más provechoso proceder tomando determinados camino. Por último
de lo que vemos que falta, y que podríamos complementar a partir de la información ya
recopilada en el estado del arte realizado en la etapa anterior.
Concluimos que el segundo método de trabajo es el más útil, dado que al seguirlo se
obtendrían de manera más rápida los patrones a incluir como necesarios en la nueva
metodología de desarrollo de software. Además, como vimos, nos brinda las mismas
posibilidades de explorar a fondo las metodologías que se escogieron para el estudio.
Así, damos una justificación a la opción tomada para trabajar en esta etapa del
proyecto, en donde hacemos un cambio a la propuesta original planteada al finalizar la
elaboración del anteproyecto que originó esta investigación.
A continuación se expone la manera en la cual se llevó a cabo el estudio propuesto por
el método escogido. Primero, se hace una breve reseña de los pasos seguidos por cada
una de las metodologías elegidas; segundo, se llega a una unión en la que se
encuentran condensados los puntos clave a tener en cuenta desde la perspectiva de
cada una, y en donde son separados según un orden que se vislumbra como el más
eficaz para seguir en la elaboración del sistema orientado a agentes; tercero, se hallan
los puntos comunes en todas, que serán el resultado a tomar como base para la
formulación de nuestra metodología. Durante este proceso, se analizarán además las
analogías, incompatibilidades y vacíos que se puedan encontrar en las metodologías,
para hacer un planteamiento temprano de lo que será nuestra propuesta.
Estudio de las metodologías seleccionadas
En esta sección, se muestran brevemente algunas de las metodologías existentes para
el desarrollo de SMA y resolución de problemas mediante el uso del paradigma
Orientado a Agentes.
Sycara
Cuando se plantea una metodología esta debe pasar o responder a los retos de
desarrollo propuestos por Sycara [SYC98]:
1. Como ingeniar SMA prácticos.
2. Cómo descomponer problemas y distribuir tareas entre los agentes.
3. Cómo coordinar el control de los agentes y la comunicación.
4. Cómo hacer que varios agentes actúen de manera coherente.
5. Cómo hacer que cada agente razone acerca de los otros agentes y su estado de
coordinación.
6. Cómo reconciliar los conflictos que puedan existir con respecto a los objetivos de
los agentes.
Boer [falta bibliografia]
Propone una metodología en la cual se deben construir 5 modelos: modelo de
agente/rol, modelos de habilidades, modelos de conocimientos, modelo de la
organización y modelos de interacción. Cada uno de los pasos de la metodología
corresponde a la construcción de uno o más de los modelos. Esta metodología puede
expresarse en 5 pasos:
1. El primer paso consiste en la identificación de los roles en la aplicación en
términos de metas o tareas. Un rol se caracteriza por las responsabilidades o
tareas que requiere el sistema. Los roles son la base para la especificación de
los tipos de agentes, análogo al manejo de clases en un enfoque OO. Se
requiere el manejo de los conceptos de OO pero con un enfoque OA.
2. Luego se identifican las habilidades principales asociadas a cada rol. Las
habilidades son responsabilidades y servicios requeridos para poder
desempeñar un rol. Hay que darle importancia al manejo de componentes que
no sean agentes y al diseño de las interfaces con estos componentes.
3. El tercer paso consiste en modelar el conocimiento que se tiene del ambiente
relacionado con los roles identificados o habilidades.
4. Se diseña la estructura organizacional (arquitectura) del SMA. Se analiza la
coordinación que debe existir entre los agentes para poder realizar sus tareas y
los esquemas de comunicación que se estén utilizando. Las estructuras de
grupos se deben identificar. Los grupos permiten tratar a un conjunto de agentes
como una entidad individual. En este paso que diseñan las estructuras genéricas
de los grupos, los esquemas de comunicación y la infraestructura del SMA.
5. Finalmente, se analiza la dinámica del sistema en términos del flujo de
información que se presentan. En éste paso se modelan las dependencias entre
los roles y los agentes. Un tema de investigación en este paso es el flujo de
información de los diferentes roles con relación a la(s) arquitectura(s) del
sistema de agentes.
Tropos [falta bibliografía]
Tropos está basado en dos ideas principales:

Noción de agente y sus estados mentales relacionados, para ser usados durante
todo el proceso de desarrollo de software.

Cubre la etapa de análisis de requerimientos para tener un conocimiento del
ambiente en el cual se va a desempeñar el sistema, y de las interacciones que
deben ocurrir entre los agentes. Es crucial tener en cuenta realizar el
modelamiento de casos de uso y un buen diseño.
Se tienen cinco fases a seguir en la metodología:
1. Análisis temprano de requerimientos: Entendimiento del problema. Se obtiene un
modelo organizacional en el cual se incluyen los actores relevantes y sus
dependencias. Cada actor tiene sus objetivos que serán logrados en conjunto en
virtud de conocimientos y dependencias reciprocas, por medio de las cuales se
distribuirán tareas y se hará una utilización correcta de los recursos.
En esta etapa el análisis de los objetivos de los usuarios del futuro sistema
conduce a obtener los requerimientos funcionales y no funcionales. Se obtienen
dos clases de diagramas; los diagramas de actores (agente, rol, posición) que
muestran una red de dependencias sociales de manera general, y los diagramas
de racionalidad, en los cuales se hace un análisis de los objetivos
(descomposición en sub-objetivos) que se establecieron para cada uno de los
actores del diagrama anterior. Por medio de este análisis se pueden añadir más
actores y dependencias.
2. Análisis de requerimientos tardíos: El sistema que se quiere obtener es descrito
en su ambiente operacional con sus funciones y cualidades. Sistema es un
conjunto pequeño de actores con dependencias sociales. En el análisis realizado
se puede hacer una descomposición en sub - actores y sub – objetivos. Se logra
mostrar un análisis de casos de uso, ya que en el diagrama de racionalidad se
muestra la manera en la que el objetivo de un actor puede ser cumplido por
medio del sistema.
3. Diseño arquitectural: Arquitectura definida en términos de subsistemas (actores),
interconectados a través de datos y flujos de control (dependencias). Se definen
las capacidades de los agentes y los tipos de agentes (donde los agentes son
una clase especial de actores). Se termina con la especificación de los agentes
del sistema. Lo anterior se logra por medio del análisis detallado del diagrama
extendido de actores.
4. Diseño detallado: Cada agente de la arquitectura es definido en términos de
eventos internos y externos, planes, creencias y protocolos de comunicación. La
especificación de las capacidades es importante para modelar los eventos
internos y externos que motivan los planes y creencias envueltas en el
razonamiento de los agentes. Para este diseño, se pueden adaptar algunos
diagramas propuestos para diseñar agentes y SMA, entre los cuales se tienen
algunos de los propuestos por AUML: Diagramas de Capacidad, Diagramas de
planes, Diagramas de Interacción de Agentes.
5. Implementación: Implementación del sistema con un lenguaje especializado para
agentes, en donde se tenga coherencia con el diseño detallado.
Multiagent Systems Engineering (MaSE)
El diseño de SMA requiere manejar problemas de distribución y concurrencia, además
de los que surgen de la necesidad de requerimientos flexibles e interacciones
sofisticadas [WOO01].
La metodología se enfoca en la construcción de un SMA por medio de un ciclo de vida
de desarrollo de software completo, que va desde la descripción del problema hasta la
implementación. Tiene algunas limitaciones. Primero, que el sistema es cerrado y que
todas las interfaces externas están encapsuladas por un agente que participa en los
protocolos de comunicación del sistema. Segundo, no se consideran sistemas
dinámicos en los que los agentes pueden ser creados, destruidos o movidos durante la
ejecución. Tercero, se supone que las conversaciones entre agentes son uno a uno,
opuesto a multicast. Cuarto, se asume que el sistema diseñado tendrá por mucho 10 o
menos clases agente. De todas maneras se podrían realizar extensiones para estas
restricciones bajo las condiciones adecuadas.
La metodología se basa en varios enfoques de agentes. Es independiente de
arquitecturas de agentes y SMA, de un lenguaje de programación o de un sistema de
paso de mensajes. El sistema puede ser implementado de varias formas a partir del
diseño. La metodología es iterativa a través de todas las fases, las cuales son
nombradas a continuación:
Figura 1. Vista general de la metodología.
1. Capturar Objetivos
En esta etapa se toma la especificación del sistema y se produce un Diagrama de
Jerarquía de Objetivos. Se tienen varios objetivos de nivel del sistema, lo cual quiere
decir que los de más bajo nivel heredan, pero cada uno siempre tiene un contexto
correspondiente al nivel al que pertenece. Se realizan dos pasos: Identificar y
estructurar los objetivos. Se identifican descomponiendo el conjunto de requerimientos
bien establecido. Se analizan y estructuran para poder ser utilizados. Son organizados
por importancia en el diagrama, donde se distinguen los detalles de interacción (en el
mismo nivel) y subordinación (entre niveles) entre sí.
Figura 2. Diagrama de Jerarquía de objetivos.
2. Aplicar casos de uso
En esta etapa se elaboran casos de uso para modelar conversaciones entre los
agentes. Los casos de uso se obtienen de los requerimientos y son estructurados en un
Diagrama de Secuencia. Allí se ven los mensajes entre los diferentes roles de agentes,
los cuales son pasados por medio de los caminos de comunicación establecidos entre
ellos. De esta manera se representa el comportamiento deseado del sistema.
Típicamente, se crea al menos una secuencia de un caso de uso. Si existen muchos
escenarios posibles, se crean múltiples diagramas de secuencia.
3. Refinar roles.
Se transforma cada uno de los objetivos de la jerarquía creada en roles. Estos roles son
los que se utilizan durante la etapa de diseño para definir cuales son las clases de
agentes que deben existir.
De manera general cada rol se encarga de mapear uno de los objetivos del sistema,
pero en ocasiones los roles similares o relacionados se pueden combinar en uno sólo
por eficiencia. Algunos objetivos implican roles distribuidos, como en el caso en que se
hable de máquinas distribuidas, o interfaces con objetos externos al sistema y de
usuario. Las definiciones de los roles son capturadas en un Modelo de Roles, en donde
se puede introducir información acerca de las interacciones entre las tareas de los roles
cuando estas sean definidas, y además se pueden listar los objetivos asociados con
cada rol. El modelo muestra los caminos de comunicación entre los roles, derivados del
diagrama de secuencia de la etapa anterior, y entre las tareas cuando estas son
definidas aquí. Por medio de las líneas de comunicación se pueden representar
protocolos internos y externos. Los roles no deben compartir o duplicar tareas.
Una tarea es un conjunto estructurado de comunicaciones y actividades, que puede ser
representado por medio de un diagrama de estado.
4. Crear clases de agente.
Las clases son identificadas a partir de los roles. Se produce un Diagrama de Clases de
Agentes, en donde se muestran los roles asociados a cada clase, y las conversaciones
que existen entre las mismas, aclarando quienes las inician y quienes responden.
Hay un mapeo uno a uno entre los roles y las clases. Se pueden combinar múltiples
roles en una sola clase, o se puede mapear un rol a múltiples clases de agentes.
Además cualquier camino de comunicación entre dos roles se convierte en una
conversación entre clases. Es deseable además combinar roles que compartan un alto
volumen de tráfico de mensajes.
5. Construir conversaciones.
Es beneficial alternar esta fase con la de ensamblar agentes. Una conversación es un
protocolo de coordinación entre dos agentes. Consiste de dos diagramas de clases de
comunicaciones, uno para el iniciador y otro para el que responde, los cuales son
maquinas de estados finitos que definen los estados de conversación de las dos clases
de agente participantes.
El agente iniciador envía un mensaje, que es verificado por el que recibe para ver en
que clase de conversación debe participar según el mismo, y cuando la encuentra hace
una transición hacia el estado correspondiente a dicha conversación. El agente debe
ejecutar ciertas actividades, que corresponden tanto a la transición como al nuevo
estado en el que se encontrará. Estas actividades son los métodos de las clases de
agente. Es difícil construir el autómata de estados finitos que define la operación y
protocolo de conversación. Estos deben ser consistentes con los diagramas de
secuencia elaborados antes. Además deben incorporar los estados de las tareas. Así,
las conversaciones se construyen añadiendo todos los estados y transiciones que
pueden ser derivados de los Diagramas de secuencia y de las tareas.
6. Ensamblar las clases de agente.
Se crea la estructura interna de las clases de agente. Para ello se definen cinco
plantillas arquitecturales diferentes: BDI, reactivo, planeador, basado en conocimiento, y
arquitectura definida por el usuario [ROB00]. Cada una tiene un conjunto específico de
componentes. Dichos componentes, pueden ser unidos mediante conectores internos o
externos de los agentes. Los conectores internos definen la visibilidad entre los
componentes, mientras que los externos definen las conexiones con recursos externos.
El comportamiento interno de los componentes puede ser representado por definición
de operaciones formales o por diagramas de estado que representen los eventos
existentes entre los componentes.
7. Diseño del sistema
Se instancian las clases en agentes reales. Se usa un Diagrama de Despliegue para
mostrar los números, tipos y ubicaciones de los agentes dentro del sistema. Se
representan los agentes, las conversaciones entre ellos, se nombran los agentes
después de la clase de agente a la que pertenecen, y además se indica si los agentes
están ubicados en la misma plataforma física.
El sistema debe ser representado en el Diagrama de Despliegue antes de ser
implementado, debido a las diferencias entre los agentes y las clases de agente. Un
agente necesita conocer el nombre de un host para poder participar en el SMA. Además
el diseñador podría distribuir a los agentes sobre diferentes configuraciones de
máquinas, para tomar provecho del ancho de banda de la red.
Gaia: Metodología para Análisis y Diseño Orientado a Agentes
Esta es una metodología expuesta por Michael Wooldridge, Nicholas Jennings y David
Kinny.
La metodología Gaia tiene en cuenta el diseño tanto a nivel macro (sociedades) como a
nivel micro (el agente individual) [WOO00].
Esta metodología maneja las fase de levantamiento de requerimientos seguida por un
análisis y un diseño detallados que llevan a una implementación.
Los conceptos en Gaia se dividen en dos categorías: los concretos y los abstractos. Los
abstractos son usados en el análisis para conceptualizar el sistema. Los concretos son
usados en el diseño y tienen una relación directa con el sistema en ejecución.
El análisis y diseño se entienden como un proceso incremental en el cual se desarrollan
modelos detallados del sistema que se desea construir.
Fase de Análisis
En la fase de análisis se conoce el sistema y su estructura por medio de un
entendimiento de la organización.
Los roles juegan un papel muy importante en esta metodología. A los roles se les
asignan responsabilidades, permisos, actividades y protocolos. Además, interactúan
entre si de ciertas formas preestablecidas que se encuentran definidas en los protocolos
de los respectivos roles.
1. Identificar los roles del sistema. Los Roles en un sistema corresponden a:

Individuos. Dentro de una organización o actuando independientemente

Departamentos. Dentro de una organización

Organizaciones
El resultado de esta etapa es un prototipo de modelo de roles. Esto es una lista
de los roles que se presentan en el sistema, cada uno con una descripción
informal y no tan elaborada.
2. Para cada rol se deben identificar y documentar los protocolos asociados. Los
protocolos son patrones de interacción que ocurren en el sistema entre los
diferentes roles. Un ejemplo de protocolo es el existente entre un Comprador y
un Vendedor en una subasta. El resultado de esta etapa es un modelo de
interacciones, en el cual se capturan los patrones recurrentes de interacción
entre los roles.
3. Partiendo del modelo de protocolos, se elabora un modelo de roles. El resultado
de esta etapa es un modelo de roles elaborado en el cual se documentan los
roles principales que se presentan en el sistema, sus permisos y
responsabilidades, junto con las actividades y protocolos en los que participan.
4. Iterar etapas (1) – (3).
Fase de Diseño
1. Crear un modelo de agentes.

Relacionar los roles con tipos de agentes y refinarlos formando jerarquías
de tipos de agentes.

Documentar las instancias de cada tipo de agente.
El propósito de un modelo de agentes es documentar los diferentes tipos de
agentes que serán usados en el desarrollo del sistema así como las instancias
de estos en tiempo de ejecución. Un modelo de agentes en esta metodología se
define por medio de un árbol en el cual las hojas corresponden a roles y los
demás nodos son los tipos de agentes.
2. Desarrollar un modelo de servicios examinando las actividades, protocolos y
características de los roles.
El propósito del modelo de servicios es identificar los servicios asociados a cada
rol y especificar las características principales de estos servicios. Por servicio se
entiende una función de un agente. Así como un método en un objeto pero otros
agentes no tienen acceso a todas las funciones por que algunas son para uso
interno del agente.
3. A partir de los modelos de interacción y de agentes, desarrollar un modelo de
acquaintance. En este modelo se definen los vínculos de comunicación que
existen entre los tipos de agentes. Estos no se refieren a los mensajes ni tipos
de mensajes que se manejan, solo indican los caminos existentes. Se
representan por medio de un grafo en el cual los nodos son los tipos de agentes
y los arcos los caminos existentes.
Diseño de Sistemas Orientados a Agentes Analizando las
Interacciones entre los agentes
Esta metodología se basa en el análisis de las interacciones entre los agentes, las
cuales conforman la parte más importante del análisis y diseño. De esta manera, los
requerimientos del sistema se descomponen en interacciones basadas en el
intercambio de objetivos [MIL00].
Los roles juegan un papel importante. Estos representan los aspectos sociales del
sistema, permitiendo describir un SMA como una organización.
Para estudiar el comportamiento de un grupo de agentes se maneja una coordinación
de medios en las sociedades de agentes o reglas organizacionales al sistema. Otro
enfoque es el análisis de las interacciones de los agentes. Este se basa en usar las
interacciones de los agentes como componente principal de análisis. Los requerimientos
son expresados en términos de interacciones del sistema más que como roles.
El análisis de requerimientos debe indicar por lo menos los principales objetivos del
sistema, los contextos en que pueden darse y las preferencias que tienen.
Análisis de Interacciones de Agentes

Se asume que el sistema contiene un número arbitrario de agentes flexibles.

Se interpretan los requerimientos del sistema como objetivos y preferencias para
ser logrados.

Se descomponen los objetivos del sistema en jerarquías de objetivos
independientes, las cuales pueden compararse con planes jerárquicos, y
acciones que llevan a cabo los objetivos del nivel más bajo.

Se le asigna a uno o más agentes la función de lograr un objetivo. Esto se ve
como una interacción.

Partiendo de los requerimientos particulares de cada interacción y las
preferencias del sistema, se derivan las formas de arquitectura y mecanismos de
coordinación particulares para que los agentes que forman parte de la
interacción se comporten de modo que las preferencias se ajusten.
Requerimientos: Los requerimientos deben ser analizados para extraer la estructura
del SMA que debe implementarlos.
Objetivos: Los objetivos describen estados del sistema.
Preferencias: Estas denotan un concepto que incluye ciertas condiciones relacionadas
con otra información importante en los requerimientos aparte de los objetivos. (ej.
Calidad de objetivos)
Interacciones: Acuerdos de coordinación entre agentes.
Agentes: Agentes o roles que pueden tomar los agentes. Estos son derivados de otras
entidades y luego implementados.
Hacia la construcción de una Metodología para Agentes de
Software
Xiaocong Fang del centro Turku de Computer Science en Finlandia desarrolló una
metodología OA. Esta tiene varias fases [FAN00]:
Fase de análisis:
1. Identificar los objetivos
2. Identificar los roles. Los roles son los realizadores de tareas. Existen dos tipos
de roles: los dependientes del dominio y los independientes. Los independientes
tales como control de concurrencia y manejo de información pueden ser
reutilizados. Los roles dependientes del dominio son más difíciles de identificar.
Es por esto que se recomienda el uso de diagramas de casos de uso para
obtenerlos.
3. Identificar los agentes. Los agentes son portadores de roles. En esta etapa se
determina qué agentes debe tener el sistema y que roles debe tener cada
agente.
4. Identificar los componentes. Se determinan los componentes para cada rol.
5. Identificar las interacciones. Se identifican las interacciones entre los
componentes de un rol, los roles de un agente, las clases de agentes y las
diferentes instancias de una clase de agente. Estas se deben especificar en
términos de dependencia.
6. Hacer un ‘agent class framming´ es decir se obtiene el framework para cada
clase de agente.
7. Jerarquizar las clases de agentes, es decir la generalización, asociación,
agregación y composición de las clases de agentes.
Fase de diseño:
En esta fase se definen las estructuras de los componentes, agentes y roles
identificados.
1. Para cada componente, especificar, por medio de algún lenguaje de
especificación, cada procedimiento primitivo dando las pre y post condiciones,
así como los posibles efectos secundarios.
2. Para cada rol, diseñar y definir diagramas de jerarquía de tareas para cada tarea
compleja.
3. Diseñar la estructura mental jerárquica para la estructura mental de las clases de
agentes. Diseñar las reglas y los algoritmos de manejo de tiempo.
También se deben tener en cuenta las relaciones entre los agentes en esta fase para
poder llegar satisfactoriamente a la implementación.
En esta fase se deben construir 4 modelos: interacciones entre agentes, entre roles, y
entre componentes. Y el cuarto se refiere a las interacciones ente las instancias de una
misma clase de agente. Estos se pueden representar por medio de diagramas de
secuencia. A estos se les hace una extensión y es que se manejan mas de un hilo.
Cada rol representa un hilo.
Se estudia la jerarquización, generalización y reutilización de agentes, como en POO.
Hay tres niveles de reutilización: a nivel de componentes (donde los procedimientos
primitivos son reutilizados por diferentes componentes), a nivel de rol (un componente
puede ser reutilizado por varios roles) y a nivel de agente (la estructuras mentales
pueden ser reutilizadas por otras aplicaciones del mismo dominio, así como algunos
comportamientos pueden ser compartidos por varias clases de agentes).
Organizaciones Multiagentes
Una organización es un arreglo de relaciones entre individuos (agentes) el cual produce
una unidad, o sistema, dotado con cualidades no aprehendidas a nivel de los
componentes individuales [FER99]. La organización crea un enlace entre estos
componentes, que entonces empiezan a ser parte de un todo. Esto asegura un grado
de interdependencia y confiabilidad, que da la posibilidad a la organización de perdurar
por un cierto periodo de tiempo, a pesar de las alteraciones.
Las organizaciones pueden ser analizadas, teniendo en cuenta tres aproximaciones:
análisis funcional, análisis estructural y parámetros de concretización.
Análisis funcional
Por medio de este análisis se describen las funciones que los componentes de la
organización deben realizar, de acuerdo a los diferentes roles que desempeñan. Estas
funciones, se pueden desarrollar en varias dimensiones que corresponden a los
diferentes puntos de vista desde los cuales la organización puede ser estudiada.
Un rol identifica la posición y actividades que un agente desempeña dentro de una
organización para lograr el objetivo de la misma, independientemente de su estructura
interna y de los mecanismos utilizados. Los roles pueden evolucionar de acuerdo a la
dinámica de la organización. Así, un agente tiene asociados un grupo de roles que
caracterizan los diferentes servicios que puede prestar, y determinan su posición con
relación a otros agentes. Los roles están agrupados en sub-organizaciones dentro de la
organización, caracterizados por sus funciones que pueden ser centralizadas o
distribuidas.
Seis de las funciones asociadas a una organización y sus roles asociados son:

Función representacional: comprende las funciones correspondientes a modelar
el ambiente y las otras organizaciones, y la memorización de eventos que
pueden haber afectado a la organización. El rol asociado es el de archivista.

Función organizacional: se relaciona con el manejo de la actividad dentro de una
organización, planeación, localización y seguimiento de tareas, coordinación de
acciones y manejo de obligaciones. Se le pueden asociar en particular los roles
de consumidor, mediador, planeador y coordinador.

Función conativa: se refiere a los recursos, límites y selección de actividades de
las organizaciones. Está dividida en tres subfunciones: la motivacional, que
define como se originan los objetivos, la referente a restricciones, que describe
las inhibiciones en el rango de acciones de la organización, y la de decisión, que
junto con el sistema organizacional se encarga de definir los objetivos a ser
logrados y las tareas a ser realizadas. El rol asociado es el de tomador de
decisiones.

Función de interacción: maneja las actividades de interacción entre la
organización y su ambiente, así como las comunicaciones con otras
organizaciones. Tiene dos subfunciones: la perceptiva, que se encarga de
adquirir datos que vienen de afuera, y la ejecutiva, que se encarga de llevar a
cabo las acciones seleccionadas por el sistema conativo. Los roles asociados
son el de observador, ejecutor y comunicador.

Función productiva u operativa: concierne las actividades primitivas que deben
ser realizadas para resolver un problema o para llevar a cabo una pieza de
trabajo. Depende de la aplicación de la organización. No hay roles
característicos asociados con ésta función.

Función vegetativa (preservativa): maneja la preservación de la estructura y de
los agentes, con la adquisición y mantenimiento de recursos, y las tareas
llevadas a cabo para mantener y reproducir la organización. También tiene que
ver con los arreglos que se tienen que hacer para que la organización perdure.
El estudio de las anteriores funciones puede ser llevado a cabo en varias dimensiones:

Dimensión física (): maneja la implementación, la arquitectura de la
organización y sus recursos personales.

Dimensión social (): concierne al lugar y rol de la organización dentro de una de
más alto nivel. También a su capacidad de responder a las necesidades de la de
más alto nivel (aspecto social).

Dimensión relacional (): concierne a las interacciones, a los intercambios que la
organización puede tener con otras del mismo nivel, y con su comunicación y
coordinación.

Dimensión ambiental (): capacidad para actuar, percibir y razonar en relación
con el mundo que lo rodea. Capacidades de interacción con el mundo.

Dimensión personal (): representa todo lo que tiene que ver con la esencia de
la organización.
Análisis Estructural
El análisis estructural de una organización, se encarga de poner orden a todas las
interacciones posibles entre los agentes aislando las relaciones abstractas de las que
los conectan y la manera en la que estas evolucionan con el tiempo.
Aproximación funcional o de objetos
Se puede tener una variedad de opciones para la identificación de los agentes, cada
una de las cuales guía hacia la creación de un SMA diferente.
La aproximación funcional es considerada la más simple cuando los agentes no están
físicamente situados. Los agentes representan especialistas caracterizados por su
función y rol dentro de la organización.
La aproximación por objetos, como se usa en los SMA, puede ser vista como una
extensión del Análisis Orientado a Objetos, por lo cual los agentes serían vistos como
objetos dotados de autonomía, capaces de razonar acerca de su ambiente y escoger
entre varias alternativas.
Descomposición horizontal y vertical
La aproximación funcional puede ser expresada en dos formas diferentes, dependiendo
si se da una concepción vertical u horizontal de las funciones.
La división vertical asocia con cada función una actividad compleja centrada en una
actividad específica. Por el contrario en la división horizontal se pone énfasis en lo que
se comparte por parte de las funciones verticales. Las descomposiciones que combinan
los dos ejes son los más comúnmente usados para la organización de sistemas
artificiales. La descomposición vertical está ligada con la solución de problemas
específicos, y la horizontal tiende a ser utilizada para los agentes de IA.
Parámetros de concretización
Al realizar el diseño de un SMA se debe decidir como distribuir las tareas de manera
que el trabajo de la organización se realice de manera efectiva. Se pueden tener
agentes especializados en una tarea, o totipotentes, es decir que poseen todas las
habilidades necesarias para llevar a cabo una tarea por si solos. Al contarse con
agentes totipotentes se obtiene un sistema más confiable, dado que la redundancia
hace fácil que al desaparecer un agente otro lo reemplace en las funciones que está
desempeñando.
Se tienen dos parámetros para caracterizar la manera en la que es distribuido en trabajo
en un SMA:

Grado de especialización: de un agente a para un problema P, indica la
calificación en sus habilidades en relación a las habilidades necesarias para
resolver un problema. Si este valor es cero, indica que el agente es totipotente;
si por el contrario es 1 se considera al agente especializado, y entre más
cercano a 1 sea el valor se considerará al agente como más especializado. Se
considera el grado de especialización del SMA, como la media de los grados de
especialización de cada uno de los agentes.

Grado de redundancia: caracteriza el número de agentes que poseen las
mismas habilidades. Si el valor es 0 significa que sólo existe un agente capaz de
llevar a cabo una tarea que requiere una habilidad. Si es 1 significa que todos
los agentes poseen esta habilidad.
Aspectos observados en las metodologías
Para poder empezar a describir una metodología para el análisis y diseño de
aplicaciones Orientadas a Agentes (OA) se debe definir primero si el en foque OA es el
más apropiado. [O’MAL01]
En el Second International Workshop On Agent-Oriented Software Engineering (AOSE2001) que se llevó a cabo en Canada, en Montreal en Mayo de 2001 se llegó a las
siguientes conclusiones sobre la decisión de usar o no el enfoque OA determinando si
es o no apropiado:
1. Un enfoque OA es útil en situaciones en las cuales se requieren tipos de
comunicación complejos o diversos.
2. Un enfoque OA es recomendado cuando el sistema debe desempeñarse bien en
situaciones en las cuales no es posible especificar su comportamiento sobre una
base de casos.
3. Un enfoque OA es útil en situaciones que involucren negociaciones, cooperación
y competencia entre diferentes entidades.
4. Un enfoque OA es recomendado cuando el sistema deba actuar de manera
autónoma.
5. Un enfoque OA es útil cuando se puede prever una expansión o modificación del
sistema o cuando se espera que el propósito del sistema cambie.
A continuación se presenta la reunión de los diferentes aspectos que son tenidos en
cuenta en cada una de las metodologías, agrupados según la serie de pasos que se
consideran necesarios para llevar a cabo el análisis y diseño de un sistema basado en
agentes. De acuerdo a lo ya expuesto anteriormente, se presenta de manera breve, el
aporte que cada una de las metodologías puede dar al paso correspondiente.
Hallar requerimientos
Según Sycara [SYK98] se debe tener la capacidad de descomponer problemas y
distribuir tareas entre los agentes. El primero de estos dos pasos se puede llevar a cabo
al hallar los requerimientos del problema, para lo cual Tropos [falta] propone seguir las
etapas de requerimientos tempranos y la de requerimientos tardíos, que son los dos
primeros pasos a realizar en su metodología. En la etapa de requerimientos tempranos
se identifican los actores y objetivos generales de los mismos dentro del sistema. En la
de requerimientos tardíos se descomponen los objetivos y actores identificados y se
obtienen casos de uso.
De la misma manera se puede tener en cuenta la etapa de captura de objetivos de
MaSE [WOO01], en la que se identifican los objetivos del sistema a partir del conjunto
de requerimientos, y se jerarquizan según su importancia.
En la metodología de análisis de interacciones entre agentes [MIL00], se asume que el
sistema contiene un número arbitrario de agentes flexibles. Aquí se interpretan los
requerimientos del sistema como objetivos y preferencias para ser logrados de manera
que el análisis de requerimientos debe indicar por lo menos los principales objetivos del
sistema, los contextos en que pueden darse y las preferencias que tienen, para que
luego se pueda extraer la estructura del SMA que debe implementarlos. Posteriormente
se descomponen los objetivos del sistema en jerarquías de objetivos independientes,
las cuales pueden compararse con planes jerárquicos, y acciones que llevan a cabo los
objetivos del nivel más bajo.
No todas las metodologías estudiadas proponen una etapa de levantamiento de
requerimientos, pero la forma en la que se propone esta por parte de las aquí
nombradas coincide en el hecho de que se deben plantear los objetivos del sistema
como los requerimientos del mismo. Además estos requerimientos deben ser
jerarquizados para priorizarlos y especificarlos. Por último quedan establecidos cuales
serán los actores del sistema, tanto externos como internos, de manera global.
Concluimos que esta fase de levantamiento de requerimientos es suficiente para dar
inicio al análisis para el desarrollo del sistema. Posteriormente describiremos más a
fondo la manera en la que se debe llevar a cabo, teniendo en cuenta las sugerencias
encontradas en las metodologías estudiadas, y posibles aportes a la misma.
Identificar roles y distribuir tareas
Se debe manejar un mecanismo de distribución de tareas, en el cual se tengan en
cuenta estrategias organizacionales por medio de las cuales los agentes combinen sus
habilidades para realizar trabajos colectivos. De esta manera, el siguiente paso a ser
realizado cuando se han identificado los requerimientos y objetivos del sistema, es el de
identificar los roles que se deben tener para poder cumplir dichos objetivos.
En la metodología propuesta por Boer [falta] el primer paso consiste en identificar los
roles que deben existir en la aplicación, en términos de las metas o tareas que requiere
el sistema. Luego se identifican las habilidades principales asociadas a cada rol, que
son responsabilidades y servicios requeridos para poder desempeñarlo. Hay que darle
importancia al manejo de componentes que no sean agentes y al diseño de las
interfaces con estos componentes.
En MaSE [WOO01], el tercer paso transforma cada uno de los objetivos de la jerarquía
creada durante la primera etapa en roles. Estos roles son los que se utilizan durante la
etapa de diseño para definir cuales son las clases de agentes que deben existir. Las
definiciones de los roles son capturadas en un Modelo de Roles, en donde se puede
introducir información acerca de las interacciones entre las tareas de los roles cuando
estas sean definidas, y además se pueden listar los objetivos asociados con cada rol. El
modelo muestra los caminos de comunicación entre los roles, derivados del diagrama
de secuencia de la etapa dos, y entre las tareas cuando estas son definidas aquí. Por
medio de las líneas de comunicación se pueden representar protocolos internos y
externos. Los roles no deben compartir o duplicar tareas. Una tarea es un conjunto
estructurado de comunicaciones y actividades, que puede ser representado por medio
de un diagrama de estado.
En la metodología Gaia [WOO00], por su parte, se presenta una fase de análisis que se
realiza posteriormente a haber levantado los requerimientos del sistema. En el primer
paso de la misma se identifican los roles del sistema, los cuales corresponden a:
individuos dentro de una organización o actuando independientemente, departamentos
dentro de una organización y a organizaciones. Así, se obtiene una lista de los roles
necesarios con una descripción informal y no tan elaborada. Posteriormente, para cada
rol se deben identificar y documentar los protocolos asociados, los cuales corresponden
a patrones de interacción que ocurren en el sistema entre las diferentes clases de los
mismos identificadas. El resultado de esta etapa es un modelo de interacciones. Por
último, se parte del modelo de protocolos elaborado para producir un modelo de roles
en el cual se documentan los roles principales que se presentan en el sistema, sus
permisos y responsabilidades, junto con las actividades y protocolos en los que
participan.
La metodología de Fang [FAN00] tiene una etapa de análisis en la cual después de
establecer cuales son los objetivos del sistema, se deben identificar los roles, quienes
son los encargados de realizar las tareas respectivas. Existen dos tipos de roles: los
dependientes del dominio y los independientes. Los independientes tales como control
de concurrencia y manejo de información pueden ser reutilizados. Los roles
dependientes del dominio son más difíciles de identificar. Es por esto que se
recomienda el uso de diagramas de casos de uso para obtenerlos.
Por último, se debe tener en cuenta el enfoque dado por Ferber [FER99] al realizar un
análisis funcional de la organización, para establecer los tipos de funciones que son
necesarios con el fin de que el SMA diseñado funcione correctamente. Además un
análisis estructural de la organización, en el cual se asignan las funciones que se
concluyen necesarias según los requerimientos, de acuerdo a una descomposición
vertical u horizontal; como consecuencia de dicha descomposición se podrán identificar
los roles que estarán presentes, las habilidades que poseerán y las tareas que deben
realizar. Como complemento a la manera en la que se establecerán los roles, se debe
analizar si es necesario tener agentes totipotentes, que grado de redundancia utilizar
para tener un sistema confiable, y también, que grado de especialización para lograr
mayor efectividad en la consecución de los objetivos del sistema.
En este paso en el cual se definen los roles, es importante definir el mecanismo de
distribución de tareas entre los agentes. Esto se hace teniendo en cuenta los
mecanismos organizacionales por medio de los cuales los agentes combinan sus
habilidades para realizar trabajos colectivos. Se debe estudiar si existen tareas que
requieran más recursos o conocimientos de los que pueda tener un solo agente y estas
deben ser divididas en sub-tareas para luego distribuirlas entre los agentes del sistema.
Los problemas o tareas que deben llevar a cabo los agentes pueden ser analizados
según nivel de abstracción, teniendo en cuenta el nivel de control, la información
disponible y los recursos con los que se cuenta. Cuando se identifican las tareas, estas
deben ser lo más independiente posible para reducir la coordinación necesaria entre los
agentes que se encargarán de llevarla a cabo.
Según Ferber [FER99], existen varias formas de distribución de tareas. Estas son:


Distribución centralizada

Estructura jerárquica de subordinación: Existe un agente superior que
ordena a un subordinado a hacer la tarea (distribución definida o rígida).

Estructura igualitaria: Existen agentes especiales (comerciantes o
bolsistas) que manejan centralizadamente los requerimientos de clientes
o servidores.
Asignación distribuida: Cada agente trata de obtener los servicios.

Red de conocimientos (acquaintance): Cada agente tiene una
representación de los otros agentes y sus capacidades: No es del todo
necesario que los agentes conozcan las habilidades de todos los otros
agentes, lo importante es que la red debe estar fuertemente conectada
(debe existir un camino entre cualquier par de agentes) y ser coherente
(las habilidades que se muestren en la red, deben corresponder con las
habilidades del agente).

Como subasta: Este método de asignación es más conocido cono red de
contrato (contract net). Este modelo está basado en un protocolo como el
de un mercado de contratos públicos y tiene la ventaja de ser muy
dinámico y fácil de implementar.
Otro aspecto a considerar son los recursos disponibles en el sistema. Estos deben ser
distribuidos entre los roles identificados anteriormente o asignados a estos. Los
recursos son un factor importante un el análisis de un sistema y de las relaciones que
se encuentren entre los roles y los recursos depende la identificación futura de las
interacciones del sistema.
Se concluye que a partir de los requerimientos u objetivos definidos en la fase anterior,
se deben determinar cuales son las tareas que se deben llevar a cabo en el sistema, al
igual que los roles que se encargarán de desempeñarlas. Estos roles parten de los
actores internos que se identificaron, y se son especificados de manera mas concreta.
En esta etapa se deben dejar mapeadas las tareas a los roles. Por último, es importante
tener en cuenta el asignar los recursos que son necesarios para el desempeño de cada
uno de los roles, para que posteriormente puedan ser fácilmente establecidas las
estrategias de coordinación.
Especificar los tipos de agentes
El tercer paso a seguir en el proceso, es identificar los agentes que serán necesarios
para que el sistema funcione. Los agentes se pueden identificar por rol o por
funcionalidad en el sistema.
Según Boer [falta] los roles son la base para la especificación de los tipos de agentes,
este es el siguiente paso que se debe seguir al estar diseñando un sistema basado en
agentes.
Tropos [falta] por otro lado, establece los agentes que se tendrán en el sistema después
de estructurar la arquitectura del sistema. Este procedimiento es nombrado en la etapa
de establecimiento de flujos de información e interacciones.
En el cuarto paso de MaSE [WOO01], las clases de agentes son identificadas a partir
de los roles. Se produce un Diagrama de Clases de Agentes, en donde se muestran los
roles asociados a cada clase, y las conversaciones que existen entre las mismas,
aclarando quienes las inician y quienes responden. Además cualquier camino de
comunicación entre dos roles se convierte en una conversación entre clases. Es
deseable además combinar roles que compartan un alto volumen de tráfico de
mensajes.
En la metodología Gaia [WOO00], después de haber culminado la etapa de análisis, se
debe seguir con la etapa de diseño del sistema. Aquí, el primer paso a seguir es crear
un modelo de agentes en el cual se relacionen los roles con tipos de agentes y luego se
refinen formando jerarquías de tipos de agentes. De esta manera el modelo queda
definido por medio de un árbol en el cual las hojas corresponden a roles y los demás
nodos son los tipos de agentes. Cada uno de los tipos identificados, así como sus
instancias en tiempo de ejecución deben ser documentados. Luego de establecer
cuales son los tipos de agentes necesarios, se debe desarrollar un modelo de servicios
en el cual se examinan las actividades, protocolos y características de los roles. El
propósito de dicho modelo es identificar los servicios asociados a cada rol y especificar
las características principales de estos servicios. Por servicio se entiende una función
de un agente. Vale aclarar que este modelo de servicios, se podría ver más ligado a la
etapa anterior en la que se distribuyeron tareas entre los roles especificados.
En cuanto a la metodología de análisis de interacciones entre agentes [MIL00], después
de tenerse claros los objetivos del sistema, se le asigna a uno o más agentes la función
de lograr un objetivo, lo cual se ve como una interacción.
Por último, en los pasos tres y cuatro de la etapa de análisis de la metodología de Fang
[FAN00], se identifican los agentes del sistema y que roles debe tener cada uno. Luego
se identifican los componentes y se determinan los componentes para cada rol.
Es importante aclarar que al identificar los agentes del sistema y realizar la respectiva
clasificación, se debe tener en cuenta la definición de agente y las características de un
agente. Un agente es un sistema que posee las siguientes características: [MIL00]
[WOO01]

Autonomía: los agentes manejan un estado interno, el cual no puede ser
accedido por otros agentes, y actúan sin intervención directa de humanos u
otros actores.

Toma de decisiones: Los agentes toman decisiones acerca de qué hacer,
basándose en su estado interno, ante las determinadas circunstancias.

Aspecto social: que le permite al agente interactuar con otros por medio de algún
lenguaje de comunicación y típicamente poseen habilidades que les permiten
cooperar con otros, resolver problemas y negociar.

Capacidades reactivas: Los agentes se encuentran en un ambiente y son
capaces de percibirlo para reaccionar a los cambios que en este se presenten.

Pro actividad: Los agentes no solo actúan como respuesta a los cambios en su
ambiente, ellos son capaces de mostrar un comportamiento basado en metas,
tomando la iniciativa.
En esta etapa de la metodología, se puede observar que las metodologías estudiadas
en general proponen mapear los roles identificados a los tipos de agentes que deben
participar en el sistema. Algunas proponen además tener en cuenta de manera general
las interacciones que pueden existir entre los componentes del sistema. Lo anterior, es
importante para determinar cuales serán los atributos y métodos que conformarán las
clases de agentes que se definan.
Para terminar, teniendo la definición clara de un agente, se puede proceder a
determinar si los agentes que se usarán en el sistema deben ser de servicio (siguiendo
el esquema Cliente / Servidor) o racionales (aquellos que realizan una acción
cumpliendo un objetivo sin que necesariamente se le este requiriendo directamente). Un
ejemplo de un agente de software que es mejor racional, a ser sólo de servicios es un
demonio de impresión. Este agente se encuentra revisando constantemente los
cambios que se generen en su ambiente, y como sabe lo que debe hacer lleva a cabo
su tarea sin esperar a que alguien se lo solicite. Así, actúa de manera asincrónica.
Diseñar la arquitectura del SMA
Cuando se diseña un SMA se debe pensar en este como una organización o sociedad
en la cual cada agente tiene una función o rol (puede tener varios roles) que
desempeña en este.
Después de tener establecidos los roles, responsabilidades y tipos de agentes que se
tendrán en el sistema, Boer [falta] dice que se debe diseñar la estructura organizacional
(arquitectura) del SMA. En ella deben estar incluidos los mecanismos de coordinación y
comunicación entre los agentes para lograr sus objetivos. Además se diseñan las
estructuras genéricas de los grupos que conformarán la organización y que son vistas
como entidades individuales.
Establecer flujos de información e interacciones
Boer [falta] en su metodología sugiere como última actividad analizar la dinámica del
sistema en términos del flujo de información que se presenta. En éste paso se modelan
las dependencias entre los roles y los agentes.
Por su parte Tropos [falta] después de haber establecido específicamente cuales son
los objetivos y actores específicos del sistema, define la arquitectura en términos de
subsistemas (actores), interconectados a través de datos y flujos de control
(dependencias). Se definen aquí las capacidades de los agentes y los tipos de agentes
(donde los agentes son una clase especial de actores). Se termina con la especificación
de los agentes del sistema. Lo anterior se logra por medio del análisis detallado del
diagrama extendido de actores obtenido en la etapa de requerimientos tardíos.
En MaSE [WOO01], el segundo paso de la metodología especifica que se deben aplicar
casos de uso para modelar conversaciones entre los agentes, capturándolos de los
requerimientos, y reestructurarlos en un Diagrama de Secuencia. Allí se ven los
mensajes entre los diferentes roles de agentes, los cuales son pasados por medio de
los caminos de comunicación establecidos entre ellos. De esta manera se representa el
comportamiento deseado del sistema.
En Gaia [WOO00], durante la fase de análisis se produce un diagrama de interacciones
que, como ya se dijo antes, es resultado del análisis que se hace de los roles que
existirán en el sistema y de las interacciones que se presentan entre los mismos. Más
adelante en la etapa de diseño, al haber sido elaborados de los modelos de interacción
y de agentes, se desarrolla un modelo de acquaintance. En este modelo se definen los
vínculos de comunicación que existen entre los tipos de agentes. Estos no se refieren a
los mensajes ni tipos de mensajes que se manejan, solo indican los caminos existentes.
Se representan por medio de un grafo en el cual los nodos son los tipos de agentes y
los arcos los caminos existentes.
En la metodología de Fang [FAN00], después de establecer a los agentes que debe
tener el sistema y los componentes de un rol, se identifican las interacciones. Estas se
presentan entre los componentes de un rol, los roles de un agente, las clases de
agentes y las diferentes instancias de una clase de agente. Se deben especificar en
términos de dependencia. Por su parte en la etapa de diseño se deben tener en cuenta
las relaciones entre los agentes para poder llegar satisfactoriamente a la
implementación. En esta fase se deben construir 4 modelos: interacciones entre
agentes, entre roles, y entre componentes. Y el cuarto se refiere a las interacciones
ente las instancias de una misma clase de agente. Estos se pueden representar por
medio de diagramas de secuencia.
Retomando los agentes racionales y se servicio, una vez determinado qué tipo de
agentes se van a utilizar en el sistema, es importante definir el modo de ejecución de
estos. Es decir, si interactuarán de manera sincrónica o asincrónica.
Existen tres tipos de interacciones a considerar: en la primera, un agente solicita un
servicio y asume que este será realizado por el otro agente. En la segunda, el agente el
agente solicita el servicio y espera a que el otro le confirme que lo hará. En la tercera, el
agente después de solicitar el servicio espera hasta que le confirmen que este ya ha
sido llevado a cabo. En los dos últimos casos, las interacciones pueden ser sincrónicas
si el agente detiene sus actividades hasta que le llega la confirmación, o pueden ser
asincrónicas, si el agente continúa con sus actividades pero esta pendiente de que
llegue el mensaje de confirmación.
Cuando ya se han identificado los diferentes tipos de interacciones que existen en el
sistema, se definen los tipos de protocolos que se pueden utilizar para cada uno de los
casos.
Cuando se definen las interacciones, estas deben realizarse teniendo en cuenta que los
agentes son comunicativos y deben tener relaciones de comunicación con otros.
También es importante en el momento de identificar las relaciones tener en cuanta las
razones por las cuales estas existen, ya que esas probablemente sean funcionalidades
del sistema. Otro aspecto que se debe tener en cuenta es la existencia de diagramas
mencionados en las diferentes metodologías para la representación de las
interacciones, estos deben utilizarse para dar mayor claridad al análisis y diseño del
sistema.
Al establecer las interacciones que existirán entre los agentes, se debe determinar que
protocolos de interacción van a utilizar los diferentes tipos de agentes entre si. FIPA ha
establecido un estándar, en el cual se han realizado especificaciones acerca de
diferentes protocolos de interacción, los cuales tomaremos como base para la
consecución de este objetivo.
Protocolos de interacción FIPA:
El conjunto de Protocolos de Interacción FIPA (IPs), se encuentra incluido en su Librería
de Protocolos de Interacción (IPL) [FIPA00025]. Dichos protocolos pueden ser
entendidos y expresados por medio de la utilización de AUML [AUM02], y además
deben cumplir ciertos requerimientos para ser incluidos en la IPL, para asegurar que
existan como un patrón a ser utilizado en varios aspectos de sistemas basados en
agentes, y por diferentes desarrolladores. Por último son registrados en la lista de
registro FIPA IP.
Los protocolos de interacción son patrones de intercambio de mensajes que se
presentan típicamente entre agentes. En FIPA se sugiere una lista de los mismos, no de
todos los existentes, los cuales deben ser adaptados al entorno de la aplicación en la
que se van a utilizar, y con la advertencia de que no manejan aspectos como manejo de
excepciones, llegada de mensajes fuera de secuencia, mensajes desaparecidos,
timeouts, cancelación, etc. Lo anterior quiere decir que al utilizar uno de los IPs
pertenecientes a la IPL, no se está asegurando automáticamente la interoperabilidad, y
que se requiere un acuerdo entre los agentes acerca de los puntos mencionados para
lograrla.
Aunque los agentes pueden estar involucrados en diferentes conversaciones, con
diferentes agentes de manera concurrente y utilizando un protocolo de interacción
distinto para cada una, la especificación de la IPL de FIPA se refiere solo a una
conversación en particular.
Los criterios mínimos que debe cumplir un Protocolo de Interacción para ser incluido en
la IPL son tener una representación clara y precisa usando el diagrama de protocolo de
AUML, proveer una documentación clara y substancial, y prestar una utilidad clara. Para
enterarse mejor acerca del estado de los Protocolos de Interacción acomodables a FIPA
y del mantenimiento que se le da a la IPL, referirse a [FIPA00025].
AUML posee Diagramas de Secuencia para hacer una especificación de los Protocolos
de Interacción, los cuales son referidos como diagramas de protocolos (PDs) por FIPA,
y muestran interacciones bien definidas entre los agentes.
Los Protocolos de Interacción que se encuentran incluidos en la IPL son nombrados
brevemente a continuación:

FIPA Request Interaction Protocol [FIPA00026]: Este protocolo simplemente
permite que un agente le pida a otro que ejecute alguna acción y que el agente
receptor ejecute la acción o responda, de alguna manera, que no puede.

FIPA Query Interaction Protocol [FIPA00027]: En este protocolo al agente
receptor se le pide que realice alguna clase de acción de informar [FIPA00037].
Dicha clase de acción es un query, y existen dos clases de query: query-if y
query-ref [FIPA00037]. Los dos tipos de querys pueden ser usados para dar
inicio a este protocolo, obteniéndose como respuesta una acción de informar,
que en el caso de un query-ref podría ser una expresión de referencia.

FIPA Request When Interaction Protocol [FIPA00028]: Este protocolo provee un
Framework para el acto de comunicación pedir-cuando [FIPA00037]. El agente
iniciador usa la acción pedir –cuando para pedir que el participante realice
alguna acción una vez que una precondición se hace verdadera. Si el agente al
cual se le solicitó la acción, entiende y no se rehúsa inicialmente, estará de
acuerdo [FIPA00037] y esperará hasta que la precondición se haga verdadera.
Luego, intentará ejecutar la acción y notificar al agente iniciador
consecuentemente. Si después del acuerdo inicial el agente participante no es
capaz de realizar más la acción, enviará una acción de rehusarse [FIPA00037] al
iniciador.

FIPA Contract Net Interaction Protocol [FIPA00029]: Este protocolo es una
pequeña modificación al patrón del Contract Net original, en cuando a que añade
actos de comunicación de rechazo y confirmación. En el Contract Net, un agente
asume el rol de administrador quien desea que una tarea sea ejecutada por uno
o más agentes, y además optimizar una función que caracterice la tarea. Esta
característica es expresada comúnmente como el costo, en algún dominio
específico, pero también podría ser el plazo más corto para la conclusión,
distribución equitativa de tareas, etc. El administrador solicita propuestas de los
otros agentes por medio del acto de llamada para propósitos [FIPA00037], en
donde especifica la tarea, y las condiciones que impone para la ejecución de la
tarea. Los agentes que reciben la llamada son contratantes potenciales y
pueden generar actos de propuesta [FIPA00037]. En este acto se incluyen las
precondiciones que el contratante impone para realizar la tarea.
Alternativamente, el contratante puede rehusarse [FIPA00037] a la propuesta.
Una vez que el plazo se vence, el administrador escoge las propuestas y
selecciona a los agentes que ejecutarán la tarea, que pueden ser uno, muchos o
ninguno. A ellos les envía un acto de aceptar-propuesta [FIPA00037], y a los
otros un acto de rechazar-propuesta [FIPA00037]. Las propuestas son ligadas al
contratante, de manera que después de que el administrador las acepta, este se
ve comprometido a ejecutar la tarea. Una vez que acaba de ejecutarla, envía un
mensaje de conclusión al administrador. Con el fin de que el administrador no se
quede esperando indefinidamente las propuestas de los contratantes, se da un
tiempo de espera antes del cual deben llegar las propuestas; las que lleguen
después son automáticamente rechazadas.

FIPA Iterated Contract Net Interaction Protocol [FIPA00030]: Esta es una
extensión del IP Contract Net FIPA básico, pero se diferencia en que se permite
una vinculación iterativa multi-ciclo. Al igual que en el protocolo original, el
administrador hace una llamada para propuestas, y los contratantes luego hacen
sus ofertas como actos de propuesta [FIPA00037]. El administrador acepta
unas, rechaza las otras o simplemente no acepta ninguna e itera el proceso
emitiendo una llamada para propuestas revisada. El objetivo es que el
administrador reciba mejores propuestas por parte de los contratantes, al revisar
y reenviar la llamada. El proceso finaliza cuando el administrador rechaza todas
las propuestas y no emite una nueva llamada, acepta una o mas propuestas, o
todos los contratantes de rehúsan a proponer.

FIPA English Auction Interaction Protocol [FIPA00031]: En este protocolo el
subastador busca encontrar el precio para un bien, proponiendo inicialmente un
valor que está por debajo de el del mercado y luego aumentándolo
gradualmente. Cada vez que el precio es anunciado, el subastador espera a ver
si alguno de los compradores está dispuesto a pagarlo. Tan pronto uno de ellos
anuncia que aceptará el precio, el administrador emite una nueva llamada con
un precio incrementado. La subasta continua hasta que no hay compradores que
estén preparados para pagar el precio. Si el último precio que fue aceptado es
mayor que el precio de reservación del subastador (conocido de manera
privada), el bien es vendido al comprador por el precio que había sido acordado.
Por el contrario, si último precio aceptado es menor que el precio de reservación,
el bien no es vendido.

FIPA Dutch Auction Interaction Protocol [FIPA00032]: En este protocolo el
subastador busca encontrar un precio de mercado para un bien, comenzando
por ofrecerlo a un precio mucho mayor que el esperado, y luego reduciéndolo
hasta que uno de los compradores acepta el precio. El índice de reducción
usualmente es escogido por el subastador, el cual usualmente tiene un precio de
reserva por debajo del que no ofrece. Si la subasta reduce el precio hasta el de
reserva sin compradores, esta se termina.

FIPA Brokering Interaction Protocol [FIPA00033]: Está diseñado para dar
soporte a las interacciones de intermediación de información en SMA. En estas,
un agente intermediario ofrece servicios para facilitar la comunicación a otros
agentes, usando cierto conocimiento acerca de sus requerimientos y
capacidades. Por ejemplo, un agente le pide al intermediario que busque uno o
más agentes que puedan responder a un interrogante determinado; el
intermediario se encarga entonces de determinar un conjunto adecuado de
agentes a los cuales reenviar el interrogante, les envía el mensaje y luego
transmite sus respuestas al agente original. El uso de intermediación puede
reducir el número de tareas de interacción en un SMA, además de hacer al
sistema adaptable, robusto en situaciones dinámicas, y dar soporte a la
escalabilidad y al control de seguridad en el agente intermediario.

FIPA Recruiting Interaction Protocol [FIPA00034]: Este protocolo al igual que el
anterior, da soporte a las interacciones de intermediación de información en un
SMA. Sin embargo, en el caso de reclutamiento, las respuestas de los agentes
seleccionados van directamente al agente original o a algún grupo designado de
receptores.

FIPA Subscribe Interaction Protocol [FIPA00035]: En este protocolo, un agente
pide ser notificado en el momento en que una condición especificada en el
mensaje de suscripción se convierte en verdadera.

FIPA Propose Interaction Protocol [FIPA00036]: En este protocolo, un agente
iniciador plantea a los receptores que él realizará las acciones descritas en el
acto de comunicación propuesto [FIPA00037] cuando ellos acepten esta
propuesta. La conclusión de este Protocolo con un acto aceptar-propuesta
[FIPA00037] podría ser seguido típicamente por la ejecución de la acción
propuesta, y después el retorno de un estatus de respuesta.
En conclusión, al llegar a la etapa de diseño de la arquitectura del sistema se deben
definir los protocolos de interacción. Con respecto a las interacciones se deben
considerar tres aspectos:

Necesidades que se tienen para que estas se den, las cuales pueden ser
inferidas a partir de los flujos de información que se dan entre las clases de
agentes. Al identificar dichas necesidades, las interacciones establecidas de
manera general al hacer el mapeo entre los roles y los agentes, se especificarán
por completo en esta etapa. Lo anterior servirá para determinar las habilidades
de los agentes, con respecto a las interacciones en las que participan, y de la
misma manera permitirá hacer un diseño más detallado de las clases de
agentes.

Protocolos que se utilizarán para manejarlas. Aquí se tendrán en cuenta los
protocolos definidos en el estándar de FIPA.

Diagramas que se emplearán para su representación. Las especificaciones de
los protocolos del estándar FIPA, tienen una representación en AUML la cual
será utilizada.
Establecer mecanismos de
comunicación entre agentes
coordinación
y
protocolos
de
La comunicación es la base de las interacciones entre los agentes. La metodología
debe plantear proponer protocolos de comunicación que se puedan utilizar, es decir
debe tener una parte en que se defina el protocolo que se va a utilizar.
Además, para Sycara [SYK98] es importante establecer cómo hacer que varios agentes
actúen de manera coherente y cómo reconciliar los conflictos que puedan existir con
respecto a los objetivos de los agentes.
En el quinto paso de MaSE [WOO01], se construyen conversaciones entre los agentes.
Una conversación es un protocolo de coordinación entre dos agentes. Consiste de dos
diagramas de clases de comunicaciones, uno para el iniciador y otro para el que
responde, los cuales son maquinas de estados finitos que definen los estados de
conversación de las dos clases de agente participantes. Además los estados en los que
debe quedar el agente dependiendo del tipo de conversación que establece y las
actividades que debe llevar a cabo de acuerdo a la misma.
Por su parte en la metodología de análisis de interacciones [MIL00], partiendo de los
requerimientos particulares de cada interacción y las preferencias del sistema, se
derivan las formas de arquitectura y mecanismos de coordinación particulares para que
los agentes que forman parte de la interacción se comporten de modo que las
preferencias se ajusten.
En las metodologías que se escogieron para este estudio, no se especifican claramente
aspectos claves para las comunicaciones entre los agentes. Estos aspectos son el acto
de lenguaje, el cual consiste en la intención que existe implícita en una comunicación.
Según éste, un mensaje se compone de la intencionalidad (performative) y de la cadena
que lo expresa. Así, detrás de toda comunicación, existe una acción que es la que el
agente emisor desea que se lleve a cabo al enviar un mensaje al receptor. Por medio de
la comunicación, un agente puede generar cambios físicos (registros en una BD), o
cambios en las creencias de otros agentes. Además, los protocolos de comunicación
que se deben utilizar. A continuación se da una definición de conceptos como ACL,
KQML, KIF, ontologías y actos de comunicación.
Agent Comunication Lenguaje (ACL)
Los agentes requieren tener un lenguaje de representación común y compartir una base
de conocimiento para interpretar los mensajes que se intercambian, con el fin de poder
comunicarse e interactuar entre ellos y con el ambiente. Aunque no existe un lenguaje
universalmente aceptado para hacer las representaciones de preguntas e información,
se establecieron algunas características que son deseables en el que sea usado por los
agentes para sus interacciones [INF01]:

Forma: Debe ser declarativo, sintácticamente simple y leíble.

Contenido: Debe tener la capacidad de acomodarse bien con otros sistemas.
Para ello en particular, se debe distinguir entre el lenguaje de comunicación y, el
cual expresa actos de comunicación, y el lenguaje de contenido, que expresa la
información acerca del dominio.

Semántica: Debe exhibir las propiedades de cualquier otro lenguaje. Ser fijo en
teoría, y también ambiguo.

Implementación: Debe ser eficiente por velocidad y para la utilización del ancho
de banda.

Funcionamiento en la red: Debe adecuarse muy bien a la tecnología de redes
moderna.

Medio ambiente: El medio ambiente debe ser altamente distribuido, heterogéneo
y dinámico.

Confiabilidad: Debe soportar comunicaciones confiables y seguras.
La implementación, la arquitectura del sistema de agentes y la aplicación a ser realizada
también son una influencia en el diseño del ACL. Surge la necesidad de mantener
información acerca del ambiente, la historia, y el objetivo de los agentes, debido al
comportamiento autónomo de los mismos. Así, un ACL debe ser un lenguaje de
representación que permite un intercambio de conocimiento entre agentes.
Ontología
Es necesario conceptualizar el mundo usando una ontología, de manera que los
agentes tengan un marco de referencia, al cual acudir para poder interpretar un
mensaje. Una ontología, en el contexto de los ACL, es la especificación de una
conceptualización, la cual a su vez consiste en conjuntos de conceptos y las relaciones
que existen entre los mismos [INF01].
La ontología es utilizada para definir el vocabulario que los agentes deben usar para
mantener el conocimiento y las reglas de comportamiento. Al ser compartida por los
agentes dentro de su ambiente, el vocabulario puede ser utilizado para efectuar su
comunicación. Por consiguiente, la ontología es escrita usando un lenguaje de
representación del conocimiento.
KIF
El Formato de Intercambio de Conocimiento, KIF, es un lenguaje de representación
común desarrollado por el KSE. KSE es un consorcio para desarrollar convenciones
que faciliten compartir y rehusar las bases de conocimiento y los sistemas basados en
conocimiento [INF01].
KIF es usado para expresar hechos sencillos, al igual que relaciones complejas por
medio de un número de operadores lógicos. Adicionalmente, provee construcciones
para describir procedimientos. KIF es una lógica de predicados de primer orden.
Los protocolos de comunicación, surgen de la necesidad de crear un método
estandarizado para el intercambio de mensajes entre los agentes. Los mismos
consisten en lenguajes que comparten una base de conocimiento la cual les permite
interpretar el intercambio de mensajes. Los dos más reconocidos son FIPA ACL y
KQML.
FIPA ACL
FIPA ACL asume la existencia de un sistema de Manejo de Agentes, que no es parte
del lenguaje, y abstrae los detalles de comunicación al bajo nivel.
Un mensaje FIPA ACL contiene un conjunto de uno o más elementos. El único
obligatorio es la “performativa”, aunque se prevé que la mayoría de los mensajes
contendrán también un “emisor”, un “receptor” y un “contenido”. Otros elementos
necesarios varían según la situación y son definidos por el usuario [FIPA00061].
Cada especificación de la representación de los mensajes ACL contiene descripciones
de una sintaxis precisa para las codificaciones de los mensajes ACL, las cuales se
encuentran basadas en XML, cadenas de texto y otros esquemas.
Los términos usados para definir la ontología y la sintaxis abstracta de la estructura de
un mensaje FIPA ACL son:

Frame: Nombre obligatorio de esta entidad, el cual debe ser usado para
representar cada instancia de esta clase.

Ontología: Nombre de la ontología.

Elemento: Identifica cada componente dentro del frame. El tipo esta definido de
acuerdo a una codificación particular. Las codificaciones de para cada uno están
dadas en las especificaciones de FIPA.

Descripción: Descripción de la semántica de cada elemento. Se usan notas para
aclarar su uso típico.

Valores reservados: Lista de constantes definidas por FIPA asociadas a cada
elemento.
Todos los elementos de los de mensajes de FIPA comparten el mismo frame (FIPAACL-Message) y ontología (FIPA-ACL).
KQML (Knowledge Query and Manipulation Language)
Los sistemas basados en agentes deben coincidir en varios aspectos, por lo menos en
las interfaces, para poder interoperar exitosamente. Los niveles en los cuales deben
coincidir son [KQML93]:

Transporte: la manera en la cual los agentes reciben y envían mensajes.

Lenguaje: lo que quieren decir los mensajes individuales.

Políticas: la manera en que los agentes estructuran las conversaciones.

Arquitectura: como conectar sistemas que estén en concordancia con los
protocolos constituidos.
KQML es un lenguaje que permite que los programas se comuniquen entre si,
compartiendo información acerca de sus estados, haciendo consultas (queries),
creencias, logros, subscripciones y ofertas. KQML es independiente del formato de la
información en si, puesto que las expresiones en KQML suelen contener subexpresiones en otros lenguajes contenedores. KQML es muy útil para comunicar
programas OA porque estos son autónomos y asincrónicos.
Los mensajes en KQML se llaman performatives. Esto se debe a que se pretende que
los mensajes ejecuten alguna acción al ser enviados. Una performative se expresa
como una cadena de caracteres ASCII usando una sintaxis especifica:
<performative> ::= (<word> {<whitespace> :<word> <whitespace>
<expression>}*)
<expression> ::= <word> | <quotation> | <string> | (<word> {<whitespace>
expression>}*)
<word> ::= <character><character>*
Para poder describir un lenguaje de comunicaciones se debe definir un modelo del
transporte de mensajes. Estas frases definen el nivel de transporte:

Los agentes se encuentran conectados por medio de vínculos de comunicación
unidireccionales que llevan mensajes.

Estos vínculos pueden tener un retraso asociado.

Cuando un agente recibe un mensaje, este conoce la conexión a través de la
cual le fue enviado el mensaje.

Cuando un agente envía un mensaje este puede elegir la conexión de salida por
la cual lo envía.

Los mensajes llegan a su destino en el orden en que fueron enviados.

La entrega de mensajes es confiable.
El modelo semántico que describe KQML es un contexto simple y uniforme en el cual
los agentes pueden ver las capacidades de los otros. Cada agente aparece como si
manejara una base de conocimiento (KB). Es decir, la comunicación con el agente se
hace con respecto a esta KB. Se manejan preguntas acerca del contenido de la KB y
las respectivas respuestas, solicitudes para agregar o eliminar declaraciones de la KB o
solicitudes para utilizar la información disponible en la KB para enrutar mensajes hacia
otros agentes.
Cuando se define una performative, es bueno clasificar las declaraciones (statements)
en dos categorías, creencias y objetivos, dentro de una base de conocimientos virtual
(VKB). Las creencias de un agente representan la información que el agente tiene
acerca de si mismo y el ambiente que lo rodea, incluyendo las VKB de otros agentes.
Los objetivos o metas de un agente representan la información acerca de los estados
que desea alcanzar o lograr en el ambiente que lo rodea. La definición de una
performative hace referencia tanto a los objetivos como a las creencias de un agente.
Los agentes se comunican entre si y se envían información acerca de las VKB que
manejan. Esto lo hacen utilizando KQML pero las declaraciones que se encuentran en
las VKB pueden usar varios lenguajes para su representación. Es decir, la performative
de KQML se usa para especificar que una cadena de caracteres determinada se
encuentra en el conjunto de creencias o metas de un determinado a gente, pero esa
cadena puede estar escrita utilizando otro lenguaje diferente a KQML.
Actos de comunicación
Los actos de discurso son una filosofía de lenguaje usada en SMA para analizar
comunicaciones simbólicas punto a punto [FER99].
Un acto de discurso es una acción intencional que se lleva a cabo en el transcurso de
una comunicación. Existen varios tipos de actos de discurso, estos son:

Asertivos: Dan información del mundo asertando algo.

Directivos: Dan directivas al receptor (”Haga esto”).

Promesivos: comprometen al locutor.

Expresivos: Dan indicaciones del estado mental del locutor

Declarativos: Hacer algo con solo mencionarlo (“Te sentencio”).
En FIPA se maneja una librería de actos de comunicación, en donde se definen los
actos existentes en FIPA. La información que se guarda de cada uno de estos actos es:
Nombre, resumen, descripción, modelo formal y un ejemplo [FIPA00037].
Al estandarizar y definir una librería de actos de comunicación en FIPA, se busca:

Garantizar la interoperabilidad ofreciendo un conjunto de actos de comunicación
estándares (que pueden ser compuestos) derivados de los actos de
comunicación primitivos definidos en FIPA.

Facilitar la reutilización de los actos de comunicación estándares.

Ofrecer un proceso bien definido para mantener un conjunto de actos de
comunicación y utilizar las etiquetas (labels) definidas por FIPA ACL
[FIPA00061].
La comunicación entre agentes esta basada en mensajes, una forma de mensaje es
una pregunta. Cuando agente hace una pregunta espera 1 de las siguientes tres
posibles reacciones: La respuesta a la presunta, Un rechazo a la pregunta (esta puede
estar acompañada por una explicación) o una solicitud de información adicional.
Para modelar una conversación manejan secuencias validas de mensajes expresadas
por medio de protocolos de comunicación. Estos se pueden describir con Redes de
Petri y Autómatas de estados finitos [FER99].
Para Ferber, llevar a cabo un número de tareas suplementarias dentro de un SMA, en
donde se debe llevar a cabo trabajo distribuido, hace necesario que se presente
coordinación de tareas. Esta se presenta cuando se tiene un grupo de agentes
dedicados a lograr sus propios objetivos. Llevar a cabo tareas productivas implica un
rango de coordinación de tareas sin las cuales las primeras no podrían ser logradas. La
coordinación está relacionada con el orden en que las tareas deben ser llevadas a cabo
[FER99].
Como parte del mecanismo de coordinación que se va a establecer al diseñar la
arquitectura del sistema, se debe definir una estrategia para cumplir con el objetivo del
mismo. El programador puede fijar una estrategia estática, diciendo quien hará que y en
qué momento. O bien puede ser dinámica, dejando que los agentes piensen como
actuar lo cual da pie a una estrategia emergente.
Podrían tenerse tres maneras de establecer la estrategia:

Crearla previamente y asignar a los agentes sus tareas para que la ejecuten.

Crearla previamente, pero dejar que en tiempo de ejecución se tome la decisión
de quien hace que.

Dejar que los agentes en tiempo de ejecución decidan su plan y lo lleven a cabo.
En los dos últimos casos los roles que se tienen serían dinámicos. Al considerar este
aspecto, se concluye que establecer una estrategia es un paso muy relacionado a fijar
los roles que tendrá el sistema. Por esa razón es recomendable que se sigan dos
etapas:

Crear la estrategia de para cumplir la meta del sistema en el momento en que se
vayan a fijar roles.

Luego, cuando se llegue a la parte en la que se debe establecer un método de
coordinación, la estrategia se debe complementar ajustando la sincronización
entre los agentes, y mirando como se manejará la resolución de conflictos entre
los mismos. Estos últimos aspectos no han sido tratados hasta ahora.
De esta manera, llegamos a la conclusión de que un paso previo a establecer
mecanismos de coordinación, es el de evaluar la manera en la que se cumplirá la meta
principal del sistema. En la metodología se podría sugerir pensar diferentes estrategias
y evaluarlas para escoger la mejor. También, se podría aconsejar que se sigan todas
para ver cual es la más conveniente.
Por ultimo, falta establecer un mecanismo de resolución de conflictos, ya que en las
metodologías escogidas para este estudio no se hace referencia a ninguna forma de lograr
que los agentes resuelvan los conflictos que se puedan presentar durante sus interacciones.
Los conflictos se producen como consecuencia de dos situaciones: el antagonismo de
objetivos y la lucha por los recursos. Se propone como solución a estos conflictos, la
negociación entre los agentes, el manejo de jerarquías, en las cuales uno de ellos es
quien toma la decisión de lo que harán los demás, y el manejo de contratos (contract
net) [FER99].
Establecer la arquitectura interna de cada agente
Este último paso consiste en cómo hacer que cada agente razone acerca de los otros
agentes y su estado de coordinación. Para Boer [falta], después de haber sido
identificados los roles que se deben tener en el sistema, se debe modelar el
conocimiento que se tiene del ambiente relacionado con los roles identificados o
habilidades.
En Tropos [falta] después de haber diseñado la arquitectura del sistema, se realiza el
diseño detallado de los agentes. Cada agente de la arquitectura es definido en términos
de eventos internos y externos, planes, creencias y protocolos de comunicación. La
especificación de las capacidades es importante para modelar los eventos internos y
externos que motivan los planes y creencias envueltas en el razonamiento de los
agentes. Para este diseño, se pueden adaptar algunos diagramas propuestos para
diseñar agentes y SMA, entre los cuales se tienen algunos de los propuestos por AUML
[AUM02]: Diagramas de Capacidad, Diagramas de planes, Diagramas de Interacción de
Agentes.
El sexto paso de la metodología MaSE [WOO01] consiste en ensamblar las clases de
agente. Aquí se crea la estructura interna de las clases de agente. Para ello se definen
cinco plantillas arquitecturales diferentes: BDI, reactivo, planeador, basado en
conocimiento, y arquitectura definida por el usuario [ROB00].
Los últimos pasos a seguir en la fase de análisis de la metodología de Fang [FAN00],
consisten en hacer un ‘agent class framming´ es decir se obtiene el framework para
cada clase de agente. Luego se deben jerarquizar las clases de agentes, es decir hacer
la generalización, asociación, agregación y composición de las mismas.
Posteriormente al continuar con la fase de diseño, se definen las estructuras de los
componentes, agentes y roles identificados: Para cada componente se especifica cada
procedimiento primitivo dando las pre y post condiciones, así como los posibles efectos
secundarios. Para cada rol, se diseñan y definen diagramas de jerarquía de tareas para
cada tarea compleja. En cuanto a las clases de agente, se diseña la estructura mental
jerárquica, las reglas y los algoritmos de manejo de tiempo.
Diseñar el sistema
El séptimo y último paso de MaSE [WOO01], consiste en instanciar las clases en
agentes reales. De esta manera se usa un Diagrama de Despliegue para mostrar los
números, tipos y ubicaciones de los agentes dentro del sistema. En el mismo se
representan los agentes, las conversaciones entre ellos, se nombran los agentes
después de la clase de agente a la que pertenecen, y además se indica si los agentes
están ubicados en la misma plataforma física. El sistema debe ser representado en el
Diagrama de Despliegue antes de ser implementado, debido a las diferencias entre los
agentes y las clases de agente. Un agente necesita conocer el nombre de un host para
poder participar en el SMA. Además el diseñador podría distribuir a los agentes sobre
diferentes configuraciones de máquinas, para tomar provecho del ancho de banda de la
red.
Mapeo de los Aspectos detectados a las Metodologías
estudiadas
Al examinar las metodologías escogidas para este estudio, se detectaron los aspectos
importantes que se deben tener en cuenta para la elaboración de un sistema orientado
a agentes. Como se pudo observar, dados los criterios expuestos por cada una, se
tienen diferentes puntos de vista de la manera en la cual el proceso debe ser llevado a
cabo; sin embargo, algunos de ellos son significativos para todas, y por esa razón se
identifican como los más importantes a tener en cuenta. A continuación se enumeran
los aspectos que se identificaron a partir de todas las metodologías, y se concluye
cuales de ellos son coincidentes para el conjunto en general de las mismas, o se
consideran imprescindibles.
Aspecto
Distribuir
agentes.
las
tareas
1
entre
los
X
Manejar aspectos de comunicación
tales como definir el tipo de la
comunicación (si es punto – punto
o multicasting), definir los caminos
(relaciones) existentes entre los
agentes, definir los protocolos a
utilizar y el formato y estilo de las
conversaciones.
X
Establecer
mecanismos de
coordinación entre los agentes,
como resolución de conflictos y
negociación.
X
2
3
4
5
6
7
8
Σ
X
X
X
X
X
X
Identificación y manejo de los roles
en el sistema, al igual que las
responsabilidades
que
les
corresponden.
X
X
Manejar un modelo del ambiente.
X
X
X
X
X
X
X

X

X

Diseñar una arquitectura, que
puede ser entendida como una
estructura o modelo organizacional
en el cual se pueden manejar
subsistemas.
X
X
Modelar las dependencias e
Interrelaciones .entre los agentes y
los roles.
X
X
Obtener
los
requerimientos
funcionales y no-funcionales del
sistema. Esto se puede obtener al
realizar un análisis de los objetivos
que deben tener los agentes.
También se debe hacer el análisis
utilizando diagramas de casos de
uso.
Definir los tipos de agentes del
sistema,
y
en
lo
posible
jerarquizarlos.
X
X
Utilizar un lenguaje como AUML o
BRIC u otro de los existentes.
X
X
X
X
X
X
X
X
X
X
X
X

X
X

X
X
Utilizar Diagramas de Secuencia
para ilustrar el comportamiento de
los agentes y sus interacciones.
X
X
Análisis de las interacciones entre
los agentes, y sus objetivos.
Establecer la arquitectura interna
de los agentes del sistema.
X
X

X
X

X
X

X
X
X

Los aspectos que tienen  son aquellos que más se repiten entre las metodologías
estudiadas, o los que se consideran más importantes y que deben tenerse en cuenta en
el momento de desarrollar una metodología.
1  Sycara
5  Gaia
2  Boer
6  Basada en Interacciones
3  Tropos
7  Fang
4  MaSE
8  Ferber
Bibliografía
[AUM02]
http://www.auml.org, “AUML Web Site”, AUML - Última consulta 23 de Abril
de 2002.
[FAN00]
Fang X.: “Towards a Building Methodology for Software Agents”. Turku
Centre for Computer science (Finlandia).
[FER99]
FERBER, Jacques. "Multiagent Systems: An Introduction to Distributed
Artificial Intelligence", Addison – Wesley Longman. 1ra. ed., 1999.
[FIPA00025] http://www.fipa.org/specs/fipa00025/XC00025D.pdf,
Foundation
for
Intelligent Physical Agents, “FIPA Interaction Protocol Library
Specification”, 29 de Enero de 2001 – Última consulta 21 de Octubre de
2002.
[FIPA00026] http://www.fipa.org/specs/fipa00026/XC00026F.pdf,
Foundation
for
Intelligent Physical Agents, “FIPA Request Interaction Protocol
Specification”, 10 de Agosto de 2001 – Última consulta 21 de Octubre de
2002.
[FIPA00027] http://www.fipa.org/specs/fipa00027/XC00027F.pdf,
Foundation
for
Intelligent Physical Agents, “FIPA Query Interaction Protocol
Specification”, 10 de Agosto de 2001 – Última consulta 21 de Octubre de
2002.
[FIPA00028] http://www.fipa.org/specs/fipa00028/XC00028F.pdf,
Foundation
for
Intelligent Physical Agents, “FIPA Request When Interaction Protocol
Specification”, 10 de Agosto de 2001 – Última consulta 21 de Octubre de
2002.
[FIPA00029] http://www.fipa.org/specs/fipa00029/XC00029F.pdf,
Foundation
for
Intelligent Physical Agents, “FIPA Contract Net Interaction Protocol
Specification”, 10 de Agosto de 2001 – Última consulta 21 de Octubre de
2002.
[FIPA00030] http://www.fipa.org/specs/fipa00030/XC00030F.pdf,
Foundation
for
Intelligent Physical Agents, “FIPA Iterated Contract Net Interaction
Protocol Specification”, 10 de Agosto de 2001 – Última consulta 21 de
Octubre de 2002.
[FIPA00031] http://www.fipa.org/specs/fipa00031/XC00031F.pdf,
Foundation
for
Intelligent Physical Agents, “FIPA English Auction Interaction Protocol
Specification”, 10 de Agosto de 2001 – Última consulta 21 de Octubre de
2002.
[FIPA00032] http://www.fipa.org/specs/fipa00032/XC00032F.pdf,
Foundation
for
Intelligent Physical Agents, “FIPA Dutch Auction Interaction Protocol
Specification”, 10 de Agosto de 2001 – Última consulta 21 de Octubre de
2002.
[FIPA00033] http://www.fipa.org/specs/fipa00033/XC00033F.pdf,
Foundation
for
Intelligent Physical Agents, “FIPA Brokering Interaction Protocol
Specification”, 10 de Agosto de 2001 – Última consulta 21 de Octubre de
2002.
[FIPA00034] http://www.fipa.org/specs/fipa00034/XC00034F.pdf,
Foundation
for
Intelligent Physical Agents, “FIPA Recruiting Interaction Protocol
Specification”, 10 de Agosto de 2001 – Última consulta 21 de Octubre de
2002.
[FIPA00035] http://www.fipa.org/specs/fipa00035/XC00035F.pdf,
Foundation
for
Intelligent Physical Agents, “FIPA Subscribe Interaction Protocol
Specification”, 10 de Agosto de 2001 – Última consulta 21 de Octubre de
2002.
[FIPA00036] http://www.fipa.org/specs/fipa00036/XC00036F.pdf,
Foundation
for
Intelligent Physical Agents, “FIPA Propose Interaction Protocol
Specification”, 10 de Agosto de 2001 – Última consulta 21 de Octubre de
2002.
[FIPA00037] http://www.fipa.org/specs/fipa00037/, Foundation for Intelligent Physical
Agents, “FIPA Communicative Act Library Specification”, 2000.
[FIPA00061] http://www.fipa.org/specs/fipa00061/, Foundation for Intelligent Physical
Agents, “FIPA ACL Message Structure Specification”, 10 de Agosto de
2001 – Última consulta 23 de Octubre de 2002.
[INF01]
http://infoeng.ee.ic.ac.uk/~malikz/surprise2001/kt197/article2/main.html,
“Agent Comunication Languaje” - Última consulta 22 de octubre de 2002
[KQML93]
The DARPA Knowledge Sharing Initiative External Interfaces Working
Group, Specification of the KQML Agent-Communication Language
[MIL00]
Miles S., Joy M. y Luck M.: “Designing Agent-Oriented Systems by
Analysing Agent Interactions”. Department of Computer Science,
University of Warwick Coventry, CV4 7AL, United Kingdom.
[O’MAL01]
Scott A. O’Malley and Scott A. DeLoach , Determining When to Use an
Agent-Oriented Software Engineering Paradigm. Proceedings of the
Second International Workshop On Agent-Oriented Software Engineering
(AOSE-2001), Montreal, Canada, May 29th 2001.
[ROB00]
Robinson, D.J.: “A Component Based Approach to Agent Specification”.
MS thesis, AFIT/ENG/00M-22. School of Engineering, Air Force Institute
of Technology (AU), Wright-Patterson Air Force Base Ohio, USA (2000).
[SYK98]
Sycara, “Multiagent Systems”, Al Magazine, 19 (2), 1998, pp 79 – 92.
[WOO01]
Wood Mark F., DeLoach Scott A., In Agent-Oriented Software Engineering
– Proceedings of the First International Workshop on Agent-Oriented
Software Engineering, 10 th June 2000, Limerick, Ireland. P. Ciancarini,
M. Wooldridge, (Eds.) Lecture Notes in Computer Science. Vol. 1957,
Springer Verlag, Berlin, January 2001.
[WOO00]
Wooldridge M., Jennings M. y Kinny D.: “The Gaia Methodology for AgentOriented Analysis and Design”. Autonomous Agents and Multi-Agent
Systems, 3, 285Œ312, 2000 © 2000 Kluwer Academic Publishers.
Manufactured in The Netherlands.