El rol de las interacciones en la ISOA es fundamental ya que las interacciones identifican dependencias entre los componentes y contribuyen a la especificación del comportamiento de los componentes así como la funcionalidad asociada. Estos aspectos cubren un alto porcentaje de los asuntos a considerar cuando se diseña un sistema. De acuerdo con la experiencia del autor, el desarrollo de interacciones constituye un importante porcentaje del esfuerzo total, similar al invertido cuando se modelan interfaces de usuario (en este área las estimaciones dicen que el desarrollo de interfaces requiere un 47% del esfuerzo de desarrollo calculando este esfuerzo como la media aritmética entre el tiempo de diseño y de implementación [Myers y Rosson 92]). Debido a la similitud entre la interacción con el usuario y la interacción entre agentes, debería quedar clara la importancia del modelado de interacciones como un concepto clave en cualquier propuesta de ISOA. Sin embargo, la mayoría de las propuestas existentes no prestan la atención suficiente a este hecho. Alguno de ellos consideran que las interaciones son el resultado de ejecutar tareas, por lo que se centran en relacionar tareas (ZEUS [Nwana et al. 99]). Otros comienzan suponiendo que la solución está en la especificación basada en paso de mensajes (MESSAGE [Caire et al. 02]) Otros estudian qué se requiere de una interacción, pero no estudian cómo deberían ser diseñadas (GAIA [Wooldridge, Jennings y Kinny 00] [Zambonelly, Wooldridge M. y Jennings N.R. 00]). Para terminar, hay metodologías que consideran la construcción de SMA desde un punto de vista de ingeniería del conocimiento, prestando poca atención a las interacciones ya que el problema principal es cómo modelar los objetivos del sistema (TROPOS [Bresciani et al. 01]).
De entre todos estos, destacan MAS-CommonKADS [Iglesias et al. 98] y Vowel Engineering [Demazeau 95] [Ricordel 01], porque tratan de integrar las interacciones en el conjunto de vistas del sistema haciéndolas parte indispensable de las metodologías. El trabajo presentado en esta sección se entiende como un complemento de los resultados alcanzados en ellas. Extiende MAS-CommonKADS y Vowel Engineering mediante la abstracción de las interacciones para estudiarlas desde diferentes puntos de vista, la naturaleza de la interacción, su ejecución, representación y contexto, integrándolas en el proceso de desarrollo (análisis y diseño), y estudiando elementos de diseño (como las diferentes formas de definir el control de la interacción) para que la implementación final sea más sencilla.
Esta sección no está orientada a la aplicación de lenguajes concretos de interacción como KQML [Finin et al. 94] o ACL [FIPA 01], ni al desarrollo de algoritmos de coordinación. Este trabajo establece cómo una interacción se puede integrar en el ciclo de desarrollo de un SMA, poniendo especial énfasis en actividades de análisis y diseño.
Las interacciones determinan el comportamiento de los agentes mostrando cuál es su reacción cuando actúan sobre ellos. Y cómo el comportamiento va a ser función de las objetivos de los agentes y las tareas a ejecutar, se puede concluir que existe un importante vínculo entre interacciones, objetivos y tareas.
El nivel de abstracción en el que se definen las interacciones cambia del análisis al diseño. En el Proceso Racional Unificado (Rational Unified Process) [Jacobson, Rumbaugh y Booch 99], un primer paso en el análisis es generar casos de uso que hagan referencia a interacciones clave, y quizás añadir diagramas de colaboración, secuencia o de actividades para mostrar cómo evoluciona el sistema. Posteriormente, en el diseño, estas interacciones se detallan con más diagramas de los antes mencionados, decorándolos con diagramas de estado y diagramas de clase para mostrar las interfaces relevantes.
En el área de agentes, sin embargo, esto no es tan simple. Aunque el análisis puede ejecutarse de una forma similar, esto es, definiendo algunos diagramas, el diseño no puede ser así. De acuerdo con la experiencia en [Eurescom P815 99], [Caire et al. 02] y [PSI3 01], la especificación completa de una interacción tiene que cubrir:
Los actores que participan. Un actor debería mostrar por qué está participando en la interacción. Esto es coherente con un modelo de agente que se basa en el principio de racionalidad.
La definición de unidades de interacción. La naturaleza de la unidad de interacción determina cómo tiene que procesarla el receptor. Una unidad de interacción puede ser tan simple como un paso de mensaje o tan compleja como la propuesta de [Ribeiro y Demazeau 98] que recibe el nombre de mensajes activos. Este tipo de mensajes se caracterizan por hacerse responsables de la interacción con el receptor de una forma personalizable dependiendo de las capacidades del receptor.
Un orden sobre las unidades de interacción. Las unidades de interacción se organizan siguiendo un protocolo estándar (como contract-net [Smith 80] o FIPA-request [FIPA 01]) o adecuado a una situación concreta. La representación del orden varía desde los diagramas de secuencia de mensajes, pasando por los diagramas jerárquicos de FIPA [FIPA 95], al actual diagrama de protocolos de Agent-UML (AUML) [Bauer, Müller y Odell 01].
Acciones ejecutadas en la interacción. Incluye detalles sobre:
Criterios para decidir cuándo ejecutar una tarea. Para ejecutar una tarea no es suficiente con que alguien lo solicite, ya que el agente tiene libertad para abandonar su ejecución (dando por hecho que no existe ningún compromiso) o simplemente negarse a aceptar la solicitud.
Consecuencias de la ejecución de una tarea. Al término de una tarea se esperan cambios en el estado mental del agente (como en Agent0 [Shoham 93]) o cambios en el estado del mundo (como en TAEMS [Decker 96]).
Definición del contexto de la interacción. El contexto consiste en detallar qué ocurre en el sistema cuando se inicia la interacción, mientras se desarrolla y a su conclusión. Esta información se proporciona, primero indicando qué actores participan, segundo qué motivos que los impulsan a hacerlo, tercero qué objetivos persigue la interacción y cuarto qué estados mentales se requieren de los agentes durante la ejecución de la interacción.
Un modelo de control. El control asegura que la interacción va a desarrollarse según fue definida. Este control debería tener en cuenta que en la mayoría de los casos se permite llevar varias interacciones en paralelo, i.e. se permiten diferentes conversaciones de los mismos protocolos (utilizando terminología de [Nowostawski, M., Purvis, M y Cranefield, S. 01]). Este control se tendría que orientar hacia la gestión de las actividades manejadas en la interacción, lo que terminaría siendo un mecanismo de coordinación [Malone y Crowston 94].
Uno de los primeros resultados del análisis es la identificación de las interacciones que son relevantes a la funcionalidad del sistema. Aparecen cuando se consideran las relaciones entre las componentes del sistema, o al tratar de explicar como el sistema soporta la ejecución de algunas tareas.
Es importante capturar estos detalles utilizando las herramientas conceptuales existentes, como los diagramas de colaboración y secuencia [OMG 00d], diagramas de protocolo [Bauer, Müller y Odell 01], redes de transición [Demazeau 95], redes de Petri [Cost et al. 00], o diagramas de paso de mensaje [Iglesias et al. 98]. Como unidades de interacción se pueden manejar mensajes como en UML [OMG 00d], bien actos del habla como en FIPA [FIPA 02] o protocolos como en GAIA [Wooldridge, Jennings y Kinny 00].
En los enfoques actuales, siguiendo el trabajo de Kendall [Kendall 98] y la especificación de diagramas de colaboración de UML [OMG 00d], se resalta la importancia de la utilización de roles en la especificación de interacciones. En ambos trabajos se sugiere que la interacción se defina de forma genérica y que posterioriormente se detalle quién debe jugar los roles indicados en la interacción. Otra influencia importante es la de FIPA en cuanto a la utilización de dos roles principales: el iniciador y los colaboradores. Sólo se admite un iniciador por interacción y al menos un colaborador.
Aunque la cantidad de información requerida para especificar una interacción pueda parecer demasiada, la mayoría de los aspectos mencionados pueden ser representados con un diagrama de colaboración UML. Tal diagrama dejaría sin especificar los puntos 4 y 6. Sin embargo, esto no debería suponer un problema, ya que el análisis no requiere tanto nivel de detalle.
Disponer de toda la información necesaria acerca de las interacciones es una situación que se da raramente. Lo normal es comenzar con un boceto de la interacción y comenzar a pensar cómo las ideas del análisis pueden aparecer en el sistema final. Según se avanza hacia el diseño, la situación cambia. Se concretan componentes que sean capaces de soportar las interacciones al mismo tiempo que se aumenta el nivel de detalle en la especificación de las interacciones. El detalle se incrementa por lo general detallando cómo se ejecuta cada unidad de interaccion en la interacción. La ejecución se explicita describiendo qué información requieren y cómo se estructuran las distintas unidades de interacción.
Cuando se trata de mensajes, se definen el número y contenido de sus parámetros. Si se trata de llamadas a procedimiento, el número, tipo y valor de los argumentos de la llamada. En el caso de espacios de tuplas, como en Linda [Carriero y Gelernter 89] [Papadopoulos y Arbab 98], se detalla qué información se debe dejar en el espacio compartido y cómo esta información debe ser leída por los colaboradores.
En cuanto a la estructuración de unidades, se consideran UML, AUML y máquinas de estados. UML propone etiquetar los pasos de mensaje con expresiones de secuencia [OMG 00d] que denotan guardas, iteraciones, paralelismo o secuenciación. AUML, aboga por la utilización de notación específica para expresar estos aspectos y añade la encapsulación de los pasos de mensaje para dar lugar a protocolos reutilizables. Las máquinas de estados tienen implícita la secuenciación de unidades de interacción en su propia construcción.
En paralelo a este proceso de incremento de detalle, se tiene la selección y parametrización de las componentes que soportan la interacción. Cuando hay un lenguaje especializado, un armazón, o una herramienta para la generación automática de código, el proceso de generación de estas componentes es directo. Por ejemplo, los aspectos de interacción mencionados en la introducción son codificables casi directamente en Agent0 o ZEUS. Situaciones similares aparecen cuando las interacciones pertenecen a alguna categoría concreta. Por ejemplo, si el problema es categorizable como “ubicación de tareas” y necesita que se aplique negociación, existe la solución contract-net [Smith 80] y la representación computacional de FIPA, el FIPA-contract-net [FIPA 01] implementada en JADE [Bellifemine, Poggi y Rimassa 01]. Si el problema es categorizable como planificación, la planificación parcial global generalizada o GPGP (Generalized Partial Global Planning ) puede usarse como especificación y como representación computacional JAF [Wagner y Horling 01] usando el armazón TAEMS [Decker 96].
Al margen de estas soluciones, se puede acudir a arquitecturas clásicas como la arquitectura de pizarra [Corkill 91] que soportan el paradigma de espacio de trabajo compartido. Las variantes existentes de las arquitecturas de pizarra suelen asociarse con los lenguajes basados en Linda. En la práctica sin embargo, se haya más extendido el modelo establecido en FIPA [FIPA 01] que soporta paso asíncrono de mensajes ACL (Agent Communication Language) bajo diferentes tecnologías de comunicación. También es bastante común el encontrar arquitecturas de interacciones específicas utilizando paradigmas cliente-servidor directamente con CORBA [OMG 00a], DCOM [Microsoft 02] o RMI [Sun Microsistems 02]. Finalmente, si el diseñador desea desacoplamiento con la arquitectura de interacción, los métodos convencionales podrían proporcionar representaciones computacionales de alto nivel a través de los patrones de diseño wrappers y proxies [Gamma et al. 95].
Los esfuerzos en el modelado de las interacciones pueden clasificarse en dos grupos: por un lado la especificación de alto nivel con diagramas de paso de mensajes (Message Sequence Charts [International Telecommunication Union 99 A.D.a]), diagramas de secuencia y colaboración (UML) y de protocolos (FIPA y AUML); y por otro lado, un diseño de más bajo nivel, sin llegar a la implementación, utilizando mecanismos de comunicación, como los espacios compartidos de tuplas, o de control, como redes de Petri1. En el caso de los primeros, existe el problema de cómo traducir estas especificaciones a elementos computacionales. En el caso de los segundos, el problema es el inverso, los mecanismos de control y comunicaciones son de demasiado bajo nivel como para expresar de forma sencilla situaciones complejas. Se puede decir que ambos enfoques son complementarios, sin embargo no es trivial pasar de uno a otro.
Hasta ahora, la notación para especificación de interacciones entre agentes más prometedoras son UML y AUML. Estas soluciones tienen el inconveniente de no contemplar todos los aspectos aquí mostrados. Estas técnicas proporcionan soluciones a la mayor parte de los aspectos expuestos en la sección Análisis y diseño de interacciones, dejando solo incompleta la parte de contextualización de las interacciones. La forma en que UML y AUML integran las interacciones en la especificación del sistema consiste en asociar las interacciones, expresadas como diagramas de secuencia y colaboración, a los casos de uso. Esta visión de las interacciones es limitada, ya que en un SMA haría falta hablar de por qué se inició la interacción, por qué decidieron participar agentes en ella y por qué los agentes envían mensajes y acceden a procesarlos. La respuesta a estas preguntas permite justificar la existencia a las interacciones más allá de la agregación a un caso de uso, definir de forma genérica el control del agente (un control adecuado del agente sería aquel capaz de responder estas preguntas) y validar la participación de agentes en la interacción (si las motivaciones de los agentes que participan en la interacción no están relacionadas, puede que no deban participar).
Persiguiendo una integración de técnicas de control y comunicación junto con el diseño de alto nivel de las interacciones, se propone una forma de ver las interacciones abierta a tanto nivel de detalle como requieran los mecanismos de control o comunicaciones y el grado de abstracción requerido por las labores de diseño. Para ello, se debe permitir que la especificación de la interacción evolucione en paralelo con las tecnologías que la soportarán, partiendo de representaciones computacionales articuladas en torno a las necesidades del problema. En esta tesis se propone dividir el problema estudiando la interacción desde varios puntos de vista: el contexto, su naturaleza (como planificación o negociación), su ejecución (como estructura secuencial de los mensajes o estructurada con guardas o bucles) y representación de la interacción (como diagramas de protocolos o diagramas de secuencia).
El meta-modelo de interacciones propuesto busca simplificar:
La definición del contexto de la interacción. Esto ayuda al ingeniero a saber qué se busca con la interacción y cómo va a afectar al sistema.
La generación de una especificación de comportamiento del sistema bottom-up / top-down. Las interacciones no están aisladas. Es posible componerlas y relacionarlas para obtener especificaciones del comportamiento del sistema. Del mismo modo, también se puede partir de interacciones con el sistema y descender hasta las especificaciones de los componentes, que en este caso son agentes.
La definición de la ejecución de la interacción. Ya sea utilizando paso de mensajes, protocolos FIPA o invocación de procedimiento remoto. De esta forma se logra independencia del medio de comunicación utilizado.
La representación de la interacción. Al abstraerse de las posibles unidades de mensajes y de su ordenación, se pueden utilizar diferentes notaciones para representar lo mismo.
El meta-modelo de interacción se construye sobre: agentes, roles, objetivos, interacciones y unidades de interacción. Los agentes y roles son los actores de las interacciones. En las interacciones se ejecutan unidades de interacción (pasos de mensaje, lectura y escritura en un espacio de tuplas) en las que hay un iniciador (emisor) y colaboradores (receptores). Además, se justifica la participación de los actores en la interacción y la existencia de la interacción en sí mediante objetivos.
Ilustración 1. Relación entre los diferentes aspectos de la interacción
Estos elementos se interrelacionan mediante el conjunto de asociaciones de la Ilustración 1. En esta ilustración, se categorizan las asociaciones en los cuatro grupos ya vistos: naturaleza, contexto, ejecución y notación.
El contexto ayuda al ingeniero a situar la interacción en el marco del SMA, estableciendo en qué condiciones se iniciarán las interacciones. Esta información se utiliza para codificar el comportamiento del agente en forma de reglas de producción o para generar métodos de validación de la interacción, como métodos de detección de interbloqueos. En el metamodelo, el contexto se expresa con los estados mentales en ejecución que deben reunir los agentes y con las meta-relaciones IPersigue, IColabora y IInicia.
La naturaleza de la interacción indica qué clase de interacción se está considerando con respecto al tipo de control. Esta clase de control es de lo que trata la coordinación. La coordinación es la gestión de las dependencias entre actividades [Malone y Crowston 94] y se estudia dentro de la teoría de la coordinación. Esta teoría debería ser capaz de proporcionar taxonomías de coordinación, sin embargo, debido a su enfoque multidisciplinario, se ha preferido restringirse al ámbito de la informática tomando una taxonomía de Huhns [Huhns 00] (Ilustración 2).
Ilustración 2. Taxonomía de métodos de coordinación entre agentes
La naturaleza de la interacción es importante porque determina qué algoritmos, herramientas y guías pueden ayudar al diseñador. Si la naturaleza es planificación, quizá el diseñador debería evaluar la adecuación de GPGP [Decker y Lesser 95] (ver [Durfee, Lesser y Corkill 89] para otras soluciones). El tipo de interacción también muestra qué elementos tienen que considerarse. Por ejemplo, si la naturaleza es competitiva entonces debería existir en la interacción una referencia al objeto por cuya posesión o uso se compite.
La ejecución de la interacción se refiere al conjunto de actividades requeridas a la hora de desarrollar la interacción. En la ejecución existe un orden impuesto sobre las acciones y unidades de interacción. El orden establece el protocolo de la interacción, mientras que las unidades representan mensajes o protocolos, dependiendo del nivel de abstracción.
Finalmente, la representación toma la información de la ejecución y la naturaleza para crear una representación gráfica o formalismo textual sencillo de manejar por los ingenieros. Por ejemplo, una negociación que siga contract-net [Smith 80] puede expresarse con diagramas de protocolo de Agent UML , diagrama de protocolos FIPA o varios diagramas de secuencia UML.
Ilustración 3. Meta-modelo de interacción
Las interacciones en este trabajo se definen con el meta-modelo de la Ilustración 3. Este meta-modelo cubre los aspectos mencionados referidos en la Ilustración 1: contexto, naturaleza, ejecución y representación. El contexto aparece como la motivación de la interacción (meta-relación IPersigue) y de los roles en el momento de participar en la interacción (meta-relaciones WFPersigue y GTPersigue). La naturaleza se asocia directamente como propiedad de la interacción. La ejecución y representación han sido agrupadas dentro la entidad Especificación que es del tipo Graph. Según GOPRR, esto implica que Especificación es un conjunto de relaciones, objetos y roles. Esta abstracción se usa para denotar las posibles formas de especificar la ejecución y tipo de las unidades de interacción. En este trabajo se ha experimentado con dos tipos de especificación:
Diagramas de colaboración UML. En estos diagramas, las unidades de interacción son mensajes y la asociación entre emisor y receptor son las relaciones UIInicia e UIColabora. Las tareas pueden agruparse al igual que los agentes o roles, pudiendo recibir mensajes. El orden de ejecución así como las condiciones mentales se expresan con una Expresión de secuencia (ver [OMG 00d]).
Diagramas especializados GRASIA. Los diagramas de colaboración UML no están pensados para el modelado de interacciones entre agentes. Así, la justificación de por qué se está ejecutando la interacción, detalles acerca de por qué se están aceptando ciertos mensajes y por qué transcurre la interacción de un modo concreto, no son fácilmente expresables. Por ello, se ha generado una especificación GRASIA adaptada a su uso dentro de la metodología (ver Ilustración 4). Esta última variante de especificación da cabida a la representación del estado mental del iniciador y de un colaborador en una unidad de interacción.
Ilustración 4. Unidades de interacción y su relación con tareas y roles dentro de una especificación.
Las unidades de interacción se detallan en la Ilustración 4. La composición de unidades de interacción siguiendo un orden determinado lleva a la especificación de la ejecución de la interacción. De forma similar a las interacciones, una unidad de interacción también describe quién la inicia (UIInicia), quién colabora (UIColabora) y qué tareas se ejecutan en cada una (RUIEjecutaD). Aunque no se menciona explícitamente, hay que entender que en una especificación GRASIA, también se tienen tareas, agentes, roles, interacciones y unidades de interacción.
Ilustración 5. Patrones de estado mental asociables con las unidades de interacción
Los patrones de estado mental (ver Ilustración 5) se usan para expresar condiciones de comienzo y colaboración en términos de entidades de estado mental. La ejecución de tareas no tiene un patrón de estado mental asociado porque la condición implícita de ejecución de una tarea es la asociada a la meta-relación UIInicia o UIColabora. Así, cuando un agente comienza una unidad de interacción, también ejecuta las tareas asociadas mediante RUIEjecutaD.
Las condiciones que más se han estudiado en este trabajo son las expresables con la gramática expuesta en Agent0 [Shoham 93] (Patron Estado Mental AOP) y las expresables como agregación de entidades mentales (Patron Estado Mental GRASIA), ya que su traducción a reglas de producción es sencilla. En ambas variantes, aparece una descripción de cómo se espera que sea el estado mental del agente en un momento concreto. En el caso de la entidad Patron Estado Mental AOP la descripción debe ser un término <mntlpattern> cuya construcción se expresa en BNF en el En el caso de Patron Estado Mental GRASIA, la descripción es un modelo de agente (ver sección ) donde se indica qué entidades deben existir asociadas al estado mental del agente y qué condiciones se deben satisfacer. Cada entidad mental se etiqueta, en caso necesario, para referenciarlas cuando se exprese qué se requiere de estas entidades.
Finalmente, existe una meta-representación de los posibles órdenes que pueden aplicarse sobre las unidades de interacción (ver Ilustración 6). Los diseñadores pueden elegir el tipo de orden más apropiado para el problema que les ocupe, definir una instancia de dicho orden y dejar que el generador de código produzca un control de la comunicación adecuado. De esta forma, es factible definir un orden como el de los behaviour de JADE [Bellifemine, Poggi y Rimassa 01] usando las primitivas de comportamiento y ejecutando una traducción directa desde la especificación a las estructuras finales de JADE.
Para representar los posibles órdenes de ejecución de JADE, UML y AUML, se utilizan las guardas definidas en las instancias de Estado Mental Ejecución en la Ilustración 4 y tres primitivas: orden secuencial (Precede), orden no determinista (UIConcurren), selección (bifurca) e iteración (UIIteracion)
Ilustración 6. Ordenes de ejecución utilizables sobre las unidades de interacción
La meta-relación Precede define secuencias de unidades de interacción. Siendo A y B1,...,Bn unidades de interacción, la asociación A Precede (B1,...,Bn) significa que la unidad A tiene lugar siempre antes que la unidad Bi. La meta-relación Bifurca sirve para expresar condiciones de precedencia entre varias unidades de interacción. Siendo A y B1,...,Bn unidades de interacción, la asociación A Bifurca (B1,...,Bn) significa que sólo un Bi tendrá lugar después de A. Cuál será depende de las condiciones de colaboración o iniciación dadas por Estado Mental Ejecución en la Ilustración 4, ya que para que tenga lugar una unidad de interacción se han de cumplir las condiciones de colaboración e iniciación asociadas. En caso de que varias se cumplan, se elegirá una de forma no determinista. La entidad UIIteracion define la ejecución repetida de un conjunto de unidades de interacción. Estas entidades aparecen asociadas como una colección (UIs). El orden de ejecución dentro del bucle se determina aparte con las otras primitivas. La condición de terminación es que ninguna unidad de interacción de las contenidas sea ejecutable o bien que se cumplan las condiciones de inicio y colaboración de la unidad de interacción que se vaya a ejecutar a continuación. La entidad Concurren especifica un orden de ejecución no determinista sobre las unidades de interacción asociadas. La unidad de interacción Concurren se da por terminada cuando todas las unidades de interacción que tiene asociadas hayan tenido lugar.
Instanciando el meta-modelo de interacción es determina cómo reaccionan los agentes frente a las acciones de otros agentes. La composición de estas instancias da lugar a la definición detallada del comportamiento del sistema. Esta composición se realiza en el marco de la organización y más concretamente dentro de los flujos de trabajo.
Para cada una de las instancias se define un contexto concreto, que es el fijado por el flujo de trabajo de las organizaciones. Al final, las interacciones entre agentes se inician porque se han ejecutado tareas que satisfacen un objetivo en la organización u organizaciones a las que pertenecen los participantes de cada interacción.
Ilustración 7. Relaciones entre la interacción y la organización
La Ilustración 7 muestra las dependencias entre la interacción y la organización. El nexo entre interacciones y organización es el objetivo perseguido por ambas. Como las tareas, la organización se vale de interacciones entre sus miembros para alcanzar sus objetivos.
Se quiere diseñar un asistente para vender y comprar acciones en la Bolsa de Madrid. El asistente representa a un usuario con el que confirma las transacciones las acciones vía móvil. Existe la posibilidad de que el agente desarrolle su labor sin intervención del usuario. Esta situación se da cuando el usuario ha configurado un margen de variación en el precio de las acciones que dispara la compra (en caso de que baje las acciones que interesen al usuario) y la venta (en caso de que suban las acciones del usuario). Para realizar las operaciones de compra y venta, la Camara de Comercio ha habilitado servidores con los que se puede obtener información en tiempo real del valor de las acciones.
Buscando influir sobre el precio de las acciones en bolsa, el asistente acude a directorios de localización de agentes para localizar a otros agentes de compra-venta de acciones con los que aliarse. Una vez localizados, nuestro asistente plantea alianzas estratégicas con las que hacer variar la bolsa.
Ilustración 8. Definición del asistente de bolsa (modelo de agente)
Las alianzas se plantean mediante negociaciones con representantes de agentes ya aliados. En el caso de que no estén aliados, el agente con el que se contacta actúa como su propio representante. Tras asociarse con otro agente o agentes, hay que darse de alta en un registro de asociaciones, para que otros agentes puedan unirse a esta alianza. El protocolo de creación de alianzas se representa mediante una interacción FormarAlianza.
Ilustración 9. Interacción para la formación de alianzas
FormarAlianza persigue el único objetivo de formar una alianza entre agentes para conseguir mover las acciones de bolsa. La descripción del protocolo se describe inicialmente con un diagrama de colaboración (ver Ilustración 10).
Ilustración 10. Descripción inicial de la interacción para formar alianzas con diagramas de colaboración
La descripción con diagramas de colaboración no reflejan, por ejemplo, el acto del habla involucrado en cada paso de mensaje. A la hora de dar más detalle, se elige una especificación GRASIA para representar la misma interacción (ver Ilustración 11).
Ilustración 11. Boceto de descripción GRASIA de la interacción para formar alianzas
Con esta especificación se añaden las posibilidades de que la proposición sea rechazada, aceptada o simplemente no comprendida. Esta última posibilidad tiene que tenerse en cuenta en situaciones en que el software que interacciona es heterogéneo, como aquí. El asistente de bolsa no sabe quién ha hecho el otro agente ni que interfaces soporta. Se asume que existe una ontología compartida por los participantes en la que se definen un conjunto de contenidos válidos de mensajes. Al término de la negociación, el solicitante recibe un certificado personalizado que servirá para certificar futuras peticiones de la alianza.
Una vez se pertenece a la alianza, se plantean negociaciones en las que los agentes que pertenecen a la alianza acuerdan nuevos parámetros de compra-venta de acciones para lograr efectos significativos en bolsa. La negociación se hace mediante un protocolo FIPA contract-net [FIPA 01]. Este protocolo se encapsula dentro de otra interacción, NegociacionMovimientoBolsa.
Ilustración 12. Interacción para conseguir movimientos en bolsa
Se definen las acciones sobre las que se va a actuar, su número y su valor. Después se acuerda un momento de actuación. Si llegado el momento se satisfacen los parámetros de actuación acordados en la negociación, entonces los agentes proceden a realizar las transacciones pertinentes con la Bolsa de Madrid.
Ilustración 13. Descripción detallada de unidades de interacción involucradas en el acuerdo de acciones a realizar en la alianza
Para que el sistema funcione debe haber un número crítico de de agentes dentro de la alianza. Por ello se define que el iniciador de la negociación no comience hasta que se alcance un número crítico y se tenga la creencia de que se puede alcanzar el objetivo Mejorar Precio Acciones.
Ilustración 14. Condición mental contenida en Condicion inicio propuesta movimiento
La creencia antes mencionada sería el fruto de una tarea de análisis del estado de la bolsa. El colaborador en la interacción NegociaciónMovimientoBolsa participa en las negociaciones en virtud del compromiso adquirido al formar una alianza (ver Ilustración 15).
Ilustración 15. Estado mental requerido por un colaborador al inicio de las negociaciones
Para participar en una negociación para el movimiento de acciones, tiene que existir el compromiso generado en la interacción FormarAlianza. Este compromiso lleva implícito un certificado con el cual se puede verificar si una solicitud de participación es válida o no.
Al final de la interacción, en los agentes participantes se crea un compromiso de determinado día a determinada hora, si se cumplen las condiciones negociadas con anterioridad (umbral de beneficio dentro de los parámetros negociados y de lo configurado por el usuario), se realiza la venta o compra.
El meta-modelo de interacción constituye una fuente de información importante para determinar cómo ha de ser el control del agente. Parte del comportamiento del agente se puede ver a través del conjunto de interacciones que definen cómo reacciona el agente ante peticiones de información de otros agentes. Mediante las interacciones, además, puede deducirse cómo se modifica el estado mental de los agentes que participan, ya que las tareas ejecutadas durante la interacción son en parte responsables de los cambios internos en los agentes.
Ilustración 16. Relación del meta-modelo de interacción con otros meta-modelos
Las tareas ejecutadas en una interacción generalmente hacen uso de los recursos que configuran el entorno. La interacción, como en el caso del comportamiento del agente, también identifica los momentos en que se pueden disparar cambios en el entorno. Además, existe la posibilidad de que la propia interacción tome como medio de comunicación el propio entorno. En tal caso, el papel de los elementos recogidos en el meta-modelo de entorno es clave para reflejar qué cambios en el entorno son entendidos por otros agentes como actos de comunicación.
Finalmente, una interacción se asocia con las metas de la organización a la que pertenecen sus participantes. El contexto de la interacción se establece a través de objetivos y patrones mentales [Shoham 93]. Los objetivos se asocian directamente a las interacciones a través de la meta-relación IPersigue e indirectamente con las metas asociadas con la organización.
Basándose en estas relaciones, se plantean los siguientes criterios de consistencia del modelo de interacción:
Los objetivos perseguidos por la interacción (instancias de IPersigue) han de pertenecer a la organización o bien estar relacionados con estos por instancias de GTDescompone en modelos de objetivos y tareas. La relación entre los objetivos de la organización y los de la interacción se muestran en la Ilustración 7. Una organización de un SMA es una entidad con identidad y propósito que agrupa juntos agentes, roles, recursos y tareas [Garijo, Gomez-Sanz y Massonet 01]. El propósito de la organización se expresa a través de objetivos que indican el motivo por el cual todos los elementos anteriores están juntos. De acuerdo con el modelo BDI [Kinny y Georgeff 97] y el diagrama de la Ilustración 7, los objetivos de una interacción se hallan íntimamente relacionos con los de la organización. Si los objetivos de la interacción son alcanzados, entonces los objetivos de la organización se hayan más próximos a su satisfacción.
Todos los participantes en la interacción persiguen objetivos relacionados con los de la interacción. Un criterio para determinar si dos objetivos están relacionados sería que existieran entre ellos relaciones de descomposición dentro de un modelo de tareas y objetivos (instancias de la meta-relación GTDescompone) o bien por igualdad de los mismos. Otro criterio posible sería determinar si las tareas ejecutadas para satisfacer uno de ellos proporcionan evidencias que ayuden a satisfacer los otros.
Las tareas ejecutadas a lo largo de la interacción permiten satisfacer los objetivos de la interacción. Para verificarlo, se utilizan las relaciones GTSatisface del modelo de objetivos y tareas y la descomposición de objetivos (GTDescompone).
Las interacciónes plantean estados mentales en los agentes que se pueden expresar con modelos de agente. Sería necesario comprobar si estos estados mentales son consistentes con las acciones que los producen. El estado mental del agente surge como resultado de la actuación de su procesador de estado mental, de su gestor de estado mental, y sobre todo de las tareas ejecutadas. Así, debiera justificarse en los modelos de agente de dónde vienen las entidades mentales referidas a lo largo de la interacción y si realmente es posible que tal estado mental se dé.
1 Se habla de diseño de bajo nivel con redes de Petri, atendiendo a la capacidad de las redes de Petri a capturar mayor nivel de detalle que los diagramas de secuencia.