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.