Agentes BDI bajo interacciones reguladas: un enfoque basado en flujos de trabajo

Agentes BDI bajo interacciones reguladas: un enfoque basado en flujos de trabajo Bexy Alfonso Espinosa Departamento de Sistemas Inform´ aticos y Computaci´ on Universitat Polit´ ecnica de Val` encia Dirigido por: Vicente Juan Botti Navarro Emilio Vivancos Rubio M´ aster en Inteligencia Artificial, Reconocimiento de Formas e Imagen Digital Junio 2012 II Agradecimientos Agradezco a mis directores Vicente Botti y Emilio Vivancos por orientarme y apoyarme para la realizaci´ on de este trabajo, y tambi´ en para mi preparaci´ on personal como investigadora. Agradezco tambi´ en a mis compa˜ neros de trabajo por su ayuda y apoyo incondicional. II ´ Indice general ´ Indice de figuras V 1. Introducci´ on 1 2. Estado del arte y motivaci´ on 5 2.1. Introducci´ on.................................... 5 2.2. Protocolos de interacci´ on............................. 5 2.2.1. Plataformas que los soportan . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2. Jade.................................... 6 2.2.3. Jadex ................................... 7 2.2.4. Opal.................................... 8 2.2.5. Magentix2 ................................ 9 2.3. An´ alisis comparativo de plataformas . . . . . . . . . . . . . . . . . . . . . . . 10 2.4. Motivaci´ onyobjetivos .............................. 11 2.5. Conclusiones ................................... 11 3. Soporte para las interacciones de agentes BDI 13 3.1. Introducci´ on.................................... 13 3.2. Herramientas de soporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.1. Plataforma de Sistema Multi-Agente: Magentix2 . . . . . . . . . . . . 13 3.2.2. Lenguaje de programaci´ on de agentes BDI: Jason . . . . . . . . . . . . 16 3.2.3. Integraci´ on de Jason en Magentix2 . . . . . . . . . . . . . . . . . . . . 19 3.3. Descripci´ on del dise˜ no para la incorporaci´ on de conversaciones en Jason . . . . 20 3.3.1. Directrices ................................ 20 3.3.2. Ideas b´ asicas ............................... 20 3.4. Entidad gestora de conversaciones . . . . . . . . . . . . . . . . . . . . . . . . 22 III ´ INDICE GENERAL 3.5. Creaci´ on de conversaciones en agentes Jason sobre Magentix2 . . . . . . . . . 24 3.6. Ejemplo de un agente Jason Conversacional . . . . . . . . . . . . . . . . . . . 25 3.6.1. Interacci´ on robot-mercado a trav´ es del protocolo Request de FIPA . . . 35 3.7. Conclusiones ................................... 40 4. Herramienta de modelado 41 4.1. Introducci´ on.................................... 41 4.2. Motivaci´ on .................................... 41 4.3. Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.4. Dise˜ no de la herramienta de modelado . . . . . . . . . . . . . . . . . . . . . . 44 4.4.1. Modelo de Negociaci´ on basado en interacciones . . . . . . . . . . . . 45 4.4.2. Descripci´ on del meta-modelo para la herramienta de modelado . . . . . 46 4.5. Implementaci´ on y generaci´ on de c´ odigo ..................... 49 4.6. Conclusiones ................................... 54 5. Aplicaci´ on a un caso de estudio: mWater 57 5.1. Introducci´ on.................................... 57 5.2. mWater ...................................... 57 5.2.1. Descripci´ on del Caso de Estudio . . . . . . . . . . . . . . . . . . . . . 57 5.2.2. Dise˜ norealizado ............................. 58 5.2.3. Modelo para mWater . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.2.4. Implementaci´ on.............................. 62 5.3. Conclusiones ................................... 63 6. Conclusiones y trabajo futuro 65 6.1. Conclusionesgenerales.............................. 65 6.2. Trabajofuturo................................... 67 Ap´ endices 68 A. C´ odigo 71 A.1. C´ odigo generado por la herramienta de modelado para el modelo ejemplo 4.4 . 71 A.2. C´ odigo para el agente simulador del entorno del ac´ apite 3.6 . . . . . . . . . . 76 A.3. Salida por consola para el ejemplo de ac´ apite3.6 ................ 78 Bibliograf´ ıa 83 IV ´ Indice de figuras 3.1. Protocolos de interacci´ on FIPA Contract Net. [19] . . . . . . . . . . . . . . . . 21 3.2. Pasos del protocolo Contract Net de FIPA para el rol iniciador.......... 22 3.3. Pasos del protocolo Request de FIPA para el rol iniciador. ........... 35 3.4. Pasos del protocolo Request de FIPA para el rol participante........... 36 4.1. Modelo de Negociaci´ on basado en interacciones propuesto. . . . . . . . . . . . 46 4.2. Ecore de la herramienta de modelado obtenido a trav´ es de EMF. . . . . . . . . 47 4.3. Paleta de componentes de la herramienta de modelado. . . . . . . . . . . . . . 50 4.4. Diagrama ejemplo realizado con la herramienta de modelado. . . . . . . . . . . 51 5.1. Modelo para la generaci´ on de c´ odigo para el prototipo mWater. . . . . . . . . . 61 5.2. Modelo para el ActionsFlow:createNTT que permite crear una nueva mesa de negociaci´ on..................................... 62 5.3. GUI para la interacci´ on humano-agente. El usuario participa en una subasta japonesa con otros agentes y/o humanos. . . . . . . . . . . . . . . . . . . . . . 64 V ´ INDICE DE FIGURAS VI Cap´ ıtulo 1 Introducci´ on El ´ area de los Sistemas Multi-agente es uno de los campos de investigaci´ on m´ as activos y prometedores hoy d´ ıa. Proporcionan adaptabilidad, escalabilidad, alta tolerancia a fallos, autonom´ ıa, versatilidad entre otras, siendo estas caracter´ ısticas muy apropiadas para un amplio espectro de aplicaciones. Los temas de investigaci´ on relacionados se centran en diversos aspectos, como es el caso de la definici´ on de est´ andares, metodolog´ ıas, lenguajes de programaci´ on, plataformas de comunicaci´ on, sem´ anticas etc. En particular el estudio de plataformas de comunicaci´ on y de aspectos relacionados con las interacciones entre agentes cobra vital importancia al considerar las necesidades y caracter´ ısticas de este tipo de sistemas. Un agente en un entorno multi-agente necesita comunicarse con otros para lograr sus objetivos. Aunque estas interacciones pudieran componerse de una secuencia indeterminada y desordenada de mensajes y acciones, el regularles mediante el uso de patrones, precedencias y restricciones, facilita la programaci´ on de los agentes. Las propuestas de lenguajes de comunicaci´ on m´ as utilizados son KQML (Knowledge Query and Manipulation Language) de DARPA [16] y ACL (Agent Communication Language) de FIPA [20]. Ambos establecen la estructura de los mensajes a intercambiar, se basan en la teor´ ıa de actos de habla [7] y parten de la existencia de una ontolog´ ıa com´ un entre los agentes. Este trabajo se ha basado en el segundo por el alto nivel de aceptaci´ on que presenta en la comunidad de programadores de agentes. Al emplear este lenguaje, los agentes intercambian mensajes cuya estructura est´ a conformada por un conjunto de par´ ametros como es el caso de: una performativa (en la que se indica el tipo de acto de comunicaci´ on que tendr´ a lugar con el mensaje), el receptor y remitente, el contenido a enviar, la ontolog´ ıa que se emplea etc. 1 2. ESTADO DEL ARTE Y MOTIVACI ´ ON creencia “rp filter se emplea para determinar qu´ e mensaje request debe activar la capacidad de protocolo. 2.2.4. Opal Opal [27] es una plataforma de agentes multi-nivel que brinda soporte para organizaciones de agentes por medio de un m´ odulo de gesti´ on de conversaciones. Se basa en la idea de concebir los agentes al m´ ınimo nivel de operaci´ on pero a´ un con las caracter´ ısticas necesarias para que se siga considerando agente para prop´ ositos de modelado y dise˜ no. De esta forma en Opal se define un agente como una entidad persistente que se implementa en un sistema multi-agente o tambi´ en un actor que juega uno o m´ as roles en una sociedad de agentes; y por otro lado tambi´ en se define el concepto de “Micro-agente” como un tipo particular de agente que representa el m´ ınimo y m´ as primitivo nivel de de instanciaci´ on de un agente. Estos micro-agentes emplean una forma de comunicaci´ on m´ as simple que los agentes de m´ as alto nivel como por ejemplo los definidos por FIPA y poseen una flexibilidad m´ as limitada. Se comportan de manera predecible y estrictamente definida y no ejecutan razonamiento en tiempo de ejecuci´ on. Los agentes por otra parte pueden estar compuestos por cualquier n´ umero de otros agentes o micro-agentes y los micro-agentes no primitivos se componen solamente de micro-agentes. Se plantea que la ventaja clave de esta arquitectura es que para los sistemas de menor escala los micro-agentes superan radicalmente en rendimiento a los agentes de grano m´ as grueso en tiempo de ejecuci´ on. Por otra parte en Opal existen los roles de micro-agente representando agentes FIPA que puede contener una variedad de roles de sub-agente. Un agente FIPA en Opal emplea un rol micro-agente como controlador de las conversaciones en las que el agente est´ a involucrado. Este controlador requiere a su vez que alg´ un micro-agente exista para jugar el rol de distribuidor de mensajes. Otro agente FIPA tambi´ en puede requerir el micro-agente con el rol BeliefDesire-Intention para permitirle que se pueda desarrollar usando el modelo BDI. Relativo a los protocolos de interacci´ on, en Opal se implementan numerosos protocolos de interacci´ on FIPA. Para controlar la expedici´ on y cambio de los estados de las conversaciones dadas las propiedades de los mensajes recibidos y enviados, existe una entidad denominada Controlador de interacci´ on. Esta entidad es responsable de iniciar, monitorizar y controlar las instanciaciones de los roles existentes para cada uno de los protocolos FIPA (por ejemplo: FIPARequestTracker o FIPAQueryTracker). Estos roles son especializaciones a su vez de un rol abstracto b´ asico que es “Interaction traker”. Otro componente especial de la infraestructura de Opal es el Gestor de conversaciones. Este gestor est´ a a cargo de aspectos como el registro 8 2.2 Protocolos de interacci´ on de protocolos de interacci´ on individuales y sus violaciones, registrando su contexto; se hace cargo adem´ as de los tiempos de espera y respuestas tard´ ıas y de la localizaci´ on de recursos para tareas m´ as importantes etc. En Opal las conversaciones se descomponen en tres capas: protocolo (plantilla de secuencia esperada de actos comunicativos organizados en roles), conversaci´ on (instancia particular de uno o varios protocolos) y pol´ ıtica (reglas y especificaciones de interacci´ on que gu´ ıan un camino o trayectoria en el espacio de una conversaci´ on). De esta manera cada protocolo define un espacio de posibles secuencias de actos comunicativos y cada conversaci´ on sigue una trayectoria en este espacio donde la pol´ ıtica gu´ ıa una conversaci´ on particular. 2.2.5. Magentix2 Magentix2 [2, 4] es una plataforma concebida para sistemas multi-agente abiertos. Adem´ as de brindar soporte para cuestiones b´ asicas necesarias en un sistema multi-agente como la ejecuci´ on del ciclo de vida de un agente y la comunicaci´ on, tambi´ en ofrece servicios y herramientas que permiten una gesti´ on optimizada y segura del sistema. Por ejemplo brinda soporte para interacciones flexibles a trav´ es de protocolos y conversaciones entre agentes y organizaciones de agentes. Tambi´ en ofrece un servicio de trazas que permite a los agentes publicar o suscribirse a determinados eventos; un API de argumentaci´ on que permite a los agentes establecer di´ alogos de argumentaci´ on para llegara a acuerdos; y un modelo de seguridad que incorpora mecanismos de seguridad a bajo nivel y medidas de confianza. En Magentix2 los usuarios pueden gestionar aspectos relativos a organizaciones de manera sencilla a trav´ es de la plataforma THOMAS. Por ´ ultimo esta plataforma ofrece una integraci´ on con el lenguaje de programaci´ on de agentes Jason [9], lenguaje de programaci´ on l´ ogica de alto nivel basado en el modelo BDI de agentes. Como se ha mencionado Magentix2 ofrece la posibilidad del empleo de protocolos de interacci´ on FIPA en las interacciones de los agentes. Esto se logra gracias a las F´ abrica de Conversaciones [18], que es la herramienta encargada de la gesti´ on de las conversaciones de agentes en la plataforma. Una f´ abrica de conversaciones permite mantener una interacci´ on completa entre dos o m´ as agentes de donde se tiene un iniciador (el que inicia la conversaci´ on) y uno o m´ as participantes (el resto de los agentes). La plataforma posee plantillas de protocolos FIPA tanto para el rol de iniciador como el de participante, que pueden ser personalizadas en los pasos del protocolo donde sea necesario a trav´ es de m´ etodos “callback”. Las dos estructuras principales que soportan las conversaciones como parte de la f´ abrica de conversaciones son CProcessor y 9 2. ESTADO DEL ARTE Y MOTIVACI ´ ON CFactory. La primera es la encargada de gestionar los mensajes enviados y recibidos en cada paso de la conversaci´ on realizando las acciones pertinentes para determinar el pr´ oximo paso en el protocolo; la segunda crea las conversaciones y los CProcessor que corresponden a un protocolo espec´ ıfico. 2.3. An´ alisis comparativo de plataformas Tanto Jadex como Jade ofrecen clases Java para implementar los protocolos de interacci´ on de FIPA, de manera que no se ofrece la posibilidad de emplear un lenguaje de programaci´ on de alto nivel espec´ ıfico para agentes directamente integrado con las herramientas para la gesti´ on de las conversaciones. Esto no limita que estas plataformas sean seleccionadas para implementar agentes que requieran interactuar siguiendo protocolos de interacci´ on, sin embargo, es m´ as conveniente contar con un lenguaje de programaci´ on de agentes de alto nivel basado en la l´ ogica cuando se requieren estructuras de razonamiento complejas que responden a la naturaleza inherente a los agentes de autonom´ ıa y proactividad. Por otra parte tanto en Jadex como en Jade es necesario cumplir con la estructura r´ ıgida del protocolo en todo momento, lo que implica una falta de flexibilidad a la hora de entablar conversaciones. La plataforma Opal sin embargo, parece cubrir estos aspectos ya que con el empleo de micro-agentes se pueden implementar agentes de “grano grueso” que pueden seguir el modelo BDI, entablar conversaciones que responden a los est´ andares de protocolos de interacci´ on de FIPA y gracias a la capa de “pol´ ıtica” de su arquitectura las conversaciones pueden ser m´ as flexibles y abiertas. No obstante el proyecto parece no haber alcanzado la madurez necesaria para ofrecer estas facilidades de manera p´ ublica en una herramienta que pueda estar disponible para su utilizaci´ on y prueba. Por ´ ultimo Magentix2 ofrece una serie de posibilidades apropiadas para los objetivos de nuestro trabajo, permitiendo el empleo de protocolos de interacci´ on que siguen los est´ andares de FIPA ofreciendo, al mismo tiempo, mecanismos para que puedan ser modificados din´ amicamente sin necesidad de reiniciar el sistema [18]. Otra de sus ventajas, como se explicar´ a en el Cap´ ıtulo 3, es que durante las conversaciones se almacena y a˜ nade la informaci´ on requerida a los mensajes que ser´ an enviados (Ej: iniciador, participantes, el estado de la conversaci´ on, etc.) de manera que no es necesario que el programador incluya esta informaci´ on de forma expl´ ıcita. Magentix2 permite adem´ as la programaci´ on de agentes en el lenguaje de alto nivel Jason [9], muy aceptado en la comunidad de programaci´ on de agentes por su flexibilidad y robustez, y 10 2.4 Motivaci´ on y objetivos el empleo de mecanismos para conseguir una gesti´ on optimizada y segura de sistemas multiagente abiertos. Dadas estas condiciones, se ha seleccionado Magentix2 como la plataforma m´ as apropiada para elaborar nuestra propuesta. 2.4. Motivaci´ on y objetivos Dada la complejidad de todos los conceptos que pueden estar asociados a la interacci´ on de agentes a trav´ es de conversaciones y protocolos de interacci´ on, el objetivo principal de esta propuesta es ofrecer un mecanismo que permita al desarrollador realizar una especificaci´ on m´ as simple y clara de los agentes. De esta forma se le alivia de los aspectos relacionados con subprocesos y sincronizaci´ on subyacentes, as´ ı como de la preparaci´ on de informaci´ on que no es del dominio o la gesti´ on de tiempos de espera, entre otros. Estos aspectos ser´ ıan gestionados de manera natural por la infraestructura del agente en lugar de hacerlo el programador. As´ ı mismo se pretende, por consiguiente, mejorar el mecanismo de paso de mensajes poniendo atenci´ on al desempe˜ no y la escalabilidad del sistema. Para conseguir este prop´ osito se proponen los siguientes objetivos espec´ ıficos: Permitir en un lenguaje de alto nivel de programaci´ on de agentes, como es el caso de Jason, el empleo del los protocolos de interacci´ on est´ andar de FIPA a trav´ es de la automatizaci´ on, en la mayor medida posible de este proceso. Estudiar y adaptar la plataforma Magentix2, con soporte para protocolos de interacci´ on, para ofrecer la funcionalidad anterior. Ofrecer un mecanismo de representaci´ on que permita establecer la interacciones que tendr´ an lugar en un sistema regulado y la relaci´ on entre ellas. Permitir la generaci´ on de c´ odigo fuente a partir de dicha representaci´ on. Aplicar las estructuras dise˜ nadas e implementadas a un caso de estudio. 2.5. Conclusiones Existe una variedad de propuestas que intentan abordar el tema de las interacciones de agentes desde distintas perspectivas. En el presente cap´ ıtulo se ha hecho una selecci´ on de las m´ as representativas y se ha estudiado un conjunto de plataformas que brindan soporte para 11 2. ESTADO DEL ARTE Y MOTIVACI ´ ON protocolos de interacci´ on, analiz´ andolas tanto de manera global como desde el punto de vista particular de las interacciones. Se han analizado las facilidades que ofrecen y cuan adecuadas son para el prop´ osito del presente trabajo y se ha justificado la selecci´ on de Magentix2 como plataforma m´ as adecuada para desarrollar la propuesta. 12 Cap´ ıtulo 3 Soporte para las interacciones de agentes BDI 3.1. Introducci´ on La plataforma Magentix2, seleccionada para implementar la propuesta, ofrece mecanismos para que los agentes puedan entablar conversaciones m´ ultiples y simult´ aneas. Por otra parte el lenguaje Jason basado en el modelo BDI de agentes permite emplear estructuras de alto nivel a trav´ es de la programaci´ on l´ ogica que facilitan la implementaci´ on de agentes con altas capacidades de razonamiento. En el presente cap´ ıtulo se introduce una propuesta para integrar ambas tecnolog´ ıas ofreciendo la posibilidad de crear agentes BDI conversacionales a nivel de la plataforma donde viven. Se detallan los aspectos fundamentales tanto de las tecnolog´ ıas de soporte como de la propuesta y se ilustra la manera de hacer uso de ella a trav´ es de un ejemplo donde dos agentes mantienen una conversaci´ on haciendo uso del protocolo Request de FIPA. 3.2. Herramientas de soporte 3.2.1. Plataforma de Sistema Multi-Agente: Magentix2 Existen numerosas plataformas y herramientas que permiten especificar agentes comunicativos. Como ha sido mencionado anteriormente se ha seleccionado Magentix2 [4] para la presente propuesta por ser una plataforma que sigue los est´ andares FIPA con capacidad para ofrecer un conjunto de mecanismos ´ utiles para la comunicaci´ on entre agentes as´ ı como herramientas para permitir la programaci´ on de agentes en un lenguaje de alto nivel basado en el 13 3. SOPORTE PARA LAS INTERACCIONES DE AGENTES BDI modelo BDI, entre otras facilidades. Magentix2, emplea el middleware orientado a mensajes AMQP (Advanced Message Queuing Protocol) 1para la comunicaci´ on. Este est´ andar facilita la interoperabilidad entre entidades heterog´ eneas, lo que convierte a la plataforma en un sistema abierto donde agentes heterog´ eneos pueden interactuar a trav´ es de mensajes FIPA-ACL. En espec´ ıfico Magentix2 emplea la implementaci´ on Apache Qpid 2de AMQP, de manera que los agentes emplean las APIs del cliente de Qpid para conectarse a un broker Qpid y comunicarse con otros agentes en cualquier punto de internet. Con Magentix2 se ofrece una plataforma de soporte para la gesti´ on de interacciones complejas entre agentes que pueden cambiar din´ amicamente, lo que permite establecer conversaciones flexibles y abiertas. Para facilitar el empleo de conversaciones, como ha sido mencionado en el cap´ ıtulo anterior, la plataforma posee dos estructuras fundamentales encargadas de gestionarlas: el procesador de conversaciones CProcessor y la f´ abrica de conversaciones CFactory. Cada ejecuci´ on de un CProcessor se realiza en un hilo independiente. Tanto en el caso del rol iniciador como del participante,´ este decide en cualquier punto de la conversaci´ on cu´ al es el pr´ oximo paso de acuerdo al protocolo de interacci´ on que se est´ a siguiendo. Adem´ as realiza las acciones y gestiona los mensajes enviados y recibidos en cada paso de la conversaci´ on. Los estados que representan las acciones que pueden ser realizadas pueden ser de los tipos [18]: Begin: Para iniciar una conversaci´ on. Siempre est´ a presente. Final: Para finalizar una conversaci´ on. Siempre est´ a presente. Action: Para representar cualquier acci´ on no relacionada con alg´ un acto de habla. Send: Para enviar un mensaje. Wait: En este tipo de estado la conversaci´ on se detiene hasta la recepci´ on de un nuevo mensaje (lo que implica que el rol pase a un estado Receive siguiente) o hasta que haya transcurrido un tiempo de espera especificado previamente. Receive: Para recibir un mensaje. Debe estar precedido de un estado Wait. Initiate: Para iniciar una nueva subconversaci´ on. 1AMQP: http://www.amqp.org/ 2Apache Qpid: http://qpid.apache.org/ 14 3.2 Herramientas de soporte Participate: Es un tipo especial del estado Receive. El rol inicia una nueva subconversaci´ on al recibir el mensaje apropiado. Adem´ as de estos estados existen otros tipos de estados para excepciones a los que se conecta todo estado normal de manera impl´ ıcita. Estos son: Cancel (cuando se recibe un mensaje para finalizar la conversaci´ on de forma inesperada), Not Accepted Message (cuando desde el estado Wait se recibe un mensaje y no existe estado Receive apropiado para su procesamiento) ySending Errors (trata la excepci´ on si se produce un error al enviar un mensaje en el estado Send). En cada uno de estos estados el programador puede implementar un m´ etodo con las acciones que se ejecutar´ an por el CProcessor cuando la conversaci´ on alcance ese estado. Estos m´ etodos tienen par´ ametros y devuelven distintos valores en dependencia del tipo de estado. Las conversaciones asociadas al CProcessor pueden sufrir modificaciones en tiempo de ejecuci´ on que pueden afectar a los estados o las transiciones entre estos. Por otra parte las CFactories tienen la finalidad de comenzar las conversaciones. Cuando comienza una conversaci´ on la CFactory inicia un CProcessor encargado de ejecutar la conversaci´ on. Existe una CFactory para el rol iniciador y una para el rol participante. En el primer caso la conversaci´ on comienza sin necesidad de eventos o est´ ımulos externos; en el segundo caso en cambio la conversaci´ on se inicia cuando el agente recibe el mensaje apropiado. Cada conversaci´ on posee un identificador ´ unico que es asignado por el CProcessor si el agente es iniciador. En el caso del participante el identificador estar´ a contenido en el primer mensaje recibido de la conversaci´ on. Este mensaje puede implicar iniciar una conversaci´ on si no existe entre los identificadores de las conversaciones a las que el participante se ha unido. En caso contrario se procesa el mensaje de acuerdo a la conversaci´ on a la que pertenece. Este proceso es realizado por el CProcessor correspondiente. Para el caso en el que ninguna CFactory pueda tratar el mensaje recibido, ´ este es asignado a una CFactory por defecto (DefaultFactory) la cual est´ a a cargo de tratar los mensajes que no pueden ser tratados por ninguna otra f´ abrica. Las conversaciones, adem´ as, se pueden anidar, existiendo para ello dos tipos de subprotocolo: s´ ıncrono (la conversaci´ on se detiene hasta que la hija finalice) y as´ ıncrono (las conversaciones madre e hija siguen su ejecuci´ on de manera individual). En el primer caso a la nueva conversaci´ on le es asignado un identificador igual al de la que la cre´ o; en el segundo caso se asigna un nuevo identificador [17]. 15 3. SOPORTE PARA LAS INTERACCIONES DE AGENTES BDI 3.2.2. Lenguaje de programaci´ on de agentes BDI: Jason A trav´ es de Magentix2 es posible dise˜ nar agentes con una alta capacidad de razonamiento que siguen el modelo BDI de agentes a trav´ es del uso de Jason[9] como lenguaje de programaci´ on de alto nivel. Jason es un int´ erprete basado en Java, para una versi´ on extendida de AgentSpeak(L) [28], lenguaje orientado a agentes que contempla los aspectos m´ as importantes de los sistemas de planificaci´ on reactiva. AgentSpeak(L) es uno de los mejores lenguajes basados en la arquitectura BDI. Es un lenguaje abstracto basado en la l´ ogica que permite implementar agentes como sistemas de planificaci´ on reactiva. De manera que se ejecutan continuamente reaccionando a eventos y ejecutando planes para esos eventos. La naturaleza proactiva se logra a trav´ es de la noci´ on de los objetivos, que no son m´ as que estados deseados del mundo. A continuaci´ on se explicar´ an estos elementos en m´ as detalle. AgentSpeak(L) permite definir los agentes en t´ erminos de tres elementos principales: creencias (Beliefs), objetivos (Goals) y planes (Plans). Las creencias representan la visi´ on actual del agente del estado del mundo en el que est´ a situado. Estas cambian de manera contin´ ua durante la ejecuci´ on del agente y esto puede estar provocado por varios factores. En primer lugar, las creencias pueden cambiar despu´ es del que el agente haya “percibido” en el entorno (el mundo observable para ´ el) alg´ un hecho nuevo o distinto a los que ya ten´ ıa registrados; cuando otro agente le ha enviado alguna informaci´ on a trav´ es de un mensaje; o cuando ´ el expl´ ıcitamente modifica su base de creencias como consecuencia de un razonamiento previo a trav´ es de “notas mentales”. Las creencias se representan, en su forma m´ as simple, a trav´ es de un conjunto de literales que expresan una propiedad de un objeto o individuo. Por ejemplo: tall(john) que expresa la propiedad tall del individuo john. Otro elemento importante que puede estar incluido en la base de creencias son las reglas. Estas permiten concluir nueva informaci´ on basadas en otra ya conocida como cierta. Poseen una parte izquierda y una parte derecha o cuerpo separadas por el operador “:-”. En la parte izquierda solo puede haber un literal que es la conclusi´ on a ser obtenida si la parte derecha se satisface. En la parte derecha en cambio puede aparecer el mismo tipo de estructuras que aparecen en el contexto de un plan. Por ejemplo dada la regla: fullname(Name,SurN,FullN) :- .concat(Name,‘‘ ’’,SurN,FullN). Esta permite, a trav´ es de la acci´ on interna .concat() (se describen m´ as adelante), y dados un nombre ( Name ) y un apellido ( SurN ), obtener la concatenaci´ on de ambos con un espacio 16 3.2 Herramientas de soporte en blanco en medio. El resultado es almacenado en la variable FullN 1. Los objetivos en cambio expresan la situaci´ on del mundo a la que el agente desea llegar. Existen dos tipos de objetivos que son: Achievement Goals: Expresan una situaci´ on a alcanzar y que el agente considerar´ a verdadera si lo consigue. Se denotan con el operador !. Por ejemplo si queremos expresar el objetivo en el que un switch est´ e en estado encendido (on) se podr´ ıa expresar de la forma !state(switch,on) . Test goals: Construcciones para extraer informaci´ on de la base de creencias, o sea, para verificar si el agente cree un literal o conjunci´ on de literales. Se denotan con el operador ?. De manera que, por ejemplo, si se quisiera saber lo que el agente cree con respecto al estado del switch del ejemplo anterior, se pudiera expresar como: ?state(switch,S) , donde ‘ S’ se instanciar´ ıa con el estado on ´ ooff. Finalmente los planes, como se puede pensar intuitivamente, permiten alcanzar un objetivo a trav´ es de una secuencia de acciones. Esto ocurre a partir de eventos que se generan como consecuencia de la adici´ on o eliminaci´ on de estos objetivos. Al generarse el evento, una secuencia de acciones que componen el plan es ejecutada y, si no ocurren fallos, el objetivo se alcanzar´ ıa. B´ asicamente los planes se componen de tres elementos: evento disparador, contexto y cuerpo y se denota de la forma: evento disparador : contexto <- cuerpo. El evento disparador se puede producir por causas asociadas a cambios en las creencias o cambios en los objetivos. Estas producen cambios en el estado mental del agente y son las siguientes: adici´ on ( +!g ) o eliminaci´ on ( -!g ) de un achievement goal ‘!g ’, adici´ on ( +b ) o eliminaci´ on ( -b ) de una creencia ‘ b’ o adici´ on ( +?g ) o eliminaci´ on ( -?g ) de un test goal ‘?g ’. Una vez se ha generado un evento, el plan correspondiente pasa a ser “relevante”. El contexto es el conjunto de condiciones que deben ser ciertas para que, dado un evento, el plan pueda pasar a ser ejecutado. Permite chequear la situaci´ on actual y determinar, entre las posibles alternativas, si es posible que un plan particular tenga ´ exito dada la ´ ultima informaci´ on que el agente posea. Este conjunto de condiciones debe existir o ser una consecuencia l´ ogica de 1En Jason los t´ erminos en may´ usculas son variables. 17 3. SOPORTE PARA LAS INTERACCIONES DE AGENTES BDI ser extendida para representar una conversaci´ on de un protocolo determinado. De esta forma tambi´ en existe una clase hija de Conversation para cada conversaci´ on cuyas instancias ser´ an visibles tanto desde las AI como del CProcessor correspondiente en la plataforma. Otro aspecto importante a destacar es que la clase Conversation contiene tambi´ en un sem´ aforo que permitir´ a al GC pausar la conversaci´ on cuando se requiera un razonamiento por parte del agente o a la AI continuarla cuando el agente la haya invocado proporcionando la informaci´ on necesaria. La manera en la que el agente es notificado acerca del paso sobre el que debe razonar y la informaci´ on asociada para que lo haga es proporcionada por el GC accediendo a la instancia de la clase Conversation correspondiente y a˜ nadiendo esta informaci´ on a la base de creencias del agente. Al GC tambi´ en lo conforman clases personalizadas para: i) especificar la arquitectura del agente Jason, ii) el agente Jason en la plataforma, iii) CProcessor de las conversaciones y iv) CFactory de las conversaciones. Todas ellas extienden de las clases ofrecidas por la plataforma para gestionar las conversaciones agregando los elementos necesarios para permitir el uso de la f´ abrica de conversaciones desde los agentes Jason. En el ac´ apite 3.5 se ofrece un resumen de los pasos necesarios para implementar protocolos de interacci´ on en un agente Jason sobre Magentix2. 3.5. Creaci´ on de conversaciones en agentes Jason sobre Magentix2 De manera general para implementar una conversaci´ on sobre cualquier protocolo en un agente Jason que se ejecuta en la plataforma Magentix2, ya sea como iniciador o como participante es necesario tener en cuenta los siguientes pasos [6]: 1. Asegurarse de que el agente tenga acceso a, o est´ e en su base de creencias, la informaci´ on requerida para iniciar la conversaci´ on. Por ejemplo, en el caso del iniciador de un protocolo Contract Net es necesario conocer el tiempo de espera para las respuestas de la otra parte y el nombre de los participantes con los que desea interactuar. 2. Implementar un plan que contenga la primera llamada a la AI correspondiente al protocolo que se va a emplear (en el caso del rol iniciador). Para el caso del participante, este debe tener un plan para unirse a la conversaci´ on cuando reciba la solicitud del iniciador. 3. Implementar un plan para cada paso del protocolo donde es necesario realizar un razonamiento o tomar una decisi´ on: para ello se debe contar con las estructuras predefinidas en 24 3.6 Ejemplo de un agente Jason Conversacional forma de creencias que son a˜ nadidas al agente cuando se necesita este razonamiento, y que act´ uan como eventos disparadores para la ejecuci´ on de los planes correspondientes. La acci´ on final para cada uno de estos planes debe ser siempre una llamada a la AI del protocolo, para el rol correspondiente en la conversaci´ on, con los par´ ametros apropiados. Esto permite que la conversaci´ on contin´ ue al pr´ oximo paso1. La AI tiene la estructura: .ia <protocolo> Initiator(...) ´ o.ia <protocolo> Participant(...) en dependencia del rol y del protocolo. El n´ umero y tipo de los par´ ametros var´ ıa, pero por normal general, el primer par´ ametro siempre debe ser un texto que identifica el paso de la conversaci´ on y el ´ ultimo un valor de cadena, literal o num´ erico que representa el identificador de la conversaci´ on. 4. Implementar, de manera opcional, un plan para cada paso de razonamiento adicional; generalmente, este paso siempre resulta ser el paso final. De manera que, por ejemplo, si se realiza alguna gesti´ on con los identificadores de las conversaciones, o es necesario realizar alg´ un procesamiento al finalizar la conversaci´ on, este debe implementarse en este paso. 3.6. Ejemplo de un agente Jason Conversacional Para ilustrar c´ omo se usan las conversaciones desde un agente Jason se tomar´ a como referencia una adaptaci´ on al ejemplo del robot dispensador de cerveza propuesto en [9], que viene integrado en la distribuci´ on del paquete Jason. El ejemplo se basa en lo siguiente: “Un robot dom´ estico tiene como objetivo servir cerveza a su due˜ no. Su misi´ on es recibir solicitudes de su due˜ no, ir a la nevera, tomar una cerveza y llev´ arsela a su due˜ no. No obstante el robot debe preocuparse por el stock de cerveza (y eventualmente ordenar m´ as cerveza al servicio de entrega a casa del mercado) y por algunas reglas incorporadas al robot por el departamento de salud (en este caso la regla define el l´ ımite diario del consumo de cerveza”). En nuestro ejemplo existen b´ asicamente tres agentes: el robot, el due˜ no y el mercado. Existe adem´ as un agente adicional que act´ ua como “entorno” y realiza las acciones que se realizar´ ıan 1Actualmente el GC posee estructuras definidas para ser empleado por agentes Jason para los protocolos de FIPA: Contract Net, Query-If, Query-Ref, Request, Subscribe, Recruiting y Japanese Auction 25 3. SOPORTE PARA LAS INTERACCIONES DE AGENTES BDI en el entorno en el ejemplo original 1. Las principales acciones que pueden realizar los agentes son las siguientes: robot •at(robot,fridge): Para dirigirse a la nevera. •at(robot,owner): Para dirigirse al due˜ no. •open(fridge): Para abrir la nevera. •get(beer): Para tomar la cerveza. •close(fridge): Para cerrar la nevera. •hand in(beer): Para entregar la cerveza. •order(beer): Para ordenar m´ as cerveza al mercado. due˜ no •get(beer): Para pedir al robot m´ as cerveza. •sip(beer): Para beber un sorbo de cerveza. mercado •deliver(beer): Para entregar N unidades de cerveza. •delivered(beer,N,OrderId): Para informar de la entrega realizada. Tanto la acci´ on at(robot,fridge) como at(robot,owner) se han simplificado de manera que solo implican cambiar la creencia del robot sobre la posici´ on donde se encuentra. La solicitud de m´ as cerveza al mercado por parte del robot se ha adaptado para nuestro ejemplo como una conversaci´ on bajo el protocolo Request de FIPA. De manera que se explicar´ a c´ omo funciona el GC en el contexto del ejemplo. Se partir´ a de que el objetivo inicial del due˜ no es obtener una cerveza. Se cuenta con un stock de dos cervezas en la nevera y cada vez que ´ este se termine se solicitar´ a al mercado 5 unidades m´ as. Cuando el robot recibe la solicitud del due˜ no ´ este realiza las acciones pertinentes para hacerle llegar la cerveza siempre y cuando no haya alcanzado el l´ ımite permitido de 1Jason ofrece la posibilidad de interactuar con un entorno a trav´ es de clases Java predefinidas para ello. En el ejemplo original este recurso se emplea para mostrar el estado de la ejecuci´ on de manera visual a trav´ es de una interfaz gr´ afica que se actualiza constantemente. En nuestro ejemplo se han representado estas funciones a trav´ es de un agente para mayor simplicidad. 26 3.6 Ejemplo de un agente Jason Conversacional cervezas consumidas establecido por el departamento de salud. El due˜ no bebe la cerveza (siempre realizar´ a 10 sorbos por cada una) y al terminarse volver´ a a solicitar m´ as cerveza al robot. Cuando el mercado reciba la solicitud por parte del robot para m´ as cerveza, ´ este la procesar´ a y realizar´ a la entrega. A continuaci´ on se muestra el c´ odigo para los agentes: due˜ no, robot y mercado. En el ap´ endice A.2 se muestra el c´ odigo para el agente que simula el entorno y se explica a trav´ es de comentarios. Agente due˜ no 1/*Objetivos iniciales */ 2 3!get(beer). // objetivo inicial: obtener cerveza 4 5+!get(beer) : true 6<- .send(robot, achieve, has(owner,beer)). 7 8+has(owner,beer) : true 9<- !drink(beer). 10 -has(owner,beer) : true 11 <- !get(beer). 12 13 // mientras tenga cerveza, bebo 14 +!drink(beer) : has(owner,beer) 15 <- !sip(beer); 16 .wait(300); 17 !drink(beer). 18 +!drink(beer) : not has(owner,beer) 19 <- true. 20 21 +msg(M)[source(Ag)] : true 22 <- .print("Message from ",Ag,": ",M); 23 -msg(M). 24 25 /*----------------- acciones con el entorno -------------------*/ 26 27 +!sip(beer)[source(self)] 28 <- .send(environmentAg,achieve,sip(beer)). El agente due˜ no tiene un objetivo inicial que es obtener cerveza (l´ ınea 3). De manera que cuando comienza la ejecuci´ on se genera el evento +!get(beer) . Este evento hace que se 27 3. SOPORTE PARA LAS INTERACCIONES DE AGENTES BDI dispare el plan de las l´ ıneas 5-6. En este caso el agente solicitar´ a al robot mediante un mensaje con la performativa achieve que consiga el objetivo has(owner,beer) . Una vez el robot ha logrado esto una percepci´ on has(owner,beer) le es enviada al agente due˜ no por el entorno lo que disparar´ a el plan de la l´ ınea 8-9. Este plan crea a su vez el objetivo !drink(beer) que conlleva a que el due˜ no comience a beber a trav´ es del plan recursivo de la l´ ınea 14-17. El ciclo termina cuando la creencia has(owner,beer) ya no est´ e, y esta se elimina cuando el agente entorno detecta que se terminaron los sorbos y se lo notifica al due˜ no (referirse a ap´ endice A.2). El plan que se ejecutar´ ıa en tal caso es el de las l´ ıneas 18-19, en cuyo contexto se verifica que no exista dicha creencia. Al mismo tiempo, la eliminaci´ on de la creencia has(owner,beer) genera un evento que dispara el plan de las l´ ıneas 10-11, el cual permite que el objetivo get(beer) para beber cerveza vuelva a ser a˜ nadido y comience el ciclo desde el inicio. El plan de las l´ ıneas 21-23 imprime un mensaje en pantalla cuando alg´ un agente Ag le env´ ıa un mensaje con el formato msg(M) 1. Al final del plan se elimina esta creencia ya que en otro caso no se generar´ ıa el evento +msg(M) si un mensaje id´ entico llegase, porque la creencia ya estar´ ıa en la base de creencias. El plan de las l´ ıneas 27-28 permite al agente due˜ no notificar al entorno a trav´ es de un mensaje, que un sorbo de cerveza ha sido bebido. Agente robot 1/*Objetivos y reglas iniciales */ 2 3// inicialmente creo que hay cerveza en la nevera 4available(beer,fridge). 5 6// inicialmente mi posici´ on es en la nevera 7at(robot,fridge). 8 9// mi due˜ no no debe consumir m´ as de 10 cervezas al d´ ıa 10 limit(beer,10). 11 12 too_much(B) :- 13 .date(YY,MM,DD) & 14 .count(consumed(YY,MM,DD,_,_,_,B),QtdB) & 15 limit(B,Limit) & 16 QtdB >= Limit. 1El t´ ermino source(Agente) es una anotaci´ on del plan y permite saber qui´ en ha generado la adici´ on de este objetivo. Cuando el valor de Agente es “self” esto indica que el objetivo ha sido a˜ nadido por el propio agente. Para m´ as informaci´ on sobre anotaciones referirse a [9]. 28 3.6 Ejemplo de un agente Jason Conversacional 17 18 19 /*Planes */ 20 21 +!has(owner,beer) 22 : available(beer,fridge)& not too_much(beer) 23 <- !at(robot,fridge); 24 !open(fridge); 25 !get(beer); 26 !close(fridge); 27 !at(robot,owner); 28 !hand_in(beer); 29 .date(YY,MM,DD); .time(HH,NN,SS); 30 +consumed(YY,MM,DD,HH,NN,SS,beer); 31 .count(consumed(YY,MM,DD,_,_,_,B),QtdB); 32 .print("Consumed: ",QtdB). 33 34 /*============== solicitud de cerveza al meracdo ===============*/ 35 /*conversation plan: START ------------------------------- */ 36 +!has(owner,beer) 37 : not available(beer,fridge) 38 <- .time(H,M,S); 39 .concat("",H,".",M,".",S,".deliverBeer",ConvID); 40 +conversationID(robot,frp,ConvID); 41 .send(supermarket,achieve,join(ConvID,Protocol)); 42 .print(" *Starting and making proposal to supermarket *"); 43 TO = 2000; 44 .ia_fipa_request_Initiator("start", supermarket , TO, 45 "Fipa request conversation started",ConvID); 46 .ia_fipa_request_Initiator("request",beer,supermarket, 47 data(count(beer,5)), ConvID). 48 /*--------------------------------------------------------- */ 49 50 /*conversation plan: TASK DONE --------------------------- */ 51 +taskdonesuccessfully(P,Result,ConvID) 52 <- .print(" *The task ",ConvID, 53 " was done successfully by agent ",P,". Result: ", 54 Result," *"); 55 +available(beer,fridge); 56 !has(owner,beer); 57 .ia_fipa_request_Initiator("taskdone",ConvID). 29 3. SOPORTE PARA LAS INTERACCIONES DE AGENTES BDI 58 /*--------------------------------------------------------- */ 59 60 /*conversation plan: END --------------------------------- */ 61 +conversationended(ConvID, Result) 62 : conversationID(robot,frp,ConvID) 63 <- -conversationID(robot,frp,ConvID). 64 /*----------------------------------------------------------*/ 65 /*=============================================================*/ 66 67 +!has(owner,beer) 68 : too_much(beer) & limit(beer,L) 69 <- .concat("The Department of Health does not allow me to give you more than ", L, " beers a day! I am very sorry about that! ",M); 70 .send(owner,tell,msg(M)). 71 72 -!has(_,_) 73 :true 74 <- .current_intention(I); 75 .print("Failed to achieve goal ’!has(_,_)’. Current intention is: ",I). 76 77 +!at(robot,P) : at(robot,P) <- true. 78 +!at(robot,P) : not at(robot,P) 79 <- .print("Moving to ",P); 80 !move_towards(P). 81 82 // cuando la nevera est´ a abierta se percibe el stock 83 // y se actualiza la creencia ’available’ 84 +stock(beer,0) 85 : available(beer,fridge) 86 <- -available(beer,fridge); 87 .print("The beer in stock has fnished."); 88 .abolish(stock(beer,_)). 89 +stock(beer,N) 90 : N > 0 & not available(beer,fridge) 91 <- -+available(beer,fridge) ; 92 .abolish(stock(beer,_)). 93 94 +!move_towards(P) 95 <- -+at(robot,P). 30 3.6 Ejemplo de un agente Jason Conversacional 96 97 /*---------------- Environment interactions ----------------------*/ 98 +!open(fridge) 99 <- .send(environmentAg,achieve,open(fridge)). 100 101 +!get(beer) 102 <- .send(environmentAg,achieve,get(beer)). 103 104 +!close(fridge) 105 <- .send(environmentAg,achieve,close(fridge)). 106 107 +!hand_in(beer) 108 <- .send(environmentAg,achieve,hand_in(beer)). El robot es el principal agente del ejemplo. Manteniendo la creencia available(beer,fridge) puede saber que a´ un hay cerveza disponible y cuando ya no est´ e deber´ a solicitar m´ as al mercado. Inicialmente cree que hay cerveza (l´ ınea 4) y tambi´ en cree que est´ a posicionado en la nevera (l´ ınea 7). Adem´ as tiene especificado un l´ ımite de cervezas que el due˜ no puede beber indicado por el departamento de salud que es 10 cervezas en este caso (l´ ınea 10). Por otra parte la regla de las l´ ıneas 12-16 le permite al robot saber si la cantidad consumida en el mismo d´ ıa (creencias con el formato consumed(A˜ no,Mes,D´ ıa,Hora,Minuto,Segundo,beer) ) sobrepasa el l´ ımite permitido. En la regla se emplea la AI .date para conocer la fecha actual y .count para saber el n´ umero de creencias con un formato determinado. El t´ ermino ‘ ’ permite especificar que en su lugar se espera cualquier valor, y en la variable QtdB se almacenar´ ıa esta cantidad consumida. La regla se cumplir´ ıa si QtdB es mayor que 10 en este caso. La principal tarea del robot, que es alcanzarle cerveza al due˜ no, se lleva a cabo cuando el objetivo has(owner,beer) es agregado. Este objetivo se alcanza a trav´ es de los tres planes de las l´ ıneas 21-32, 36-47 y 67-70. El primer plan se dispara cuando existe cerveza disponible y no se ha bebido demasiado (ver contexto del plan). En este plan el robot realiza las acciones necesarias para alcanzarle cerveza al due˜ no, a˜ nadiendo subobjetivos que ir´ an disparando los planes correspondientes. Primero el robot desea dirigirse a la nevera (l´ ınea 23) y lo consigue a trav´ es de los planes de las l´ ıneas 77 y 78-80. Si ya est´ a en la nevera (creencia at(robot,P) donde P=nevera ) no realiza ninguna acci´ on (l´ ınea 77); si no est´ a se actualiza su posici´ on (l´ ınea 95) a trav´ es del subjetivo move towards(P) que dispara el plan de la l´ ınea 94. Luego de moverse a la nevera el robot debe abrir la nevera (subobjetivo open(fridge) de la l´ ınea 24); este subobjetivo dispara el plan de la l´ ınea 98-99 para notificar esta acci´ on al entorno. 31 3. SOPORTE PARA LAS INTERACCIONES DE AGENTES BDI Seguidamente el robot toma la cerveza a trav´ es del plan de las l´ ıneas 101-102 que igualmente notifica esta acci´ on al entorno. Este plan es disparado por el subobjetivo get(beer) de la l´ ınea 25. Como consecuencia de esta acci´ on el entorno decrementar´ a la disponibilidad y en caso de que esta llegue a cero le notificar´ a al robot que no hay cerveza disponible (ap´ endice A.2). Luego se agrega el subobjetivo para cerrar la nevera close(fridge) que act´ ua como los anteriores a trav´ es del plan de las l´ ıneas 104-105. En este paso el entorno notifica al robot del stock existente a trav´ es de un mensaje con el contenido stock(beer,AvB) siendo AvB la cantidad restante. Los subobjetivos at(robot,owner) (l´ ınea 27) y hand in(beer) (l´ ınea 28) act´ uan de manera similar a los anteriores a trav´ es de los planes de las l´ ıneas 77-80 y 107-108 y permiten que el robot se mueva hacia el due˜ no y le entregue la cerveza. Finalmente se a˜ nade una creencia asociada al consumo de una nueva cerveza (l´ ınea 30) en el d´ ıa actual proporcionado por la AI .date y en la hora actual proporcionada por la AI .time (l´ ınea 29). Adem´ as se imprime un mensaje con la cantidad de cerveza que el due˜ no ha consumido en ese d´ ıa (l´ ınea 32) obtenido a trav´ es de la AI .count (l´ ınea 31). Las l´ ıneas de la 36 a la 63 corresponden a la estructura requerida para iniciar una conversaci´ on con el mercado a trav´ es del GC solicitando m´ as cerveza. Esto ser´ a explicado m´ as adelante. El plan de las l´ ıneas 67-70 se dispara en caso de que el due˜ no haya consumido m´ as cerveza de lo permitido (ver contexto). En ese caso se imprime un mensaje en pantalla y se le notifica esto al due˜ no mediante un mensaje con la performativa tell. Si durante la ejecuci´ on de alguno de los planes cuyo evento disparador es has(owner,beer) ocurre alg´ un fallo, se disparar´ ıa el plan de contingencia de las l´ ıneas 72-75 (referirse a [9] para m´ as informaci´ on) que simplemente imprime la intenci´ on actual del agente, obtenida a partir de la AI .current intention (l´ ınea 74), como un mensaje en pantalla (l´ ınea 75). Como ha sido mencionado, cuando en el entorno se realizan las acciones para cerrar la nevera, el robot es notificado del ‘stock’ disponible de cerveza a trav´ es de un mensaje con el contenido stock(beer,AvB) . Este mensaje a˜ nade una creencia stock(beer,AvB) en la base de creencias del robot, y esto a su vez genera un evento que disparar´ a el plan de las l´ ıneas 84-88 o 89-92 en dependencia de si el ‘stock’ es cero (primer plan) o si es mayor que cero (segundo plan). Si se ejecuta el primer plan, no quedar´ ıa cerveza disponible con lo que es necesario eliminar la creencia available(beer,fridge) (l´ ınea 86). Adem´ as en este plan 32 3.6 Ejemplo de un agente Jason Conversacional se eliminan las creencias del tipo stock(beer, ) mediante la AI .abolish 1. Si se ejecuta el segundo se confirma que a´ un hay cerveza disponible (l´ ınea 91) y de igual forma se eliminan las creencias del tipo stock(beer, ) . Agente mercado 1/*Creencias iniciales */ 2// identificador de la ´ ultima orden de compra: 1 3last_order_id(1). 4// productos que se venden, en este caso, solo cerveza 5products([beer]). 6 7/*Planes */ 8 9/*============ ANSWER ROBOT REQUEST FOR MORE BEER =============*/ 10 /*conversation plan: START ------------------------------- */ 11 +!join(ConvID,Protocol)[source(robot)] 12 <- TO = 1000; 13 .ia_fipa_request_Participant("joinconversation",TO,ConvID). 14 /*----------------------------------------------------------*/ 15 16 /*conversation plan: AGREE ------------------------------- */ 17 +request(Sender,Content,Data,ConvID) 18 : Sender=robot & last_order_id(N) & products(Prod) & 19 .member(Content,Prod) 20 <- .print(" - I’ve received a request for doing: ",Content, 21 " and I’m AGREE. - "); 22 -+orderStatus(Content,agree); 23 .ia_fipa_request_Participant("agree",ConvID). 24 /*----------------------------------------------------------*/ 25 26 /*conversation plan: REFUSE ------------------------------ */ 27 +request(Sender,Content,Data,ConvID) 28 : not Sender=robot & ast_order_id(N) & products(Prod) & 29 .member(Content,Prod) 30 <- .print(" - I’ve received a request for doing: ",Content, 31 " and I REFUSE. - "); 32 -+orderStatus(Content,refuse); 1Puede darse el caso de que se a˜ nadan dos creencias stock(beer,AvB) donde el valor de AvB coincida, con lo que las creencias ser´ ıan iguales. En ese caso no se disparar´ ıa este plan. 33 3. SOPORTE PARA LAS INTERACCIONES DE AGENTES BDI 3.7. Conclusiones En este cap´ ıtulo se ha hecho una descripci´ on detallada tanto de las herramientas que se han empleado para la propuesta como de la manera en que ha sido concebida e implementada. Se ha indicado c´ omo es posible, a trav´ es de un gestor de conversaciones, mantener varias conversaciones simult´ aneas por parte de un agente ya sea empleando el mismo protocolo o distintos protocolos. Se ha mostrado a trav´ es de un ejemplo, como de una manera sencilla se intenta abstraer al programador de las complejidades intr´ ınsecas de las interacciones concurrentes manteniendo una comunicaci´ on indirecta. Como se ha observado, esta propuesta presenta numerosas estructuras que son est´ andares para cualquier dominio y que pueden ser definidas f´ acilmente de manera autom´ atica. Por esta raz´ on se ha trabajado en una herramienta de modelado que permite definir, de manera visual estas interacciones aplicado a un entorno regulado de agentes conversacionales, que permite generar una plantilla para el c´ odigo. Se comentar´ an los detalles de la herramienta en el cap´ ıtulo 4. 40 Cap´ ıtulo 4 Herramienta de modelado 4.1. Introducci´ on En la Ingenier´ ıa Dirigida por Modelos o Model Driven Engineering (MDE) por sus siglas en ingl´ es, las aplicaciones son definidas por modelos lo que permite la generaci´ on autom´ atica de c´ odigo haciendo uso de un nivel de abstracci´ on mayor. Esto permite a los programadores aumentar su productividad si existen partes del c´ odigo que se repiten constantemente en distintos momentos y esta es una tarea que puede ser ser automatizada. Tal es el caso de las interacciones entre agentes que se han abordado a lo largo de este trabajo: presentan estructuras repetitivas que abren una ventana para su posible automatizaci´ on. En el presente cap´ ıtulo se presenta una extensi´ on al Gestor de Conversaciones propuesto en el cap´ ıtulo 3 a trav´ es de una herramienta de modelado basada en workflows que permite representar interacciones y procesos en una manera gr´ afica amigable. La herramienta se implementa como un plug-in para el entorno de desarrollo integrado de Eclipse. Puede ser empleada en contextos donde varios agentes interact´ uan para intercambiar bienes o servicios en un entorno regulado. El empleo de este tipo de herramientas supone innumerables ventajas en el desarrollo de agentes, que van desde: hacer la tarea m´ as f´ acil para los desarrolladores, eliminar las posibilidades de errores y ofrecer mayor modularidad hasta un mejor control y gesti´ on de las interacciones. 4.2. Motivaci´ on Dado que la implementaci´ on de protocolos de interacci´ on es una tarea bastante apropiada a ser automatizada (ya que existen estructuras que pueden ser reutilizadas independientemente 41 4. HERRAMIENTA DE MODELADO del dominio) han surgido una serie de herramientas que permiten tanto el modelado gr´ afico de las interacciones como la generaci´ on del c´ odigo de los agentes a partir de modelos [14, 15, 22]. En [22] se realiza una propuesta tipo “metodolog´ ıa” que toma la descripci´ on de un protocolo y genera la descripci´ on del comportamiento correspondiente de los agentes. Esta descripci´ on se realiza a trav´ es de un lenguaje de modelado independiente de la plataforma para sistemas multi-agente denominado DSML4MAS (Platform Independent Modelling Language for MAS); a trav´ es de esta herramienta se puede obtener c´ odigo tanto para agentes JACK 1como para agentes Jade. En cambio en [14] se propone la metodolog´ ıa “Hermes” para dise˜ nar las interacciones entre agentes en t´ erminos de “objetivos de interacci´ on”. Se explica c´ omo los dise˜ nos obtenidos a partir de esta metodolog´ ıa se pueden implementar mapeando los artefactos de dise˜ no a colecciones de planes. Estos planes pueden ser de los tipos: Coordinaci´ on: se derivan de los objetivos de interacci´ on para coordinar los agentes en la interacci´ on). Ejecuci´ on: se derivan directamente de las acciones y son pasos para completar un objetivo de interacci´ o n. De interfaz: para transformar los mensajes entre agentes en objetivos y eventos para el procesamiento intra-agente. La implementaci´ on en este caso requiere de plataformas de agentes cuyo comportamiento es definido a trav´ es de planes y objetivos como es el caso de JACK, Jadex, JAM 2, y Jason. Concretamente para este trabajo se ha seleccionado la plataforma Jadex. Por otra parte en [15] se ofrece una herramienta gr´ afica para cubrir la brecha entre el an´ alisis y el dise˜ no de sistemas multi-agente integrando el dise˜ no y la implementaci´ on de conversaciones de agentes a trav´ es de un plug-in de Eclipse [3] que genera c´ odigo en Jade. Existen adem´ as propuestas que se basan en la met´ afora de flujos de trabajo (workflows) para contextos BPM (Business Process Management), donde un workflow representa un proceso de negocio. Tal es el caso de Wade (Workflows and Agents Development Environment) [12]. Esta plataforma est´ a basada en Jade y ofrece formalismos basados en lenguaje Java. Adem´ as de definir agentes de acuerdo a workflows, esta ofrece una arquitectura, componentes adicionales 1http://www.agent-software.com.au/products/jack 2http://www.marcush.net/IRS/irs downloads.html 42 4.3 Herramientas utilizadas y mecanismos que facilitan la administraci´ on de aplicaciones distribuidas basadas en Wade en t´ erminos de configuraci´ on, activaci´ on y monitorizaci´ on. Wade permite coordinar los sistemas existentes y tambi´ en se ofrece como marco de desarrollo de software para crear aplicaciones nuevas que impliquen la ejecuci´ on de tareas largas y complejas. Junto a Wade se ofrece un entorno de desarrollo denominado WOLF (WOrkflow LiFe cycle management environment) [13] que facilita la creaci´ on de aplicaciones basadas en Wade de manera gr´ afica a trav´ es de un plug-in de Eclipse. En las propuestas analizadas se han realizados algunas observaciones. En algunos casos el enfoque es hacia la generaci´ on del c´ odigo correspondiente a las interacciones independientemente del contexto en el que ´ estas se producen, pudi´ endose obtener c´ odigo para distintas plataformas pero consider´ andose ´ unicamente las interacciones. En otros casos tambi´ en se carece de mecanismos para la gesti´ on de conversaciones a nivel de la l´ ogica interna del sistema y tambi´ en para la generaci´ on de c´ odigo de agentes BDI. En otro caso no se ofrecen mecanismos para la especificaci´ on de sistema de manera amigable a trav´ es de alg´ un entorno gr´ afico. Atendiendo a lo anteriormente expuesto y adoptando la met´ afora de workflows empleada en [12], en este trabajo se ha elaborado una herramienta de modelado que permite la especificaci´ on de manera gr´ afica de un sistema regulado por determinadas condiciones y donde participan un conjunto de roles. La herramienta permite adem´ as la especificaci´ on de interacciones, basadas en los protocolos de FIPA, que ser´ an transformadas en c´ odigo Jason de acuerdo a la estructura presentada en el cap´ ıtulo 3. 4.3. Herramientas utilizadas La herramienta de modelado que se ha dise˜ nado ha sido concebida como un plug-in para Eclipse. Se ha escogido esta variante por ser un IDE (Integrated Development Environment) que proporciona gran flexibilidad y por su amplia aceptaci´ on en la comunidad de programadores. Adem´ as, al ser un IDE para desarrollo en Java, es perfectamente compatible tanto con la plataforma de sistemas multi-agente como con los agentes Jason que est´ an tambi´ en basados en Java. Eclipse permite la programaci´ on de agentes Jason a ser ejecutados sobre la plataforma Magentix2, de manera que es posible la creaci´ on de un modelo, la generaci´ on de c´ odigo para los agentes y su reutilizaci´ on en el proyecto para el sistema multi-agentes. Puede ser extendido modularmente por los denominados plug-ins, que proporcionan funcionalidad a otros plug-ins 43 4. HERRAMIENTA DE MODELADO a trav´ es de los puntos de extensi´ on. Eclipse adem´ as proporciona una s´ olida base con el EMF 1 (Eclipse Modelling Framework) y el GMF 2(Graphical Modelling Framework). El EMF es un framework de modelado y generaci´ on de c´ odigo que ofrece un conjunto de herramientas que soportan MDE de manera primaria en Java. Permite la definici´ on de un modelo en XML Schema, UML o Java anotado para luego ser importados a EMF. El modelo obtenido es una representaci´ on de alto nivel que que establece la equivalencia entre estos formatos. Desde la especificaci´ on de este meta-modelo, EMF ofrece herramientas y soporte para obtener un conjunto de clases Java para el modelo, de clases para la visualizaci´ on y edici´ on y un editor b´ asico. Este meta-modelo describe las caracter´ ısticas de los elementos que componen el modelo en s´ ı a trav´ es de la definici´ on de clases, atributos, m´ etodos, relaciones de agregaci´ on y herencia, tipos de datos etc. El GMF en cambio ofrece una serie de componentes generativos e infraestructuras para tiempo de ejecuci´ on para el desarrollo de editores gr´ aficos basado en EMF y GEF 3(Graphical Editing Framework). Eclipse tambi´ en ofrece herramientas para generar c´ odigo ejecutable a partir de los modelos a trav´ es de M2T 4(Model To text). Con M2T es posible generar artefactos textuales desde los modelos partiendo de la definici´ on de un modelo concreto y del meta-modelo a partir del cual ha sido creado. Para ello es necesario principalmente crear un generador de c´ odigo y una plantilla de transformaci´ on (haciendo uso del lenguaje Xpand para controlar la generaci´ on de salida). 4.4. Dise˜ no de la herramienta de modelado El modelo propuesto est´ a dise˜ nado b´ asicamente para representar las condiciones y caracter´ ısticas de las acciones que puede realizar un agente en el sistema. Para conseguir esto se tiene en cuenta que existe un agente especial o “agente regulador” que mantendr´ a conversaciones con el resto de los agentes ofreci´ endoles informaci´ on del dominio siempre y cuando se satisfagan las condiciones necesarias. Las conversaciones que mantengan los agentes fuera de este contexto no se contemplan en esta versi´ on de la propuesta, pero se pretende incluir utilidades en este sentido en versiones futuras. Estas decisiones de dise˜ no han sido tomadas a partir 1http://www.eclipse.org/modeling/emf/ 2http://www.eclipse.org/modeling/gmp/ 3http://www.eclipse.org/gef/ 4http://www.eclipse.org/modeling/m2t/ 44 4.4 Dise˜ no de la herramienta de modelado del modelo de negociaci´ on presentado en [5], que fundamenta su estructura en interacciones del tipo de las comentadas en el cap´ ıtulo 3 de este trabajo. 4.4.1. Modelo de Negociaci´ on basado en interacciones El modelo propuesto [5] ofrece estructuras para la negociaci´ on a ser empleadas en un entorno donde existen agentes que poseen determinados bienes o servicios, que est´ an interesados en negociar con ellos y que juegan determinados roles en esta negociaci´ on. Los roles que se incluyen en esta propuesta pueden ser agrupados en participantes ystaff. Dentro del primer grupo se encuentran: el rol guest (g) que representa cualquier agente interesado en entrar en el sistema, y una vez en el sistema el guest pasa a ser un participante (p), que luego ser´ a instanciado en los roles black (b) owait (w) en dependencia de la parte que representa en la negociaci´ on. En el segundo grupo se encuentran los roles mediator (m),Negociation Table Manager (ntm) y Legal Authority (la) que se encargan de tareas reguladoras espec´ ıficas, en este caso, la gesti´ on de los protocolos de negociaci´ on de manera global, el control de las negociaciones de manera individual y las tareas asociadas a la adopci´ on de los acuerdos respectivamente. La especificaci´ on del modelo se realiza fundamentalmente a trav´ es de tres elementos: interacciones (proceso at´ omico o di´ alogo entre los agentes), workflows (modelos de interacci´ on complejos y prescripciones procedurales) y transiciones (permiten la navegaci´ on de los participantes entre las interacciones). Con estos elementos se han definido las estructuras que componen el modelo que son las siguientes (figura 4.1): Admission: Interacci´ on para realizar las acciones de verificaci´ on y registro de posibles participantes en una negociaci´ on. Los invitados ofrecen su informaci´ on individual. Negotiation Hall: Grupo de interacciones que permiten a los participantes estar al tanto de las negociaciones activas, de las que han finalizado y de sus correspondientes acuerdos. En este workflow tambi´ en es posible crear nuevas mesas de negociaci´ on y realizar tareas asociadas a acciones cr´ ıticas. Negotiation Table: En este workflow los participantes ejecutan las negociaciones haciendo uso de protocolos de negociaci´ on est´ andar como por ejemplo subastas. Agreement Enactment: Interacci´ on que permite la firma de los acuerdos y la gesti´ on de quejas por parte de los participantes que pueden llegar a modificar estos acuerdos. 45 4. HERRAMIENTA DE MODELADO Negotiation Hall Admission Negotiation Table Agreement Enactment g,la,m m p g,la,m la g,la,m m,b,w m,b,w m,p m,p m,b,w ntm,b,w ntm,b,w Interaction Work-Flow Transition (Junction) Object Flow Notation Figura 4.1: Modelo de Negociaci´ on basado en interacciones propuesto. Este modelo propuesto ha sido aplicado en un caso de estudio de un mercado de agua. Este caso de estudio ser´ a utilizado m´ as adelante para la aplicaci´ on de la propuesta. 4.4.2. Descripci´ on del meta-modelo para la herramienta de modelado Como se ha descrito anteriormente en la secci´ on 4.4.1 existen determinados roles que regulan las acciones que van realizando los agentes en el sistema para poder entablar negociaciones y obtener beneficios de estas. Partiendo de esto, la herramienta de modelado propuesta puede ser empleada para contextos en el que se siga este tipo de modelo de negociaci´ on. Actualmente existe solo un “agente regulador” que auna los roles en el grupo staff del modelo de negociaci´ on, pero se pretende ampliar la propuesta para que existan agentes reguladores con responsabilidades m´ as espec´ ıficas. Los elementos que conforman el modelo a generar se presentan con m´ as detalle en [5]. Se puede tener una mejor comprensi´ on de cu´ ales son estos elementos y sus caracter´ ısticas si se observa el meta-modelo (Ecore) de la figura 4.2 concebido para este prop´ osito y obtenido a partir del EMF de Eclipse. Uno de los elementos principales es el representado por la clase Action que es una clase abstracta dise˜ nada para representar las acciones del sistema. Esta clase posee una descripci´ on y un identificador que permite hacer referencia a ella en todo el c´ odigo. Las clases del meta-modelo consideradas como acciones (a trav´ es de una relaci´ on de herencia) son: 46 4.4 Dise˜ no de la herramienta de modelado Figura 4.2: Ecore de la herramienta de modelado obtenido a trav´ es de EMF. 47 4. HERRAMIENTA DE MODELADO SingleAction: Dise˜ nada para especificar operaciones en un trozo c´ odigo embebido en la definici´ on del sistema. En la transformaci´ on a c´ odigo este tipo de acci´ on se convierte en un plan Jason, de manera que los atributos: code ytriggeringEvent corresponden a las acciones del plan y a la descripci´ on del evento disparador del plan respectivamente. ActionsFlow: Clase que representa un workflow en el sistema. A trav´ es de la relaci´ on hasAction se observa como un ActionsFlow puede contener, adem´ as de todos los elementos del diagrama, todo tipo de acciones incluy´ endose a s´ ı mismo (definici´ on recursiva). De esta forma un workflow puede contener otros workflows. La inclusi´ on de un ActionsFlow en el modelo implica la generaci´ on de un nuevo modelo. Interaction: Representa las interacciones presentes en el sistema. Es una clase abstracta de la que extienden todos los tipos de interacciones que puedan ser representadas en el modelo. El tipo de dato InteractionKind del meta-modelo es el empleado para determinar el tipo de la interacci´ on a trav´ es del atributo InteractionKind. Como se ha visto en el cap´ ıtulo 3 los elementos que var´ ıan en la utilizaci´ on de un protocolo para un prop´ osito u otro est´ an dados por: el contexto en el que se ejecuta cada paso del protocolo, que determina cu´ al es la alternativa a seleccionar para continuar la conversaci´ on y por el conjunto de acciones a ser ejecutadas como parte de un razonamiento. Por el momento la herramienta admite solo interacciones basadas en los protocolos Request, Query-If y Query-Ref de FIPA, pero se pretende extenderla para incluir todos los protocolos que soporte la plataforma, una vez comprobada la validez y utilidad de nuestro modelo. Las clases del meta-modelo que representan este tipo de interacciones y los atributos que permiten especificar estos elementos son: RequestInteraction: Interacci´ on seg´ un el protocolo Request de FIPA. Esta posee los atributos: startCondition,agreeCondition yactionCondition para las condiciones de los pasos del protocolo Begin,Agree yAction respectivamente. Tambi´ en posee el atributo taskPlan para especificar el conjunto de acciones a ser realizadas en el paso Action y el atributo timeout para definir el tiempo de espera para las respuestas del otro agente. QueryInteraction: Interacci´ on seg´ un el protocolo Query de FIPA. De esta clase extienden QueryRefInteraction yQueryIfInteraction que son los que realmente se utilizar´ an en la especificaci´ on del modelo. Posee los atributos para los pasos del protocolo Begin y 48 4.5 Implementaci´ on y generaci´ on de c´ odigo Agree, as´ ı como las acciones a realizar en el paso Action del protocolo para ofrecer la informaci´ on solicitada, especificadas en el atributo recoverInfoCode. Tambi´ en se define en esta interacci´ on el atributo timeout para esperar por las respuestas del otro agente. Adem´ as de las clases para representar las posibles acciones que se puedan realizar el metamodelo tambi´ en comprende las clases: InitialState: Para definir el punto de partida por el que el agente entra al sistema. FinalState: Para definir el punto por el que el agente sale del sistema. State: Se asocia a las acciones. Puede representar el estado en el que tiene que estar el agente para ejecutar la acci´ on o el estado resultante al que pasa el agente despu´ es de haber ejecutado la acci´ on, dependiendo de si la relaci´ on est´ a orientada hacia la acci´ on (el estado es un requisito) o hacia el estado (el estado es una consecuencia). StateLink: Permite establecer la relaci´ on State-Action yAction-State. SequenceLink: Permite establecer la relaci´ on Action-Action,InitialState-Action yActionFinalState. De esta forma establece una relaci´ on de precedencia entre las acciones. Este tipo de relaci´ on puede tener asociado roles y condiciones. Estos son los roles que debe tener el agente para ejecutar la acci´ on que tiene la relaci´ on como consecuente y las condiciones que se deben cumplir. El tipo de dato Condition del meta-modelo es el empleado para estas condiciones. 4.5. Implementaci´ on y generaci´ on de c´ odigo Como se ha mencionado GMF ofrece una serie de componentes que permiten la generaci´ on de las estructuras necesarias para la herramienta de modelado partiendo de un conjunto de especificaciones realizadas a trav´ es del EMF y el GEF. Como resultado de su empleo y adaptaci´ on al prop´ osito de la herramienta se ha obtenido un plug-in para eclipse que ofrece un entorno gr´ afico para el modelado. A trav´ es de una paleta de componentes es posible seleccionar el elemento a incluir en el modelo (ver figura 4.3). Una vez incluidos los elementos en el modelo, se pueden editar sus propiedades para especificar los valores que deben tener. Por ejemplo en la figura 4.4 se muestra un sencillo escenario en el que el “Agente regulador” es una especie de tabl´ on informativo con productos en el que los agentes pueden consultar los 49 4. HERRAMIENTA DE MODELADO 56 Cap´ ıtulo 5 Aplicaci´ on a un caso de estudio: mWater 5.1. Introducci´ on En este cap´ ıtulo se comentar´ an los detalles tanto del empleo de la herramienta de modelado como del uso del “Gestor de conversaciones” en un prototipo para un caso de estudio enmarcado en un mercado de agua. El caso de estudio “mWater” presenta las caracter´ ısticas requeridas para la aplicaci´ on de la propuesta, al existir un conjunto de entidades o personas con el inter´ es de negociar sus derechos de agua y de llegar a acuerdos, propiciando as´ ı un uso m´ as eficiente de los recursos h´ ıdricos. Se presentar´ a tanto el dise˜ no realizado como las estructuras empleadas en la implementaci´ on. 5.2. mWater 5.2.1. Descripci´ on del Caso de Estudio En este caso de estudio se aborda una problem´ atica de inter´ es en numerosos pa´ ıses hoy d´ ıa: la escasez de agua y el aprovechamiento de los recursos h´ ıdricos. Actualmente existe poco balance entre los tipos de uso del agua (por ejemplo el consumo humano, uso en la industria, la navegaci´ on etc), lo que conduce a una necesidad urgente de mejorar este proceso . Para ello es necesario considerar aspectos econ´ omicos, de medio ambiente y sociales determinados por condiciones f´ ısicas como las lluvias, distribuci´ on de la poblaci´ on, uso de la tierra, actividades econ´ omicas y adem´ as, principalmente por la demanda de agua. Una forma de medir el ´ exito 57 5. APLICACI ´ ON A UN CASO DE ESTUDIO: MWATER de una pol´ ıtica de gesti´ on de agua es observando su uso actual. Un dise˜ nador de pol´ ıticas en este sentido tiene como objetivo crear leyes de agua apropiadas para regular las acciones de los usuarios y darles la posibilidad de intercambiar recursos. Un mercado de agua se comporta como un mercado tradicional de bienes en el que los derechos de agua deben intercambiarse seg´ un bases del d´ ıa a d´ ıa, cumpli´ endose con determinadas normas preestablecidas y a cambio de alguna compensaci´ on. Estos mercados permiten dar respuesta a cambios r´ apidos en la oferta y la demanda de manera que pueden contribuir a un aumento de la inversi´ on y empleo partiendo de que los usuarios poseen acceso asegurado a suministros de agua. En estas negociaciones puede que se desee fomentar salidas que se asocien a expectativas de precio, y adem´ as a otros factores como la garant´ ıa de bienes p´ ublicos en un entorno saludable, el equilibrio entre distintas partes interesadas como granjeros, municipios, la empresa energ´ etica etc. [10] Partiendo de esto se puede intuir que el dise˜ no de pol´ ıticas en este sentido es una tarea dif´ ıcil. Surge la necesidad entonces de que los dise˜ nadores de pol´ ıticas cuenten con medios y metodolog´ ıas que les permitan predecir y visualizar las consecuencias potenciales de la inclusi´ on de nuevas regulaciones y de ajustarlas antes de su aplicaci´ on en un contexto real para evitar comportamientos no deseados. Experiencias internacionales en California (USA), Chile, Australia y M´ exico has demostrado que estos mercados de agua mejoran la eficiencia econ´ omica del uso del agua y estimulan la inversi´ on [21, 23, 29, 30]. Como se ha mencionado en el cap´ ıtulo 4, este caso de estudio ha sido empleado para la aplicaci´ on del Modelo de Negociaci´ on (MN) para una infraestructura basada en Sistemas Multiagente que proponemos en [5]. En este cap´ ıtulo se explica en m´ as detalle esta implementaci´ on haciendo uso de las herramientas y t´ ecnicas descritas a lo largo del trabajo. 5.2.2. Dise˜ no realizado Las estructuras empleadas para el dise˜ no del prototipo se resumen en un conjunto de roles e interacciones descritas en la secci´ on 4.4.1. Por simplicidad del dise˜ no se ha considerado agrupar los roles en buyer yseller (correspondientes a black ywhite en el grupo de roles participantes) y staff (grupo de roles staff), de manera que, el modelo obtenido a trav´ es de la herramienta de modelado generar´ a el c´ odigo para el rol staff, mientras que el c´ odigo para el razonamiento de los agentes buyer yseller debe ser ofrecido por las entidades participantes. No obstante se han incluido las estructuras necesarias para interactuar con el agente “staff” y solicitarle informaci´ on en un conjunto de plantillas a ser empleadas por estas entidades, de manera 58 5.2 mWater que solo sea necesario implementar los planes en los que se toman decisiones dependientes del dominio. Por otra parte en el prototipo se incluyen las siguientes acciones agrupadas por la estructura del MN a la que pertenecen: Admission 1. Acreditaci´ on: Corresponde a la interacci´ on Admission del MN. A trav´ es de esta acci´ on los usuarios podr´ an entrar al mercado. Negociation Hall 1. Mesas de negociaci´ on: Acci´ on para saber cu´ ales son las mesas de negociaci´ on actualmente abiertas en el mercado y a cu´ ales de ellas el agente ha sido invitado. 2. Unirse a mesa de negociaci´ on: Permite al agente solicitar entrar a una mesa de negociaci´ on a negociar. 3. Crear nueva mesa de negociaci´ on: Permite al agente solicitar crear una nueva mesa de negociaci´ on. 4. Invitar participantes: Para invitar a posible participantes de la mesa de negociaci´ on. Negociation Table 1. Negociar: Para establecer negociaciones con otros agentes (subasta japonesa en este caso), pero nuevos protocolos pueden ser f´ acilmente incorporados. Agreement Enactment 1. Registrar Acuerdo de Transferencia: Para registrar los datos del acuerdo de negociaci´ on as´ ı como de las participaciones si ´ este ha sido exitoso. Estas acciones resumen a gran escala lo necesario en el mercado de agua. Existen otras acciones que tambi´ en forman parte de este tipo de mercados como es el caso de las validaciones de los acuerdos para verificar si los acuerdos est´ an acordes con las convenciones normativas del plan hidrol´ ogico y de los procesos de quejas en los que se pueden generar modificaciones a los acuerdos ya realizados, pero se salen del alcance de este trabajo. No obstante este prototipo sienta las bases para un sistema con mayores prestaciones y funcionalidades. 59 5. APLICACI ´ ON A UN CASO DE ESTUDIO: MWATER 5.2.3. Modelo para mWater Partiendo de las funcionalidades comentadas en la secci´ on 5.2.2 se ha procedido, mediante la herramienta de modelado, a la creaci´ on del modelo que permitir´ a obtener las plantillas de c´ odigo para el agente staff en este caso. El modelo realizado se muestra en la figura 5.1. El primer proceso una vez es iniciado el prototipo es la ejecuci´ on de una SingleAction denominada createConfiguration; en esta acci´ on se crea una nueva configuraci´ on. Esta configuraci´ on permite recuperar, para una ejecuci´ on realizada con unos par´ ametros determinados, todas las operaciones realizadas y resultados obtenidos. Estos par´ ametros son un requisito necesario para crear la configuraci´ on que estar´ a asociada a todos los procesos a realizar con lo que se especifica en el SequenceLink desde el estado inicial a createConfiguration. Seguidamente el agente puede acreditarse ya sea como buyer o como seller. Para ello iniciar´ a una interacci´ on con el staff del tipo Request en la que ´ este realizar´ a una serie de comprobaciones en los pasos correspondientes del protocolo como participante. Estas comprobaciones se especifican en las propiedades de la interacci´ on. Como resultado de esta interacci´ on el agente que solicita acreditarse pasara a los estados “accredited” y “inTradingHall” tambi´ en representados en la figura. Como se observa, este ´ ultimo estado es un requerimiento para iniciar la interacci´ on para obtener la lista de mesas de negociaci´ on activas (getOpenNTTList), para unirse a una mesa de negociaci´ on (joinNTT) y para crear una nueva mesa de negociaci´ on (createNTT). En todas las interacciones el agente que inicia puede participar tanto como buyer o como seller. Un vez el agente conoce las mesas de negociaci´ on abiertas puede decidir unirse a alguna a la que haya sido invitado o crear una nueva. Si se une a alguna mesa pasar´ a a tener el estado InTable. Posteriormente el staff pasar´ a a verificar si est´ an dadas las condiciones para iniciar una negociaci´ on (VerifyAuctionCondition); esta acci´ on se ejecutar´ a cada vez que se cree una nueva mesa o se una un participante a un mesa existente realiz´ andose las acciones necesarias para notificar al due˜ no de la mesa que la negociaci´ on debe comenzar. Una vez finalizada una negociaci´ on el seller debe informar al staff tanto de los datos asociados al acuerdo y al derecho de agua como de las participaciones. Las acciones para registrar los datos del acuerdo y de las participaciones se realizan mediante las SingleAction registerTransferAgreement yregisterParticipations respectivamente. Como se observa en la figura 5.1 la acci´ on createNTT es de tipo ActionsFlow. Esto significa que esta acci´ on contiene una secuencia de acciones similar a las que presenta el modelo en la que est´ a contenida y que estas acciones se definen a su vez en un nuevo modelo (ver sec60 5.2 mWater Figura 5.1: Modelo para la generaci´ on de c´ odigo para el prototipo mWater. 61 5. APLICACI ´ ON A UN CASO DE ESTUDIO: MWATER Figura 5.2: Modelo para el ActionsFlow:createNTT que permite crear una nueva mesa de negociaci´ on. ci´ on 4.4.2). El modelo correspondiente se muestra en la figura 5.2. En este modelo se incluyen b´ asicamente dos interacciones: una para crear la mesa de negociaci´ on y otra para invitar a lo participantes especificados. En el modelo no se contemplan las posibles negociaciones que puedan llevar a cabo los agentes porque esto debe estar implementado en razonamiento particular de cada agente. No obstante se ofrecen plantillas que pueden ser empleadas y adaptadas con este prop´ osito. 5.2.4. Implementaci´ on Este caso de estudio ha sido desarrollado en conjunto en un equipo de trabajo con responsabilidades distintas para cada miembro. Otros miembros realizaron el dise˜ no y especificaci´ on de la base da datos a trav´ es de gestor de base de datos MySQL 1. Por otra parte ha sido desarrollada, tambi´ en por otros miembros del equipo, una aplicaci´ on que permite, a partir de los datos en la base de datos, obtener estad´ ısticas y mostrarlas de gr´ aficamente de una manera amigable dada una configuraci´ on particular del sistema [5]. Como parte del prototipo ha sido necesario la creaci´ on de una interfaz, a trav´ es de estructuras proporcionadas por Jason, que permitiera leer y almacenar las creencias del agente en la base datos. 1http://www.mysql.com/ 62 5.3 Conclusiones El prototipo tambi´ en cuenta con una GUI (Graphical User Interface) que permite la interacci´ on humano-agente, de tal manera que un humano puede interactuar con otros humanos o agentes autom´ aticos en tiempo de ejecuci´ on, realizando cambios en el sistema e incluso negociaciones. Esta interfaz permite estudiar distintas situaciones y comportamientos para ver su influencia en la evoluci´ on del mercado. Para este prop´ osito se cre´ o un sitio Web con PHP como lenguaje de interpretaci´ on para facilitar la comunicaci´ on entre la Web y el sistema multiagente. Adem´ as se emple´ o una aplicaci´ on interfaz, tambi´ en creada en el grupo de trabajo, que facilita el paso de informaci´ on de la Web al sistema multi-agente y viceversa. En este sentido el humano tendr´ a una representaci´ on en el sistema a trav´ es de un agente que, conoce las estructuras para interactuar y realizar las acciones necesarias pero no razona sobre ning´ un proceso ya que las decisiones las toma el humano y se las trasmite. La figura 5.3 muestra una p´ agina del sitio en la que el humano participa en una negociaci´ on bajo una Subasta Japonesa con dos agentes autom´ aticos del sistema. Por ´ ultimo el c´ odigo para los agentes ha sido extendido a partir de las plantillas generadas por la herramienta de modelado, y tambi´ en se ha implementado el comportamiento de los agentes participantes tanto en su rol de seller como buyer. 5.3. Conclusiones En el presente cap´ ıtulo se ha presentado un prototipo que ha servido como base de pruebas para el empleo de la herramienta de modelado y de las t´ ecnicas para las conversaciones propuestas en los cap´ ıtulos 3 y 4. El prototipo es una base para el sistema multi-agente que asistir´ a a los dise˜ nadores de pol´ ıticas en el contexto de mercados de agua, ofreciendo soporte para el control del comportamiento del mercado y la toma de decisiones. Tras el desarrollo del sistema multi-agente a trav´ es de estas herramientas se han podido ejecutar m´ ultiples conversaciones concurrentes sobre la plataforma de manera satisfactoria y se ha comprobado cu´ anto se ahorra en la implementaci´ on, en t´ erminos de esfuerzo y tiempo de desarrollo. En este sentido el programador solo debe enfocarse en la estructura a nivel global del sistema y en el razonamiento a realizar por parte de los agentes en puntos concretos del c´ odigo, abstray´ endose de factores como tiempos de espera, control de conversaciones concurrentes, de excepciones asociadas a las interacciones, etc. La herramienta de modelado adem´ as permite ofrecer modularidad, organizaci´ on y facilita las comprobaciones necesarias a nivel de c´ odigo. 63 5. APLICACI ´ ON A UN CASO DE ESTUDIO: MWATER Figura 5.3: GUI para la interacci´ on humano-agente. El usuario participa en una subasta japonesa con otros agentes y/o humanos. 64 Cap´ ıtulo 6 Conclusiones y trabajo futuro 6.1. Conclusiones generales Los sistemas multi-agentes prometen ser capaces de hacer frente a diversos dominios de aplicaciones complejas, pero la realidad es que estos en s´ ı mismos tienden a ser complejos. Se han dedicado esfuerzos de investigaci´ on a distintos niveles intentando cubrir necesidades tanto a nivel de plataformas, de los agentes de manera individual como de metodolog´ ıas y herramientas de dise˜ no. Para el caso particular de las interacciones entre agentes han sido elaboradas distintas propuestas que ofrecen mecanismos para soportarlas y facilitarlas, aunque generalmente se suelen cubrir aspectos de manera parcial, siendo necesario a menudo la b´ usqueda de varias tecnolog´ ıas para que, su conjunto, permitan obtener una soluci´ on. El trabajo aqu´ ı presentado se relaciona con varios de estos niveles intentando cubrir la brecha que pueda existir entre ellos y ofreciendo un conjunto de herramientas que permiten implementar las conversaciones entre agentes de una manera m´ as sencilla, organizada, robusta y regulada. En primer lugar se ha creado un gestor de conversaciones que permite a los programadores emplear protocolos de interacci´ on para la comunicaci´ on entre agentes, desde un modelo BDI (agentes Jason) y sobre una plataforma con soporte para protocolos de interacci´ on (Magentix2). La posibilidad de crear acciones internas ofrecida por Jason ha facilitado el intercambio de informaci´ on asociada a la conversaci´ on entre el gestor de conversaciones y el agente. Para ello es necesario definir un conjunto de planes e invocar a determinadas acciones internas en esos planes dependiendo del protocolo de interacci´ on que se est´ e empleando y de cada paso en particular del protocolo. Pudiera pensarse que el empleo del gestor de conversaciones, lejos de hacer el c´ odigo m´ as simple, hace que ´ este se haga m´ as extenso dado por la necesidad de 65 A. C ´ ODIGO 18 /*------------------------------------------------------------- */ 19 20 /*-> FIPA REQUEST objectPrice - */ 21 /*Interaction to provide the price of an object. */ 22 23 @join_request_fail_objectPrice 24 +?join(ConvID,frp,request("objectPrice","Interaction to provide the price of an object.",[RequestParameters]),AgentName,Rol): 25 objectPriceConv(ConvID,[RequestParameters]) 26 &(not .member(Rol,[guest]) 27 |(not .member(object(Obj),RequestParameters)) 28 |(not price(Obj,_))) 29 <- 30 .fail. 31 32 @join_request_objectPrice 33 +?join(ConvID,frp,request("objectPrice","Interaction to provide the price of an object.",[RequestParameters]),AgentName,Rol): 34 ConvID = conversation(objectPrice,ID)& 35 objectPriceTimeOut(TO)&.member(object(Obj),[ RequestParameters]) 36 &.member(price(P),RequestParameters) 37 &(.member(Rol,[guest]) 38 |(.member(object(Obj),RequestParameters)) 39 |(price(Obj,_))) 40 <- 41 +objectPriceConv(ConvID,[RequestParameters]); 42 .ia_fipa_request_Participant("joinconversation",TO,ConvID). 43 44 45 @not_understood_objectPrice 46 +request(Sender,Content,Data,ConvID): 47 strName(Sender,StrSender)& 48 objectPriceConv(ConvID,[RequestParameters])& 49 possibleactions(L)& not .member(Content,L)&Content= objectPrice 50 <- 51 .print("- I’ve received a request for doing: objectPrice but I don’t understand. It is not inside the actions I can do."); 52 -+taskStatus(Content,notunderstood,StrSender,ConvID); 72 A.1 C´ odigo generado por la herramienta de modelado para el modelo ejemplo 4.4 53 .ia_fipa_request_Participant("notunderstood",ConvID). 54 55 @refuse_objectPrice 56 +request(Sender,Content,Data,ConvID): 57 strName(Sender,StrSender)& 58 objectPriceConv(ConvID,[RequestParameters])& 59 Data=request("objectPrice",[RequestParameters])& 60 Content=objectPrice 61 <- 62 .print("- I’ve received a request for doing: objectPrice but I refuse."); 63 -taskStatus(Content,_,StrSender,ConvID); 64 +taskStatus(Content,refuse,StrSender,ConvID); 65 .ia_fipa_request_Participant("refuse",ConvID). 66 67 @agree_objectPrice 68 +request(Sender,Content,Data,ConvID): 69 strName(Sender,StrSender)& 70 objectPriceConv(ConvID,[RequestParameters])& 71 Data=request("objectPrice",[RequestParameters])& 72 Content=objectPrice 73 74 <- 75 //.print("- I’ve received a request for doing: objectPrice and I’m agree."); 76 -taskStatus(Content,_,StrSender,ConvID); 77 +taskStatus(Content,agree,StrSender,ConvID); 78 .ia_fipa_request_Participant("agree",ConvID). 79 80 @do_task_inform_objectPrice 81 +timetodotask(Content,Data,ConvID): 82 objectPriceConv(ConvID,[RequestParameters])& 83 Content=objectPrice& 84 taskStatus(Content,agree,StrSender,ConvID) 85 <- 86 !doTask(Content,StrSender,Data,ConvID); 87 ?taskResult(Content,ConvID,StrSender,Result); 88 -taskStatus(Content,agree,StrSender,ConvID); 89 .ia_fipa_request_Participant("inform",Content,Result,ConvID) . 90 73 A. C ´ ODIGO 91 92 @do_task_objectPrice 93 +!doTask(Content,Data,ConvID): 94 objectPriceConv(ConvID,[RequestParameters])& 95 Content=objectPrice& 96 Data=request(objectPrice,[RequestParameters])& 97 taskStatus(Content,agree,StrSender,ConvID) 98 &.member(object(Obj),[RequestParameters]) 99 &.member(price(P),RequestParameters) 100 <- 101 //{User code. The result must be stored in a ’Result’ variable.} 102 103 Data = request(_,RequestParameters); 104 .member(object(Obj),RequestParameters); 105 .member(price(Price),RequestParameters); 106 ?price(Obj,Price); 107 Result = price(Obj,Price). 108 109 +taskResult(Content,ConvID,StrSender,Result). 110 111 @do_task_failure_objectPrice 112 -!doTask(Content,Data,ConvID): 113 objectPriceConv(ConvID,[RequestParameters])& 114 Content=objectPrice 115 <- 116 .ia_fipa_request_Participant("failure",Content,ConvID). 117 118 @conversation_ended_objectPrice 119 +conversationended(ConvID,Result): 120 objectPriceConv(ConvID,[RequestParameters])& 121 Content=objectPrice& 122 taskResult(Content,ConvID,Sender,Result) 123 <- 124 -taskResult(Content,ConvID,Sender,Result); 125 registerPossibleBuyer(AgentName). 126 127 128 /*- FIPA REQUEST objectPrice <- */ 129 130 74 A.1 C´ odigo generado por la herramienta de modelado para el modelo ejemplo 4.4 131 @single_action_RegisterPBuyer 132 +!registerPossibleBuyer(AgentName): 133 (.member(Rol,[guest])) 134 <- 135 if (possibleBuyers(PB)) 136 {.concat(PB,AgentName,NewPB); 137 -possibleBuyers(PB); 138 +possibleBuyers(NewPB);} 139 else{ +possibleBuyers([AgentName]); } 140 .abolish(state(Sender,_)); 141 +state(Sender,PotentialBuyer). beliefs builder.asl 1/*GENERAL RULES */ 2 3strName(Name,StrName):- .string(Name)&StrName=Name. 4strName(Name,StrName):- not .string(Name)&.concat("",Name,StrName). 5possibleactions(objectPrice). 6 7/*GENERAL PLANS */ 8 9//Plan for getting a list of the terms given a list of one argument literals 10 +!listFromOneArgLiterals([Lit|LiteralsListTail],Result) 11 <- Lit=..[A,[B],C]; 12 if (not .ground(B)){Elem=[];}else{Elem=B;} 13 !concatElems(Elem,LiteralsListTail,Result). 14 +!listFromOneArgLiterals([],[]). 15 +!concatElems(Elem,Tail,Out) 16 <- 17 !listFromOneArgLiterals(Tail,Result); 18 if (Elem\==[]){.concat([Elem],Result,Out);}else{.concat(Elem ,Result,Out);}. 19 +!concatElems([],""). 20 21 //Plan for getting a string by concatenating the elements of a list 22 +!concatListElements(L,Out) 23 <- .reverse(L,List); 24 !concatListElem(List,Out). 25 75 A. C ´ ODIGO 26 +!concatListElem([Head|Tail],Out) 27 <- !concatListElem(Tail,Result); 28 if (.ground(Head)){.concat(Result,Head,Out);}else{.concat( Result,"",Out);}. 29 +!concatListElem([],""). A.2. C´ odigo para el agente simulador del entorno del ac´ apite 3.6 A continuaci´ on se muestra el c´ odigo correspondiente al agente simula al entorno en el ejemplo de la secci´ on 3.6. ´ Este posee una serie de planes para dar respuesta a solicitudes del robot, el due˜ no y el mercado. En los comentarios se describe la funcionalidad de cada uno. environmentAg.asl 1/*Creencias iniciales */ 2 3//Estado del due˜ no 4//---------------- 5//Cantidad de sorbos inicial. Como no tiene cerveza inicialmente este valor es cero. 6sipCount(0). 7//Para controlar si el robot est´ a llevando una cerveza consigo 8carryingBeer(false). 9 10 //Estado de la nevera 11 //------------------- 12 //Inicialemente la nevera est´ a cerrada 13 fridgeOpen(false). 14 //Hay dos cervezas disponibles 15 available(beer,2). 16 17 /*Planes */ 18 19 //Para registrar que el due˜ no ha bebido un sorbo. 20 //Si se agota el n´ umero de sorbos se le notifica tanto al due˜ no como al robot. 21 +!sip(beer)[source(owner)] 22 <- ?sipCount(Sc); 23 if (Sc > 0) { 24 NewValue = Sc - 1; 25 -+sipCount(NewValue); 76 A.2 C´ odigo para el agente simulador del entorno del ac´ apite 3.6 26 .print("Taking sip: ",NewValue); 27 }else{ 28 .send(robot,untell,has(owner,beer)); 29 .send(owner,untell,has(owner,beer)); 30 .print("No more beer!"); 31 }. 32 33 //Cuando se actualiza el n´ umero de sorbos, si este valor 34 //es positivo se notifica al due˜ no y al robot que ya el due˜ no tiene cerveza. 35 +sipCount(C) 36 <- if (C > 0) { 37 .send(owner,tell,has(owner,beer)); 38 .send(robot,tell,has(owner,beer)); 39 }. 40 41 //Para actualizar el estado de la nevera a ’abierta’ 42 +!open(fridge)[source(S)]:available(beer,AvB) 43 <- .print(S, " is opening the fridge..."); 44 -+fridgeOpen(true). 45 46 //Para tomar una cerveza. Debe haber cerveza disponible, la nevera 47 //debe estar abierta y el robot no debe llevar una cerveza consigo. 48 //Si se agota la cerveza se notifica al robot y se actualizan las 49 //creencias necesarias. 50 @pgetbeer[atomic] 51 +!get(beer)[source(S)] 52 : available(beer,AvB) & fridgeOpen(true) & 53 AvB>0 & carryingBeer(false) 54 <- NewValue = AvB - 1 ; 55 if (NewValue = 0) 56 {.send(robot,untell,available(beer,fridge));}; 57 -+available(beer,NewValue); 58 -+carryingBeer(true). 59 60 //Para actualizar el estado de la nevera a ’cerrada’. 61 //Se env´ ıa el stock restante al robot. 62 +!close(fridge)[source(S)] 63 <- .print(S, " is closing the fridge..."); 64 -+fridgeOpen(false); 65 ?available(beer,AvB); 66 .send(robot,tell,stock(beer,AvB)). 77 A. C ´ ODIGO 67 68 //Para entregar la cerveza al due˜ no. Se reinicia la cantidad de sorbos a 10 69 //y se actualiza que el robot ya no lleva cerveza consigo. 70 +!hand_in(beer) 71 <- if (carryingBeer(true)){ 72 .print("Beer given in hand to owner. 10 sips left."); 73 -+sipCount(10); 74 -+carryingBeer(false); 75 }. 76 77 //Para actualizar la cantidad de productos disponibles tras 78 //una entrega realizada por el mercado. 79 +!deliver(Product,Qtd) 80 <- -+available(Product,Qtd); 81 .print(Qtd," unities of ",Product," delivered!"). A.3. Salida por consola para el ejemplo de ac´ apite 3.6 En esta secci´ on se muestra la salida en pantalla generada tras la ejecuci´ on del ejemplo propuesto en la secci´ on 3.6. 1[environmentAg] robot is opening the fridge... 2[robot] Moving to owner 3[robot] Consumed: 1 4[environmentAg] robot is closing the fridge... 5[environmentAg] Beer given in hand to owner. 10 sips left. 6[environmentAg] Taking sip: 9 7[environmentAg] Taking sip: 8 8[environmentAg] Taking sip: 7 9[environmentAg] Taking sip: 6 10 [environmentAg] Taking sip: 5 11 [environmentAg] Taking sip: 4 12 [environmentAg] Taking sip: 3 13 [environmentAg] Taking sip: 2 14 [environmentAg] Taking sip: 1 15 [environmentAg] Taking sip: 0 16 [environmentAg] No more beer! 17 [robot] Moving to fridge 18 [environmentAg] robot is opening the fridge... 19 [robot] Moving to owner 20 [robot] Consumed: 2 21 [environmentAg] robot is closing the fridge... 22 [robot] The beer in stock has fnished. 78 A.3 Salida por consola para el ejemplo de ac´ apite 3.6 23 [environmentAg] Beer given in hand to owner. 10 sips left. 24 [environmentAg] Taking sip: 9 25 [environmentAg] Taking sip: 8 26 [environmentAg] Taking sip: 7 27 [environmentAg] Taking sip: 6 28 [environmentAg] Taking sip: 5 29 [environmentAg] Taking sip: 4 30 [environmentAg] Taking sip: 3 31 [environmentAg] Taking sip: 2 32 [environmentAg] Taking sip: 1 33 [environmentAg] Taking sip: 0 34 [environmentAg] No more beer! 35 [robot] *Starting and making proposal to supermarket * 36 [supermarket] - I’ve received a request for doing: beer and I’m AGREE. - 37 [supermarket] - Informing of task done - 38 [robot] *The task 3.2.32.deliverBeer was done successfully by agent supermarket. Result: delivered(beer,5,2) * 39 [environmentAg] 5 unities of beer delivered! 40 [robot] Moving to fridge 41 [environmentAg] robot is opening the fridge... 42 [robot] Moving to owner 43 [robot] Consumed: 3 44 [environmentAg] robot is closing the fridge... 45 [environmentAg] Beer given in hand to owner. 10 sips left. 46 [environmentAg] Taking sip: 9 47 [environmentAg] Taking sip: 8 48 [environmentAg] Taking sip: 7 49 [environmentAg] Taking sip: 6 50 [environmentAg] Taking sip: 5 51 [environmentAg] Taking sip: 4 52 [environmentAg] Taking sip: 3 53 [environmentAg] Taking sip: 2 54 [environmentAg] Taking sip: 1 55 [environmentAg] Taking sip: 0 56 [environmentAg] No more beer! 57 [robot] Moving to fridge 58 [environmentAg] robot is opening the fridge... 59 [robot] Moving to owner 60 [robot] Consumed: 4 61 [environmentAg] robot is closing the fridge... 62 [environmentAg] Beer given in hand to owner. 10 sips left. 63 [environmentAg] Taking sip: 9 64 [environmentAg] Taking sip: 8 65 [environmentAg] Taking sip: 7 66 [environmentAg] Taking sip: 6 67 [environmentAg] Taking sip: 5 68 [environmentAg] Taking sip: 4 69 [environmentAg] Taking sip: 3 70 [environmentAg] Taking sip: 2 71 [environmentAg] Taking sip: 1 72 [environmentAg] Taking sip: 0 73 [environmentAg] No more beer! 79 A. C ´ ODIGO 74 [robot] Moving to fridge 75 [environmentAg] robot is opening the fridge... 76 [robot] Moving to owner 77 [robot] Consumed: 5 78 [environmentAg] robot is closing the fridge... 79 [environmentAg] Beer given in hand to owner. 10 sips left. 80 [environmentAg] Taking sip: 9 81 [environmentAg] Taking sip: 8 82 [environmentAg] Taking sip: 7 83 [environmentAg] Taking sip: 6 84 [environmentAg] Taking sip: 5 85 [environmentAg] Taking sip: 4 86 [environmentAg] Taking sip: 3 87 [environmentAg] Taking sip: 2 88 [environmentAg] Taking sip: 1 89 [environmentAg] Taking sip: 0 90 [environmentAg] No more beer! 91 [robot] Moving to fridge 92 [environmentAg] robot is opening the fridge... 93 [robot] Moving to owner 94 [robot] Consumed: 6 95 [environmentAg] robot is closing the fridge... 96 [environmentAg] Beer given in hand to owner. 10 sips left. 97 [environmentAg] Taking sip: 9 98 [environmentAg] Taking sip: 8 99 [environmentAg] Taking sip: 7 100 [environmentAg] Taking sip: 6 101 [environmentAg] Taking sip: 5 102 [environmentAg] Taking sip: 4 103 [environmentAg] Taking sip: 3 104 [environmentAg] Taking sip: 2 105 [environmentAg] Taking sip: 1 106 [environmentAg] Taking sip: 0 107 [environmentAg] No more beer! 108 [robot] Moving to fridge 109 [environmentAg] robot is opening the fridge... 110 [robot] Moving to owner 111 [robot] Consumed: 7 112 [environmentAg] robot is closing the fridge... 113 [robot] The beer in stock has fnished. 114 [environmentAg] Beer given in hand to owner. 10 sips left. 115 [environmentAg] Taking sip: 9 116 [environmentAg] Taking sip: 8 117 [environmentAg] Taking sip: 7 118 [environmentAg] Taking sip: 6 119 [environmentAg] Taking sip: 5 120 [environmentAg] Taking sip: 4 121 [environmentAg] Taking sip: 3 122 [environmentAg] Taking sip: 2 123 [environmentAg] Taking sip: 1 124 [environmentAg] Taking sip: 0 125 [environmentAg] No more beer! 80 A.3 Salida por consola para el ejemplo de ac´ apite 3.6 126 [robot] *Starting and making proposal to supermarket * 127 [supermarket] - I’ve received a request for doing: beer and I’m AGREE. - 128 [supermarket] - Informing of task done - 129 [environmentAg] 5 unities of beer delivered! 130 [robot] *The task 3.2.54.deliverBeer was done successfully by agent supermarket. Result: delivered(beer,5,3) * 131 [robot] Moving to fridge 132 [environmentAg] robot is opening the fridge... 133 [robot] Moving to owner 134 [robot] Consumed: 8 135 [environmentAg] robot is closing the fridge... 136 [environmentAg] Beer given in hand to owner. 10 sips left. 137 [environmentAg] Taking sip: 9 138 [environmentAg] Taking sip: 8 139 [environmentAg] Taking sip: 7 140 [environmentAg] Taking sip: 6 141 [environmentAg] Taking sip: 5 142 [environmentAg] Taking sip: 4 143 [environmentAg] Taking sip: 3 144 [environmentAg] Taking sip: 2 145 [environmentAg] Taking sip: 1 146 [environmentAg] Taking sip: 0 147 [environmentAg] No more beer! 148 [robot] Moving to fridge 149 [environmentAg] robot is opening the fridge... 150 [robot] Moving to owner 151 [robot] Consumed: 9 152 [environmentAg] robot is closing the fridge... 153 [environmentAg] Beer given in hand to owner. 10 sips left. 154 [environmentAg] Taking sip: 9 155 [environmentAg] Taking sip: 8 156 [environmentAg] Taking sip: 7 157 [environmentAg] Taking sip: 6 158 [environmentAg] Taking sip: 5 159 [environmentAg] Taking sip: 4 160 [environmentAg] Taking sip: 3 161 [environmentAg] Taking sip: 2 162 [environmentAg] Taking sip: 1 163 [environmentAg] Taking sip: 0 164 [environmentAg] No more beer! 165 [robot] Moving to fridge 166 [environmentAg] robot is opening the fridge... 167 [robot] Moving to owner 168 [robot] Consumed: 10 169 [environmentAg] robot is closing the fridge... 170 [environmentAg] Beer given in hand to owner. 10 sips left. 171 [environmentAg] Taking sip: 9 172 [environmentAg] Taking sip: 8 173 [environmentAg] Taking sip: 7 174 [environmentAg] Taking sip: 6 175 [environmentAg] Taking sip: 5 176 [environmentAg] Taking sip: 4 81