Tesis De Agentes Yanis

UNIVERCIDAD DE PAMPLONA FACULTAD DE INGENIERIAS Y ARQUITECTURA DEPARTAMENTO DE INGENIERÍA ELÉCTRICA, ELECTRÓNICA, SISTEMAS Y TELECOMUNICACIONES INGENIERÍA DE SISTEMAS

“APLICACIÓN DE METODOLOGIAS INGENIAS, ZEUS, MASINA AL DESARROLLO DE SISTEMAS MULTI-AGENTE, PARTIENDO DE SMA DE SUBASTAS PARA LA IDENTIFICACION DE MEJORES PRACTICAS”

Trabajo presentado para optar por el título de: Ingeniero de sistemas

AUTOR: Yanis Stanley Pérez Ardila DIRECTOR: Ing. Jorge Omar Portilla

Pamplona, Colombia Abril, 2007

“APLICACIÓN DE METODOLOGIAS INGENIAS, ZEUS, MASINA AL DESARROLLO DE SISTEMAS MULTI-AGENTE, PARTIENDO DE SMA DE SUBASTAS PARA LA IDENTIFICACION DE MEJORES PRACTICAS”

AGRADECIMIENTOS A Dios por darme la vida e iluminarme el camino que hace brillar mi vida en éxitos y triunfos. A mis padres, quienes han llenado mi vida de amor y han derrochado sobre mí, ternura y abnegación. A mis hermanos por brindarme su apoyo y confianza en los momentos más difíciles. A Liliana por aguantarme estos meses de estrés, trabajos hasta la madrugada, y brindarme su amor incondicional. A mi hija VANESSA por todo el amor y ternura que despiertan en mí las ganas de salir adelante y triunfar. Al profesor Omar quien aguanto esos desplantes y aun así me brindo su ayuda para superarme intelectualmente y estimularme a seguir adelante. A mis amigos que con su confianza me daban ánimo para culminar este trabajo que parecía interminable. A todos aquellos que con el comentario más pequeño me dieron una luz sobre el camino a seguir.

La inteligencia consiste no sólo en el conocimiento, sino también en la destreza de aplicar los conocimientos en la práctica. /Aristóteles/

El que tiene la verdad en el corazón no debe temer jamás que a su lengua le falte fuerza de persuasión. /John Ruskin/

RESUMEN Apoyándose en los resultados de la investigación en agentes y Sistemas Multi-Agente, surge una línea de trabajo cuyo propósito es consolidar la experiencia adquirida en forma de metodologías. Estas metodologías proporcionan medios para construir Sistemas Multi-Agente de forma disciplinada y repetible. En este trabajo se presenta un resumen de lo que proponen las metodologías actuales. Ante la imposibilidad de revisar todas y cada una de las existentes, se ha optado por seleccionar un conjunto significativo cercano a las prácticas de ingeniería del software. La selección atiende a la presencia de un proceso de desarrollo, el combinar diferentes vistas para describir el sistema, e incorporar elementos asociados al área de los agentes. ABSTRACT Relying on the results of the investigation in agents and Systems Multi-agent, a work line arises whose purpose is to consolidate the experience acquired in form of methodologies. These methodologies provide means to build Systems Multi-agent in a disciplined way and repeatable. In this work he/she shows up a summary of what you/they propose the current methodologies. In the face of the impossibility of revising all and each one of the existent ones, it has been opted to select a significant near group to the practices of engineering of the software. The selection assists to the presence of a development process, combining different views to describe the system, and to incorporate elements associated to the area of the agents.

INDICE GENERAL INTRODUCCION -1JUSTIFICACION -4MARCO TEORICO - 5 1.1 Qué es un Agente?......................................................................................................5 1.10. ESTANDARES ACEPTADOS.............................................................................30 1.10.1.................................................................................................................Estándares ......................................................................................................................................30 1.10.2.........................................................................Organizaciones de estandarización ......................................................................................................................................30 1.11 .......................................Plataformas para el Desarrollo de Sistemas Multiagente ......................................................................................................................................31 1.11.1.........................................................................................................................JACK ......................................................................................................................................31 1.11.2 .............................................................MADKit (Multi-Agent Development Kit) ......................................................................................................................................33 1.11.3 ........................................JAFMAS (Java Framework for Multi-agent Systems) ......................................................................................................................................35 1.11.4.....................................................................................GRASSHOPPER AGENTS ......................................................................................................................................35 1.11.5 .....................................................................Comparación JACK MADKit ZEUS ......................................................................................................................................37 1.12 ARQUITECTURAS DE AGENTES.....................................................................38 1.12.1................................................................................................Arquitectura BDI [9] ......................................................................................................................................39 1.12.10 PRS......................................................................................................................47 1.12.11 SOAR..................................................................................................................48 1.12.2 Arquitectura de sistemas inteligentes adaptativos............................................40 1.12.3 ATLANTIS...........................................................................................................41 1.12.4 CIRCA..................................................................................................................42 1.12.5 HOMER................................................................................................................43 1.12.6 ICARUS................................................................................................................44 1.12.7 Motor de reducción de entropía.........................................................................44 1.12.8 PHOENIX............................................................................................................45 1.12.9 PRODIGY............................................................................................................46 1.13 ¿Cuándo aplicar el desarrollo basado en agentes?..............................................49 1.13.1 Resolviendo nuevos tipos de problemas............................................................50 1.14...........................................................................Definición ejemplo \“SMA Subasta\ ......................................................................................................................................52

1.14.1...............................................................................................¿Qué es una subasta? ......................................................................................................................................52 1.14.2.....................................................................................Parámetros de una Subasta ......................................................................................................................................52 1.14.3...............................................................................................................Negociación ......................................................................................................................................53 1.14.3.1...................................................................................Atributos de la negociación ......................................................................................................................................53 1.14.4..............................................................................................TIPOS DE SUBASTA ......................................................................................................................................53 1.14.4.1.......................................................................................................Subasta inglesa ......................................................................................................................................53 1.14.4.2.................................................................................................Subasta holandesa ......................................................................................................................................54 1.14.4.3........................................................................................Subasta a sobre cerrado ......................................................................................................................................54 1.14.7....................................................................................................Riesgo de conflicto ......................................................................................................................................55 1.2......................................................................................Propiedades de los Ambientes ........................................................................................................................................9 1.3..............................................................................................CLASES DE AGENTES ......................................................................................................................................10 1.3.1................................................................................................Agentes Colaborativos ......................................................................................................................................10 1.3.2...................................................................................................Agentes de Interface ......................................................................................................................................10 1.3.3...........................................................................................................Agentes móviles ......................................................................................................................................11 1.3.4..............................................................................................Agentes de información ......................................................................................................................................12 1.4.....................................................................................................Orígenes de los SMA ......................................................................................................................................13 1.5...........................................................................................Taxonomía De Los Agentes ......................................................................................................................................13 1.5.10..............................................................................................................Benevolencia ......................................................................................................................................15 1.5.2...................................................................................................................Autonomía ......................................................................................................................................14 1.5.4.....................................................................................................................Movilidad ......................................................................................................................................14 1.5.5.............................................................................................................Comunicación ......................................................................................................................................14 1.5.6.................................................................................................................Sociabilidad ......................................................................................................................................15

1.5.7..................................................................................................................Reactividad ......................................................................................................................................15 1.5.8.............................................................................................Pro actividad, iniciativa ......................................................................................................................................15 1.5.9.....................................................................................................................Veracidad ......................................................................................................................................15 1.6.............................................................................Arquitectura Abstracta De Agentes ......................................................................................................................................15 1.6.1................................................................Funciones de Transformación de Estados ......................................................................................................................................16 1.6.2......................................................................................................Agentes y Acciones ......................................................................................................................................16 1.6.3....................................................................................................Sistemas de Agentes ......................................................................................................................................16 1.7...........................................Comparativa entre agentes Objetos y sistemas expertos ......................................................................................................................................18 1.8 CONSTRUCCIÓN DE SMA...................................................................................18 1.8.1 ............................................................................¿Qué es un Sistema Multiagente? ......................................................................................................................................20 1.8.2..................................Lenguajes de agentes y el diseño de Sistemas Multi-Agente ......................................................................................................................................20 1.8.3 ...............................................Plataformas para diseño de Sistemas Multi-Agente ......................................................................................................................................21 1.9 METODOLOGIAS EXISTENTES.......................................................................24 1.9.1......................................................................................................Vowel Engineering ......................................................................................................................................24 1.9.2..........................................................................................................................MaSE ......................................................................................................................................26 1.9.3............................................................................................................................GAIA ......................................................................................................................................27 1.9.4 ..................................................................................................................MESSAGE ......................................................................................................................................28 2. INGENIAS [................................................................................................................57 2.1................................................................................................................ Nomenclatura ......................................................................................................................................58 2.1.1........................................................................................................Entidades básicas ......................................................................................................................................59 2.1.2 ......................................................................................................................Notación ......................................................................................................................................60 2.2............................................META-MODELOS DEL SISTEMA MULTI AGENTE ......................................................................................................................................62 2.2.1.............................................................................................Modelo de organización ......................................................................................................................................63 2.2.2 Modelo de agente...................................................................................................65 2.2.3 Modelo de objetivos y tareas...............................................................................67

2.2.4.............................................................................................Modelo de interacciones ......................................................................................................................................70 2.2.5......................................................................................................Modelo de entorno ......................................................................................................................................72 2.3......................................................CASO DE ESTUDIO SUBASTA EN INGENIAS ......................................................................................................................................74 2.3.1..........................................................................Casos de uso asociados al problema ......................................................................................................................................74 2.4.................................................................................FUNCIONAMIENTO DEL IDK ......................................................................................................................................75 2.4.1......................................................................................................... Partes del editor ......................................................................................................................................77 2.4.2...................................................................................................................................... ........................................................................... proyecto y visualización de proyecto ......................................................................................................................................77 2.4.3.................................................................................................. la vista de Entidades ......................................................................................................................................78 2.4.4.................................................................................................... Editor de diagrama ......................................................................................................................................78 2.4.5...................................................................................................................... Módulos ......................................................................................................................................81 2.5...RESULTADO FINAL DE IMPLEMENTACION DE CASO DE ESTUDIO EN LA METODOLOGIA INGENIAS IDK...................................................................81 3. MAS-commonKads....................................................................................................85 3.1.........................................................................Ciclo de desarrollo de los casos de uso ......................................................................................................................................86 3.1.1.................................................................................................................... Actividad\ ..........................................................................................................................................  Identificación de los actores.......................................................................................86 3.1.2 ...................................................................................................................Actividad\ ..........................................................................................................................................  Descripción de los actores..........................................................................................87 3.1.3 ...................................................................................................................Actividad\ ..........................................................................................................................................  Identificación de los casos de uso...............................................................................87 3.1.4 ...................................................................................................................Actividad\ ..........................................................................................................................................  Descripción de los casos de uso..................................................................................87 3.1.4.1 Notación de los casos de uso..............................................................................87 3.1.4.1.1 Notación textual...............................................................................................88 3.1.5 .........................................................................................................Notación gráfica ......................................................................................................................................88 3.1.6 ...................................................................................................................Actividad\ ..........................................................................................................................................

 Descripción de las intervenciones de los casos de uso...............................................89 3.1.7 ...................................................................................................................Actividad\ ..........................................................................................................................................  Descripción de las relaciones entre casos de uso........................................................89 3.2 ........................................................................................................ Modelo de Agente ......................................................................................................................................90 3.2.1 .............................................................................................Antecedentes históricos ......................................................................................................................................90 3.2.2 ........................................................................Fundamentos del modelo de agente ......................................................................................................................................90 3.2.2.1 ....¿Qué problemas de IAD deben ser resueltos en el desarrollo del modelo de agente?.........................................................................................................................91 3.2.2.2 .........¿Cuándo es el modelo útil, y cuándo debe ser incluido en el conjunto de modelos?......................................................................................................................91 3.2.3.......................................................... Dependencias en la construcción del modelo ......................................................................................................................................91 3.2.3.1 Modelo de Tareas................................................................................................91 3.2.3.2 Modelo de Comunicación...................................................................................91 3.2.3.3 Modelo de Coordinación....................................................................................91 3.2.3.4 Modelo de la Experiencia...................................................................................91 3.2.3.5 Modelo de Organización....................................................................................92 3.2.4 Ciclo de desarrollo del modelo de agente............................................................92 3.2.5...........................................................................Relación entre el modelo de agente ......................................................................................................................................93 3.3 ..........................................................................................................Modelo de Tareas ......................................................................................................................................94 3.3.2 Entidades del modelo de tareas............................................................................94 3.4..................................................................................................Modelo de Experiencia ......................................................................................................................................98 3.4.1 Fundamentos del modelo de la experiencia.........................................................98 3.4.2 Estructura del modelo de la experiencia.............................................................98 3.4.3 Conocimiento del dominio....................................................................................98 3.4.4 Notación del modelo de la experiencia.................................................................99 3.4.5 Técnicas de adquisición del conocimiento.........................................................100 3.4.6 Desarrollo del modelo de la experiencia............................................................100 3.4.7 Actividades de construcción del esqueleto del modelo.....................................101 3.4.8 Actividades de instanciación...............................................................................101 3.4.9 Particularización para sistemas multiagente....................................................101 3.5 Modelo de Coordinación........................................................................................102 3.5.1 Antecedentes históricos.......................................................................................103 3.5.2.1 Teoría de los actos de habla.............................................................................104 3.5.2.2 Teoría del discurso............................................................................................104 3.5.2.3 El lenguaje de comunicación KQML..............................................................104 3.5.2.4 La especificación de la FIPA............................................................................105

3.5.3 Fundamentos del modelo de coordinación........................................................106 3.5.3.1 ¿Qué problemas de la IAD deben ser resueltos en el desarrollo del modelo de coordinación?............................................................................................................107 3.5.3.2 ¿Cuándo es el modelo útil, y cuándo debe ser incluido en el conjunto de modelos?....................................................................................................................107 3.5.3.3 Restricciones\..........................................................................................................  ¿qué no puede ser modelado?...................................................................................108 3.5.4 Estructura del modelo.........................................................................................108 3.5.4.1 Constituyentes del modelo...............................................................................108 3.5.4.2 Plantilla del modelo de Coordinación.............................................................109 3.5.5 Ciclo del desarrollo del modelo...........................................................................111 3.5.5.1 Desarrollo estándar del modelo de coordinación...........................................111 3.5.5.2 Ciclos de desarrollo no estándar del modelo de coordinación......................113 3.5.6 Dependencias en la construcción del modelo....................................................114 3.5.7 Evaluación del modelo.........................................................................................114 3.6...............................................................................................Modelo de Organización ....................................................................................................................................120 3.6.1 Antecedentes históricos.......................................................................................121 3.6.2 Bases teóricas del modelo....................................................................................121 3.6.2.1 Relaciones de herencia en un sistema multiagente........................................121 3.6.2.1.1 ¿Entre qué constituyentes se establece una relación de herencia?............121 3.6.2.1.2 ¿Cómo se define la relación de herencia?....................................................121 3.6.3 Fundamentos del modelo de organización........................................................123 3.6.3.1 ¿Qué problemas de IAD deben ser resueltos en el desarrollo del modelo de organización?............................................................................................................123 3.6.3.2 ¿Cuándo es el modelo útil, y cuándo debe ser incluido en el conjunto de modelos?....................................................................................................................123 3.6.3.3 Restricciones\..........................................................................................................  ¿qué no puede ser modelado?...................................................................................124 3.6.4 Estructura del modelo.........................................................................................124 3.6.4.1 Constituyentes del modelo...............................................................................124 3.6.4.2 Notación gráfica del modelo............................................................................125 3.6.5 Ciclo de desarrollo del modelo...........................................................................126 3.6.5.1 Desarrollo estándar del modelo de organización...........................................126 3.6.6 Actividades de construcción del modelo de organización................................126 3.6.7 Actividades de modelado de la organización.....................................................127 3.6.7.1 Modelado de la situación actual......................................................................128 3.6.7.10 Actividad\...............................................................................................................  Evaluación de soluciones..........................................................................................131 3.6.7.2 Actividad\.................................................................................................................  Introducción en la organización................................................................................128 3.6.7.3 Actividad\.................................................................................................................  Comprensión de la organización...............................................................................128 3.6.7.4 Actividad\.................................................................................................................

 Análisis detallado......................................................................................................128 3.6.7.5 Actividad\.................................................................................................................  Evaluación del análisis..............................................................................................129 3.6.7.6 Modelado de la situación futura.....................................................................129 3.6.7.7 Actividad\.................................................................................................................  Identificación de soluciones......................................................................................129 3.6.7.8 Actividad\.................................................................................................................  Investigación de viabilidad........................................................................................130 3.6.7.9 Actividad\.................................................................................................................  Preparación para la toma de decisiones....................................................................130 3.6.8 Actividades de modelado de la organización multiagente...............................131 3.6.8.1 Actividad\.................................................................................................................  Identificación de las relaciones de herencia..............................................................131 3.6.8.2 Actividad\.................................................................................................................  Identificación de objetos del entorno........................................................................131 3.6.8.3 Actividad\.................................................................................................................  Identificación y descripción de estructuras organizativas.........................................131 3.6.9 Dependencias en la construcción del modelo....................................................132 3.6.9.1 Modelo de Agente.............................................................................................132 3.6.9.2 Modelo de Tareas..............................................................................................132 3.6.9.3 Modelo de Comunicación.................................................................................132 3.6.9.4 Modelo de Coordinación..................................................................................132 3.7.......................................................................................................... Modelo de Diseño ....................................................................................................................................133 3.7.1 Antecedentes históricos.......................................................................................133 3.7.2 Bases teóricas.......................................................................................................133 3.7.2.1 El Modelo de Red..............................................................................................134 3.7.2.1.1 Facilidades de red..........................................................................................135 3.7.2.1.2 Facilidades de coordinación..........................................................................136 3.7.2.1.3 Facilidades de conocimiento.........................................................................136 3.7.3 Fundamentos del modelo de diseño...................................................................137 3.7.3.1 ¿Qué problemas de IAD deben ser resueltos en el desarrollo del modelo de diseño?.......................................................................................................................137 3.7.3.2 ¿Cuándo el modelo es útil, y cuándo debe ser incluido en el conjunto de modelos?....................................................................................................................137 3.7.3.3 Restricciones\..........................................................................................................  ¿qué no puede ser modelado?...................................................................................137 3.7.4 Estructura del modelo.........................................................................................138 3.7.4.1 Diseño del modelo de red.................................................................................138 3.7.4.2 Constituyentes del modelo...............................................................................139 3.7.4.2.1 Constituyentes del diseño de red..................................................................139 3.7.4.3 Diseño de los agentes........................................................................................140 3.7.4.4 Diseño de la plataforma...................................................................................141

3.7.5 Ciclo de desarrollo del modelo...........................................................................141 3.7.6 Dependencias en la construcción del modelo....................................................142 3.7.6.1 Modelo de agente..............................................................................................142 3.7.6.2 Modelo de comunicación..................................................................................142 3.7.6.3 Modelo de tareas...............................................................................................143 3.7.6.4 Modelo de la experiencia..................................................................................143 3.7.6.5 Modelo de organización...................................................................................143 3.7.6.6 Modelo de coordinación...................................................................................143 3.7.6.7 Actividades de desarrollo del modelo de diseño.............................................143 3.7.7 Diseño de la red....................................................................................................143 3.7.7.1 Actividad\.................................................................................................................  Identificación y descripción de las facilidades de red...............................................143 3.7.7.1.2 Servicios de red básicos.................................................................................144 3.7.7.1.3 Servicios de red avanzados...........................................................................144 3.7.7.1.4 Servicios de red no funcionales....................................................................144 3.7.7.2 Actividad\.................................................................................................................  Identificación y descripción de las facilidades de conocimiento..............................145 3.7.7.2.1 Servicios de conocimiento básicos................................................................145 3.7.7.3 Actividad\.................................................................................................................  Identificación y descripción de las facilidades de coordinación...............................145 3.7.7.3.1 Servicios de coordinación..............................................................................146 3.7.7.4 Actividad\.................................................................................................................  Identificación y descripción de agentes de red.........................................................146 3.7.8 Diseño de la aplicación........................................................................................147 3.7.8.1 Actividad\.................................................................................................................  Determinación de la arquitectura de los agentes.......................................................147 3.7.8.2 Actividad\.................................................................................................................  Revisión de los agentes identificados........................................................................147 3.7.8.3 Actividad\.................................................................................................................  Diseño detallado de los módulos..............................................................................148 3.7.9 Diseño de la plataforma......................................................................................148 3.7.9.1 Actividad\.................................................................................................................  Selección del lenguaje de implementación...............................................................148 3.7.9.2 Actividad\.................................................................................................................  Selección de los recursos software............................................................................149 3.7.9.3 Actividad\.................................................................................................................  Selección de los recursos hardware...........................................................................149 3.8 APLICACION DE CASO DE ESTUDIO “SMA SUBASTAS........................150 3.8.1 Modelo de agentes................................................................................................154 3.8.2 Modelo de Experiencia.......................................................................................157 3.8.3 Modelo de coordinación......................................................................................158 3.8.4 Modelo de tareas..................................................................................................162 3.8.5 Modelo de comunicación....................................................................................162

3.8.6 Modelo de Organización....................................................................................164 3.8.7 El Modelo de Red................................................................................................165 4 MASINA\.......................................................................................................................   MultiAgent Systems in Automation.........................................................................166 4.1 Modelo de agentes..................................................................................................167 4.2 Modelo de tareas....................................................................................................167 4.3 Modelo de Inteligencia..........................................................................................168 4.4 Modelo de coordinación........................................................................................169 4.5 Modelo de Comunicación......................................................................................172 4.6. APLICACION DE \“SMA SUBASTAS\.............................................................175 4.6.1 .............................................................................................Actores y Casos de uso. ....................................................................................................................................175 4.6.2 Modelo de agentes................................................................................................179 4.6.2.1 Canales básicos de comunicación....................................................................186 4.6.3...............................................................................................Modelo de Inteligencia ....................................................................................................................................182 4.6.4 Modelo de coordinación......................................................................................183 4.6.4 Modelo de tareas..................................................................................................187 4.6.5 Modelo de comunicación.....................................................................................187 5 The Zeus Agent Building Toolkit..............................................................................190 5.1 El agente conceptual de Zeus.................................................................................192 5.10 Asignación de recurso inicial del agente.............................................................202 5.11 Interacciones del agente......................................................................................204 5.12 Uso general de la configuración del agente.......................................................206 5.13 Cómo crear un agente con un GUI del espectador del agente.........................207 5.2.....................................................................................Metodología Principal de Zeus ....................................................................................................................................194 5.3 – Análisis de Dominio.............................................................................................195 5.4 – Agente Diseño.......................................................................................................195 5.5 – Agente Comprensión...........................................................................................195 5.6 – Soporte de Tiempo de Ejecución........................................................................195 5.7 Descripción del proceso de la realización del agente...........................................197 5.7.1 Etapa 1\.......................................................................................................................  Creación de Ontología..............................................................................................197 5.7.2 Etapa 2\.......................................................................................................................  Creación del agente...................................................................................................197 5.7.3 Etapa 3\.......................................................................................................................  Configuración para uso general del agente...............................................................197 5.7.4 Etapa 4\.......................................................................................................................  Configuración del agente de la tarea.........................................................................197 5.7.5 Etapa 5\.......................................................................................................................  Puesta en práctica del agente.....................................................................................198 5.8 La etapa de la creación de la Ontología................................................................199

5.9 Creación de Agentes...............................................................................................201 6. JADE..........................................................................................................................209 6.1 FIPA.........................................................................................................................209 6.2 JADE........................................................................................................................210 6.3 Arquitectura............................................................................................................211 6.4 Programación de Agentes en JADE......................................................................212 6.5 Comportamientos...................................................................................................214 6.5.1. Comunicación.....................................................................................................216 6.6. Entorno de ejecución.............................................................................................217 6.6.1. Interfaz RMA......................................................................................................217 6.6.2. Agente Dummy....................................................................................................218 6.6.3 Interfaz DF...........................................................................................................219 6.6.4. Agente Sniffer......................................................................................................219 6.6.5. Agente Instrospector..........................................................................................220 6.7. Razones para el uso de JADE...............................................................................221 6.8.............................................................................Implementación del caso de estudio ....................................................................................................................................221 7.1 Criterios de examen................................................................................................229 7.1.1. Cuatro cualidades de las etapas de desarrollo.................................................229 7.1.2. Aplicación de las cualidades a las etapas..........................................................229 7.1.3 Otros criterios......................................................................................................234 7.CONCLUCIONES....................................................................................................226 ANEXO I...........................................................................................................................1 ANEXO I Documentación generada por ingenias IDE.................................................1 ANEXO II Codigo fuente de JADE..............................................................................10 ANEXO III Código creado para Zeus.........................................................................46 BIBLIOGRAFIA...............................................................................................................i CAPITULO III..............................................................................................................85 CAPITULO I....................................................................................................................5 CAPITULO II.................................................................................................................57 CAPITULO IV .............................................................................................................166 CAPITULO V...............................................................................................................190 CAPITULO VI..............................................................................................................209 CAPITULO VII............................................................................................................226 INTRODUCCION............................................................................................................1 JUSTIFICACION.............................................................................................................4 MARCO TEORICO.........................................................................................................5 ¿AGENTE?.......................................................................................................................5

INDICE DE FIGURAS Figura 1: Descripción del agente........................................................................................8 Figura 2: Taxonomía de agentes.......................................................................................13 Figura 3: Componentes de SMA......................................................................................19 Figura 4: Plataformas para diseño de Sistemas Multi-Agente.........................................23 Figura 5: Arquitectura de capas de Vowel Engineering...................................................25 Figura 6: MaSE.................................................................................................................26 Figura 7: Metodologías.....................................................................................................29 Figura 8: JAFMAS...........................................................................................................35 Figura 9: Arquitectura Gasshopper...................................................................................36 Figura 10: Comparación JACK MADKit ZEUS..............................................................37 Figura 11: Arquitectura BDI.............................................................................................39 Figura 12: Arquitectura AIS.............................................................................................41 Figura 13 : Arquitectura CIRCA......................................................................................42 Figura 14: Arquitectura HOMER.....................................................................................43 Figura 15: Arquitectura ICARUS.....................................................................................44 Figura 16: Arquitectura MRE...........................................................................................45 Figura 17: Arquitectura PHOENIX..................................................................................46 Figura 18: Arquitectura PRODIGY..................................................................................47 Figura 19: Arquitectura SOAR.........................................................................................48 Figura 20: Arquitecturas de agentes]................................................................................49 Figura 21: pantalla principal de ingenias..........................................................................58 Figura 22: Expresión BNF para la los nombres de las relaciones....................................59 Figura 23: Entidades básicas de la metodología...............................................................59 Figura 24: Notación empleada en la representación de los modelos................................61 Figura 25: Estructura de cuatro niveles utilizada en el meta-modelado...........................62 Figura 26: Descripción estructural...................................................................................63 Figura 27: Descripción social...........................................................................................64 Figura 28: Descripción funcional.....................................................................................64 Figura 29: Elementos del modelo de agente.....................................................................66 Figura 30: Diagrama del modelo de agente......................................................................66 Figura 31: Agente planificador.........................................................................................67 Figura 32: Ciclo de vida de un objetivo...........................................................................68 Figura 33: Árboles Y/O....................................................................................................68 Figura 34: Elementos de definición de tareas...................................................................69 Figura 35: Una tarea afecta a un objetivo.........................................................................69 Figura 36: Ejemplo de Tareas...........................................................................................70 Figura 37: Protocolos FIPA_CONTRCTNET..................................................................71 Figura 38: Entorno de asistente de ficheros de un pc.......................................................73 Figura 39: Casos de usos subasta.....................................................................................74 Figura 40: IDE pantalla principal.....................................................................................76 Figura 41: Partes del editor...............................................................................................77 Figura 42: pasos para crear una relación de dos entidades...............................................80 Figura 43: Relación entre el IDE, modelos y componentes.............................................81 Figura 44: Asociación de agentes.....................................................................................82

Figura 45: Ambientes de agentes......................................................................................82 Figura 46: Objetivos y tareas............................................................................................83 Figura 47: Modelo de interacción.....................................................................................83 Figura 48: Flujo de eventos..............................................................................................84 Figura 49: modelos de Mas commonKads.......................................................................86 Figura 50: Notación de los casos de uso..........................................................................89 Figura 51: Modelo de Agente...........................................................................................90 Figura 52: Tarjetas CRC para agentes..............................................................................92 Figura 53: Constituyentes y relaciones del modelo de agentes........................................93 Figura 54: Modelo de tarea...............................................................................................94 Figura 55: Diagrama entidad-relación del modelo de tareas de CommonKADS............94 Figura 56: Notación estándar para indicar descomposición de tareas..............................95 Figura 57: Notación alternativa para representar la descomposición de tareas................96 Figura 58: Principales componentes del modelo de la experiencia..................................98 Figura 59: Ontología.........................................................................................................99 Figura 60: Nivel de dominio y inferencia.........................................................................99 Figura 61: Adquisición de conocimiento........................................................................100 Figura 62: Ejemplo de diagrama de inferencia de un agente.........................................102 Figura 63: Objetos del modelo de coordinación.............................................................110 Figura 64: Descomposición del objeto Intervención......................................................111 Figura 65: Orden de los hitos del modelo de coordinación............................................112 Figura 66: Estados hito en el desarrollo del modelo de Coordinación...........................113 Figura 67: Notación Agentes MSC.................................................................................116 Figura 68: Estructuras extremas de diagramas de interacción.......................................117 Figura 69: Constituyentes del modelo de organización de CommonKADS..................120 Figura 70: Representación de herencia entre agentes.....................................................122 Figura 71: Modelo de organización de CommonKADS................................................125 Figura 72: Notación gráfica del modelo de organización...............................................126 Figura 73: Arquitectura multi-agente genérica...............................................................134 Figura 74: El modelo de red...........................................................................................135 Figura 75: Descomposición del modelo de diseño.........................................................138 Figura 76: Constituyentes del diseño de red...................................................................139 Figura 77: Constituyentes del diseño de los agentes......................................................140 Figura 78: Diseño de la plataforma................................................................................141 Figura 79: Conversación en subasta...............................................................................159 Figura 80: Canales de comunicación..............................................................................161 Figura 81: Descomposición de tarea Escoger tipo de subasta........................................162 Figura 82: Modelos de MASINA...................................................................................167 Figura 83: Modelo de tarea.............................................................................................168 Figura 84: Modelo de inteligencia..................................................................................169 Figura 85: Plantilla de una Conversación en el Modelo de Coordinación.....................170 Figura 86: Modelo de Coordinación...............................................................................171 Figura 87: Descripción de la conversación de los agentes.............................................172 Figura 88: Plantilla del Modelo de comunicación..........................................................173 Figura 89 Modelo de Comunicación].............................................................................174

Figura 90: Conversación en subasta...............................................................................184 Figura 91: Canales de comunicación..............................................................................186 Figura 92: Descomposición de tarea Escoger tipo de subasta........................................187 Figura 93: La estructura conceptual de un agente de ZEUS..........................................192 Figura 94: Desarrollo de la metodología Zeus...............................................................194 Figura 95: presentación de Zeus agent Generator 1.2.2.................................................198 Figura 96: Un screenshot del panel de las opciones de Ontología de la herramienta del generador........................................................................................................................200 Figura 97: Un Screenshot de uno de los paneles del editor de Ontología. ...................200 Figura 98: Un screenshot del panel de las opciones del agente de la herramienta del generador. La tabla sabida del agente enumera todos los agentes que se han definido en el proyecto actual............................................................................................................201 Figura 99: Screenshot del panel de la identificación de la tarea....................................202 Figura 100: El panel inicial de los recursos del agente, y cómo utilizarlo....................203 Figura 101 Un Screenshot del redactor primitivo de la tarea con las actividades principales de la etapa de la definición de la tarea demostrada]....................................203 Figura 102: Los modificantes de la condición previa]...................................................204 Figura 103: Un diagrama de la estado-transición de una negociación típica de la red del contrato]..........................................................................................................................205 Figura 104: El panel del plan de la generación, y cómo utilizarlo.................................208 Figura 105: Esquema de distribución de los containers y las plataformas.....................212 Figura 106: Ejecución de dos agentes en dispositivos móviles y su arquitectura vista en el RMA...........................................................................................................................213 Figura 107: Flujo de ejecución de un agente básico en JADE.......................................214 Figura 108: Interfaz gráfica del agente Dummy.]..........................................................218 Figura 109: Interfaz gráfica del agente DF.]...................................................................219 Figura 110 Interfaz gráfica del agente sniffer.]..............................................................220 Figura 111: Interfaz gráfica del agente introspector.].....................................................220 Figura 112 Archivos de Subasta en jade].......................................................................222 Figura 113: Cuadro comparativo....................................................................................235

INTRODUCCION La tecnología de agentes está recibiendo una gran atención en los últimos años y, como consecuencia, la industria está comenzando a interesarse en adoptar esta tecnología para desarrollar sus propios productos. Sin embargo, a pesar del rápido desarrollo de teorías, arquitecturas y lenguajes de agentes, se ha realizado muy poco trabajo en la especificación (y aplicación) de técnicas para desarrollar aplicaciones empleando tecnología de agentes. La introducción de la tecnología de agentes en la industria requiere de metodologías que asistan en todas las fases del ciclo de vida del sistema de agentes. La necesidad del empleo de estas técnicas será más importante a medida que el número de agentes de los sistemas aumente. Aunque en la comunidad multi-agente se ha mencionado que es necesario el desarrollo y aplicación de metodologías, sorprendentemente se ha realizado muy poco esfuerzo investigador en esta área. Actualmente se está realizando un notable esfuerzo en el estudio de teoría, arquitecturas y lenguajes de agentes, así como en la definición de un conjunto de primitivas para normalizar las interacciones, pero todavía no se han extendido estos avances al plano de la metodología o ingeniería del conocimiento. En muchas aplicaciones es necesario tener sistemas que puedan decidir por ellos mismos que necesitan para satisfacer sus objetivos y presentar una solución a un usuario. Tales sistemas son conocidos como agentes (agentes inteligentes o agentes autónomos), estos tienen que actuar en entornos cambiantes e impredecibles, donde existe la posibilidad de que las acciones emprendidas puedan fallar. Los agentes nacieron de la investigación en Inteligencia Artificial (IA) y más concretamente de la Inteligencia Artificial Distribuida (DIA). Al principio, la IA hablaba de los agentes como programas especiales cuya naturaleza y construcción no se llegaba a detallar. Recientemente se ha escrito mucho acerca de este tema explicando qué se puede entender por un agente y qué no, en general atendiendo a características que debe tener un agente: autonomía, reactividad, iniciativa, habilidad social, etc.

Los SMA tienen un amplio rango de aplicaciones, uno de los campos principales la constituyen los agentes software, los cuales se focalizan principalmente en la explotación cooperativa de recursos accesibles por Internet. El otro campo de aplicaciones incluye la utilización de agentes físicos y ha dado lugar a la robótica cooperativa; campo en el cual los conceptos y las teorías de SMA encuentran un mayor reto de aplicación. Los SMA, conjugan los modelos de la IA con los desarrollos de los sistemas concurrentes y distribuidos, tienen un gran potencial de aplicación para la solución de problemas de la vida práctica y por ende para el desarrollo de nuevos productos. Algunos de los campos de aplicación de los SMA incluyen: asistentes personales, supervisión hospitalaria, asistentes financieros, manipulación y filtrado de información aplicados a diferentes dominios, agentes bancarios, ventas y comercio electrónico, difusión de noticias y publicidad, realidad virtual y avatares, control de procesos y manufactura, telecomunicaciones, entre otros.

Actualmente, la comunidad científica

tanto privada

como pública y las grandes

empresas de la informática realizan trabajos en busca de normalizar los aspectos básicos de la arquitectura y formas de comunicación de los sistemas de agentes. Hasta el momento se destacan: KQML de ARPA en lo relacionado al intercambio de conocimiento, KIF en lo relativo a representación del conocimiento, ACL como lenguaje basado en el concepto de actos del lenguaje y FIPA en cuanto a la arquitectura y servicios de infraestructura. Se han propuesto algunas plataformas y arquitecturas para el desarrollo de agentes [3] Recientemente, el estándar FIPA ha tenido gran desarrollo y en

consecuencia han surgido plataformas que cumplen con este [FIPA – Fundación for Intelligent Physical Agents, http://www.fipa.org , 2006.]

Estos objetivos son seguidos hoy cuando ya numerosos agentes y sistemas multi-agentes han sido desarrollados, y a pesar que se continúa discutiendo qué es un agente. En la discusión de qué es un agente, diferentes opiniones se pueden escuchar en relación a la necesidad de la inclusión de varias características.

JUSTIFICACION Este trabajo de grado se basa en resolver el dilema existente de elegir una metodología, Pero cual es mejor. Esta pregunta no tiene una respuesta simple. Cada metodología, por el bagaje de sus creadores, se especializa en áreas concretas. Apoyándose en los resultados de la investigación en agentes y Sistemas Multi-Agente, surge una línea de trabajo cuyo propósito es consolidar la experiencia adquirida en forma de metodologías. Estas metodologías proporcionan medios para construir Sistemas Multi-Agente de forma disciplinada y repetible. En este trabajo de grado se presentan las metodologías actuales. Ante la imposibilidad de revisar todas y cada una de las existentes, se ha optado por seleccionar un conjunto significativo cercano a las prácticas de ingeniería del software. La selección atiende a la presencia de un proceso de desarrollo, el combinar diferentes vistas para describir el sistema, e incorporar elementos asociados al área de los agentes. Objetivo General Establecer un comparativo de las metodologías INGENIAS, ZEUS, MASINA aplicadas en le especificación de un sistema multi-agente de subastas.

Objetivos Específicos •

Caracterizar las principales arquitecturas de agente existentes.

•

Modelar un sistema multi-agente de subastas usando las metodologías INGENIAS, ZEUS, y MASINA.

•

Proporcionar recomendaciones para la especificación de agentes usando las metodologías INGENIAS, ZEUS, y MASINA.

•

Implementar agentes independientes en una plataforma ZEUS.

•

Implementar agentes independientes en una plataforma JADE.

CAPITULO I

MARCO TEORICO ¿AGENTE?

Básicamente, un agente es una entidad de software que exhibe un comportamiento autónomo y un sistema multi-agente es un conjunto de agentes que tienen la capacidad de interactuar en un entorno común. Así, agentes en un entorno con otros agentes poseen capacidades como la comunicación, negociación, y coordinación. Características que podemos considerar opcionales son encontradas en varios tipos de agentes, como la movilidad y, la necesidad de interacción con usuarios y el consiguiente aprendizaje de su comportamiento. 1.1 Qué es un Agente? Resulta tan embarazosa como la pregunta ¿qué es la inteligencia? El problema es que, aunque el término sea ampliamente utilizado por mucha gente, desafía los intentos de establecer una definición única y universalmente aceptada. Esto no debe ser necesariamente un problema: si se desarrollan con éxito muchas aplicaciones interesantes y útiles, entonces apenas importa que no se establezca un acuerdo sobre detalles terminológicos potencialmente triviales. Sin embargo, si no intentamos definirlo, existe el peligro de que la palabra “agente” pueda convertirse en un término mal empleado, confundiendo a la comunidad de investigadores. Se pueden encontrar una gran cantidad de definiciones. Se presentan algunas para examinarlas y compararlas. Desde una perspectiva amplia y poco limitada: “Los agentes inteligentes son programas que realizan tareas interactivas, dirigidas por la petición y los deseos de los usuarios. Poseen un grado de autonomía e independencia, en virtud del cual pueden realizar una serie de tareas sin que las personas u otros agentes les dirijan en cada paso que dan en su camino.”

El Agente AIMA [Russell y Norving 1995] “Un agente es cualquier cosa que pueda ser vista percibiendo su entorno a través de sensores y actuado hacia el entorno a través de unos efectores.” El Agente Maes [Maes 1995] “Los agentes autónomos son sistemas computacionales que habitan en entornos dinámicos complejos, percibiendo y actuando autónomamente en ese entorno, y realizan un conjunto de metas o tareas para las que han sido diseñados.” El Agente KidSim [Smith, Cyper y Spohrer] “Definiremos un agente como una entidad software persistente dedicada a un propósito específico. La ‘persistencia’ distingue a los agentes de las subrutinas; los agentes tienen sus propias ideas sobre cómo ejecutar tareas, sobre sus agendas. Con ‘propósito específico’ se distinguen los agentes de las aplicaciones multifunción, que son típicamente más pequeños.” El Agente Hayes-Roth [Hayes-Roth 1995] “Los agentes inteligentes realizan continuamente tres funciones: percibir condiciones dinámicas en el entorno, actuar afectando a las condiciones del entorno, y razonar para interpretar lo percibido; resuelven problemas, muestran interfaces y determinan acciones” El Agente IBM [http://activist.gpl.ibm.com:81/WhitePaper/ptc2.htm] ”Los agentes inteligentes son entidades software que llevan a cabo un conjunto de operaciones en beneficio de un usuario u otro programa con algún grado de independencia o autonomía, y haciendo esto, emplean algún conocimiento o representación de las metas y deseos del usuario” El Agente Wooldridge y Jennings “Es un hardware o más comúnmente un sistema software basado en computador que disfruta de las siguientes propiedades:

• autonomía: los agentes operan sin la intervención directa de personas u otros, y tienen algún tipo de control sobre sus actuaciones y estado interno. • habilidad social: los agentes interactúan con otros agentes (posiblemente humanos) vía algún tipo de lenguaje de comunicación de agentes. • reactividad: los agentes perciben el entorno o ambiente, (lo que representa la palabra físicamente, un usuario vía una interfaz de usuario, una colección de otros agentes, Internet, o quizás todos ellos combinados), y responde rápidamente a cambios que ocurren en dicho entorno. • pro-actividad: los agentes no actúan simplemente en respuesta a su entorno, sino que son capaces de exhibir ‘comportamiento dirigido hacia el objetivo’, tomando la iniciativa” El Agente FAQ: • Agentes autónomos: son programas que viajan de un sitio a otro, decidiendo ellos mismos cuándo moverse y lo que hacer. (ej. Telescript de General Magic). Es importante destacar que sólo pueden viajar entre servidores especiales. • Agentes Inteligentes: son programas que ayudan a los usuarios a hacer cosas, tales como elegir un producto, dar una guía al usuario a través de un formulario rellenado, o incluso ayudar a los usuarios a hacer sus búsquedas. • User-Agent: es el nombre técnico para los programas que realizan tareas de red para los usuarios, tales como Web User-agents como Netscape Navigator o Microsoft Internet Explorer, y Email User-Agent como Qualcomm Eudora etc. En estas definiciones, la propiedad de autonomía tiene gran importancia, y se obvia el término inteligente. Los estudiosos del tema no se ponen de acuerdo, pues algunos valoran mucho la autonomía y otros en cambio piensan que ya existían sistemas autónomos; como el control de procesos y la monitorización, y que la propiedad que caracteriza a un agente es la inteligencia. La cuestión de qué es un agente, como hemos comentado, está aún siendo debatida, corriendo el riesgo de que cualquier programa sea denominado agente. Se pueden distinguir dos nociones extremas de agentes:

• Una noción débil de agente consiste en definir un agente como a una entidad que es capaz de intercambiar mensajes utilizando un lenguaje de comunicación de agentes [4]. Esta definición es la más utilizada dentro de la ingeniería software basada en agentes, cuyo fin es conseguir la interoperabilidad entre aplicaciones a nivel semántico utilizando la emergente tecnología de agentes. • Una noción más fuerte o restrictiva de agente es la enunciada por Shoham [5] en su propuesta de programación orientada a agentes (AOP), donde un agente se define como una entidad cuyo estado es visto como un conjunto de componentes mentales, tales como creencias, capacidades, elecciones y acuerdos. Después de esbozar la definición de agente inteligente, podemos extenderla de manera natural a Sistema basado en agentes, que será el sistema que utiliza agentes para realizar su función. Si este sistema utiliza varios agentes, y éstos colaboran juntos e interactúan para resolver un problema, estaremos ante un Sistema multiagente. Debido a la controversia sobre la definición de agente (ya hemos visto varias definiciones), se ha optado por enumerar un conjunto de propiedades que lo caracterizan: autonomía, sociabilidad, reactividad, iniciativa, movilidad, veracidad, benevolencia y racionalidad. Un agente, sin embargo, no tiene porqué poseerlas todas. Varios investigadores y grupos de investigación han definido el término de agente desde diferentes puntos de vista, esto ha influido a que en la actualidad existan diferentes definiciones de lo que es un agente.

Figura 1: Descripción del agente

La dificultad se debe especialmente a que los agentes se pueden emplear en muchos dominios de aplicación, llevando consigo a que cada dominio asocie varios y diferentes atributos a la definición de agente. Por lo tanto es conveniente dar una corta definición de agente que no involucre las características que debe tener un agente inteligente. Un agente es un sistema que está en algún ambiente y que es capaz de tomar acciones autónomas de acuerdo al estado del ambiente para cumplir sus objetivos de diseño. Lo anterior no quiere decir que el agente tenga dominio completo del ambiente, por el contrario en la mayoría de situaciones este es muy complejo y el agente solo tendrá un control parcial de este. Así mismo puede suceder que para un estado del ambiente muy similar, dos acciones diferentes tomadas por el agente produzcan efectos heterogéneos en el ambiente. Las acciones que puede tomar el agente se ven afectadas por las diferentes propiedades del ambiente. 1.2

Propiedades de los Ambientes

Los ambientes pueden tener diferentes propiedades que hacen que las percepciones y acciones de un agente cambien, a continuación veremos dichas propiedades Accesibles vs. no accesibles ¿Es posible explorar toda la información necesaria? Deterministas vs. No deterministas ¿La evolución del entorno se sigue de un cómputo o hay actores que responden de forma no previsible? Episódicos vs. No episódicos ¿La acción del agente se produce bajo demanda o el agente ha de ser proactivo? Estáticos vs. Dinámicos ¿Cambia el entorno aunque no entre en acción el agente? Discretos vs. Continuos ¿El modelo del ambiente es continuo o discreto (simbólico)?

1.3

CLASES DE AGENTES [6]

1.3.1 Agentes Colaborativos Este tipo de agentes se enfatiza en la autonomía y las habilidades sociales con otros agentes para ejecutar las tareas de sus usuarios. La coordinación de los agentes se logra mediante la negociación para alcanzar acuerdos que sean aceptables para los agentes negociantes. Los agentes colaborativos son capaces de actuar racionalmente y autónomamente en ambientes multi-agente y con restricciones de recursos. Otras características de estos agentes es que poseen habilidades sociales, son proactivos, benévolos, estáticos y veraces. Los agentes colaborativos se pueden utilizar en la solución de algunos de los siguientes problemas: • Para resolver problemas que son muy grandes para un agente centralizado. • Para permitir la interconexión e interoperabilidad de sistemas de IA existentes como sistemas expertos, sistemas de soporte de decisión etc. • Solucionar problemas que son inherentemente distribuidos. • Proporcionar soluciones que simulen recursos de información distribuidos. • Incrementar la modularidad, velocidad, confiabilidad, flexibilidad y reutilización en sistemas de información. 1.3.2 Agentes de Interface Los agentes de interfaz se enfatizan en la autonomía y la adaptabilidad para realizar tareas a sus usuarios. Este tipo de agentes básicamente presta soporte y asistencia a un usuario que está aprendiendo una nueva aplicación o nuevos conceptos. El agente puede aprender mediante alguna de las siguientes cuatro técnicas, observando y monitoreando la interfaz:

1. Por observación e imitación del usuario. 2. A través de una retroalimentación positiva o negativa del usuario. 3. Recibiendo instrucciones explicitas del usuario. 4. Asesorándose de otros agentes. De esta manera el agente puede actuar como un asistente personal y autónomo del usuario, cooperando con él para terminar una cierta tarea. 1.3.3 Agentes móviles Estos agentes se enfatizan en las habilidades sociales y la autonomía, a diferencia de los agentes cooperativos, estos son móviles. Los agentes móviles son procesos de software que son capaces de transitar por una red, generalmente una WAN, interactuando con computadores alejados, reuniendo información para el usuario y volviendo a su origen cuando las tareas fijadas por el usuario se hayan completado. Las tareas que se pueden realizar son por ejemplo reservaciones de vuelos, manejo de una red de telecomunicaciones entre otras. Los agentes móviles traen con si grandes beneficios aunque no son funcionales, esto quiere decir que una tarea que realiza un agente móvil puede ser realizada por un agente colaborativo, la diferencia radica en que para movilizar el agente se requiere de un costo muy alto de recursos. Algunas de las ventajas que se pueden obtener al usar agentes móviles son: • Reducen el costo de comunicación, por ejemplo cuando en una ubicación hay un gran volumen de información que necesita ser examinada y transmitida, esto ocuparía una gran cantidad de recursos en la red y consumiría mucho tiempo. En este caso el agente móvil puede determinar la información relevante al usuario y transmitir un resumen comprimido de esta información. • Facilitar la coordinación, es más sencillo coordinar un cierto número de requerimientos remotos e independientes al comparar solo los resultados localmente. • Reduce los recursos locales, los agentes móviles pueden ejecutar sus tareas en computadores diferentes del local, de tal manera que no consuman recursos de procesamiento, memoria y almacenamiento en estos.

• Computación asíncrona, mientras que un agente móvil realiza su tarea el usuario puede ir realizando otra, de tal manera que después de un tiempo el resultado del agente móvil sea enviado al usuario. 1.3.4 Agentes de información Los agentes de información nacieron debido a la gran cantidad de herramientas que surgieron para el manejo y recuperación de información. Los agentes de información tienen los roles de manejar, manipular, e integrar información de muchas fuentes de datos distribuidas. La hipótesis fundamental de los agentes de información es que puedan mejorar de algún modo, pero no completamente el problema de la sobrecarga de información y en general el manejo de esta. • • • • • •

¿Cómo formular, describir, descomponer problemas y sintetizar resultados entre un grupo de agentes inteligentes? ¿Cómo permitir a los agentes comunicarse e interactuar? ¿Qué lenguajes de comunicación y protocolos se pueden usar? ¿Qué arquitectura es la más adecuada para construir Sistemas multi-agente prácticos? ¿Qué lenguajes y herramientas de desarrollo se pueden utilizar? ¿Cómo construir herramientas para soportar las metodologías de desarrollo?, etc.

Un Sistema Multi-Agente (SMA) es aquel que consiste de un número de agentes que interactúan entre sí. En un caso general, los agentes actúan en nombre de los usuarios, con diferentes objetivos y motivaciones. Para interactuar exitosamente, los agentes deben ser capaces de cooperar, coordinarse, y negociar con otros, tal como lo hacen los humanos.

1.4

Orígenes de los SMA

Para resolver tal tipo de problemas, el estudio de los SMA ha estado fuertemente influenciado e inspirado por varias áreas científicas: • • • • • • • 1.5

Economía Filosofía Teoría de Juegos Lógica Ecología Ciencias Sociales etc.

Taxonomía De Los Agentes

Figura 2: Taxonomía de agentes

“Se puede hacer una taxonomía más detallada de los agentes basándose en los siguientes criterios: inteligencia, autonomía, racionalidad, movilidad, comunicación y agencia. Vamos a empezar introduciendo estos términos” [7]: 1.5.1 Inteligencia: Es bastante difícil de definir con precisión. Cuando se aplica a los agentes, se podría definir la inteligencia como algunas capacidades de alto nivel, como la capacidad del agente para razonar sobre su conocimiento, aprender e inferir nuevos conocimientos, y planificar las acciones consecuentes para alcanzar sus

objetivos. En este caso, la inteligencia tiene el mismo sentido que el término "inteligencia artificial". 1.5.2 Autonomía: Existen diferentes formas de entender el término "autonomía". En el sentido más común (absoluto), la autonomía se refiere a lo impredecible del comportamiento del agente: cuanto más impredecible sea, más autonomía aparecerá. Sin embargo, la autonomía absoluta no se aplica muy bien a los agentes ya que, de acuerdo con nuestra mínima definición, un agente tiene que servir para algunos propósitos que se la limitan. Un tipo más útil de autonomía es la "autonomía social", que se refiere a la autonomía del agente cuando se pone en una sociedad de agentes. No obstante, unas relaciones más sociales, como la cooperación, coordinación y compromiso, limitan al agente. Finalmente, la ejecución de la autonomía se refiere a la capacidad del agente para elegir y llevar a cabo la acción adecuada en el momento oportuno (técnicas de planificación). De hecho, al diseñar un agente, se tiene que encontrar un fino equilibrio entre autonomía y servidumbre. Un nivel inferior puede consistir en un agente que represente a un usuario, como el bien conocido PDA (Asistente Personal Digital). 1.5.3 Racionalidad: Se aplica esencialmente a los agentes autónomos e inteligentes. Los agentes racionales tienden a elegir y realizar acciones que maximicen su esperada utilidad en función de sus percepciones y de nuestro propio conocimiento. La racionalidad también implica que la acción elegida sea consistente con los deseos y creencias del agente. 1.5.4 Movilidad: Es la capacidad que tiene un agente para iniciar su ejecución en cualquier sitio, e irse a otra posición (llevándose datos y códigos) donde continuar su ejecución. De hecho, la "movilidad" tiene dividida a toda la comunidad de agentes en dos escuelas: la de los que piensan que la movilidad no es un aspecto esencial (la comunidad de multi-agentes DAI, esencialmente académicos) y la de los que claman que los agentes móviles son el futuro de los agentes (comunidad de programadores orientados a objetos). Como sucede en todo, la verdad está en un punto intermedio. Sí parece claro que algo que puede ser hecho con los agentes móviles, puede a priori hacerse con técnicas de programación convencionales, se trata de un hecho que la programación basada en agentes móviles trae un nuevo paradigma que realza la flexibilidad y eficacia del diseño y ejecución de las aplicaciones distribuidas, y reduce el ancho de banda de red requerido. 1.5.5 Comunicación: Es un aspecto crucial para un agente, que, por definición, tiene que comunicarse durante su vida bien con la entidad en nombre de la que actúa, bien con los otros agentes con los cuales necesita colaborar. E1 nivel de interacción/comunicación depende en gran medida del nivel de conocimiento del agente, que se mueve entre "datos", "información" y "conocimiento". Los datos se corresponden con el nivel más básico, que puede ser el contenido de una variable, un archivo, etc. La

información está mucho más estructurada y puede consistir en la descripción de parte de un equipo de telecomunicación, un documento XML (eXtensible Markup Language) [XML] como un formulario de pedido (en aplicaciones de agentes de comercio electrónico), o un correo electrónico (con datos asociados). El conocimiento consiste en información estructurada y reglas lógicas. Se pueden asociar con cada nivel de información los lenguajes de comunicación y protocolos adecuados. Por ejemplo, un agente puede usar FTP (Protocolo de Transferencia de Archivos) para enviar un archivo, o llamar al método de otro agente para obtener o transmitir información. El HTTP (HyperText Transfer Protocol) se puede utilizar para transmitir descripciones XML. Finalmente, lenguajes basados en la Speech Acts Theory, como KQML/KIF (Knowledge Query and Manipulation Language/Knowledge Interchange Format) [KQML, KIF], el lenguaje de comunicación de agentes FIPA (Formation for Intelligent Physical Agents) pueden ser usados para intercambiar información. 1.5.6 Sociabilidad: los agentes son capaces de interaccionar con otros agentes (humanos o no) a través de un lenguaje de comunicación entre agentes; 1.5.7 Reactividad: los agentes son capaces de percibir estímulos de su entorno y reaccionar a dichos estímulos; 1.5.8 Pro actividad, iniciativa: los agentes no son sólo entidades que reaccionan a un estímulo, sino que tienen un carácter emprendedor, y pueden actuar guiados por sus objetivos; 1.5.9 Veracidad: asunción de que un agente no comunica información falsa a propósito; 1.5.10 Benevolencia: asunción de que un agente está dispuesto a ayudar a otros agentes si esto no entra en conflicto con sus propios objetivos. 1.6

Arquitectura Abstracta De Agentes

Asuma que un ambiente se puede encontrar en cualquiera de un conjunto finito de estados instantáneos discretos:

Se asume que un agente tiene un repertorio de posibles acciones disponibles, que transforman el estado del ambiente:

Una ejecución, r, de un agente sobre un ambiente es una secuencia de estados y acciones:

1.6.1 Funciones de Transformación de Estados Una función de transformación de Estados representa la conducta del ambiente:

Tome en cuenta que los ambientes son: Dependientes de la historia No deterministas Si ‫(ז‬r)=ø, no existen estados sucesores posibles para r (el sistema ha terminado su ejecución).

Env  E , e0 , Formalmente, un ambiente Env es una tripleta, de estados ambientales de estados

e0  E

Es el estado inicial





, donde: E es el conjunto

Es una función de transformación

1.6.2 Agentes y Acciones Un agente representa una “función” que transforma ejecuciones en acciones:

Un agente toma decisiones acerca de que acción realizar basándose en el historial del sistema hasta la fecha.

1.6.3 Sistemas de Agentes Un sistema es un par que contiene un agente y su ambiente.

Todo sistema tendrá asociado un conjunto de posibles ejecuciones. El conjunto de ejecuciones de un agente Ag en el ambiente Env se denota R ( Ag , Env)

Formalmente, una secuencia

Representa una ejecución de un agente Ag en el ambiente

e0

es el estado inicial de Env

 0  Ag (e0 )

Env  E , e0 , 

si:

1.7

Comparativa entre agentes Objetos y sistemas expertos

SMA Vs OO Los métodos de producción de software convencionales que parten de un modelo conceptual orientado a objetos están muy arraigados y es poco apreciable las ventajas que los agentes conceden. AGENTES Autonomía de decisión Flujo de control propio Encapsula la activación del comportamiento Estado mental: objetivos, creencias Comportamiento: como decir lo que hacer Interacciones: actos de habla (intencionalidad) Organización: relaciones sociales

OBJETOS Ejecuta modelos invocados Flujo de control del llamante Encapsula estado y comportamiento Estado: Valor de las variables Comportamiento: salida a partir de una entrada Mensajes invocan procedimiento Asociaciones entre objetos

SMA Vs Sistemas Expertos Un sistema experto (SE) es una rama de la Inteligencia Artificial y es aquel que imita las actividades de un humano para resolver problemas de distinto índole (no necesariamente tiene que ser de Inteligencia Artificial). También se dice que un SE se basa en el conocimiento declarativo (hechos sobre objetos, situaciones) y el conocimiento de control (información sobre el seguimiento de una acción), mientras que los agentes evocan unas grandes ventajas. AGENTES Interactúan con el entorno Distribución de la toma de decisiones: Comportamiento emergente Mayor grado de interacción con el usuario Interacción con otros agentes

1.8 CONSTRUCCIÓN DE SMA

SISTEMAS EXPERTOS Sistemas cerrados Sistemas de decisión centralizados Interacción con el usuario bajo petición del usuario Normalmente carecen de habilidades sociales (cooperación).

Figura 3: Componentes de SMA

La construcción de SMA integra tecnologías de distintas áreas de conocimiento: técnicas de ingeniería del software para estructurar el proceso de desarrollo; técnicas de inteligencia artificial para dotar a los programas de capacidad para tratar situaciones imprevistas y tomar decisiones, y programación concurrente y distribuida para tratar la coordinación de tareas ejecutadas en diferentes máquinas bajo diferentes políticas de planificación. Debido a esta combinación de tecnologías, el desarrollo de SMA se complica. Existen plataformas de desarrollo que dan soluciones parciales al modelado de comportamiento y a la coordinación de agentes. El rango de estas soluciones va desde proporcionar servicios básicos (gestión de agentes, librerías de algoritmos, localización de agentes o movilidad), como JADE, Grasshopper o ABLE, hasta entornos de desarrollo donde se parametrizan armazones (framework) software, como ZEUS o AgenTool. Aunque facilitan el proceso, las plataformas de desarrollo quedan incompletas sin un proceso de desarrollo de software especializado para agentes que haga similar la creación de SMA a la producción de software convencional. Las técnicas convencionales de ingeniería (Unified Process), CommonKADS no tienen en cuenta las necesidades de especificación de los SMA, como la especificación de planificación de tareas, intercambio de información con lenguajes de comunicación orientados a agentes, movilidad del código o motivación de los componentes del sistema. Por ello, se plantean nuevas metodologías basadas en agentes (BDI, Vowel Engineering, MAS-CommonKADS, GAIA. Estas metodologías parten de un modelo, informal en la mayoría de casos, de cómo debe ser un SMA y dan guías para su construcción. En las primeras metodologías, las guías consistían en una lista breve de pasos a seguir. Las más modernas, aunque han progresado en la integración con la ingeniería del software clásica, aún no muestran la madurez que se puede encontrar en metodologías convencionales como el Unified Process. El motivo principal es que siguen faltando herramientas de soporte y un lenguaje para la especificación del SMA que permitan trabajar de forma similar a como se trabaja en Rational Rose, TogetherJ o

Paradigm+. Existe una gran cantidad de metodologías y cada día van creciendo en paridad a grupos de investigación que las proponen; De entre las metodologías existentes, se ha seleccionado un conjunto utilizando tres criterios: utilización de diferentes vistas para la especificación del sistema, incorporar la idea de proceso de desarrollo, e integrar técnicas de ingeniería y teoría de agentes. De acuerdo con estos criterios, se han identificado tres metodologías. La primera es MAS-CommonKADS y posterior su estudio evolutivo hacia Masina que, debido a su origen (CommonKADS, se trata de una metodología orientada al desarrollo utilizando experiencia en sistemas expertos. A continuación brevemente el diseño basado en BDI que ha influido notablemente en la forma de concebir el control de los agentes. Después, se estudian metodologías soportadas por herramientas: ZEUS. Por último, INGENIAS, creada a partir del trabajo de MESSAGE. Tras la presentación de estas metodologías, se presenta una sección para orientar en la elección de una metodología, otra en la que se dan referencias de trabajos en la evaluación de metodologías y una última orientada a proporcionar más información y otros puntos de vista acerca de las metodologías existentes. 1.8.1 ¿Qué es un Sistema Multi-agente? Hasta el momento, tenemos la noción de agentes autónomos individuales. Un Sistema Multi-agente (SMA) contiene cierto número de agentes que • • • •

Interactúan a través de la comunicación Son capaces de actuaren el ambiente Tienen diferentes “esferas” de influencia Están conectados por relaciones en la organización

1.8.2 Lenguajes de agentes y el diseño de Sistemas Multi-Agente Los lenguajes de agentes parten, en su mayoría, de modelos operacionales que definen la semántica de sus instrucciones. Estos modelos se suelen describir informalmente, aunque también existen trabajos que primero parten de un modelo operacional expresado como arquitectura software que luego es formalizado, como es el caso de AgentSpeak (L). El trabajo más referenciado en lenguajes de agentes es Agent0 que acuñó el término programación orientada a agentes. Agent0 propone un nuevo paradigma de programación en el que la entidad principal es el agente. En Agent0, un agente es una entidad cuyo estado se ve como un conjunto de componentes mentales tales como creencias, habilidades, elecciones y compromisos. Con estas entidades y un conjunto de

primitivas, como enviar mensaje, comprometerse o solicitar la ejecución de una tarea, se elabora un lenguaje de descripción de agentes. Se hallan otros lenguajes que siguen el modelo de Shoham como CASA o PLACA. Estos lenguajes añaden principalmente la capacidad de planificar acciones de los agentes en el SMA. Desde un punto de vista metodológico, el principal problema de estos lenguajes es su aplicación a desarrollos de complejidad media. Los lenguajes de agentes pueden verse como lenguajes de implementación de más alto nivel que otros más convencionales como C++ o JAVA, pero con una particularidad: son muy pobres en mecanismos de abstracción y encapsulación. Los programas o especificaciones generados con ellos tienen como unidad principal de encapsulación el agente y de abstracción procedimental la tarea, lo cual limita su aplicación. Así pues, a los problemas de desarrollar un sistema directamente con un lenguaje de implementación se une la falta de medios para realizar esta tarea incrementalmente. Entonces, la necesidad de metodologías es doblemente justificable. Por un lado, para cubrir las deficiencias de los lenguajes de agentes en cuanto a mecanismos de encapsulación y abstracción. En este sentido, las metodologías actuales definen elementos que les sirven para agrupar las distintas funcionalidades asociadas a un agente o a un grupo de agentes. Así aparecen conceptos como rol o servicio. Y por otro lado, para facilitar la comprensión de sistemas complejos tal y como ocurre con los lenguajes convencionales de implementación. Este aspecto, como se verá en las secciones posteriores, no se haya resuelto completamente en las metodologías existentes, ya que la idea de desarrollo incremental no aparece de forma explícita. 1.8.3 Plataformas para diseño de Sistemas Multi-Agente El desarrollo de SMA hoy en día es más proclive a la utilización de plataformas de desarrollo que a la aplicación de lenguajes de agentes. Esto se debe en gran parte al nivel de conocimientos necesarios que generalmente implica programar con un lenguaje de agentes. Por ello, han proliferado por un lado armazones software de SMA adaptables a diferentes dominios de aplicación y por otras plataformas de desarrollo de ámbito genérico que son implementaciones de estándares de agentes. Aunque el desarrollo con los armazones es más sencillo, hoy en día predominan los segundos. Las plataformas de desarrollo más extendidas son JADE Y Grasshopper. JADE es la implementación oficial del estándar FIPA, y soporta todos los servicios básicos de infraestructura especificados en FIPA (comunicaciones, movilidad, gestión de agentes y localización de agentes), a los que añade algunas utilidades gráficas para facilitar la administración de las plataformas y la depuración de los mensajes intercambiados por agentes en tiempo de ejecución. Grasshopper es la implementación del estándar MASIF,

que soporta la movilidad de agentes en un entorno distribuido utilizando comunicación y servicios CORBA. En JADE y Grasshopper existe una arquitectura básica de agente que hay que utilizar para acceder a los servicios de la plataforma correspondiente. El diseño de agentes con estas plataformas significa atenerse a unos estándares de comunicación y de gestión de agentes. El resto, como la especificación del control del agente, su inteligencia o las relaciones entre las tareas del sistema, se deja al criterio del desarrollador. La aportación de una metodología a desarrollos basados en este tipo de plataformas consistiría en organizar el proceso de generación del SMA y en proporcionar elementos para el diseñador pueda describir estos aspectos teniendo en cuenta las restricciones de la plataforma destino. En cuanto a los armazones software, la aportación de las metodologías varía según el caso. ZEUS, por ejemplo, presenta un entorno de desarrollo con el que se programa visualmente el SMA. Las posibilidades de configuración del SMA a través de este entorno son muy variadas. Entre otros, hay que suministrar una ontología, reglas de comportamiento, planes de ejecución de tareas y mensajes a enviar a otros agentes. Debido a esta versatilidad en su configuración, el diseño con ZEUS se hace tan complejo como programar con lenguajes de agentes. Aunque se facilita el desarrollo de aspectos como la coordinación, quedan pendientes decisiones como qué hay que coordinar y para qué. Por ello, la aportación de una metodología en este caso consistiría en proporcionar un ciclo de desarrollo, actividades y elementos conceptuales que ayudasen al descubrimiento incremental de los elementos requeridos por ZEUS. Un ejemplo, aunque limitado, de metodología para ZEUS se tiene de mano de sus propios desarrolladores [Collis y Ndumu], donde se aplica la idea de rol para guiar el descubrimiento de funciones del sistema. ABLE (Agent Building and Learning Environment) aunque también permite el prototipado rápido de SMA, no llega al nivel de ZEUS. ABLE es una herramienta de IBM para la construcción de sistemas de agentes inteligentes donde todos sus elementos, incluso los agentes, se construyen por composición de AbleBeans, una extensión de los JavaBeans. Son de interés un conjunto de AbleBeans especializados que implementan sistemas de aprendizaje estadísticos (mapas auto organizativos, redes neuronales, mapas de conexión) y control simbólico (razonamiento por encadenamiento hacia delante y lógica de predicados). ABLE incorpora también un entorno visual de desarrollo donde se interconectan AbleBeans. El interés de esta plataforma es que soluciona visualmente la construcción y comunicación de los agentes. ABLE no llega a detallar cómo se obtiene la funcionalidad de los agentes y cómo deben actuar en cada situación. La aportación de una metodología a ABLE sería más amplia que en el caso de ZEUS. Se trataría de dar medios para detallar aspectos de control del

agente teniendo en cuenta los elementos de control que vienen predefinidos en ABLE. Sería útil, por ejemplo, la idea de casos de uso [Jacobson, Booch y Rumbaugh 00] para identificar conjuntos de funciones a proporcionar por el sistema y escenarios para describir cómo se espera que se realice el proceso de aprendizaje de los agentes.

Figura 4: Plataformas para diseño de Sistemas Multi-Agente

1.9 METODOLOGIAS EXISTENTES Aquí un pequeño resumes de ellas Apoyándose en los resultados de la investigación en agentes y Sistemas Multi-Agente, surge una línea de trabajo cuyo propósito es consolidar la experiencia adquirida en forma de metodologías. Estas metodologías proporcionan medios para construir Sistemas Multi-Agente de forma disciplinada y repetible. En este trabajo se presenta un resumen de lo que proponen las metodologías actuales. Ante la imposibilidad de revisar todas y cada una de las existentes, se ha optado por seleccionar un conjunto significativo cercano a las prácticas de ingeniería del software. La selección atiende a la presencia de un proceso de desarrollo, el combinar diferentes vistas para describir el sistema, e incorporar elementos asociados al área de los agentes. Se dejan para el siguiente capítulo el estudio detallado de las metodologías seleccionadas para implementación 1.9.1 Vowel Engineering Se trata de la metodología seguida en el grupo MAGMA. El término vowel engineering viene de que el sistema final depende de la ordenación y agrupamiento de cuatro vocales A (por agentes), E (por entorno), I (por interacciones) y O (por organización). Los modelos de agente abarcan desde simples autómatas hasta complejos sistemas basados en conocimiento. La forma de ver las interacciones van desde modelos físicos (propagación de onda en el medio físico) hasta los actos del habla (speech acts). Las organizaciones van desde aquellas inspiradas en modelos biológicos hasta las gobernadas por leyes sociales basadas en modelos sociológicos. El propósito de Vowel engineering es lograr librerías de componentes que den soluciones al diseño de cada uno de estos aspectos, para que posteriormente, el diseñador seleccione un modelo de agente, un modelo de entorno, un modelo de interacciones y modelos de organización a instanciar.

Figura 5: Arquitectura de capas de Vowel Engineering

Como ejemplo, propone para aspectos de interacción un lenguaje para la descripción de protocolos de interacción basado en procesos de comunicación síncronos o asíncrono donde la semántica es muy similar a la de los actos del habla. La representación en sí se hace mediante redes de transición en las que los arcos se corresponden con los mensajes intercambiados y los estados reflejan la situación global (i.e. no hay posibilidad de que un estado se refiera al estado de un agente concreto). Una de las más recientes publicaciones de Vowel Engineering propone la implementación mediante la plataforma Volcano. La plataforma utiliza el ensamblaje de componentes utilizando lenguajes de composición arquitecturas, concretamente UniCon. El desarrollo consiste en ensamblar componentes que pueden ser desarrolladas ad-hoc o proceder de una librería. Cada componente pertenece a una categoría concreta de las cuatro consideradas. Pese a que en la literatura se indica que existe un entorno de desarrollo basado en estas ideas, este no es público. De todas formas, el trabajo desarrollado dentro de MAGMA con esta metodología es reseñable debido a su variedad en los dominios de aplicación (Sistemas de información geográfica, Robocup, simulaciones de mercados o agentes en tiempo real). Vowel Engineering ha sido una de las primeras metodologías en modelar sistemas utilizando diferentes vistas. Aunque es prometedor, el trabajo en Vowel Engineering está incompleto ya que no termina de estabilizarse con herramientas de soporte. Además, no existen instrucciones acerca de cómo describir cada uno de los aspectos considerados.

A favor de esta metodología está la visión del modelado de sistemas como composición de elementos. Esta composición se define con un lenguaje apropiado para el problema como es un lenguaje de descripción de arquitecturas, Unicon en este caso. Como consecuencia de esta forma de desarrollo, hay que señalar que facilita la reutilización de código. Metodológicamente es mejorable. 1.9.2 MaSE [11]

Figura 6: MaSE

MaSE (Multi-agent systems Software Engineering) se concibe como una abstracción del paradigma orientado a objetos donde los agentes son especializaciones de objetos. En lugar de simples objetos, con métodos que pueden invocarse desde otros objetos, los agentes se coordinan unos con otros vía conversaciones y actúan pro activamente para alcanzar metas individuales y del sistema. En MaSE los agentes son simplemente una abstracción conveniente, que puede o no poseer inteligencia. En este sentido, los componentes inteligentes y no inteligentes se gestionan igualmente dentro del mismo armazón. Dado el enfoque inicial, los agentes se ven como especializaciones de objetos. De hecho, el sistema se construye sobre

tecnología orientada a objetos y su aplicación a la especificación y diseño de sistemas multi-agente. El análisis en MaSE consta de tres pasos: capturar los objetivos, aplicar los casos de uso y refinar roles. El diseño consta de cuatro pasos: crear clases de agentes, construir conversaciones, ensamblar clases de agentes y diseño del sistema. La mayoría de estos pasos se ejecutan dentro de la herramienta que soporta MaSE, AgentTool. Como productos de estas etapas, MaSE espera: diagramas de secuencia para especificar interacciones, diagramas de estados para representar procesos internos a las tareas y modelar interacciones, descomposición del sistema (agente) en subsistemas (componentes del agente) e interconexión de los mismos (definición de la arquitectura del agente). Estos elementos son característicos del UML, de hecho su uso recuerda mucho a SDL [International Telecommunication Union 99 A.D.b]. Además, la integración de estos diagramas en el proceso de desarrollo parece demasiado simple. Al final, la metodología podría traducirse como tome la herramienta de soporte y rellene los diferentes apartados. Esto supone ignorar que, como en el modelo BDI, se tienen dependencias entre los diagramas propuestos (como entre los diagramas de secuencia y las conversaciones) y que no es tan sencillo el saber qué máquinas de estados definen la ejecución de una tarea en el contexto de una interacción. La herramienta de soporte permite generar código automáticamente a partir de la especificación. La generación de código es independiente del lenguaje de programación utilizado, ya que se realiza recorriendo las estructuras de datos generadas en la especificación y generando texto como salida. No obstante, el proceso de generación de código es mejorable, ya que el código de los componentes a generar está entremezclado con el código que lee la especificación. 1.9.3 GAIA [12][13] GAIA es una metodología para el diseño de sistemas basados en agentes cuyo objetivo es obtener un sistema que maximice alguna medida de calidad global (no se llega a detallar cuál). GAIA pretende ayudar al analista a ir sistemáticamente desde unos requisitos iníciales a un diseño que, según los autores, esté lo suficientemente detallado como para ser implementado directamente. En GAIA se entiende que el objetivo del análisis es conseguir comprender el sistema y su estructura sin referenciar ningún aspecto de implementación. Esto se consigue a través de la idea de organización. Una organización en GAIA es una colección de roles, los cuales mantienen ciertas relaciones con otros y toman parte en patrones institucionalizados de interacción con otros roles. Los roles agrupan cuatro aspectos: responsabilidades del agente, los recursos que se le permite utilizar, las tareas asociadas

e interacciones. GAIA propone trabajar inicialmente con un análisis a alto nivel. En este análisis se usan dos modelos, el modelo de roles para identificar los roles clave en el sistema junto con sus propiedades definitorias y el modelo de interacciones que define las interacciones mediante una referencia a un modelo institucionalizado de intercambio de mensajes, como el FIPA-Request. Tras esta etapa, se entraría en lo que GAIA considera diseño a alto nivel. El objetivo de este diseño es generar tres modelos: el modelo de agentes que define los tipos de agente que existen, cuántas instancias de cada tipo y qué papeles juega cada agente, el modelo de servicios que identifica los servicios (funciones del agente) asociados a cada rol, y un Modelo de conocidos, que define los enlaces de comunicaciones que existen entre los agentes. A partir de aquí, los autores de GAIA proponen aplicar técnicas clásicas de diseño orientado a objetos. Sin embargo, GAIA declara que queda fuera de su ámbito. Esta metodología sólo busca especificar cómo una sociedad de agentes colabora para alcanzar los objetivos del sistema, y qué se Requiere de cada uno para lograr esto último. 1.9.4 MESSAGE [34] MESSAGE trata de integrar resultados de las anteriores. Propone el análisis y diseño del SMA desde cinco puntos de vista para capturar los diferentes aspectos de un SMA: el de Organización, que captura la estructura global del sistema; el de Tareas/Objetivos, que determina qué hace el SMA y sus agentes constituyentes en términos de los objetivos que persiguen y las tareas implicadas en el proceso; el de Agente, que contiene una descripción detallada y extensa de cada agente y rol dentro del SMA; el de Dominio que actúa como repositorio de información (para entidades y relaciones) concernientes al dominio del problema; y el de Interacción, que trata las interacciones a distintos niveles de abstracción. Estos elementos están presentes en los dos modelos fundamentales que propone MESSAGE: el modelo de análisis y el modelo de diseño. El modelo de análisis se limita a generar modelos a partir de los meta-modelos. El modelo de diseño no llegó a concretarse completamente. Se decidió que el propósito del diseño sería producir entidades computacionales que representen el SMA descrito en el análisis. Por ello, cada artefacto producido en el análisis debería transformarse en una entidad computacional o varias cuyo comportamiento fuera el que se esperaba en el análisis. Esto significa que las entidades del análisis se deberían traducir a subsistemas, interfaces, clases, signaturas de operaciones, algoritmos, objetos, diagramas de objetos y otros. MESSAGE aporta mejoras en cuanto a conceptos de ingeniería respecto de las alternativas existentes, entre ellas el desarrollo dentro de un paradigma de ingeniería del software (el Proceso Racional Unificado), aportación de métodos para la traducción de entidades de análisis a entidades de diseño y guías para la generación de los modelos.

Sin embargo, los objetivos de MESSAGE no se completaron totalmente. La integración con el Proceso Racional Unificado no fue total, ya que las actividades definidas no se adecuaban a las necesidades reales y no se indicó cómo encajaban dentro de este proceso. Además, faltó trabajo en el estudio de las interdependencias entre los distintos modelos propuestos. A favor de MESSAGE hay que destacar que ha sido la primera metodología en utilizar una herramienta para soporte del proceso de especificación de SMA de forma visual, como en UML. En cuanto a la implementación, MESSAGE provee guías en cuanto a posibles arquitecturas y componentes a utilizar en esta etapa. Basándose en estas guías y los modelos de análisis y diseño, se realizó manualmente la implementación, lo cual hizo que se detectaran incorrecciones en las definiciones iníciales de los modelos. Esta experiencia es la base de la crítica realizada con anterioridad a ZEUS.

Figura 7: Metodologías

1.10. ESTANDARES ACEPTADOS 1.10.1 Estándares FIPA (www.fipa.org) •

JADE http://jade.cselt.it

•

LEAP (para PDAs) http://leap.crm-paris.com

•

FIPA OS http://fipa-os.sourceforge.net

•

JACK http://www.agent-software.com

•

ZEUS (BT) http://193.113.209.147/projects/agents/zeus/

Agentes móviles (MASIF, FIPA) •

Grasshopper http://www.grasshopper.de

•

Aglets (IBM) http://sourceforge.net/projects/aglets/

No estándares •

ABLE (IBM) http://www.alphaworks.ibm.com/tech/able

1.10.2 Organizaciones de estandarización •

OMG (Object Management Group) o Mobile Agent System Interoperability Facilities (MASIF)

•

KSE (Knowledge Sharing Effort) o Knowledge Querying and Manipulation Language (KQML) o Knowledge Interchange Format (KIF)

•

FIPA (Foundation for Intelligent Physical Agents) o Especificaciones de arquitectura, infraestructura y aplicaciones

•

Agent Society o Arquitectura y protocolos de comunicación genéricos

30

1.11. Plataformas para el Desarrollo de Sistemas Multi-agente En general la implementación de aplicaciones con sistemas multi-agente ha sido realizada por expertos donde los agentes, la plataforma de comunicación y el protocolo de interacción han sido programados en forma ad-hoc para cada sistema. A pesar que estas aplicaciones se basan en los mismos conceptos teóricos de agentes y sistemas multi-agente, al momento de implementarlas se han utilizado diferentes lenguajes de programación de propósito general, y cada aplicación ha resuelto el mismo problema de diferente manera. Por ejemplo, el protocolo de comunicación entre agentes ha sido resuelto de diferentes maneras en la mayor de las aplicaciones. Las plataformas de desarrollo de sistemas multi-agente coinciden en algunas características básicas, pero sin embargo, poseen capacidades diferentes y están orientadas a diferentes escenarios. A pesar de que el uso de una plataforma acelerara el desarrollo de la aplicación, el aprendizaje y uso de estas plataformas no es trivial, y requerirla de un tiempo extra considerable que se sumarla al del desarrollo de la aplicación. Por lo tanto, elegir la plataforma adecuada resulta fundamental. Sin embargo, esto es motivo nuevamente de la consulta a expertos que posean los elementos de juicio necesarios para la evaluación de la plataforma adecuada para el escenario de la aplicación. Como se trabajaran dos plataformas en un aplicativo, a continuaron solo menciono algunas otras existentes para poder tener un punto de vista más objetivo 1.11.1 JACK [14]

JACK provee un entorno de desarrollo orientado a agentes construido sobre Java y completamente integrado con este lenguaje de programación. Incluye todas las componentes del entorno de desarrollo de Java, y además incluye las siguientes extensiones específicas para implementar el comportamiento de los agentes: (a) define nuevas clases base, interfaces y métodos (b) provee extensiones a la sintaxis de Java para soportar clases orientadas a agentes y (c) provee extensiones semánticas para soportar la ejecución del modelo.

31

Incluye a JACK Agent, un lenguaje orientado a agentes y utilizado para implementar sistemas de software orientados a agentes. JACK Agent no solo extiende la funcionalidad de Java, sino que además provee un entorno para soportar un nuevo paradigma de programación. Como JACK fue desarrollado para proveer una extensión de Java orientada a agentes, el código JACK es primero compilado a código Java regular antes de ser ejecutado. La relación entre JACK y Java es análoga a la relación entre los lenguajes C++ y C. Todas las formas en las que extiende a Java, son implementadas como plug-ins, lo que permite que el lenguaje sea lo más extensible y exigible posible. Las metas más importantes en el diseño de JACK fueron proveer a los desarrolladores de un producto robusto, estable y liviano, satisfacer una variedad de necesidades prácticas, facilitar la transferencia de tecnología de la investigación a la industria, y permitir la investigación aplicada. Los agentes JACK no están ligados a ningún lenguaje de comunicación entre agentes particular. Sin embargo, nada previene la adopción de un protocolo simbólico de alto nivel como KQML o FIPA ACL, posiblemente integrando software existente en el dominio público. Además, JACK provee una infraestructura de comunicaciones para situaciones donde se requiere alta performance. Desde la óptica de un programador, JACK ofrece tres extensiones a Java: un lenguaje de agentes, un compilador de agentes y un kernel de agentes. A continuación se describe cada una de ellas brevemente. El lenguaje de agentes JACK: este lenguaje es un súper conjunto de Java utilizado para describir un sistema orientado a agentes. Las diferencias con el lenguaje Java son un conjunto de agregados que se detallan a continuación: Un pequeño conjunto de palabras claves para la identificación de los componentes principales de un agente. Un conjunto de sentencias para la declaración de atributos y otras características de los componentes. Todos los tributos son fuertemente tipados. Un conjunto de sentencias para la definición de relaciones estáticas.

32

Un conjunto de sentencias para la manipulación de los estados de un agente. Además, el programador puede usar sentencias Java dentro de las componentes de un agente. Para la conveniencia de los programadores, en particular aquellos con conocimientos en inteligencia artificial, JACK también soporta variables lógicas y sin instanciar. Su semántica es un intermedio entre los lenguajes de programación en lógica (con el agregado del chequeo de tipos del estilo de Java) y SQL embebido. El compilador de agentes JACK: La segunda extensión es un compilador que convierte las extensiones descriptas anteriormente a clases Java y sentencias que pueden ser cargadas con, y ser llamadas por, otro código Java. El compilador también transforma parcialmente el código de los planes para obtener la semántica correcta de la arquitectura BDI El kernel de agentes JACK: Finalmente, un conjunto de clases (llamado kernel) provee el soporte de tiempo de ejecución para el código generado. Este incluye: La administración automática de la concurrencia. El comportamiento normal del agente en la reacción a los eventos y falla de acciones y tareas. Una infraestructura liviana de comunicaciones de alta performance para las aplicaciones multi-agente. 1.11.2 MADKit (Multi-Agent Development Kit) [15]

MADKit es una plataforma multi-agente para desarrollar y ejecutar aplicaciones basadas en un paradigma orientado a la organización. Este paradigma utiliza a los grupos y los roles como base para construir aplicaciones complejas. MADKit no está asociado a ninguna arquitectura de agentes en particular, permitiendo a los usuarios de esta plataforma implementar libremente sus propias arquitecturas.

33

MADKit permite el desarrollo de aplicaciones distribuidas de manera muy simple. Para los programadores, consideraciones acerca de componentes distribuidos básicos (como “sockets” o “ports”) son totalmente transparentes. Una aplicación desarrollada en MADKit puede ser ejecutada en forma distribuida sin cambiar ninguna línea de código. Los mecanismos de distribución de MADKit no utilizan las técnicas de RMI o CORBA de acceso remoto, lo cual brinda un modo más eficiente de comunicación. La plataforma MADKit está construida alrededor del concepto de Agente/Grupo/Rol desarrollado en el contexto del proyecto AALAADIN. MADKit implementa y usa su propio modelo de administración. A continuación se presentan algunas características generales de este modelo. Un agente es especificado como una entidad activa que se comunica, la cual posee roles dentro de los grupos. Esta definición de agentes es intencionalmente general para permitir a los diseñadores de agentes adoptar el modelo de agente más preciso relacionado con sus aplicaciones. El modelo no restringe la arquitectura interna de los agentes. El diseñador es el responsable de elegir el modelo más apropiado de agente de acuerdo a sus necesidades o preferencias. Los grupos son definidos como conjuntos atómicos de agregaciones de agentes. Cada agente es parte de uno o más grupos. En su forma básica, el grupo es solo una manera de nombrar un conjunto de agentes. En una forma más desarrollada, en conjunción con la definición de rol, puede representar cualquier sistema multi-agente. Un agente puede ser miembro de un grupos al mismo tiempo. Un grupo puede ser fundado por cualquier agente. El rol es una representación abstracta de la función de un agente, servicio o identificación dentro de un grupo. Cada agente puede manejar múltiples roles y cada rol manejado por un agente es local a un grupo. Manejar un rol en un grupo debe ser requerido por el agente candidato, y no es necesariamente otorgado. Los esquemas abstractos de comunicación son definidos como roles. El modelo no es una descripción estática de la organización de un agente. También permite definir reglas para especificar la parte dinámica de la organización de un agente.

34

1.11.3 JAFMAS (Java Framework for Multi-agent Systems) [16]

Figura 8: JAFMAS

JAFMAS provee una metodología genérica para desarrollar sistemas multi-agente basados en los actos del habla junto con un conjunto de clases para soportar la implementación de estos agentes en Java. La intención del framework es asistir a los desarrolladores principiantes y expertos a estructurar sus ideas en aplicaciones de agentes concretas. El soporte para la comunicación está provisto para ambos casos de comunicación, directo y broadcast basado en sujetos. El soporte lingüista es provisto por los lenguajes de comunicación basados en los actos del habla (Ej.: KQML). El soporte de coordinación proviene de la conceptualización de los planes de un agente y su coordinación como conversaciones basadas en reglas representadas mediante modelos de autómatas. 1.11.4 GRASSHOPPER AGENTS [17][18] Grasshopper (A Universal Agent Plataform Based on OMG MASIF and FIPA Standards) es una plataforma para el desarrollo y la ejecución de agentes móviles escritos en lenguaje Java creada por la empresa alemana IKV++ y que cumple con las normas especificadas en MASIF por el O.M.G. La arquitectura de esta plataforma consta de los siguientes elementos: Agencia: entorno mínimo de ejecución para agentes móviles y estáticos. Núcleo de la agencia: contiene las funciones básicas de la agencia (comunicación, registro, seguridad y persistencia). Lugar: agrupación funcional lógica dentro de una agencia. Región: mantiene un registro de todos los componentes pertenecientes a una determinada organización. 35

Figura 9: Arquitectura Gasshopper

Las características principales de Grasshopper son: Soporta interacción mediante CORBA, RMI o sockets. Permite transparencia respecto a la localización de los objetos. La comunicación entre agentes puede ser asíncrona, dinámica o multipunto. Puede trabajar con los siguientes ORB: JDK 1.2 de Sun, VisiBroker de Inprise y OrbixWeb de IONA. Los agentes, otros entornos y las aplicaciones normales pueden acceder a la funcionalidad de agencias remotas y del registro de la región. Cada agencia mantiene servicios de seguridad interna y externa. Soporta las siguientes operaciones para la gestión de agentes: creación, borrado, suspensión, reanudación, clonación, copia, migración, almacenamiento e invocación de acciones.

36

1.11.5 Comparación JACK MADKit ZEUS

Figura 10: Comparación JACK MADKit ZEUS

37

1.12 ARQUITECTURAS DE AGENTES Bajo el concepto de arquitectura de agente subyace la descripción particular de los elementos que constituirán un agente concreto y como estos elementos interactúan entre sí. En este punto comentaremos primera una breve clasificación de agentes para a continuación presentar diferentes arquitecturas que hacen uso del concepto de agente en un sentido más o menos amplio. Algunas de ellas además están pensadas para el funcionamiento conjunto de agentes desarrollando lo que se conoce como arquitecturas multi-agente. Se ha estudiado fundamentalmente aquellas que pretenden ser aplicadas a entornos de tiempo real o al menos con capacidad reactiva. Una primera división de las arquitecturas considera el acceso a los sensores y actuadores. En concreto si todas las capas de la arquitectura tienen acceso a dichos componentes se considera una arquitectura horizontal. Por el contrario, en las arquitecturas verticales, sólo la capa inferior tiene acceso a ellos. Otra posible clasificación atendería al tipo de procesamiento empleado, distinguiendo en este caso las arquitecturas deliberativas, las reactivas y las híbridas. Las arquitecturas deliberativas son aquellas que manejan símbolos físicos. Se indica que estas arquitecturas deben ser capaces de describir objetivos y como alcanzarlos. Normalmente hacen uso de técnicas de planificación para determinar qué pasos realizar. Una subdivisión de este grupo, contemplaría las arquitecturas intencionales, aquellas en que los agentes pueden razonar sobre sus creencias e intenciones, y las sociales donde cada agente es capaz de mantener un modelo de otros agentes y razonar sobre ello. Normalmente presentan una estructura horizontal. Las arquitecturas reactivas por el contrario no presentan un modelo de razonamiento simbólico complejo, sino un modelo estimulo-respuesta. En este caso las arquitecturas son verticales, donde las capas superiores especializadas manejan directamente los datos, inhibiendo las capas inferiores y obteniendo las acciones a realizar ante dichas entradas. Finalmente las arquitecturas híbridas presentan varios subsistemas, unos deliberativos para resolver tareas que requieren un modelo simbólico y otros reactivos para responder ante estímulos que no requieren deliberación.

Una metodología particular para construir agentes. Especifica cómo puede descomponerse el agente construyendo un conjunto de componentes modulares y cómo deben realizarse estos módulos para que interactúen. El conjunto total de módulos y sus interacciones tienen que dar una respuesta a la pregunta de cómo los datos de los sensores y el estado interno actual del agente determinan las acciones y el futuro estado

38

interno del agente. Una arquitectura comprende técnicas y algoritmos que soportan esta metodología.”. 1.12.1 Arquitectura BDI [9]

Figura 11: Arquitectura BDI

Las arquitecturas BDI se inspiran en un modelo cognitivo del ser humano. Según esta teoría, los agentes utilizan un modelo del mundo, una representación de cómo se les muestra el entorno. El agente recibe estímulos a través de sensores ubicados en el mundo. Estos estímulos modifican el modelo del mundo que tiene el agente (representado por un conjunto de creencias). Para guiar sus acciones, el agente tiene Deseos. Un deseo es un estado que el agente quiere alcanzar a través de intenciones. Éstas son acciones especiales que pueden abortarse debido a cambios en el modelo del mundo. Aunque la formulación inicial es de Bratman, fueron Georgeff, Rao y Kinny quienes formalizaron este modelo y le dieron aspecto de metodología. De hecho es su trabajo, y no el original de Bratman, lo que aquí se comenta. Para especificar el sistema de agentes, se emplean un conjunto de modelos que operan a dos niveles de abstracción: externo e interno. Primero, desde un punto de vista externo, un sistema se modela como una jerarquía de herencia de clases de agentes, de la que los agentes individuales son instancias. Las clases de agente se caracterizan por su propósito, sus responsabilidades, los servicios que ejecutan, la información acerca del mundo que necesitan y las interacciones externas. Segundo, desde un punto de vista interno, se emplean un conjunto de modelos (modelos internos) que permiten imponer una estructura sobre el estado de información y motivación de los agentes y las estructuras de control que determinan su comportamiento (creencias, objetivos y planes en este caso). En esta metodología, la integración con el ciclo de vida de software es reducida. Los autores proponen una serie concreta de pasos para generar los modelos. Estos pasos se repiten haciendo que los modelos, que capturan los resultados del análisis, sean progresivamente elaborados, revisados y refinados. Además, el refinamiento de los 39

modelos internos conlleva la realimentación de los modelos externos. Por ejemplo, el construir los planes y creencias de una clase de agente clarifica qué nivel de detalle se requiere en la representación del mundo que posee el agente. inicializar -estado (); repetir opciones:= generadorOpciones(colaEventos); opcionesSeleccionadas:=deliberar(opciones); actualizarIntenciones(opcionesSeleccionadas); ejecutar(); obtenerNuevosEventosExternos(); eliminarAccionesTerminadasConExito(); eliminarAccionesImposiblesDeTerminarConExito(); fin repetir Control interno de los agentes BDI Se imponen varias restricciones sobre la arquitectura que soporte estos modelos: que asegure que los eventos se responden en su momento, que las creencias se mantengan consistentemente, y que la selección de planes y ejecución se desarrolle de manera que refleje ciertas nociones de racionalidad.

1.12.2 Arquitectura de sistemas inteligentes adaptativos [35] AIS Adaptative Intelligent Systems. Es una arquitectura pensada para el desarrollo de agentes inteligentes que trabajen en entornos de alta variabilidad. Se trata por tanto de una arquitectura que debería funcionar en entornos de tiempo real aunque no estricto. Su nombre procede de la capacidad de adaptación que deben tener los agentes para poder trabajar en esos entornos de alta variabilidad. Para conseguirlo el agente podrá variar varias de sus características en función de la situación de cada momento. En concreto podrá variar su estrategia de percepción, el modo de funcionamiento del control y del meta-control, así como los métodos de razonamiento usados. La arquitectura presenta tres componentes básicos que reflejan las operaciones básicas de cualquier agente, es decir, percibir, razonar y actuar. Estos componentes son: Modulo de percepción. No se encarga únicamente de recoger datos del exterior sino también de filtrarlos y hacer un proceso de abstracción con ellos. El objetivo es reducir la cantidad de información a manejar por el agente, centrándose este en los datos más interesantes en cada momento.

40

Figura 12: Arquitectura AIS

El subsistema cognitivo. Recibe e interpreta los datos que le manda el sistema de percepción (al cual también guía en el proceso de filtrado), realiza el razonamiento en función del conocimiento existente y elabora los planes que guían tanto su funcionamiento como el del resto de módulos. Utiliza para ello una arquitectura de pizarra que permite una planificación dinámica. Subsistema de acción. Se encarga de ejecutar aquellas acciones externas calculadas por el subsistema anterior. Como se puede ver por la funcionalidad de estos módulos los agentes operaran en función tanto de los datos externos como del proceso de razonamiento que es capaz de realizar, siendo su funcionamiento flexible para adaptarse a las circunstancias del entorno en cada momento.

Es de destacar la existencia de un agente denominado “Guardián” construido con esta arquitectura, encargado de la vigilancia de pacientes en unidades de cuidados intensivos. 1.12.3 ATLANTIS [36] Arquitectura diseñada para ser aplicada en tareas robóticas, por lo que dispone de una alta reactividad, aunque incorporando mecanismos que le permitan ser lo bastante flexible para trabajar en entornos complejos. Se basa en una estructura multicapa, donde las capas superiores controlan las inferiores hasta cierto punto, pues estas actúan en un modo semi independiente.

41

La capa inferior representa la parte en contacto con el exterior, que realiza funciones de percepción y acción, leyendo de los sensores y mandando órdenes a los actuadores. La capa intermedia o de secuenciación, señala las acciones a tomar en función de los datos recibidos. Esta operación la realiza de acuerdo a un mapping interno que puede ser cambiado en función de la evolución del sistema. La capa superior o deliberativa, dispone de descripciones simbólicas del entorno, y se encarga de desarrollar planes para la obtención de los objetivos de alto nivel.

1.12.4 CIRCA [37][38] CIRCA son las siglas de Arquitectura de Control en tiempo Real Inteligente Cooperativo. Esta arquitectura forma parte del reducido grupo que pretende utilizar técnicas potentes de inteligencia artificial en entornos de tiempo real. Debido a la naturaleza impredecible de la mayoría de dichas técnicas, la apuesta de CIRCA para conseguir el uso de la inteligencia artificial en estos entornos, es la separación del sistema que se encarga de la parte de tiempo real y del que se encarga de las tareas inteligentes, ambos elementos están relacionados a través de un modulo de planificación. Los elementos básicos que maneja esta arquitectura son los denominados pares testacción (PTA). Estos pares constan, como su nombre indica, de un conjunto de precondiciones, que marcan cuando pueden ser aplicados y de las acciones a realizar si se ejecutan. Además, y para poder ser planificados, los PTA dispone de información acerca de los recursos que necesitan para su ejecución y el tiempo en el peor de los casos para evaluar las precondiciones y ser ejecutados.

Figura 13 : Arquitectura CIRCA

El subsistema de inteligencia artificial es el encargado de las tareas en principio más

42

complejas, para ello descompone sus objetivos en elementos más simples, hasta llegar al nivel de PTA. Estos PTA’s serán enviados al planificador para el estudio de su viabilidad. El planificador construye planes con los PTA’s usando la información que posee sobre los tiempos máximos de ejecución. Si la información recibida del sistema inteligente no es planificable, devolverá la petición a dicho sistema. Además detecta la existencia de tiempo excedente y lo comunica al sistema inteligente para que lo utilice en la ejecución de tareas no críticas. El sistema de tiempo real se encarga de ejecutar tareas predecibles. Para ello comprueba las precondiciones y ejecuta las acciones según los planes de PTA que le informa el planificador. 1.12.5 HOMER [39] Modelo muy orientado a la utilización de técnicas de inteligencia artificial, pues se basa en el desarrollo de una arquitectura que disponga de elementos encargados de la planificación, módulos de gestión de memoria, otros para los procesos reactivos incluso para interpretar el lenguaje natural y generación de mensajes al usuario.

Figura 14: Arquitectura HOMER

Su autonomía es limitada pues funciona bajo demanda del usuario. Así mismo el conocimiento que maneja es limitado pues se desarrolló para un ambiente determinado, la simulación de un entorno submarino.

43

1.12.6 ICARUS [40] Esta arquitectura presenta una estructura jerárquica donde vuelven a aparecer los elementos que hemos visto en otras arquitecturas. Dispone de los módulos de percepción, de acción y de planificación de las operaciones a realizar. Así como de un modulo de almacenamiento de la información.

Figura 15: Arquitectura ICARUS

El ciclo de control también es típico. El módulo de percepción toma información del exterior. Esta información junto a la que ya posee el sistema es usada por el planificador para generar un plan. El tercer módulo se encarga tanto de ejecutar este plan como de monitorizarlo. En esta arquitectura es importante el tratamiento que se hace de la información. Al trabajar en entornos dinámicos, permite por un lado el mantenimiento de información contradictoria y sobre todo el tratamiento incremental que hace de los planes. Estos no necesitan ser finalizados en su elaboración, para comenzar a ser ejecutados. La monitorización que realiza el módulo de acción permite su continuación completándolo de forma incremental o bien realizar una re planificación si el comportamiento se aleja de lo esperado. 1.12.7 Motor de reducción de entropía [41] Esta arquitectura hace uso de uno de los conceptos que mencionábamos anteriormente para integrar la inteligencia artificial en entornos de tiempo real: la computación anytime. Y lo hace no en el sentido de que aplique algoritmos anytime a las tareas a resolver, sino que la propia planificación que el sistema realiza es anytime. Esto le permite ejecutar planes no finalizados en su totalidad y que puede ir completando según las restricciones en cada momento.

44

Figura 16: Arquitectura MRE

De nuevo aparece la división de tareas que hemos visto en arquitecturas anteriores. Aquí se trata de tres módulos, encargados de las operaciones de planificación, scheduling y control. El primero llamado reductor sería el módulo cognitivo de alto nivel, encargado de elaborar estrategias para resolver el problema actual. Estas estrategias las generará basándose en estrategias ya existentes y en su propia experiencia. El segundo módulo recibe el nombre de prospector. En base a las estrategias generadas por el módulo anterior planificará y asignará las acciones a realizar por el tercer módulo. El tercer módulo, el ejecutor sería el componente de acción existente en otras estrategias, controlando su ejecución 1.12.8 PHOENIX [42] Este proyecto tiene como objetivo el diseño de agentes autónomos, que operen en entornos complejos y que combine componentes reactivos junto a componentes deliberativos. La arquitectura que presenta PHOENIX para el desarrollo de un agente propone cuatro componentes diferenciados. Por una parte están los típicos módulos de relación con el exterior, por un lado el de los sensores y por otro el de actuadores.

45

Figura 17: Arquitectura PHOENIX

A continuación se encuentran los módulos que generan la respuesta. Existen para ello dos módulos. El primero es el de acción refleja, compuesto de pares estímulo respuesta, cuya acción se calcula directamente con la llegada del estímulo del entorno y que se utiliza cuando no se dispone de suficiente tiempo para que entre el modulo de más alto nivel. El módulo de alto nivel, o módulo cognitivo se encarga de calcular respuestas más complejas (y costosas), así como de realizar planificación, coordinación entre agentes, análisis de la percepción, monitorización de las acciones, etc. Es de destacar que PHOENIX presenta no sólo la arquitectura para construir los agentes, sino las herramientas para construir un entorno simulado (en concreto de control de extinción de bosques) para la validación de los agentes. Esto es especialmente importante debido a la Complejidad de los agentes es necesario disponer de entornos de simulación lo suficientemente ricos para realizar pruebas con garantías. 1.12.9 PRODIGY [43] Esta arquitectura es de tipo modular y se basa en la utilización de la lógica de primer orden como mecanismo de representación del conocimiento. La lógica es usada para representar las reglas de inferencia y de control, el meta-conocimiento y los hechos del problema.

46

Figura 18: Arquitectura PRODIGY

El control es bastante simple, ya que emplea una estrategia de búsqueda, donde a partir del conocimiento que dispone selecciona un nodo que expande y aplica todos los operadores posibles hasta llegar a la solución. Esta arquitectura hace especial énfasis en el aprendizaje, pues permite aplicar simultáneamente diferentes técnicas, cada una llevada a cabo por un módulo de aprendizaje diferente y que no interfieren entre sí. 1.12.10 PRS [44] PRS son las siglas de “Procedural Reasoning System” un sistema de razonamiento general para entornos de tiempo real. Un agente PRS consta de una serie de elementos para realizar dicho razonamiento. Estos elementos son: una base de datos, con las creencias que tiene el agente sobre el estado actual del entorno; un conjunto de objetivos que deben ser alcanzados por el agente; una biblioteca de procedimientos denominados áreas de conocimiento que describen cómo y cuándo actuar; y una estructura de intenciones, que consiste en un conjunto parcialmente ordenado de planes que indican que elemento elegir para ejecutar. Otro de los elementos es el intérprete, este debe ser visto como un mecanismo de inferencia, que maneja los componentes anteriores, seleccionando planes en función de los datos existentes y de los objetivos, modifica la estructura de intenciones, y ejecuta los planes. Las áreas de conocimiento describen, tal y como se ha indicado previamente, las acciones a llevar a cabo para resolver el problema. En realidad estas áreas no solo describen las operaciones que realizan sino también que condiciones deben darse en el 47

estado actual y que eventos deben haberse producido para que dicha área pueda ejecutarse. Además existe meta-áreas de conocimiento, que funcionan de forma similar a las anteriores pero cuyo objetivo es guiar el proceso de solución indicando al agente como debe manejar sus objetivos, creencias, etc., en función de la situación. Finalmente indicar que la necesaria conexión con el exterior es efectuada en este caso a través de la propia base de datos, que dispone de sistemas de mantenimiento de la consistencia para mantener en un estado fiable las creencias que se tiene sobre el entorno. 1.12.11 SOAR [45] Esta arquitectura está basada en la existencia de diferentes estrategias de control, que aunque dirigidas por el objetivo, presentan diferentes alternativas a la hora de tratar los datos (que toman la forma de pares atributo-valor) y por tanto de obtener los resultados. Entre las estrategias se encuentran las que están basadas en ciclos de decisiones secuenciales o en paralelo, las guiadas por interrupciones, que le permiten un comportamiento más reactivo, o las basadas por la no existencia de valores.

Figura 19: Arquitectura SOAR

La estrategia basada en la no existencia de valores basa su funcionamiento en completar aquellos atributos sin valor. Para ello si no consigue determinar un valor para un atributo, por ejemplo por la existencia de ambigüedades, el sistema dividirá el objetivo en subobjetivos, de forma que sean estos los que guíen ahora el proceso de búsqueda, en principio de una forma más efectiva al ser más específicos.

48

Arquitecturas de sistemas de agentes (Ferber)

Figura 20: Arquitecturas de agentes]

1.13 ¿Cuándo aplicar el desarrollo basado en agentes? El desarrollo basado en agentes es una técnica relativamente nueva para abordar el diseño de sistemas en general (no sólo de información). Como en todos los campos de la ciencia, y más en Informática, cuando aparece una técnica nueva, debemos preguntarnos: ¿qué nos ofrece?, es decir, ¿qué tienen los agentes que ofrecernos? Para que una técnica sea considerada de interés, debe cumplir al menos uno de estos dos criterios: •

capacidad para resolver problemas que se han salido fuera del campo de la automatización, ya sea porque la tecnología existente no puede usarse para resolver el problema o porque se considera que es muy costoso (en términos de dificultad, tiempo ó riesgo) desarrollar soluciones con la tecnología actual

•

capacidad de resolver problemas ya resueltos de manera que su resolución con la nueva tecnología resulte más barato, más natural, más sencillo o más eficiente.

49

1.13.1 Resolviendo nuevos tipos de problemas Ciertos tipos de sistemas software son inherentemente más difíciles de designar e implementar correctamente. La clase más simple de sistemas software son los funcionales. Estos sistemas trabajan obteniendo alguna entrada, realizando una función con ella y produciendo una salida. Los compiladores son un caso obvio de sistemas funcionales. En contraste, los sistemas reactivos, que mantienen continua interacción con algún sistema, son mucho más difíciles de diseñar e implementar. Sistemas de control de procesos, sistemas operativos y sistemas de configuración de red son ejemplos claros de sistemas reactivos. En todos esos ejemplos, se desea que un sistema pueda trabajar de forma independiente durante largos períodos de tiempo. Este tipo de programas es de los más difíciles de implementar, y por eso se ha empleado mucho trabajo en diseñar herramientas software, lenguajes de programación y metodologías para manejar esa complejidad. Sin embargo, todavía quedan distintos tipos de programas que son tan difíciles que pocas herramientas ayudan. Se requerirán nuevas técnicas. Se pueden caracterizar en tres tipos:

•

Sistemas abiertos

•

Sistemas complejos

•

Sistemas de computación ubicuos.

Un sistema abierto es uno en el que la estructura del sistema mismo puede cambiar dinámicamente. La característica de este tipo de sistemas es que sus componentes no se conocen de antemano, pueden cambiar con el tiempo y pueden llegar a ser muy heterogéneos (desarrollados por diferentes personas, en períodos diferentes, utilizando diferentes lenguajes y herramientas de diseño, etc.) Este tipo de programas tienen cada vez más demanda por los usuarios. El ejemplo más conocido de este tipo de entornos es Internet. Internet puede ser vista como un sistema de información distribuido, con sus nodos implementados y mantenidos por distintas compañías. Cualquier sistema que actúe en Internet debe ser capaz de interactuar con los distintos nodos sin la ayuda constante de los usuarios, pero, sin embargo, entre límites bien definidos. Esa funcionalidad se apoya decididamente en los sistemas de cooperación de los sistemas multi-agentes.

50

Los sistemas complejos son tratados a través de la modularidad y la abstracción para dividirlos en partes más pequeñas que interactúan entre sí para resolver el problema completo. En estos sistemas, la visión de agentes colaborando entre sí para resolver el problema es una visión más natural que las usadas convencionalmente. Para muchos sistemas, esta visión es simplemente más apropiada que las demás alternativas. A medida que los ordenadores se van haciendo más ubicuos, nuevos usuarios con menos conocimientos llegan a usarlos. Los programas deben cambiar: en vez de tener que especificar el conjunto de instrucciones hasta un alto nivel de detalle, los programas deben cooperar con el usuario para alcanzar los objetivos que este último desee. Para obtener este tipo de funcionalidad, las aplicaciones software tienen que ser: •

autónomas: dadas unas especificaciones vagas e imprecisas, deben determinar cómo se resuelve el problema de la mejor manera y resolverlo, sin el continuo apoyo del usuario

•

oportunistas: no deberían esperar a que se les diga qué hacer después. En vez de eso deberían hacer sugerencias al usuario

•

reactivas: deben tener en cuenta los cambios en las necesidades del usuario y los cambios en el entorno

•

adaptativas: deben intuir o conocer las preferencias del usuario y adaptar las interacciones para reflejarlas

En otras palabras, se deben comportar como un agente inteligente.

51

1.14 Definición ejemplo “SMA Subasta” Las subastas son un mecanismo para la fijación de precios en el que la negociación se ciñe a un proceso sumamente simple de coordinación. En este suelen intervenir compradores y vendedores, pero el intercambio mismo se suele realizar gracias a un intermediario - el subastador - que presenta los bienes a intercambiar y va presentando (o recibiendo) ofertas por dichos bienes siguiendo alguna convención de puja preestablecida que determina tanto la secuencia de ofertas, como la manera como se designa al ganador y el monto al que se adjudica el bien. 1.14.1 ¿Qué es una subasta? El sistema se concibe como un Sistema Multi-Agente en el que el usuario es representado entre un agente conocido como el subastador y un conjunto de agentes conocido como los postores. El objetivo de la subasta es que el subastador asigne un bien a uno de los postores En muchos escenarios, el subastador desea maximizar el precio mientras que los postores desean minimizarlo. 1.14.2 Parámetros de una Subasta Bienes pueden tener • Valores privados • Valores públicos La determinación del ganador puede estar basada en: • Primer precio • Segundo precio Ofertas pueden ser • Abiertas a todos • “Sobrecerrado” El ofrecimiento puede ser • • •

One shot Ascendente descendente

52

1.14.3 Negociación Subastas solo se preocupan de la asignación de bienes: se requieren mejores técnicas para lograr acuerdos La Negociación es el proceso de lograra cuerdos en temas de interés común. Un escenario de negociación tiene 4 componentes: • • • •

Un conjunto de negociación ( propuestas posibles) Un protocolo. Estrategias privadas( una por cada agente) Una regla que determina cuando se ha logrado un trato y cuales el acuerdo.

Pero ¿qué pasa con agentes heterogéneos y self-interested? En este caso los sistemas: • • • •

No están diseñados centralizadamente No existe la noción de utilidad global Son dinámicos No actúan “benévolamente” a menos quesea parte de sus intereses de esa forma.

1.14.3.1

Atributos de la negociación

Eficiente: Estable: Simple: Distribuida: Simétrica:

Optimo de Pareto No hay incentivo para desviarse Bajo costo computacional y de comunicación No hay toma de decisiones centralizada Agentes toman roles equivalentes.

1.14.4 TIPOS DE SUBASTA 1.14.4.1

Subasta inglesa

Características habituales: • primer precio • abierta • ascendente

53

hacerlo

Estrategia dominante: pujar por una cantidad poco mayor que la más alta hasta alcanzar el valor máximo 1.14.4.2

Subasta holandesa

Características habituales: • Primer precio • Abierta • Descendente Funcionamiento: El subastador comienza por un valor artificialmente alto se va bajando el precio hasta que alguien realiza una oferta al precio actual El género se vende al agente que ha realizado la oferta En algún caso, puede comprarse sólo una parte del género (si admite partirse en lotes) No hay estrategias dominantes 1.14.4.3

Subasta a sobre cerrado

Características habituales: • • •

Primer precio, en sobre cerrado Cerrada puja única

El género se vende a aquel que ofrece el mayor precio Se paga el valor de la puja más alta Estrategia dominante: pujar por debajo del valor propio 1.14.5 Protocolo de negociación: Concesión monótona Reglas del protocolo Se realizan varias rondas en la primera ronda, los agentes sugieren un trato simultáneamente acuerdo: cuando un agente detecta que el trato del otro es al menos tan bueno como el suyo si no hay acuerdo, se lanza otra ronda ningún agente puede proponer un trato peor para los demás que en la ronda anterior si ningún agente realiza una concesión, la negociación termina con el acuerdo conflicto.

54

Se garantiza que el protocolo termina con un acuerdo (el número de tratos posibles es finito)

1.14.6 Estrategia de negociación: La estrategia de Zeuthen Problemas del protocolo (a resolver por cada agente) ¿Cuál debe ser la primera propuesta? ¿Quién debe ceder en cada ronda? ¿Cuánto se debe ceder? El acuerdo más favorable El agente con menor riesgo de conflicto Lo justo para salir del riesgo 1.14.7 Riesgo de conflicto Un agente tendrá más riesgo de conflicto cuando la diferencia de utilidad entre la propuesta actual y el acuerdo conflicto es baja. Disponibilidad al conflicto de un agente i en la ronda t se mide

Función de riesgo:

Convenciones para el registro de participantes y bienes, convenciones sobre garantías y pagos, comisiones, precios de salida, etc. y suelen referirse a las casas de subastas" como instituciones. Se harán cumplir convenciones explicitas de tres tipos: Convenciones Ontológicas y de Comunicación en las que se esclarecen tanto los elementos que conlleva una subasta, como el significado de las ilocuciones que se intercambian dentro de una casa de subastas.

55

Convenciones Sociales que reglamentan las interacciones de los participantes en una subasta mientras intervienen en ella. Reglas de conducta individual a las que están sujetos los participantes de una subasta y que establecen los compromisos, obligaciones y derechos que les atañen.

56

CAPITULO II 2.

INGENIAS [19]

Parte del trabajo de MESSAGE, es una metodología que ha tenido un gran impacto en la comunidad dedicada al estudio de los agente software. Como muestra de esta influencia, está la metodología que se presenta en esta sección, INGENIAS. INGENIAS como evolución de las ideas de MESSAGE. INGENIAS profundiza en los elementos mostrados en el método de especificación, en el proceso de desarrollo, además de incorporar nuevas herramientas de soporte y ejemplos de desarrollo. INGENIAS, como MESSAGE, define un conjunto de meta-modelos (una descripción de alto nivel de qué elementos tiene un modelo) con los que hay que describir el sistema. Los meta-modelos indican qué hace falta para describir: agentes aislados, organizaciones de agentes, el entorno, interacciones entre agentes o roles, tareas y objetivos. Estos metamodelos se construyen mediante un lenguaje de meta-modelado, el GOPRR (Graph, Object, Property, Relationship, and Role). En la construcción de estos meta-modelos se integran resultados de investigación en forma de entidades y relaciones entre entidades. La instanciación de estos meta-modelos produce diagramas, los modelos, similares a los que se usa en UML, con la diferencia de que estos diagramas se han creado exclusivamente para definir el sistema multi-agente. El proceso de instanciación de los meta-modelos no es trivial. Existen muchas entidades y relaciones a identificar, además de dependencias entre distintos modelos. Por ello, INGENIAS define un conjunto de actividades cuya ejecución termina en un conjunto de modelos. Estas actividades a su vez se organizan siguiendo un paradigma de ingeniería del software, el Proceso Unificado. La ejecución de actividades para producir modelos se basa en la herramienta INGENIAS IDE, una herramienta para modelado visual. Esta herramienta almacena la especificación del sistema utilizando XML.

57

Figura 21: pantalla principal de ingenias

Desde la especificación en XML, se plantea el procesarla: · Para generar código. Genera código rellenando plantillas de código con información de la especificación. · Para generar la documentación. De una forma similar a la generación de código, se parte de plantillas de documentación que se completan utilizando información de los modelos Tanto la herramienta de análisis/diseño como el editor se pueden encontrar en http://ingenias.sourceforge.net. Desde esta web también se tiene acceso a ejemplos de especificación siguiendo la metodología. 2.1

Nomenclatura

El nombre asociado a las relaciones obedece a unas reglas sencillas mostradas. Se trata de hacer que el nombre de la relación sea precedido por un conjunto de letras que denote su procedencia, como el flujo de trabajo (WF), meta-modelo de agente (A), interacción (I), unidad de interacción (UI), modelos de tareas y objetivos (GT), relaciones sociales (AGO), organización (O) o el entorno (E).

58

Figura 22: Expresión BNF para la los nombres de las relaciones

2.1.1 Entidades básicas La metodología proporciona una jerarquía de conceptos básicos para el desarrollo de un SMA así como una notación para representar estos conceptos. La jerarquía comienza con la Entidad MAS GRASIA y la Relación MAS GRASIA, que reciben este nombre por el grupo de investigación en que han sido desarrolladas (GRupo de Agentes Software del departamento de Sistemas Informáticos y progrAmación o GRASIA)

Figura 23: Entidades básicas de la metodología

59

2.1.2 Notación Los diagramas correspondientes al nivel del modelo (M2) que se presentan a lo largo de este trabajo utilizan una notación desarrollada ad hoc con la herramienta METAEDIT+. Y posteriormente exportados a la herramienta de trabajo INGENIAS IDE Para entender los diagramas se debe revisar antes la notación.

60

Figura 24: Notación empleada en la representación de los modelos

61

2.2

META-MODELOS DEL SISTEMA MULTI AGENTE

Un meta-modelo define las primitivas y las propiedades sintácticas y semánticas de un modelo. A diferencia de otros enfoques más formales, como Z, los meta-modelos están orientados a la generación de representaciones visuales de aspectos concretos del sistema de forma incremental y flexible. Los modelos crecen incorporando más detalle gracias a que no es necesario que se instancien absolutamente todos los elementos del meta-modelo para tener un modelo. Como ha demostrado UML, construido también con meta-modelos, este tipo de notación facilita enormemente el desarrollo de sistemas. Otra ventaja de utilizar meta-modelos es que las especificaciones generadas de SMA son lo suficientemente estructuradas para ser procesadas de forma automática. Así, se puede plantear la verificación automática de la construcción de los modelos para ver si cumplen restricciones identificadas por el desarrollador, generar documentación del sistema en diferentes formatos de diferentes partes de los modelos, e incluso establecer la generación automática de código desde la información recogida en los modelos. El meta-modelado se comprende a partir de una estructura de cuatro niveles. En esta estructura, el nivel M1 establece las primitivas de meta-modelado, esto es, el lenguaje de meta-modelado. En el nivel M2, se definen los meta-modelos en sí con las primitivas de M1. En M3 se aplican los meta-modelos para generar instancias, que se denominan modelos. Por último, la instanciación de los modelos, lleva al nivel donde se tiene la información que se manejará en el sistema.

Figura 25: Estructura de cuatro niveles utilizada en el meta-modelado

62

2.2.1 Modelo de organización La organización define una estructura donde van a existir los agentes, recursos, tareas y objetivos Estructura. Descomposición de la organización en: • • • • • • • • • • • •

Grupos Flujos de trabajo Interrelación de tareas en flujos de trabajo Relaciones entre agentes respecto a las tareas Recursos disponibles y asignación Relaciones sociales Relaciones de poder (p.ej. subordinación) y cliente/servidor entre agentes Relaciones entre grupos Relaciones entre organizaciones Funcionalidad Propósito Tareas que debe realizar

Figura 26: Descripción estructural

63

DESCRIPCIÓN SOCIAL

En concreto, aquí se incluyen relaciones de subordinación, de prestación de un servicio y de cliente de un servicio. Estas relaciones se definen teniendo como extremos posibles organizaciones, agentes, roles y grupos.

Figura 27: Descripción social

DESCRIPCIÓN FUNCIONAL El objetivo del flujo de trabajo es establecer cómo se asignan los recursos, qué pasos (tareas) son necesarios para la consecución de un objetivo, y quiénes son los responsables de ejecutarlas. Según el WorkFlow Management Coalition (WfMC), un flujo de trabajo [Workflow Management Coalition 99] es la automatización de un proceso de negocio, en su totalidad o parcialmente, durante el cual los documentos, información o tareas son pasados de un participante a otro, de acuerdo con un conjunto de reglas procedimentales. En el flujo de trabajo, se habla de actividades en lugar de tareas7, aunque en este contexto se pueden emplear indistintamente.

Figura 28: Descripción funcional

64

2.2.2 Modelo de agente El meta-modelo de agente se usa para describir agentes particulares excluyendo las interacciones con otros agentes. Este meta-modelo se centra en la funcionalidad del agente y en el diseño de su control. En este sentido, proporciona información acerca de los siguientes aspectos: Descripción de agentes particulares Funcionalidad del agente: Responsabilidades Qué tareas sabe ejecutar Qué objetivos se compromete a alcanzar

Comportamiento: Control del agente Estado mental Agregación de entidades mentales: objetivos, creencias, compromisos, hechos Gestión de estado mental Creación, destrucción, modificación de las entidades del estado mental Mecanismo de decisión: procesador de estado mental Reglas, planificación, etc.

65

Figura 29: Elementos del modelo de agente

Figura 30: Diagrama del modelo de agente

66

Planificador clásico Las tareas transforman entidades mentales para alcanzar objetivos del agente

Figura 31: Agente planificador

2.2.3

Modelo de objetivos y tareas

Qué consecuencias tiene la ejecución de tareas y por qué se deberían ejecutar Justifica la ejecución de tareas basándose en objetivos Que a su vez se van modificando tras su ejecución Objetivo: Situación deseada Conjunto de estados que el agente quiere lograr, mantener, o evitar Una función de utilidad que maximizar Responde a ¿por qué? Tarea: Transiciones de estado Conduce a la consecución de objetivos Responde a ¿cómo? 67

Figura 32: Ciclo de vida de un objetivo

Descomposición de objetivos

Figura 33: Árboles Y/O

68

Figura 34: Elementos de definición de tareas

Relaciones entre tareas y objetivos

Figura 35: Una tarea afecta a un objetivo

69

Ejemplo de tareas

Figura 36: Ejemplo de Tareas

2.2.4

Modelo de interacciones

Intercambio de conocimiento o peticiones (intencionalidad) entre agentes. Define las interacciones entre los agentes o entre agentes y humanos, se definen a alto nivel, en diseño se detalla el protocolo de interacción, se puede usar el concepto de protocolo de interacción de Agent UML o los protocolos de Gaia Definición de interacciones Qué actores participan en la interacción, cada actor debe mostrar la razón por la que participa, roles iniciador y colaboradores, definición de unidades de interacción, mensajes, actos de habla Orden de las unidades de interacción Protocolos: contract net, FIPA request, específicos. Diagramas de protocolos AUML Acciones ejecutadas en la interacción Criterios para decidir cuándo ejecutar una tarea, consecuencias de la ejecución de una tarea

70

Definición del contexto de la interacción Objetivos que persigue la interacción, estado mental de los participantes Modelo de control Mecanismos de coordinación, comunicaciones entre agentes, actos del habla, determina un conjunto de primitivas con las que se comunican los agentes request:solicitar la ejecución de una acción inform: modificar la información que almacena un agente not-understood: no se ha comprendido el mensaje Necesita de un lenguaje de contenido • •

XML SL0

Una ontología A qué se refieren los elementos que aparecen en el mensaje, un protocolo Fipa-request: solicitar de un agente la ejecución de una tarea Protocolo

Figura 37: Protocolos FIPA_CONTRCTNET

71

2.2.5

Modelo de entorno

Define las entidades del entorno del SMA con las que vaya a interactuar Recursos Elementos consumibles o no consumibles: Descriptores de ficheros, hilos de ejecución, memoria, dispositivos de E/S, sockets, ancho de banda, etc. Aplicaciones Uso más complejo, por medio de alguna interfaz, se pueden ver como objetos o como agentes Agentes Satisfacen el principio de racionalidad Tipos de entorno Accesible/Inaccesible Capacidad para percibir todo el entorno Determinista/No determinista Dado un estado y una acción ejecutada, se puede predecir el siguiente estado Episódico/No episódico La experiencia del agente se puede segmentar en episodios independientes Estático/Dinámico El mundo no cambia mientras el agente delibera Continuo/Discreto Existe un conjunto finito de variables a observar y un conjunto finito de acciones posibles Formas de modelar el entorno Representar el mundo que rodea al agente Tarea extremadamente difícil Enfoque pragmático y redes neuronales Discretizar el entorno utilizando un conjunto finito de variables observables Categorizar el tipo de entidades relevantes del entorno Restringir la interacción (percepción y actuación) con estas entidades: Recursos Aplicaciones Agentes 72

Ejemplo de entorno Entorno para un asistente de ficheros en un PC

Figura 38: Entorno de asistente de ficheros de un pc

Son muchos diagramas, entidades y relaciones Por ello se define Un proceso de desarrollo Compuesto de actividades Y que determina entregas a realizar Un entorno de desarrollo que facilite la implementación Y damos Ejemplos de modelado Una tesis doctoral que describe la notación y el proceso Otras tesis próximamente (extensiones)

73

2.3

CASO DE ESTUDIO SUBASTA EN INGENIAS

Como un ejemplo de uso de de la metodología ingenias IDE podemos probar un ejemplo que corresponde al planteado en esta tesis. El ejemplo es muy simple sólo para ilustrar la funcionalidad básica de IDE. Ha sido desarrollado pensando solo en mostrar la funcionalidad del la metodología y la herramienta. Aunque no indica todas características que pueden ser especificadas en un sistema multi- Agente, provee la lo suficientemente información conseguir algunos agentes correr sobre una plataforma de Agente existente definitivamente. Primero realizamos un pequeño esbozo de lo que será nuestro sistema En esta etapa el objetivo es convencerse de que el desarrollo es posible. Para ello se identifican los casos de uso más importantes que reflejen los problemas principales que se van a encontrar y cuáles van a ser los componentes del sistema que participarán en su resolución. 2.3.1 Casos de uso asociados al problema

Figura 39: Casos de usos subasta

74

2.3.1.1

Definir tipo de subasta:

Se definirá que tipo de subasta será implementada para un artículo en particular (Subasta Inglesa [Por defecto en y único en esta versión] / Holandesa / Sobre serrado) para poder definir qué tipo de protocolo se seguirá. 2.3.1.2

Subastar Artículos:

Se incluyen los artículos a subastar y se publican con el tipo de subasta, el agente subastador y el precio base 2.3.1.3

Buscar Artículos:

Se realiza una búsqueda del articulo a adquirir al encontrarlo se comprueba que el precio base no sobrepase el precio tope. 2.3.1.4

Realizar puja:

Se realiza la puja por el artículo seleccionado, según criterios de riesgo beneficio 2.3.1.5

Anunciar puja mayor:

Se publica la puja ganadora hasta el momento para que los postores realicen una puja mayor, si no se obtiene una puja mayor de cierto tiempo se declara como la puja final y ganadora. 2.4

FUNCIONAMIENTO DEL IDE

Al iniciar el IDE, el editor principal aparecerá como se muestra a continuación. Algunos mensajes salen en el tabulador de Logs para indicar que algunos módulos del IDE han sido cargados.

75

Figura 40: IDE pantalla principal

Para empezar a trabajar, se deberá crear un nuevo proyecto El editor guarda estas especificaciones usando XML para que otras herramientas externas poder analizarlos y producir la otra clase de productos. También, el editor suministra el acceso para plugins instalados en el tiempo de ejecución, y puede cargar nuevos plugins en el tiempo de ejecución.

76

2.4.1. Partes del editor Relacionados indican lo diferente partes de el editor.

Figura 41: Partes del editor

2.4.2 proyecto y visualización de proyecto, organizado como un árbol, las diagramas diferentes de un proyecto. Los diagramas son representados con iconos especiales, y son los permisos del árbol. Los diagramas pueden ser agrupados en paquetes, que son representados como carpetas. Las acciones frecuentes en la vista de proyecto lo son: Arrastrar. Se puede arrastrar y bajar un diagrama en un paquete o un paquete en otro paquete. Abrir un diagrama. Haciendo doble clic con el botón de ratón izquierdo en el nombre de diagrama o el icono, el diagrama se abrirá en la ventana de diagrama Creación de un paquete. Para crear un paquete, se debe seleccionar un paquete primero, haciendo clic en el botón derecho del ratón y seleccionar. Añadir paquete en el menú emergente. Seleccionado una vez, escribir un nombre. 77

Creación de un diagrama. Crear un diagrama, seleccionando primero un paquete, se hace clic en el botón derecho del ratón y se selecciona el tipo de diagrama en el menú emergente. Escribir un nombre. Renombrar. Seleccionar el diagrama, y luego hacer clic en el botón derecho del ratón y seleccionar poner un nuevo nombre. Escriba el nuevo nombre, y luego aceptar. Modificar las propiedades de un diagrama. Algunos diagramas tienen propiedades especiales. Éstos pueden ser accedidos a través del menú emergente provocado en hacer clic con el botón derecho del ratón en un icono de diagrama. Las propiedades son modificadas del mismo modo como las propiedades de objeto. 2.4.3

la vista de Entidades

La visualización de Entidades contiene una visualización árbol –igual a la de clases de entidades que existen en la especificación. El árbol indica tipos y ejemplos de tipo en curso (las entidades en la especificación, que puede salir en algunos diagramas). Los tipos son representados por carpetas. Los ejemplos de tipo son distinguidos por iconos diferentes de las carpetas. Algunas operaciones pueden ser llevadas a cabo sobre cada entidad seleccionando el icono correspondiente (no una carpeta) y presionar el botón derecho del ratón. Un menú emergente aparece eso indica algunas operaciones: añadir la entidad seleccionada a la diagrama en curso. Crear una copia de la entidad en la diagrama, pero solamente si el diagrama puede manejar ese tipo específico. Una entidad puede salir en algunos diagramas. Editar las propiedades. Muestra las propiedades diferentes asociar a la entidad seleccionada. 2.4.4

Editor de diagrama

El editor de diagrama de IDE consta de tres partes: la barra de edición, con las operaciones comunes para la edición. La barra de entidades admitidas, que es específico para cada tipo de diagrama. Tiene botones que lo permiten para crear los ejemplos de tipos de entidad especiales en el 78

diagrama en curso. Normalmente, todos tipos de entidad que son dejados para un diagrama especial salen en la barra. Para saber qué tipo de entidad representa un botón, sólo proponga que el ratón sobre un botón y su nombre aparecerá. Para insertar una nueva entidad en la diagrama en curso, presione uno de los botones. La nueva entidad será asignada en la ventana de diagrama. • Ventanas de diagrama, organizado como poner una lengüeta a ventanas, uno para cada diagrama que ha sido abierto. Los diagramas seleccionados son presentados en algunos tabuladores en la ventana de diagrama. Para cada diagrama abierto hay un tab que es etiquetado con su título (tabs para diagramas seleccionadas). La etiqueta de la diagrama en curso es highlight en el gris ligero. Las etiquetas de los otros diagramas salen en el gris oscuro. Los diagramas pueden ser dirigidos de la siguiente manera: Abrir un diagrama. Seleccionar un diagrama en la opinión de proyecto y haga clic dos veces con el botón de derecho de ratón. Un nuevo tabulador aparecerá el diagrama será escogida como la diagrama en curso. Las acciones frecuentes con el diagrama en curso son: Insertar una nueva entidad. Cuando haga clic con el botón derecho del ratón en la ventana de diagrama, un menú emergente aparecerá con las entidades legítimas diferentes que pueden ser incluidas en la diagrama. Esta acción es igual que presionar un botón de entidad en el admitir a quienes las entidades obstruyen. Conecte dos entidades con una relación. Hay dos maneras de conectar entidades en un diagrama. Cómo conectar un Agente y un objetivo. Primero, al poner el ratón sobre el cuadrado pequeño en medio de una de estas cifras. Entonces arrastrar a lo largo desde allí a la otra entidad. La entidad de meta selecciona cuando la relación ha encontrado el destino. En ese momento, libere el botón de ratón. Una nueva ventana aparecerá, indicando las relaciones legítimas posibles diferentes que podían ser definidas (en caso de que la 79

relación no sea admitidos en esta diagrama la nueva ventana notará esto). Usted tiene que seleccionar uno (también cuando hay solamente un el tipo de relación posible que usted tiene para reconocerlo). Después, pregunta cómo arreglar los extremos de la relación, ya que, a veces, algunas asignaciones son legítimas (aunque normalmente ésos seleccionados por ausencia del otro son la mejor opción). al terminar, una nueva relación es creada.

Figura 42: pasos para crear una relación de dos entidades

Añadir una nueva entidad a una relación existente. Algunas relaciones aceptan más de dos entidades, cuando usted ya ha creado una relación y quiere añadir otra entidad, el proceso es simple. Primero, usted cambia de lugar el ratón a la relación para hasta cuál quiere conectar la entidad usted ve que el icono de ratón cambia. Arrastre el ratón hacia la entidad que usted quiere conectar y libere el ratón. Siguiendo, una ventana aparecerá juegue a voluntad con la nueva entidad en la relación. Seleccione uno y acepte el nuevo tipo. Si la entidad no puede ser aceptada por la relación, debido a su tipo, un diálogo de error aparecerá. Campos de caja de Combo. Estos campos pueden admitir solamente valores definidos en la lista asociada. Un valor tiene que ser seleccionado. Campos de referencia de Diagrama. Este campo permite consultar otros diagramas. El procedimiento consiste en seleccionar el nombre de la diagrama en el combo. El combo indicará solamente diagramas existentes de un tipo pre-configurado. Seleccionado una vez, presione él un modelo seleccionado. Esto hará el cambio de etiqueta de valor en curso. Para sacar precipitadamente el diagrama seleccionado, la función de la prensa debe de estar seleccionada.

80

2.4.5. Módulos Los módulos son programas que procesan las especificaciones y producen un poco de producto: el código fuente. Hay una infraestructura que facilita la creación del código fuente. La infraestructura que bases sobre plantillas definido con XML. Estas plantillas son llenadas con la información extraída de las diagramas. Informes. Los diagramas también pueden ser analizados, verificados, por ejemplo, si tienen ciertas propiedades o si semántica especial (definido por el desarrollador) está estando respetado, o coleccionar las estadísticas del uso de elementos diferentes. Modificaciones sobre diagramas en curso. Aunque esta característica está en el escenario de beta, un módulo podía insertar y/o modificar entidades en las diagramas, o insertar / eliminar diagramas. Esta característica es útil para definir a asistentes personales que interactúan con la herramienta.

Figura 43: Relación entre el IDE, modelos y componentes

2.5 RESULTADO FINAL DE IMPLEMENTACION DE CASO DE ESTUDIO EN LA METODOLOGIA INGENIAS IDE En este ejemplo, hay dos agentes., hay un agente, Postor, que tienen cuidado de encontrar y comprar los artículos. Definitivamente, el subastador tiene los artículos. Cada agente en este sistema tiene un papel, como especificar el diagrama de la Asociación de papel, que es una diagrama de agente modelo de tipo

81

Figura 44: Asociación de agentes

Ambos agentes residen en el mismo ambiente, y esto es representado por un diagrama de ambiente.

Figura 45: Ambientes de agentes

El comportamiento es definido por los objetivos y las tareas de los Agentes, y las interacciones entre agentes. El Postor, por ejemplo, ejerce el objetivo de buscar los artículos a comprar, con el compromiso de realizar las pujas más bajas para conseguir su objetivo de minimizar

82

precio, por el contrario el agente subastador tiene como compromiso maximizar precio, y vender el artículo.

Figura 46: Objetivos y tareas

En este ejemplo hay solamente una interacción, que es mostrado. En INGENIAS una interacción podría ser una asociación multipartidista, con un iniciador y uno o más colaboradores, como en este ejemplo. A decir verdad, una interacción en INGENIAS es considerada algo más que sólo un mensaje - paso y podría representar mayor cantidad que la idea de una transacción, que puede estar constituido por el intercambio de varios envía un mensaje o notas en un espacio tuple compartido, dependiendo del paradigma de comunicación.

Figura 47: Modelo de interacción

La circulación de los mensajes en la especificación puede ser especificado por un diagrama de colaboración de Gracia, o por otro clases de interacción las diagramas, como UML o diagramas de secuencia de UML de Agente, En INGENIAS las interacciones son provocadas en las tareas. La circulación de las tareas y las 83

interacciones condiciona el comportamiento mundial del sistema. Esta información es muy importante cuando se genera las claves.

Figura 48: Flujo de eventos

DOCUMENTACION GENERADA (Ver anexo)

84

CAPITULO III 3.

MAS-commonKads [20] [21]

La necesidad de presentar en esta tesis a MAS-commonKads es puesto que como es predecesora de MASINA y esta última no posee documento liberado, se procede a detallar menudamente esta metodología y mostrar un pequeño ejemplo del caso de estudio que nos concierne. Esta metodología extiende CommonKADS aplicando ideas de metodologías orientadas a objetos y metodologías de diseño de protocolos para su aplicación a la producción de SMA’s. La metodología CommonKADS gira en torno del modelo de experiencia (explicado más tarde) y está pensada para desarrollar sistemas expertos que interactúan con el usuario. De hecho considera sólo dos agentes básicos: el usuario y el sistema. Este hecho influye en el modelo de comunicación que, consecuentemente, trata de interacciones hombre-máquina. Esta metodología ha sido la primera en hacer un planteamiento de SMA integrado con un ciclo de vida de software, concretamente el espiral dirigido por riesgos. Propone siete modelos para la definición del sistema: agente, tareas, experiencia, coordinación, comunicación, organización y diseño. Cada modelo presenta una reseña a la teoría sobre la que se basa. El modelo en sí parte de una descripción gráfica que luego se complementa con explicaciones en lenguaje natural de cada elemento. Existe por cada modelo una descripción de las dependencias respecto de otros modelos y de las actividades involucradas. Estos modelos se hayan descritos ampliamente [20] en lenguaje natural, complementándose con otras notaciones como SDL (Specification and Description Language) [International Telecommunication Union 99 A.D.b] o MSC (Message Sequence Chart) [International Telecommunication Union 99 A.D.a] para describir el comportamiento de los agentes cuando interaccionan. MAS-CommonKADS es la metodología más cercana a las líneas principales de esta tesis. Incorpora la idea de proceso de ingeniería y describe con bastante detalle cómo se debe definir el sistema teniendo en cuenta las dependencias entre los modelos. En contra hay que decir que no tiene herramientas de soporte específicas y que presenta problemas a la hora de razonar sobre la especificación de forma automática. Por otro lado, se aprecia en este trabajo el esfuerzo de cubrir todo el ciclo de vida de la aplicación, llegando hasta la implementación del sistema, lo cual no es frecuente. La especificación de SMA que proporciona MAS-CommonKADS detalla la mayoría de aspectos en lenguaje natural. Esta particularidad dificulta el análisis automático de la especificación generada y supone una gran desventaja frente a semi-formalismos como 85

UML, soportado por muchas herramientas y con la posibilidad de hacer chequeos para verificar el desarrollo (¿Existen elementos no utilizados? ¿Se ha asociado especificaciones de comportamiento a los casos de uso?). Para lograr lo mismo en MASCommonKADS habría que restringir el uso de lenguaje natural o bien incluir formalismos que logren una definición más precisa y menos ambigua del SMA. En la tesis presentada por Carlos Ángel Iglesias Fernández Ingeniero de Telecomunicación, el problema se salva utilizando meta-modelos como mecanismo de especificación. El desarrollo de meta-modelos está soportado por herramientas que permite el procesamiento automático de los modelos generados. Los meta-modelos en algunos casos profundizan más en el detalle que MAS-CommonKADS. Tal es el caso del meta-modelo de organización, el de tareas y objetivos, o el de agentes.

Figura 49: modelos de Mas commonKads

En este apartado se presentan el conjunto de actividades que se suceden en el desarrollo de la fase de conceptuación. 3.1

Ciclo de desarrollo de los casos de uso

3.1.1

Actividad: Identificación de los actores

86

• Descripción: identificación de los agentes externos al sistema y que interactúan con él. • Técnicas: los actores se identifican partiendo de los posibles usuarios del sistema. • Producto: ninguno. 3.1.2 Actividad: Descripción de los actores • Descripción: descripción de los agentes externos al sistema y que interactúan con él. • Técnicas: los actores se describen empleando la siguiente plantilla textual: Actor entidad. Nombre de una entidad que interactúa con el sistema. nombre ranura, texto, (Obl.), 1. El nombre del agente es una cadena de texto corta. El nombre debe ser único dentro de la fase de conceptuación, ya que es el principal mecanismo de referencia. descripción ranura, texto, (Obl.), 1. Descripción de las características y usos del sistema por parte del actor. • Producto: diccionario de actores. 3.1.3 Actividad: Identificación de los casos de uso • Descripción: identificación de los posibles usos que da cada actor al sistema. • Técnicas: pueden emplearse las preguntas enunciadas en la sección 4.2.1. • Producto: ninguno. 3.1.4 Actividad: Descripción de los casos de uso • Descripción: identificación de los posibles usos que da cada actor al sistema. • Técnicas: los casos de uso pueden describirse de forma textual y gráfica. • Producto: plantillas de casos de uso. 3.1.4.1 Notación de los casos de uso

87

Para la descripción de los casos de uso se utilizan habitualmente dos tipos notaciones: textuales y gráficas. 3.1.4.1.1 Notación textual Se muestra a continuación la notación textual propuesta por Rumbaugh . Los actores se describen con plantillas diferentes de las de los agentes para facilitar la reutilización de los casos de uso, sin dificultar por ello la trazabilidad. Caso-de-uso entidad. Interacción o uso de un elemento externo con el sistema. Nombre ranura, texto, (Obl.), 1. El nombre del caso de uso es una cadena de texto corta. El nombre debe ser único dentro de la fase de conceptuación, ya que es el principal mecanismo de referencia para especificar las relaciones entre casos de uso. Resumen ranura, texto, (Obl.), 1. Breve descripción de la secuencia de interacciones entre los actores y el sistema. Actores ranura, texto, (Obl.), muchos a muchos. Actores que participan en el caso de uso. Debe ser un valor definido en la ranura nombre de una entidad Actor. Precondiciones ranura, texto, (Opt.), muchos a muchos. Condición que debe ser cierta para que el caso de uso pueda darse. Descripción ranura, texto, (Obl.), 1. Descripción detallada e informal de las interacciones, referenciado las posibles excepciones. Excepciones ranura, texto, (Opt.), muchos a muchos. Descripción de cada excepción y de sus ocurrencias. postcondiciones ranura, texto, (Opt.), muchos a muchos. Descripción de las postcondiciones del caso de uso. 3.1.5 Notación gráfica La notación gráfica de los casos de uso sigue la propuesta por Regnell que extiende la notación de Jacobson para indicar la relación entre un caso de uso y el diagrama MSC que muestra las interacciones de dicho caso de uso. La relación entre casos de uso se realiza empleando HMSCs. Tanto la notación de los MSCs como HMSC (High level Message Sequence Charts). La notación para los casos de uso distingue entre agentes software y agentes humanos.

88

3.1.6 Actividad: Descripción de las intervenciones de los casos de uso • Descripción: descripción de las intervenciones de los casos de uso. • Técnicas: la descripción de las intervenciones se realizará de forma textual en cada caso de uso y de forma gráfica empleando MSCs. • Producto: ninguno. 3.1.7 Actividad: Descripción de las relaciones entre casos de uso • Descripción: descripción de las relación entre los casos de uso.

Figura 50: Notación de los casos de uso

• Técnicas: la relación entre casos de uso se puede realizar empleando HMSCs. • Producto: ninguno.

89

3.2

Modelo de Agente

A continuación se presenta un modelo de agente para sistemas multi-agente.

Figura 51: Modelo de Agente

Los agentes son capaces de realizar tareas, que se especifican en un ejemplar del modelo de tareas. Los agentes pueden ofertar la realización de determinadas tareas (denominadas servicios) a otros agentes. Los agentes se caracterizan además por tener objetivos. Un objetivo es una responsabilidad aceptada por el agente. Los objetivos pueden adoptarse desde el nacimiento del agente (objetivos iníciales) o en el transcurso de la ejecución del agente. Los agentes pueden adoptar objetivos para satisfacer otros objetivos propios, para satisfacer objetivos de otros agentes, o para responder a eventos del entorno. La principal distinción para clasificar a los agentes es entre agentes software y agentes humanos. Mientras que no se puede esperar la captura completa de las habilidades y restricciones de los agentes humanos, sí deben especificarse para los agentes software. El modelo de agente tiene como propósito: La especificación de los diversos agentes involucrados en la resolución del problema. 3.2.1 Antecedentes históricos El modelo de agente de MAS-CommonKADS tiene su origen en el modelo de comunicación de CommonKADS. 3.2.2 Fundamentos del modelo de agente

90

3.2.2.1 ¿Qué problemas de IAD deben ser resueltos en el desarrollo del modelo de agente? El modelo de agente sirve para especificar las características de los agentes involucrados en la resolución de un problema. El modelo de agente está pensado para recoger los requisitos que debe tener un agente para poder realizar las tareas (responsabilidades) asignadas. 3.2.2.2 ¿Cuándo es el modelo útil, y cuándo debe ser incluido en el conjunto de modelos? El modelo de agente es el modelo central de MAS-CommonKADS y debe ser incluido siempre. El modelo de agente tiene como propósito: La especificación de los diversos agentes involucrados en la resolución del problema. 3.2.3

Dependencias en la construcción del modelo

3.2.3.1 Modelo de Tareas La relación entre el modelo de agente y el modelo de tarea es clara: las tareas de las hojas del modelo de tareas son ejecutadas por uno o varios agentes. 3.2.3.2 Modelo de Comunicación El modelo de agente debe ser desarrollado con antelación al modelo de comunicación, y proporcionar las capacidades de los agentes involucrados. 3.2.3.3 Modelo de Coordinación El modelo de agente debe ser desarrollado con antelación al modelo de coordinación, proporcionando un conjunto inicial de agentes con unas determinadas habilidades y objetivos. 3.2.3.4 Modelo de la Experiencia El modelo de la experiencia se emplea para describir las capacidades de razonamiento de los agentes. 91

3.2.3.5 Modelo de Organización El modelo de organización describe las relaciones estáticas entre los agentes y recursos de la organización. 3.2.4 Ciclo de desarrollo del modelo de agente Actividad: Identificación de los agentes Descripción: en esta fase se emplean diversas técnicas para identificar los agentes del sistema. Estados resultantes: agentes identificados. -Utilización de heurísticos para identificar los agentes. -Determinación de los agentes utilizando “casos de uso internos”, identificación de agentes empleando tarjetas CRC (Clases-Responsabilidades-Colaboraciones).

Figura 52: Tarjetas CRC para agentes

Actividad: Descripción de los agentes, Identificación de los objetivos procedentes del modelo de tareas, identificación de los objetivos empleando tarjetas CRC, identificación de restricciones, identificación de servicios El modelo de agente es una herramienta para analizar el sistema desde una perspectiva orientada a agentes.

92

3.2.5 Relación entre el modelo de agente

Figura 53: Constituyentes y relaciones del modelo de agentes

93

3.3

Modelo de Tareas

El modelo de tareas permite describir las actividades relacionadas para alcanzar un objetivo. El objetivo del desarrollo del modelo de tareas es documentar la situación actual y futura de la organización, facilitar la gestión de cambios, y ayudar a estudiar el alcance y viabilidad del sistema inteligente que se desea desarrollar

Figura 54: Modelo de tarea

3.3.1 Entidades del modelo de tareas

Figura 55: Diagrama entidad-relación del modelo de tareas de CommonKADS

94

Modelo de Comunicación. El modelo de comunicación proporciona un entorno para elaborar la estructura y contenidos de la comunicación entre tareas y agentes humanos. Modelo de Coordinación. El modelo de coordinación proporciona un entorno para elaborar la estructura y contenidos de la comunicación entre tareas y agentes software. Modelo de la Experiencia. Una tarea compleja que requiera conocimiento puede descomponerse en detalle en el modelo de la experiencia. Modelo de Diseño. El modelo de diseño hace que las tareas realizadas por el sistema multi-agente sean operativas. Una tarea se implementa en un subsistema del modelo de diseño. Notación del modelo de tareas La notación del modelo de tareas no es estricta, sino que se deja abierta al usuario de la metodología. Esta notación puede ser extendida para mostrar otros aspectos, como un árbol Y-O (al descomponer una tarea puede tenerse que realizar todas las subtareas (nodo Y) o alguna de las subtareas (nodo O); indicar paralelismo entre sub-tareas; indicar tareas iterativas, etc.

Figura 56: Notación estándar para indicar descomposición de tareas

Otros autores han propuesto la utilización de técnicas convencionales como diagramas de flujo de datos (que permite representar el flujo de datos entre tareas) o IDEF3 (que permite representar alternativas, secuencias, alternativas exclusivas y sincronía o asincronía entre tareas).

95

Desarrollo y gestión del modelo de tareas El modelo de tareas define las situaciones y objetivos de riesgo que permiten determinar qué estados de los constituyentes del modelo de tareas se desean alcanzar.

Figura 57: Notación alternativa para representar la descomposición de tareas

El desarrollo del modelo de tareas no es específico de CommonKADS, sino que es una tarea general para cualquier metodología de ingeniería software. Las principales técnicas para desarrollar el modelo de tareas son: • Técnicas básicas: realización de entrevistas al personal, observación de su trabajo, análisis de manuales, guías y material de aprendizaje, análisis de casos previos, análisis de la información procesada en las tareas y análisis de la gestión de las tareas. • Estudio de los objetivos de las tareas: descomponer las tareas en sub objetivos que permiten realizarlas. • Estudio de los agentes: identificación de tareas mediante la identificación de los agentes que realizan una tarea. • Estudio de los objetos: identificación de los objetos relacionados con las tareas, que permitirá identificar tareas relacionadas con cada objeto. • Estudio del orden de las tareas: estudiar si siguen un orden arbitrario, qué dependencias se dan entre tareas, etc., lo cual permitirá refinar el árbol de tareas. El modelado de las tareas debe terminarse cuando:

96

• una tarea se puede realizar de una forma simple y bien determinada (no hay que abordar ya su complejidad). • una tarea ya está siendo realizada por un sistema de software que no vamos a reemplazar. • una tarea puede ser realizada por software estándar. • una tarea requiere conocimiento y se puede refinar mejor en el modelo de la experiencia. • una tarea indica comunicación y se puede refinar en el modelo de comunicación o coordinación. • una tarea no se puede descomponer en tareas con una estructura de control simple. Será candidata de refinarse en el modelo de la experiencia.

97

3.4

Modelo de Experiencia

Se presenta el modelo de la experiencia para desarrollar y describir el conocimiento de los agentes MAS-CommonKADS desarrolla en el modelo de la experiencia las tareas que requieren conocimiento para ser llevadas a cabo y que permitirán caracterizar al agente como un sistema basado en conocimiento. 3.4.1 Fundamentos del modelo de la experiencia En este apartado se revisan los principales conceptos desarrollados en la comunidad de ingeniería del conocimiento o adquisición del conocimiento En palabras de Newell: “Existe un nivel diferenciado en los sistemas computacionales que descansa sobre el nivel simbólico y que se caracteriza por el conocimiento como el medio, y el principio de racionalidad como la ley de conducta” La comunidad de ingeniería del conocimiento ha tratado desde entonces de “estar en el nivel del conocimiento”. 3.4.2 Estructura del modelo de experiencia

1. Traducción poco afortunada de “operationalization”, proceso mediante el cual se obtiene un programa ejecutable a partir de unos requisitos.

Figura 58: Principales componentes del modelo de la experiencia

3.4.3 Conocimiento del dominio El conocimiento del dominio en CommonKADS está compuesto de ontologías del dominio y modelos del dominio

98

La ontología del dominio describe las entidades relevantes del dominio y las relaciones mantenidas entre los ejemplares de dichas entidades. CommonKADS distingue las siguientes categorías ontológicas

Figura 59: Ontología

La definición del modelo del dominio se realiza indicando qué relaciones se tienen en cuenta y enunciando axiomas sobre estas relaciones. Por ejemplo, para el modelo causal, emplearíamos la relación “causa” y enunciaríamos axiomas del tipo “estado del depósito vacío causa indicador de gasolina indica sin gasolina”. 3.4.4 Notación del modelo de la experiencia El lenguaje CML (Lenguaje de Modelado Conceptual, Conceptual Modelling Language) permite la descripción del modelo de la experiencia.

Figura 60: Nivel de dominio y inferencia

99

3.4.5 Técnicas de adquisición del conocimiento Las técnicas de adquisición del conocimiento permiten que el ingeniero del conocimiento pueda modelar el conocimiento empleado por humanos en la realización de actividades. Técnicas de entrevistas, observación, multidimensionales, Entrevista temática, Entrevista estructurada, Introspección, Entrevista introductoria (tutorial interview),

Figura 61: Adquisición de conocimiento

3.4.6 Desarrollo del modelo de la experiencia La adquisición del conocimiento basada en modelos: el modelado se ve como un proceso constructivo descendente, es decir, primero se selecciona o construye un modelo abstracto y después se especifica con conocimiento específico del dominio. Se pueden distinguir las siguientes actividades en la adquisición de conocimiento basada en el modelo: construcción del esqueleto del modelo (skeletal model), instanciación, compilación y refinamiento del modelo. La construcción del esqueleto del modelo consiste en la creación o selección de una especificación abstracta del conocimiento requerido para realizar la tarea deseada.

100

3.4.7 Actividades de construcción del esqueleto del modelo La construcción del esqueleto de un modelo consta de las siguientes actividades 1. Descripción informal del dominio y tareas de la aplicación 2. Identificación de tareas genéricas. 3. Construcción del esquema del modelo, que hemos desglosado en identificación y descripción del esquema del modelo 4. Especificar las correspondencias entre papeles de tareas genéricas diferentes. 5. Especificar las correspondencias entre papeles del esquema del modelo y de las tareas genéricas. 6. Validación del esqueleto 3.4.8 Actividades de instanciación Del esqueleto del modelo Se pueden distinguir las siguientes actividades en la “instanciación” del esqueleto del modelo •

Elicitación manual

•

Elicitación automatizada

3.4.9 Particularización para sistemas multi-agente La definición de un modelo de la experiencia para sistemas multi-agente no ha sido el principal objetivo de esta tesis analizada, y se desarrolla en trabajos posteriores. En el nivel de arquitectura de agente, su descripción en el nivel del conocimiento favorecerá la adquisición y operación del mismo. Aunque CommonKADS no da suficiente ayuda para las tareas de planificación, algunos trabajos recientes abordan esta línea

101

Figura 62: Ejemplo de diagrama de inferencia de un agente

Una vez determinada la arquitectura de los agentes, se deberá refinar el conocimiento adquirido estableciendo los papeles que desempeña dicho conocimiento en la arquitectura. En cuanto al esquema del modelo, en el caso de un sistema multiagente, podemos distinguir los siguientes dominios de modelado, comunes en las arquitecturas de agentes •

Conocimiento sobre el propio agente

•

Conocimiento sobre el resto de agentes

•

Conocimiento de la aplicación

3.5 Modelo de Coordinación Una de las áreas actuales de interés de la inteligencia artificial distribuida es, sin duda, la normalización de las interacciones entre diversos agentes que cooperan para resolver un problema de forma conjunta. El principal objetivo del modelo de coordinación propuesto es abordar los riesgos que están directamente relacionados con el desarrollo de las interacciones entre los agentes y dar soporte en el desarrollo mediante un método que prevenga tales riesgos. El modelo de comunicación de CommonKADS estaba diseñado para modelar cualquier tipo de interacción de un agente con el exterior (otros agentes, sensores, sistema

102

operativo, etc.). En MAS-CommonKADS se ha revisado el modelo de comunicación, y sólo se encarga del modelado de las relaciones hombre-máquina. Por tanto: Las interacciones con otros agentes no humanos son modeladas en el modelo de coordinación. • Las señales recibidas del exterior son modeladas mediante una entidad genérica denominada entorno. El modelo de coordinación tiene como propósito: • Este modelo sirve para almacenar las decisiones sobre la estructura de comunicaciones y los protocolos de dichas comunicaciones, abordando los riesgos asociados con los requisitos funcionales de los protocolos de comunicación. 3.5.1 Antecedentes históricos El modelo de coordinación tiene su origen en el modelo de comunicación de CommonKADS. Dicho modelo tenía sus bases en el de cooperación de KADS-I. El modelo de cooperación de KADS-I constaba de tres niveles de diseño pensados para ser desarrollados en secuencia: el nivel de tarea, el nivel semántico y el nivel de comunicación. • Nivel de tarea: descomposición de las tareas y distribución de las mismas. • Nivel semántico: establecimiento para cada tarea de los ingredientes intercambiados, emisor y receptor de cada ingrediente y determinación del iniciador de la transacción. • Nivel de comunicación: estructura de comunicación entre el usuario y el sistema, esto es, conjunto de transacciones involucradas. En CommonKADS, las funcionalidades del modelo de cooperación de KADS-I fueron repartidas entre el modelo de tarea (distribución de tareas e identificación de los ingredientes) y el modelo de comunicación (determinación de la iniciativa en las tareas de transferencia). 3.5.2 Por último, los lenguajes y protocolos de comunicación, KQML (Lenguaje de consulta y manipulación del conocimiento; Knowledge Query and Manipulation Language), ya que es la propuesta más difundida en la comunidad multi-agente.

103

3.5.2.1 Teoría de los actos de habla La teoría de los actos de habla (speech acts) es un marco teórico de alto nivel para el estudio del lenguaje desarrollado por Austin, Grice y Searle, entre otros. La teoría de los actos de habla está siendo aplicada en áreas muy diferentes, de las que destacamos: • Comprensión y generación de lenguaje natural: el proceso de comprensión a menudo se estudia como un proceso de reconocimiento de la planificación que tiene como misión reconocer cuál es la intención del hablante cuando expresa una frase. • Inteligencia artificial distribuida: los mensajes intercambiados pueden considerarse actos de habla. Se han seguido diversos enfoques para determinar la semántica de los actos de habla. El primer enfoque considera que la semántica de los actos de habla consiste en determinar bajo qué condiciones se puede asegurar que un acto comunicativo ha ocurrido, es decir, cómo identificar el tipo de acto comunicativo (asertivo, directivo, etc.) que ha tenido lugar. El segundo enfoque consiste en centrarse en el estudio de los aspectos perlocutivos del acto comunicativo, esto es, qué efectos tiene el acto comunicativo en los estados cognitivos de oyente y hablante. 3.5.2.2 Teoría del discurso El análisis de las conversaciones entre agentes puede enmarcarse dentro de la teoría del discurso elaborada en el campo de procesamiento del lenguaje natural, para reconocer las intenciones del hablante. Dominio (plan común que intentan conseguir los interlocutores); resolución de problemas (método de resolución para conseguir el objetivo común); creencias (creencias mutuas de los interlocutores que motivan sus decisiones); y discurso (acciones comunicativas iniciadas para conseguir las creencias mutuas). 3.5.2.3 El lenguaje de comunicación KQML KQML (Lenguaje de Consulta y Manipulación del Conocimiento, Knowledge Query and Manipulation Language) es un lenguaje para la comunicación entre agentes 104

software. KQML ofrece un conjunto de tipos de mensajes, denominados realizativos (performatives), que se corresponden con actos de habla. KQML forma parte del esfuerzo del consorcio KSE (Esfuerzo para Compartir el Conocimiento, Knowledge Sharing Effort), patrocinado por las instituciones ARPA (Advanced Research Projects Agency), ASOFR (Air Force Office of Scientific Research), NRI (National Research Initiative) y NSF (National Science Foundation), para facilitar que el conocimiento pueda ser compartido entre sistemas. • Los mensajes KQML son opacos al contenido que llevan, que se expresa en un lenguaje de representación del conocimiento. En KQML sólo se expresa el tipo de mensaje, que comunican una actitud sobre el contenido (asertar, pedir, consultar). • Las primitivas del lenguaje se denominan realizativas (performatives), relacionadas con la teoría de actos de habla. Las realizativas definen las interacciones posibles entre los agentes. • KQML también define una arquitectura, en donde unos agentes especiales denominados facilitadores (facilitators) proporcionan diversas funciones: asociación de dirección física con nombres simbólicos, registro de bases de datos y/o servicios ofrecidos o buscados por los agentes; y servicios de comunicación como reenvío e intermediación (brokering). KQML está siendo tomado como base para el intento de estandarización de agentes de la FIPA. 3.5.2.4 La especificación de la FIPA La FIPA (Fundación para Agentes Inteligentes Físicos; Foundation for Intelligent Physical Agents) es un comité para fomentar la estandarización de la tecnología de agentes. Está en fase de definición de dichos estándares, de los que hay algunos borradores públicos Las principales características de esta propuesta son: • Los mensajes se corresponden con actos de habla, al igual que en KQML, y son opacos al contenido que llevan. 105

• Se definen diferentes tipos de mensajes para abarcar los diferentes actos de habla, así como una estructura de los mensajes similar a la de KQML. • Este estándar define un modelo de referencia de gestión de agentes constituido por un canal de comunicación de agentes, un servidor de nombres de agentes (páginas blancas), un facilitador de directorio (páginas amarillas), un sistema de gestión de agentes (supervisión) y los agentes que se comunican por dicho canal. • Define un lenguaje de contenido de gestión, que permite describir a los agentes, la plataforma, los servicios y al servidor de nombres de agentes. Esto no se normalizaba en KQML, que era dependiente de la ontología. • Frente a KQML, el número de actos comunicativos es mucho mayor, incluyendo numerosos actos comunicativos para negociar. • Define explícitamente tipos de mensajes para agentes móviles. • El concepto de servicio es explícito: un agente ofrece servicios. En KQML un agente ofertaba tipos de mensaje que era capaz de procesar. • Define una arquitectura para interaccionar con software diferente de agentes software. El software que no posea las capacidades de agente debe ser encapsulado con un envoltorio (wrapper) que facilite la interacción con los agentes. Se definen dos ontologías FIPA-ARB (Intermediario de Recursos de Agentes, Agent Resource Broker) y FIPA-PROXY para interaccionar con estos elementos software. Si un agente soporta la ontología FIPA-ARB, es capaz de ofrecer como servicios las funcionalidades de dicho software, que puede registrar en el facilitador de directorio, indicando las propiedades fijas y negociables de dichos servicios junto con una descripción del mismo. 3.5.3 Fundamentos del modelo de coordinación El modelo de coordinación describe las interacciones entre agentes involucrados en la resolución de un problema. Cada interacción entre dos agentes se realiza mediante el envío de un mensaje, y tiene asociado un acto de habla.

106

El modelo de coordinación propuesto está orientado a servicios: un agente puede ofertar la realización de determinas tareas, denominadas servicios, a otros agentes. Se pueden identificar dos razones para iniciar una conversación: necesitar ayuda o proporcionar ayuda. De la misma manera, un agente puede responder a una conversación por dos causas: suministrar ayuda o aceptar ayuda. 3.5.3.1 ¿Qué problemas de la IAD deben ser resueltos en el desarrollo del modelo de coordinación? El modelo de coordinación aborda varios problemas centrales a la inteligencia artificial distribuida: • Coherencia, coordinación y cooperación: un sistema multiagente debía buscar la coherencia, que definíamos como la propiedad del sistema de comportarse como una unidad. • Modelado de asignación dinámica de tareas. En el modelo de coordinación se modelan interacciones prototípicas. Es necesario modelar al menos todas las posibles interacciones, lo cual no implica tener que modelar todas las posibles asignaciones de tareas, dado que esta asignación puede darse utilizando un protocolo de negociación. • El modelo de coordinación propuesto puede ser usado de dos formas: - Por el diseñador, para especificar y prever las interacciones que pueden darse en el sistema. - Por el agente software, para determinar qué protocolo debe emplear y seguir las especificaciones de los protocolos que esté empleando. 3.5.3.2 ¿Cuándo es el modelo útil, y cuándo debe ser incluido en el conjunto de modelos? El modelo de coordinación describe las interacciones entre un conjunto de agentes envueltos en la resolución de una o varias tareas. Dado que en CommonKADS el

107

desarrollo de los modelos sigue un ciclo de vida en espiral, dirigido por riesgos, este modelo debe ser desarrollado cuando los siguientes riesgos hayan sido percibidos: • Se han identificado más de dos agentes del sistema no humanos. • La construcción del modelo de coordinación sirve como un medio de validación de la asignación de tareas y la construcción del modelo de agente. • Se propone una asignación dinámica de tareas entre los agentes. 3.5.3.3 Restricciones: ¿qué no puede ser modelado? Las siguientes restricciones se derivan de la estructura del modelo: • Un ejemplar del modelo de coordinación no tiene que ser construido para cada asignación de tareas. • El modelo de coordinación no modela la comunicación humano-humano. • El modelo de coordinación no modela la comunicación humano-ordenador ni tiene en cuenta los factores humanos del desarrollo de una interfaz hombre-máquina. Este es el objetivo del modelo de comunicación. 3.5.4 Estructura del modelo 3.5.4.1 Constituyentes del modelo El modelo se estructura en torno a los conceptos de agente y tareas (objetivos) e introduce los siguientes conceptos: • Mensaje: estructura de datos que intercambian los agentes para comunicarse. • Acto de habla: intención del emisor del mensaje al transmitir el contenido del mensaje. • Servicio: prestación realizada por un agente para satisfacer las necesidades de otro agente. • Intervención: intercambio de un mensaje entre un agente y otro agente. Puede haber tres tipos de interacciones básicas: síncrona (bloqueante hasta recibir respuesta), asíncrona (sin respuesta) y diferida (envío no bloqueante y recepción de respuesta).

108

• Conversación: conjunto de interacciones cuyo fin es la realización de un servicio. Distinguimos dos tipos de conversaciones: conversaciones de información y conversaciones de servicio. • Protocolo: normas asociadas a las conversaciones. Un protocolo determina las interacciones que se llevan a cabo en una conversación. 3.5.4.2 Plantilla del modelo de Coordinación La plantilla del modelo de Coordinación de MAS-CommonKADS contiene por defecto las siguientes entidades y relaciones. Se definen los siguientes tipos de entidades: Conversación entidad. Representación de una conversación. Las conversaciones constituyen el elemento central del modelo de coordinación. nombre ranura, texto, (Obl.), 1. El nombre de la conversación es una cadena de texto corta. El nombre debe ser único. tipo ranura, texto, (Obl.), 1 a muchos. Tipo de conversación (negociación, reactiva , etc.). La conversación que se describe puede ser un subtipo de una conversación definida previamente,

109

Figura 63: Objetos del modelo de coordinación

110

Figura 64: Descomposición del objeto Intervención

3.5.5 Ciclo del desarrollo del modelo 3.5.5.1 Desarrollo estándar del modelo de coordinación El modelo de coordinación está íntimamente ligado al desarrollo del modelo de agente, ya que su objetivo es abordar la descripción de los mecanismos de coordinación entre los agentes. Los estados hitos del modelo de coordinación son: 1. Identificación de las conversaciones entre los agentes. 2. Descripción de las conversaciones. 3. Identificación de las intervenciones que constituyen las conversaciones y de los servicios solicitados en las conversaciones. 4. Descripción de las intervenciones y de los servicios identificados. 5. Identificación de los datos intercambiados en cada intervención. 6. Identificación de los protocolos de cada conversación. 7. Elaboración de un prototipo del modelo. 8. Identificación de los protocolos de negociación del modelo. 9. Descripción de los protocolos de negociación. 10. Validación con el resto de modelos.

111

Figura 65: Orden de los hitos del modelo de coordinación

112

Figura 66: Estados hito en el desarrollo del modelo de Coordinación

3.5.5.2 Ciclos de desarrollo no estándar del modelo de coordinación En algunos casos puede ser conveniente realizar un modelo de coordinación previo y posterior a la creación del sistema. Por el momento, hemos identificado los siguientes casos: 1. Existe un sistema multiagente que se extiende y como resultado se modifican las comunicaciones existentes. 2. Existe un sistema no multiagente pero distribuido que se va a transformar en un sistema multiagente. 3. Existe un sistema no multiagente y no distribuido que se desea transformar en un sistema multiagente distribuido. En el primer caso, la extensión de un sistema multiagente preexistente puede conllevar alguna modificación de los módulos previamente desarrollados, como por ejemplo, modificación en la asignación de objetivos iníciales, modificación de las habilidades requeridas, modificación en las interacciones que se desean mantener, etc. 113

El segundo caso permite una transición más sencilla: se puede optar por encapsular simplemente los elementos dotándoles de una interfaz para comunicarse en un lenguaje de comunicación de agentes. 3.5.6 Dependencias en la construcción del modelo Modelo de Agente La relación entre el modelo de coordinación y el modelo de agente es clara: el modelo de coordinación describe las conversaciones entre agentes. Modelo de Tareas El modelo de tareas describe los ingredientes de las tareas que se comunican los agentes entre sí. Modelo de Comunicación El modelo de comunicación depende del modelo de coordinación. Durante el desarrollo del modelo de coordinación hemos supuesto que los usuarios humanos son sustituidos por agentes software que actúan como asistentes personales. Modelo de Organización El modelo de coordinación puede ser utilizado para representar las interacciones habituales en una organización. En este caso, en vez de fijarnos en agentes concretos representaremos interacciones de papeles (roles) concretos de los agentes de la organización. Modelo de la Experiencia Las interacciones de las tareas de transferencia (tareas cuyo objetivo es la comunicación con otro agente) del modelo de la experiencia se describen en este modelo y en el modelo de comunicación. 3.5.7 Evaluación del modelo En este apartado recogeremos algunos criterios que permitan la evaluación de las decisiones tomadas durante el desarrollo del modelo y su posible revisión. •

Actividad: Identificación de las conversaciones entre agentes

114

• Descripción: identificación de las conversaciones necesarias para satisfacer un objetivo de un agente (o del sistema). • Estados habilitadores: conjunto inicial de agentes identificado y una asignación inicial de tareas. • Estados resultantes: conversación identificada. • Técnicas: se proponen los siguientes métodos para identificar las conversaciones: Suposición de mundo ideal. Determinación de conversaciones derivadas de los casos de uso. Determinación de conversaciones utilizando “casos de uso internos”. Determinación de las conversaciones derivadas de las plantillas CRC. Determinación de conversaciones derivadas de los modelos de tarea, experiencia y agente. • Producto: ninguno. •

Actividad: Descripción de las conversaciones

• Descripción: descripción de las conversaciones. • Estados habilitadores: conversación identificada y agentes o grupos de agentes involucrados en la conversación identificados. • Estados resultantes: conversación descrita. • Técnicas: Para cada conversación utilizaremos la plantilla textual del constituyente Conversación y emplearemos la notación de casos de uso propuesta por Jacobson con extensiones para distinguir los agentes internos del sistema de los usuarios del mismo. • Producto: diagramas de conversación y plantillas de conversación. •

Notación gráfica para el constituyente Conversación

Una vez determinadas estas conversaciones, habremos especificado unos escenarios de conversación entre los agentes. Utilizaremos como notación gráfica la de diagramas de caso de uso internos. Cada caso de uso se relaciona con los agentes humanos y no humanos que participan en su resolución, asimilando un uso del sistema a una conversación, si participa más de un agente. Los casos de uso que sean conversaciones se describen con MSCs, que se indica mediante una flecha a trazos. Los casos de uso se pueden descomponer en episodios mediante diagramas HMSC, o mostrar directamente las interacciones asociadas al caso de uso con diagramas MSC. También es posible mostrar varios casos de uso en un único MSC. Si un caso de uso se asocia con un HMSC o MSC, se relacionan por tener el mismo nombre. Si varios casos de uso se representan en un único HMSC o MSC, se indica con la relación descrito-en (flecha gris a trazos).

115

Figura 67: Notación Agentes MSC

•

Actividad: Identificación de las intervenciones que constituyen conversaciones y de los servicios requeridos en cada conversación

las

• Descripción: identificación de las intervenciones. • Estados habilitadores: identificación y descripción de las conversaciones. • Estados resultantes: intervención identificada. • Técnicas: las intervenciones se describen en lenguaje natural, tomando como entrada las conversaciones identificadas. Es necesario fijarse en quién tiene la iniciativa en cada conversación y describir los pasos que se dan hasta que se finaliza la conversación. • Producto: ninguno. •

Actividad: Descripción de los datos intercambiados en cada intervención

• Descripción: descripción de los datos intercambiados en las intervenciones. • Estados habilitadores: descripción de las intervenciones. • Estados resultantes: intervención descrita.

116

Figura 68: Estructuras extremas de diagramas de interacción

• Técnicas: los datos intercambiados en las intervenciones habrán sido descritos en general (o deben describirse) en los modelos de tarea y de la experiencia. En este apartado sólo deben describirse los datos cuyo resultado sea dependiente sólo del protocolo de comunicación empleado (por ejemplo, el coste del Protocolo de Contratos), y los métodos para describirlos son los mismos que en el modelo de tarea y de la experiencia, es decir, se describirán empleando un lenguaje de representación del conocimiento en una ontología. • Producto: ninguno. •

Actividad: Identificación de los protocolos de negociación

• Descripción: determinar qué conversaciones necesitan interacciones más complejas (y flexibles). • Estados habilitadores: descripción de los canales de comunicación. • Estados resultantes: conversación identificada. •

Técnicas: se proponen las siguientes técnicas para identificar las conversaciones con protocolos de negociación:

- Determinación de conversaciones secundarias. - Determinación de conversaciones para asignación dinámica de tareas. - Determinación de conflictos entre agentes. - Determinación de peticiones no aceptables. - Determinación de grupos de agentes. - Determinación de coaliciones de agentes. • Producto: ninguno.

117

•

Determinación de peticiones no aceptables

Un tipo especial de conflicto sucede cuando un agente realiza una petición que es inaceptable por el agente que la recibe. Empleando un protocolo cliente-servidor, esta petición sería rechazada. Una posibilidad para mejorar esto es introducir un protocolo de negociación de los valores de los parámetros que resultan inaceptables. Los criterios de negociación pueden ser automáticos o asistidos por un humano. Algunas interacciones típicas de este tipo son: interacciones para la introducción o consulta de datos e interacciones para peticiones de planificación. •

Determinación de grupos de agentes

En el caso de que la misma interacción se repita con varios destinatarios, pueden darse los siguientes casos: • El número de los agentes destino y su identidad son conocidos. • El número de agentes destino y su identidad no están determinados. En ambos casos, puede ser conveniente la definición de un grupo de agentes, para simplificar estas interacciones. Podemos distinguir diferentes tipos de grupos, dependiendo de las siguientes características: • Dinamismo del grupo: capacidad del grupo para variar su composición dinámicamente. Normalmente será necesario que un agente desempeñe labores de gestor del grupo. • Ámbito del grupo: número de agentes que conocen la existencia de un grupo y pueden interactuar con él. Distinguimos varios tipos de grupos atendiendo a su ámbito: - Grupo privado: sólo es conocido por un agente, que será quien gestione el grupo si es dinámico. Este grupo sólo será de interés para el agente que lo conoce, y puede ser útil para razonar sobre el grupo. - Grupo restringido: el grupo es conocido por más de un agente, pero la pertenencia al grupo o su uso (envío a la dirección del grupo, conocimiento de los miembros del grupo) está restringido. Un caso habitual serían los grupos locales, grupos cuyo ámbito es un dominio concreto. - Grupo público: grupo conocido por más de un agente y al que puede subscribirse cualquier agente.

118

Cuando especifiquemos un grupo, deberemos determinar su ámbito y dinamicidad deseada, así como sus componentes iniciales y, en el caso de grupos dinámicos, el protocolo y responsable(s) de gestión del grupo. •

Determinación de coaliciones de agentes

Si determinamos que varios agentes tienen objetivos comunes o complementarios, puede estudiarse la posibilidad de dotarles de mecanismos para la formación de una coalición. Deberemos especificar los objetivos de la coalición, posibles condiciones de activación de dichos objetivos y las condiciones de finalización de la misma. •

Actividad: Descripción de los protocolos de negociación

• Descripción: descripción de un nuevo protocolo de negociación. • Estados habilitadores: identificación de los protocolos de negociación. • Estados resultantes: protocolo descrito. • Técnicas: la definición de un protocolo de negociación conlleva la definición de las primitivas de dicho protocolo y el proceso de interpretación de dichas fases. Los protocolos se describen combinando diagramas HMSC para las fases, que son refinados con diagramas MSC, y diagramas SDL para mostrar el procesamiento de los mensajes. • Producto: diagramas HMSC, MSC, SDL y plantillas asociadas.

119

3.6

Modelo de Organización

El modelo de organización de MAS-CommonKADS tiene como objetivo analizar desde una perspectiva de grupo las relaciones entre los agentes (tanto software como humanos) que interactúan con el sistema. Frente a los modelos de comunicación y de coordinación que modelan las relaciones dinámicas, este modelo está pensado para modelar las relaciones estructurales entre los agentes como, por ejemplo, las relaciones de herencia, agregación, autoridad, utilización, etc. El modelo original de CommonKADS tenía los siguientes propósitos • Identificar las áreas prometedoras para aplicaciones multiagente. • Identificar los posibles impactos debidos a la introducción de un sistema multiagente. • Identificar las capacidades de la organización. • Identificar la nueva situación de la organización tras introducir el sistema multiagente. Este modelo ha sido extendido en MAS-CommonKADS para poder describir tanto la organización humana como la sociedad de agentes software. Además de tener como objetivo facilitar el estudio de viabilidad de la introducción de un sistema multiagente, el modelo de organización se emplea para describir las relaciones y actividades de los agentes software.

Figura 69: Constituyentes del modelo de organización de CommonKADS

120

3.6.1 Antecedentes históricos El modelo de organización de MAS-CommonKADS tiene como antecesor al modelo homónimo de CommonKADS. 3.6.2 Bases teóricas del modelo 3.6.2.1 Relaciones de herencia en un sistema multiagente En este apartado vamos a definir la relación de herencia entre agentes 3.6.2.1.1 ¿Entre qué constituyentes se establece una relación de herencia? En la literatura orientada a objetos, suele distinguirse entre lenguajes orientados a objetos basados en clases y lenguajes orientados a objetos basados en prototipos. En los lenguajes basados en clases la conducta de los objetos se especifica en clases. Las clases pueden heredar de otras clases, y los objetos se crean ejemplificando una clase. Las operaciones posibles suelen ser paso de mensajes, herencia y ejemplificación. Los lenguajes basados en prototipos (también denominados basados en objetos o centrados en objetos) no distinguen el concepto de clase: un objeto puede ser creado a partir de otro objeto mediante clonación o herencia. Las operaciones aplicables a los objetos son paso de mensajes, delegación, concatenación, clonación, etc. Dada la mayor extensión de los lenguajes orientados a objetos basados en clases (Java, C++, etc.) sobre los lenguajes orientados a objetos basados en prototipos (Self, Agora, etc.), los lenguajes de programación de agentes si soportan la herencia suelen hacerlo basándose en clases. 3.6.2.1.2 ¿Cómo se define la relación de herencia? La relación de herencia en un modelo orientado a objetos significa que la clase derivada hereda los atributos y métodos de la clase madre. En este apartado se define qué se entiende en esta metodología por herencia entre clases de agentes.

121

Una clase de agentes generaliza un conjunto de agentes con la misma arquitectura de agente, y define los servicios (ofrecidos y requeridos), habilidades (tareas conocidas), sensores y actuadores, creencias y objetivos compartidos por dichos agentes. Parece claro que lo que deseamos es que un agente tenga todos los objetivos, creencias, planes y servicios de los agentes de su misma clase, pero pueda añadir objetivos, creencias, planes y servicios particulares. Para expresar esto, tenemos varias posibilidades: • Definir cada objetivo, creencia, plan y servicio como un atributo o método independiente. Un agente heredaría todos los atributos y métodos de las clases precedentes. Si se desea que un agente tenga más objetivos, servicios, etc. que su clase, se debería permitir la adición

Figura 70: Representación de herencia entre agentes

Dinámica de métodos y atributos. Para que fuera fácilmente representable de forma gráfica deberíamos distinguir tantas regiones como atributos heredables. • Definir conjuntos de valores para un atributo dado. Un agente hereda la unión de los valores de las clases precedentes, pudiendo unir valores particulares a estos conjuntos. Como vemos, que un agente especifique un valor no implica que desea particularizar y no heredar el valor por defecto, sino que añade una característica. Para distinguir si

122

deseamos particularizar un atributo (y no heredar su valor), deberemos indicarlo mediante el símbolo de admiración (!) antes del nombre del atributo. En la Figura --- b) hemos representado esta idea, introduciendo además un nuevo símbolo especial para distinguir a los agentes de los objetos del entorno. En esta representación sólo se distinguen dos partes: la parte superior contiene los atributos propios del agente para caracterizar su estado mental, mientras que la parte inferior contiene las características que se pueden invocar desde el exterior (servicios) o que le permiten interaccionar con el entorno (sensores y actuadores). Los agentes de la clase B tendrán los objetivos [OA1, OA2, OB1, OB3], las creencias [CA1, CA2], los servicios [SA1, SB1, SB2], los sensores [sen1] y los actuadores [ab1]. Obsérvese que no se heredan los actuadores de la clase A. 3.6.3 Fundamentos del modelo de organización 3.6.3.1 ¿Qué problemas de IAD deben ser resueltos en el desarrollo del modelo de organización? El modelo de organización aborda algunos de los problemas centrales de la inteligencia artificial distribuida, relacionados con la perspectiva de grupo. 3.6.3.2 ¿Cuándo es el modelo útil, y cuándo debe ser incluido en el conjunto de modelos? El modelo de organización describe la estructura organizativa de los agentes del sistema multiagente y de la organización donde el sistema multiagente está en funcionamiento. A continuación enunciamos algunas situaciones de riesgo que recomiendan el desarrollo del modelo de organización, distinguiendo entre las: a) Situaciones de riesgo debidas a la sociedad multiagente: • Se han identificado agentes con características comunes. Es necesario desarrollar un ejemplar del modelo de organización para mostrar las relaciones de herencia. • Los agentes identificados interactúan con el entorno. Es necesario desarrollar un ejemplar del modelo de la organización para modelar los objetos del entorno y su relación con los agentes.

123

• Se han identificado agentes con una relación de autoridad, poder o estructura entre los agentes. Es necesario desarrollar un ejemplar del modelo de organización para modelar dicha relación. • Se han identificado grupos o coaliciones de agentes o tipos (clases) de agentes. Es necesario desarrollar un ejemplar del modelo de organización para modelar la estructura y relaciones del grupo. • Se han identificado relaciones entre agentes software y agentes humanos. Es necesario desarrollar un ejemplar del modelo de organización para modelar dicha relación. b) Situaciones de riesgo debidas a la estructura de la organización humana: • Es necesario modelar la situación actual de la organización para comprender su composición. • Es necesario modelar la situación de la organización tras la introducción del sistema multiagente para estudiar su viabilidad, estudiar las alternativas y evaluarlas. 3.6.3.3 Restricciones: ¿qué no puede ser modelado? Se han observado las siguientes restricciones: • El modelo de organización permite el modelado de las relaciones mantenidas en una coalición de agentes. Sin embargo, dado que su composición es determinada dinámicamente, no es posible modelar su composición a priori. • El modelo de organización está pensado para el modelado de agentes semiautónomos. Algunas arquitecturas de agente son descritas en términos de subagentes. El modelo de organización no ofrece ninguna guía para la definición de dichas relaciones. 3.6.4 Estructura del modelo 3.6.4.1 Constituyentes del modelo. La definición del modelo de organización de CommonKADS sigue la estructura de la Figura a continuación. En el modelo se analiza una organización con varias perspectivas: recursos, funciones, estructura, relaciones de autoridad y procesos en la organización. También se describen los problemas de la organización que pueden resolverse con la introducción de un sistema inteligente.

124

3.6.4.2 Notación gráfica del modelo La notación gráfica propuesta para mostrar las relaciones entre los agentes se presenta en la Figura 9.5. Las asociaciones son empleadas para describir relaciones de poder o autoridad o relaciones entre agentes y objetos. La relación de grupo se puede realizar encerrando a varios agentes en una caja o mediante la relación de agregación, y describiendo las propiedades del “agente” que representa al grupo. En la representación de los agentes, como ya hemos comentado (Figura 9.3), representamos la parte interna (estado mental) y/o la parte externa (relación con el entorno y resto de agentes) Por último, los objetos relevantes de un problema son modelados con la notación de OMT.

Figura 71: Modelo de organización de CommonKADS

125

Figura 72: Notación gráfica del modelo de organización

3.6.5 Ciclo de desarrollo del modelo 3.6.5.1 Desarrollo estándar del modelo de organización El desarrollo estándar del modelo de organización está dividido en dos estados: el estudio de la organización humana y el estudio de la organización multiagente. En el caso de que se realicen ambos, deben abordarse en el siguiente orden: 1. Modelado de la organización humana. Los principales objetivos del modelado de la organización humana son la comprensión de su funcionamiento, la detección de los problemas que pueden ser resolubles con un sistema inteligente, la propuesta de soluciones y el estudio de la viabilidad de dichas propuestas. 2. Modelado de la sociedad multiagente. Los principales objetivos del modelado de una sociedad multiagente son la descripción de las relaciones entre los agentes y con su entorno. 3.6.6 Actividades de construcción del modelo de organización En este apartado se presenta el conjunto de actividades que se suceden en el desarrollo del modelo de organización. También cabe destacar que las actividades de evaluación pueden conllevar la modificación de cualquier constituyente del modelo desarrollado. Es decir, aunque la evaluación se haga tras cada paso de modelado, las evaluaciones posteriores pueden conllevar modificaciones en los pasos previos. El desarrollo del modelo puede conllevar

126

asimismo la modificación de los modelos relacionados y, en especial, del modelo de agente. Dado que uno de los objetivos del modelo de organización es servir como base para el estudio de viabilidad del proyecto, este modelo será un modelo motor del proyecto en la fase de decisión de la viabilidad del mismo. Una vez aprobado el proyecto, este modelo se desarrollará bajo demanda del modelo de agente. Para cada paso del modelo se indicará: • Descripción. • Estados de los constituyente(s) del modelo que permiten aplicar la actividad. • estado resultante del modelo que se pretende con el paso del modelo. • un conjunto de técnicas para alcanzar el estado objetivo, heurísticos para seleccionar entre dichas técnicas y notación empleada si el paso de modelado es un paso descriptivo. • Productos que se generan en una actividad, entendiendo por producto un documento o prototipo que se entregará al cliente. Podemos distinguir dos tipos de actividades del modelo de organización: • Actividades relacionadas con el modelado de la organización en que se introduce el sistema, orientadas al estudio de la viabilidad del desarrollo del sistema y del impacto del sistema en la organización. Estas actividades se describen en la sección 9.6. • Actividades relacionadas con el modelado de la estructura organizativa de la sociedad de agentes, orientadas a la descripción de dicha sociedad. 3.6.7 Actividades de modelado de la organización Las actividades han sido incluidas para proporcionar un documento auto contenido en la medida de lo posible. Podemos distinguir dos grandes actividades de modelado de la organización: • El modelado de la situación actual, que permite comprender cómo la organización está trabajando ahora. • El modelado de la situación futura, cuya principal actividad es la identificación de soluciones a los problemas identificados en la actividad anterior y el estudio de su viabilidad.

127

Cada una de estas actividades puede ser dividida en sub actividades, tal y como se detalla a continuación. 3.6.7.1 Modelado de la situación actual Esta fase de modelado suele comenzar con todos los constituyentes del modelo vacíos, en el caso de que sea desarrollada por miembros ajenos a la organización, y termina cuando todos los constituyentes han alcanzado el estado final deseado. 3.6.7.2 Actividad: Introducción en la organización • Descripción: conocimiento de las características generales de la organización. Este estado es el primero en ser alcanzado tras una breve introducción en la organización. • Estados habilitadores: ninguno. • Estados resultantes: función y estructura identificadas. • Técnicas: estudio de folletos, documentación, etc. y entrevistas con empleados experimentados. • Producto: ninguno. 3.6.7.3 Actividad: Comprensión de la organización • Descripción: obtención de una comprensión global de las estructuras y procesos de la organización. • Estados habilitadores: función y estructura identificadas. • Estados resultantes: personal, proceso y recursos identificados; función y estructura descritos. • Técnicas: actuando como personal externo a la empresa, es necesario llevar a cabo un gran número de entrevistas informales con el personal, comparable al modo en que un gestor interno comienza normalmente su trabajo. • Producto: ninguno. 3.6.7.4 Actividad: Análisis detallado • Descripción: recopilación de información relevante para soportar un estudio de viabilidad detallado. • Estados habilitadores: personal, proceso y recursos identificados; función y estructura descritos. • Estados resultantes: personal, proceso y recursos descritos; función y estructura validada; problemas y oportunidades identificados.

128

• Técnicas: los aspectos relevantes de la organización deben ser analizados. Para identificar los problemas y oportunidades en una organización, normalmente se emplea uno de los tres enfoques siguientes: - Estudio de los procesos: el análisis de los procesos de trabajo permite identificar cuellos de botella en el rendimiento de la organización. - Estudio del conocimiento: el análisis de la disponibilidad y diseminación del conocimiento en la organización permite la identificación de los problemas que pueden ser resueltos con tecnología de sistemas inteligentes. Estudio del personal: el análisis de los aspectos sociales y motivadores permite identificar los problemas y oportunidades de la organización. • Producto: descripciones de los constituyentes de la organización. 3.6.7.5 Actividad: Evaluación del análisis • Descripción: terminación del trabajo en el modelo. Esta es la actividad final de recopilación de datos sobre la organización. • Estados habilitadores: personal, proceso y recursos descritos; función y estructura validada; problemas y oportunidades descritos. • Estados resultantes: todos los constituyentes alcanzan su estado final o son considerados no relevantes. • Técnicas: normalmente la supervisión del proyecto y de la conducta de la organización es suficiente. • Producto: ninguno. 3.6.7.6 Modelado de la situación futura Partiendo de un estado vacío, en que no se dispone de ninguna idea sobre proyectos de sistemas inteligentes, se han identificado las siguientes sub actividades. 3.6.7.7 Actividad: Identificación de soluciones • Descripción: se identifican las soluciones (no se validan). En este estado, se dispone de una lista con los posibles proyectos de sistemas inteligentes, con esquemas de las soluciones deseadas. Esta lista puede verse como hipotética, ya que se basa en pronósticos sobre qué soluciones podrán adecuarse a la organización. 129

• Estados habilitadores: ninguno. • Estados resultantes: problemas y oportunidades identificadas; soluciones identificadas. • Técnicas: se proponen soluciones a partir de la literatura y las experiencias pasadas. • Producto: ninguno. 3.6.7.8 Actividad: Investigación de viabilidad • Descripción: se describe la nueva situación. En primer lugar, durante el estudio de viabilidad, sólo se listan los cambios con la situación antigua. Se deben identificar tantos cambios como sea posible. • Estados habilitadores: problemas y oportunidades identificadas; soluciones identificadas. • Estados resultantes: para la nueva situación: función identificada; proceso descrito; recursos computacionales identificados. Soluciones descritas. • Técnicas: para identificar los cambios pueden emplearse redes de tendencias. • Producto: ninguno. 3.6.7.9 Actividad: Preparación para la toma de decisiones • Descripción: en este estado se conoce suficientemente la viabilidad de los proyectos de sistemas inteligentes listados por prioridad para iniciarlos o paralizarlos. • Estados habilitadores: para la nueva situación: función identificada; proceso descrito; Recursos computacionales identificados. Soluciones descritas. • Estados resultantes: soluciones validadas. • Técnicas: se proponen los siguientes métodos: - la solución (y el plan) tiene que ser estudiada. - los responsables de las decisiones deben ser identificados. - la actitud de dichos responsables frente a los cambios debe ser investigada (matriz de actitudes). - debe averiguarse con qué apoyo se dispone para realizar los cambios. • Producto: ninguno.

130

3.6.7.10 Actividad: Evaluación de soluciones • Descripción: se deriva la nueva situación (al final de proyecto). En este estado la constituyente solución ha alcanzado su contenido final. • Estados habilitadores: soluciones validadas. • Estados resultantes: problema actual descrito. • Técnicas: técnicas estándar de evaluación de soluciones. • Producto: ninguno. 3.6.8 Actividades de modelado de la organización multi-agente El conjunto de actividades que se enuncian a continuación tienen como objetivo la descripción de las relaciones mantenidas entre los agentes software y su entorno. 3.6.8.1 Actividad: Identificación de las relaciones de herencia • Descripción: en este apartado se pretenden identificar relaciones de herencia entre los agentes descritos en el modelo de tarea. Estas relaciones pueden haber sido identificadas directamente al desarrollar un nuevo agente. • Estados habilitadores: agentes descritos. • Estados resultantes: relación de herencia validada. • Técnicas: las técnicas habituales para determinar mecanismos de generalización y especificación, mediante la observación de comparación de propiedades. • Producto: diagramas de herencia. 3.6.8.2 Actividad: Identificación de objetos del entorno • Descripción: se identifican los objetos del entorno con los que los agentes interactúan a través de sensores y actuadores. El modelado de los objetos del entorno nos permite identificar las características y métodos relevantes para el problema. • Estados habilitadores: agente descrito. • Estados resultantes: objetos identificados. • Técnicas: los objetos del entorno representan objetos “pasivos” del entorno, como por ejemplo, cada obstáculo para un agente-robot que tiene que encontrar una salida; una impresora para un agente que debe supervisar si tiene fallos y notificárselo al administrador de la red, etc. • Producto: diagramas de agente y objetos del entorno. 3.6.8.3 Actividad: Identificación y descripción de estructuras organizativas • Descripción: en esta actividad se identifican y describen las estructuras organizativas de la sociedad multi-agente en caso de que se den.

131

• Estados habilitadores: conjunto inicial de agentes identificado y una asignación inicial de tareas. • Estados resultantes: constituyente organización descrita. • Técnicas: la determinación de la estructura de la organización de agentes es un tema que aún debe ser estudiado, y es previsible que tome mayor importancia a medida que las sociedades de agentes sean más numerosas, pudiendo tenerse en cuenta algunos de los criterios aplicables a las organizaciones humanas.. • Producto: ninguno. 3.6.9 Dependencias en la construcción del modelo Las dependencias del modelo de organización con el resto de modelos deben validarse durante el desarrollo del mismo. 3.6.9.1 Modelo de Agente La relación entre el modelo de agente y de organización consiste en que el modelo de organización describe las relaciones estructurales entre los agentes humanos y software tanto de la organización humana como de la sociedad multi-agente. El modelo de organización requiere, por tanto, que se hayan identificado y descrito los agentes. 3.6.9.2 Modelo de Tareas El modelo de tareas está relacionado con la perspectiva del modelo de organización que analiza las funciones desempeñadas en la organización. Las funciones se relacionan con las tareas de dos formas: Una función define principalmente varias tareas requeridas para realizar dicha función y una tarea sirve para realizar una o varias funciones. Las funciones de la organización que vayan a ser realizadas por el sistema multi-agente serán el nodo raíz de un ejemplar del modelo de tareas. 3.6.9.3 Modelo de Comunicación El modelo de comunicación puede obtener información para realizar el modelado de los usuarios del modelo de organización, que debería ser desarrollado con antelación. 3.6.9.4 Modelo de Coordinación El modelo de coordinación depende de las estructuras organizativas definidas en el modelo de organización, en el caso de que se definan. Las estructuras organizativas pueden limitar o definir los protocolos que deben mantenerse entre los componentes de dichas estructuras. 132

3.7

Modelo de Diseño

Frente a la concepción tradicional de que el diseño transforma un conjunto de requisitos, que sólo especifican qué debe hacer el sistema, en la descripción de componentes agrupados en módulos, que especifican cómo se realizan estos requisitos, hemos seguido la filosofía del modelo de diseño original de CommonKADS, en la que se considera el diseño como la descripción de los componentes que satisfacen las restricciones y requisitos que están implícita o explícitamente contenidos en los productos (modelos) de CommonKADS. No contienen sólo los requisitos funcionales, sino que también contienen requisitos no funcionales (tales como el tiempo permitido de ejecución de una tarea) y toman decisiones que podrían ser consideradas de diseño (por ejemplo, el modelado de un razonamiento como causal o heurístico en el modelo de la experiencia). Las ventajas que se pretenden obtener a través del desarrollo del modelo de diseño son: • Separación entre análisis e implementación. (p. ej. con un modelo del dominio & reglas). • Especificación del sistema independiente de la plataforma. • Descomposición de la tarea de diseño. • Adición de requisitos del entorno. • Reutilización de componentes. • Diseño de la interfaz y la interacción. 3.7.1 Antecedentes históricos El modelo de diseño de MAS-CommonKADS parte del modelo homónimo de CommonKADS. Distinguiremos entre diseño del agente (aplicación), diseño de la red (arquitectura) y diseño de la plataforma, tal y como se presenta en el resto del capítulo. 3.7.2 Bases teóricas La arquitectura propuesta se estructura en torno a dos entidades básicas: los agentes y la red a través de la cual interaccionan. Las funcionalidades básicas y las interfaces de la red constituyen el modelo de red.

133

Figura 73: Arquitectura multi-agente genérica

3.7.2.1 El Modelo de Red El modelo de red proporciona a los agentes una visión uniforme de la red. Está definido como un modelo en capas, y distingue entre dos tipos de agentes: • Agentes de red: aquellos agentes que ofrecen servicios para mantener la red. • Agentes de aplicación: aquellos agentes que resuelven un problema concreto de la aplicación de forma autónoma o cooperando con otros agentes. El modelo de red está constituido por tres capas: • Capa de Interfaz: proporciona los mecanismos de abstracción y encapsulación necesarios para aislar al agente de la red a través de la que interacciona con otros agentes. • Capa de Mensaje: implementa las facilidades para gestionar la composición de mensajes y su recepción. Cada mensaje consiste en: - dirección del destinatario y del remitente: En este nivel, los nombres de los agentes son traducidos a direcciones de transporte. - primitiva de comunicación del mensaje: Representa las interacciones primitivas disponibles o entendidas por el agente de acuerdo a un protocolo concreto: solicitar un servicio, responder a un mensaje, conectarse a la red, etc. - cuerpo: Incluye los argumentos del acto comunicativo especificado. Está codificado utilizando un lenguaje de representación del conocimiento concreto. - lenguaje de representación del conocimiento: El lenguaje utilizado para codificar el cuerpo del mensaje que debe ser declarado explícitamente. 134

• Capa de Transporte: es responsable de facilitar el transporte de datos extremo a extremo de forma fiable.

Figura 74: El modelo de red

La capa de mensaje interacciona con el agente a través de la capa de interfaz y entrega/recibe mensajes de la red a través de la capa de transporte. Esta capa ofrece tres grupos de facilidades (modeladas como primitivas de comunicación) para estandarizar las interacciones entre los agentes: • Facilidades de red: Proporcionan los medios para conectarse y desconectarse de la red y para recibir información de los cambios dinámicos del entorno (nuevas conexiones y desconexiones, modificación en la dirección de algún agente, modificación en la oferta de servicios, etc.). • Facilidades de coordinación: Proporcionan un conjunto limitado de primitivas de comunicación para los agentes. También incluye mecanismos de coordinación de Inteligencia Artificial Distribuida (IAD) tales como el protocolo de contratos. • Facilidades de conocimiento: Proporcionan soporte para la gestión de ontologías y de conversión de lenguajes de representación del conocimiento. 3.7.2.1.1 Facilidades de red Este nivel ofrece los siguientes servicios: • Conexión/Desconexión: Se proporcionan primitivas para conectarse y desconectarse de la red. Un agente permanece desconocido al resto de los agentes hasta que se conecte a la red, sin poder recibir ni enviar mensajes. 135

• Registro/Baja de capacidades: Estas primitivas permiten que un agente indique sus capacidades para que otros agentes puedan solicitarlas. • Registro/Baja de capacidades requeridas: Estas primitivas permiten que un agente indique las capacidades en que está interesado. • Servidor de nombres de agentes: Es necesario para mantener y consultar la base de datos que relaciona nombres de agentes con las direcciones de transporte. • Notificación de conexión/desconexión: Proporcionan los medios para notificar a los agentes de la incorporación o salida de nuevos agentes a la red. • Notificación de capacidades requeridas: Este servicio permite informar a los usuarios de qué agentes ofrecen una determinada capacidad, y de si las propiedades de dicha capacidad son modificadas. • Gestión de grupos de agentes: Permiten el mantenimiento de grupos de agentes para el envío de mensajes a grupos. • Gestión de seguridad: Pueden necesitarse mecanismos para cifrar y descifrar los mensajes y prevenir las interferencias de agentes intrusivos. • Gestión de fallos: La red puede ofrecer mecanismos para detectar fallos de los agentes de la misma (p. ej. caídas) y llevar a cabo alguna acción correctiva. • Gestión de tarificación: Pueden necesitarse mecanismos para gestionar la tarificación de los servicios realizados. • Facilidad de trazado: Pueden necesitarse mecanismos para trazar cómo se ha llegado a la consecución de un objetivo requerido. 3.7.2.1.2 Facilidades de coordinación En este nivel se define el conjunto de interacciones permitidas entre los agentes de aplicación, así como los protocolos compuestos de estas interacciones y la coordinación de planes globales. 3.7.2.1.3 Facilidades de conocimiento Se distinguen tres funciones principales dentro de este nivel: • Proporcionar una interfaz transparente entre los objetos y las descripciones de conocimiento, esto es, una interfaz entre el contenido de los mensajes y objetos 136

que pueden manipular los agentes. Este servicio es necesario cuando el lenguaje de programación de los agentes no sea interpretado. • Proporcionar primitivas para acceder a las bases de conocimiento de otros agentes (acertar, eliminar un hecho, realizar una consulta, etc.). • Proporcionar mecanismos para la gestión de ontologías. Los agentes son capaces de interaccionar porque comparten ontologías. Una ontología es una descripción de conceptos en un lenguaje de representación del conocimiento concreto. El cuerpo de los mensajes intercambiados por los agentes se compone de ejemplares encadenados de estos conceptos. Para la gestión de estas ontologías compartidas puede ser conveniente la existencia de agentes de red especializados. 3.7.3 Fundamentos del modelo de diseño 3.7.3.1 ¿Qué problemas de IAD deben ser resueltos en el desarrollo del modelo de diseño? El modelo de diseño aborda la transformación de los requisitos de un sistema en un conjunto de agentes ejecutables. 3.7.3.2 ¿Cuándo el modelo es útil, y cuándo debe ser incluido en el conjunto de modelos? El modelo de diseño debe ser incluido siempre en el conjunto de modelos desarrollados, ya que es el puente entre el análisis y la implementación. 3.7.3.3 Restricciones: ¿qué no puede ser modelado? El modelo de diseño se ha planteado de forma genérica, independiente de la arquitectura de agente y plataforma en que se implementa cada agente. Esto implica que una vez determinados los agentes, los requisitos que deben cumplir, y los recursos de red disponibles, el diseño detallado deberá adaptarse a cada arquitectura. Algunos problemas actuales, como qué tareas deben ser realizadas de una forma deliberativa o reactiva, no han sido abordados.

137

3.7.4 Estructura del modelo El modelo de diseño de MAS-CommonKADS distingue tres clases de decisiones de diseño1 (Figura 10.3): diseño de la red, que consiste en diseñar el modelo de red (sección 10.2.1), diseño de los agentes, que consiste en descomponer cada agente en subsistemas, y diseño de la plataforma, que recoge las decisiones de software y hardware.

Figura 75: Descomposición del modelo de diseño

3.7.4.1 Diseño del modelo de red En este apartado nos proponemos determinar las funcionalidades del modelo de red y los agentes de red encargados de llevarlas a cabo. Deberemos tomar las siguientes decisiones para cada nivel del modelo: 1. Nivel de Red: Se toman las decisiones de diseño sobre la infraestructura de la arquitectura multi-agente. Se deben especificar qué agentes se necesitan para mantener la sociedad multi-agente (facilitadores, gestores de bases de conocimiento, coordinadores de grupos, etc.). Es necesario responder diversas preguntas, como por ejemplo: • ¿Es necesario un agente servidor de nombres (ANS)? • ¿Es necesario un agente gestor de grupos de agentes? • ¿Es necesario un almacén de servicios? ¿Debe ser dinámico o estático? • ¿Es necesario una capacidad de intermediario (bróker)? • ¿Qué protocolo telemático es más adecuado para esta aplicación (http, enchufes tcp, correo electrónico, etc.)? • ¿Qué grado de seguridad se necesita? Las interacciones necesarias para realizar tareas de red tales como conectarse a la red, desconectarse de la red, etc., pueden ser representadas en los diagramas definidos en el modelo de coordinación. 2. Nivel de Conocimiento: Varias decisiones de diseño deben ser tomadas para la gestión de las ontologías:

138

• ¿Hay ontologías distribuidas? ¿Es necesario un gestor de ontologías? • ¿Deben los agentes entender diferentes lenguajes de representación del conocimiento? ¿Es necesario un agente traductor entre lenguajes de representación del conocimiento? • ¿Hay PSMs distribuidos? ¿Es necesario un gestor de PSMs? 3. Nivel de Coordinación: En aras del reciclaje software, varios autores han señalado las ventajas de definir el conocimiento de cooperación como un módulo reciclable o la definición de protocolos de coordinación reciclables Este conocimiento, el conjunto de primitivas adecuadas y los agentes para formar planes conjuntos son la base de la definición de este nivel. Las decisiones tomadas en el diseño de la red se describen enunciando los servicios que el nivel de red ofrece a los agentes y los agentes de red que ofrecen dichos servicios (Figura 10.4).

Figura 76: Constituyentes del diseño de red

3.7.4.2 Constituyentes del modelo 3.7.4.2.1 Constituyentes del diseño de red La plantilla del modelo de diseño de MAS-CommonKADS contiene por defecto las entidades y relaciones mostradas en la Figura 10.4. Los constituyentes de Servicios y Agentes se describen con las plantillas definidas en el modelo de agente. Los principales componentes del diseño de la red son: Red entidad. La red representa el conjunto de facilidades que son ofrecidas a todos los agentes y que constituyen la infraestructura de la sociedad de agentes. 139

Figura 77: Constituyentes del diseño de los agentes

3.7.4.3 Diseño de los agentes El diseño de los agentes documenta la arquitectura seleccionada para cada agente y las funciones de los módulos que deben implementarse en dicha arquitectura. Los principales componentes del diseño de los agentes son: Sistema-Agente entidad. El sistema agente representa un agente que va a ser implementado y está siendo diseñado. Puede corresponderse con uno o varios ejemplares del modelo de agente. Subsistema entidad. Subsistema o módulo de un agente. Diseño detallado subsistema entidad. Descripción en un lenguaje de diseño detallado de un subsistema de un agente.

140

Figura 78: Diseño de la plataforma

3.7.4.4 Diseño de la plataforma El diseño de la plataforma permite documentar las decisiones de bajo nivel sobre el lenguaje de implementación seleccionado, el software y hardware empleado y los usuarios finales del sistema. Los principales componentes del diseño de la plataforma son: Plataforma entidad. La plataforma recoge todas las decisiones del entorno de implementación y operación del sistema multi-agente. 3.7.5 Ciclo de desarrollo del modelo El modelo de diseño no contempla, por el momento, desarrollos estándar y no estándar. Siguiendo el modelo de diseño de CommonKADS, podemos distinguir los siguientes enfoques: 1. Atendiendo al empleo de una biblioteca de diseño o no, podemos seguir dos enfoques: - Uso de biblioteca de componentes: el diseño se crea con componentes de una biblioteca de diseño que son localizados, seleccionados, especializados, configurados y combinados en el diseño. - Construcción a partir de cero: todos los componentes se crean específicamente para el diseño. 2. Atendiendo a la dirección de los modelos de especificación, podemos distinguir entre: - Especificación descendente: se estudia cómo diseñar las tareas del modelo de tareas, y se refina: tareas del modelo de la experiencia,

141

inferencias del modelo de la experiencia, modelo del dominio; por otra parte tareas del modelo de coordinación, etc. - Especificación ascendente: se recorre el árbol desde las hojas hasta llegar a la raíz del modelo de tareas. 3. Atendiendo a cómo se tratan las estructuras de los modelos de especificación, podemos distinguir entre: - Preservación de la estructura: las estructuras de los modelos de especificación se transforman en estructuras isomórficas del modelo de diseño. - Eliminación de la estructura: se eliminan las estructuras de control de los modelos de especificación en el modelo de diseño. - Re emplazamiento de la estructura: se recoge la información de los modelos de especificación pero se sustituye por una estructura más útil. 3.7.6 Dependencias en la construcción del modelo El modelo de diseño debe estar vinculado al resto de modelos, ya que especifica cómo las funcionalidades definidas en el resto de modelos son implementadas. En CommonKADS los modelos de especificación presentan una especificación detallada del comportamiento del sistema, no sólo de los requisitos de dicho sistema. Por tanto, aportan más información que la contenida en un documento de requisitos software. Los modelos de análisis de CommonKADS deben expresar todos los requisitos funcionales (que describen la conducta funcional del sistema) y expresan, además, algunos de los requisitos no funcionales (requisitos de restricciones para que una implementación sea aceptable). 3.7.6.1 Modelo de agente El modelo de agente recoge las restricciones y capacidades de los agentes para llevar a cabo los objetivos asignados. En el diseño pueden combinarse o subdividirse los agentes del análisis, bien para satisfacer requisitos no funcionales, bien debido a las características de la arquitectura de agente seleccionada (por ejemplo si permite la realización de tareas simultáneas o no). 3.7.6.2 Modelo de comunicación El modelo de comunicación es la entrada del diseño de la interfaz de usuario. En dicho modelo se ha recogido la representación de la información intercambiada y la secuencia de interacciones entre el usuario y el sistema.

142

3.7.6.3 Modelo de tareas El modelo de tareas puede ayudar en el diseño, dado que ofrece la descomposición global de tareas del sistema, algunas de las cuales son descompuestas en otros modelos (experiencia, comunicación, coordinación) y asignadas a agentes. Los atributos “funcionales” de la plantilla textual del modelo de tareas son objetivo, precondición y control-tareas. Los atributos “no-funcionales” de dichas plantilla son frecuencia y tiempo-ejecución. Estos parámetros pueden influir en la implementación de dichas funciones o en el diseño general de la aplicación para satisfacer estas restricciones. 3.7.6.4 Modelo de la experiencia La comunidad de adquisición del conocimiento ha estudiado en profundidad cómo se pueden “operar” las descripciones conceptuales de los modelos de la experiencia. 3.7.6.5 Modelo de organización El estudio de la organización restringe las decisiones de diseño. En concreto, en el modelo de organización se enumeran los recursos hardware y software disponibles. También el estudio de la organización puede proporcionar información sobre los requisitos no funcionales, tales como estándares seguidos para la instalación, operación y mantenimiento de aplicaciones, políticas de seguridad, etc. 3.7.6.6 Modelo de coordinación El modelo de coordinación describe las interacciones y protocolos entre los agentes y el procesado de dichas interacciones. El diseño de los protocolos entre agentes deberá seguir las especificaciones desarrolladas en el modelo de coordinación. 3.7.6.7 Actividades de desarrollo del modelo de diseño 3.7.7 Diseño de la red 3.7.7.1 Actividad: Identificación y descripción de las facilidades de red • Descripción: en esta actividad pretendemos identificar qué facilidades debe ofrecer el modelo de red. • Estados habilitadores: agentes validados, recursos computacionales descritos, estructura descrita. • Estados resultantes: servicios de red identificados.

143

• Técnicas: proponemos la realización de un formulario para determinar qué servicios de red son necesarios. Los servicios de red determinados servirán como guía en la selección de una plataforma multiagente u otra. • Producto: formulario y conjunto de servicios descritos. 3.7.7.1.2 Servicios de red básicos En este apartado se pretenden determinar qué servicios de red básicos son necesarios. En general, puede asumirse que una aplicación deseará tener todos los servicios de red básicos. Sólo deberá revisarse el número de servicios de red básicos cuando se haya percibido el riesgo de obtener agentes demasiado complejos (por ejemplo para ser móviles) y se desee reducir la complejidad de los mismos. Podemos considerar como servicios básicos, partiendo de la especificación de la FIPA: 1. Servicio de comunicación básica. 2. Servicio de páginas blancas. Un servidor de nombres de agentes mantiene una lista de nombres de agentes junto con sus direcciones. El servidor de nombres de agentes asegura que los identificadores de los agentes son únicos. Los agentes se registran cuando han obtenido un identificador válido, y se desapuntan cuando dejan de estar en las páginas blancas. 3. Servicio de páginas amarillas. Un servicio de páginas amarillas o directorio permite registrar a los agentes sus servicios y consultar quién ofrece un servicio. 3.7.7.1.3 Servicios de red avanzados En este apartado se pretenden determinar qué servicios de red avanzados son necesarios en nuestra aplicación. Definimos un servicio avanzado como aquel que ofrece una funcionalidad añadida a la mera comunicación entre los agentes y a la solicitud mutua de servicios. Estos servicios pueden ser ofrecidos por agentes de aplicación o por agentes de red. 3.7.7.1.4 Servicios de red no funcionales En este apartado se pretende determinar qué servicios de red debemos ofrecer para satisfacer requisitos no funcionales del sistema. Podemos citar los siguientes servicios no funcionales: 1. Seguridad. 2. Protocolos de comunicación.

144

3.7.7.2 Actividad: Identificación y descripción de las facilidades de conocimiento • Descripción: el objetivo de esta actividad es la identificación y descripción de los servicios que permiten a los agentes comunicar conocimiento y procesar lenguajes de representación del conocimiento. • Estados habilitadores: agentes validados, recursos computacionales descritos, estructura descrita. • Estados resultantes: servicios de conocimiento descritos. • Técnicas: proponemos la realización de un formulario para determinar qué servicios de red son necesarios. • Producto: plantillas asociadas. 3.7.7.2.1 Servicios de conocimiento básicos En este apartado ofrecemos una lista los servicios de conocimiento más frecuentes. 1. Servidor de ontologías: proporciona a los agentes la capacidad de recibir conocimiento sobre un dominio durante su ejecución. 2. Servidor de métodos de resolución de problemas (PSM, Problem Solving Methods): proporciona a los agentes la capacidad de obtener dinámicamente métodos de resolución de un problema y poder aplicarlos. 3. Servicio de traducción de lenguajes de conocimiento. Proporciona servicios de traducción entre dos lenguajes de representación del conocimiento. 4. Servicios especiales (planificación, programación lógica de restricciones, etc.). Dado que las capacidades de los agentes deben limitarse (deben tener la mínima inteligencia requerida), podemos pensar que determinadas capacidades de razonamiento pueden ser ofrecidas por agentes especializados (como realizar tareas de planificación o empleo de programación lógica de restricciones en problemas de configuración). 3.7.7.3 Actividad: Identificación y descripción de las facilidades de coordinación • Descripción: en esta actividad pretendemos identificar qué facilidades de coordinación debe ofrecer el modelo de red. • Estados habilitadores: agentes validados, recursos computacionales descritos, estructura descrita.

145

• Estados resultantes: servicios de coordinación descritos • Técnicas: proponemos la realización de un formulario para determinar qué servicios de coordinación son necesarios. • Producto: plantillas asociadas. 3.7.7.3.1 Servicios de coordinación En este apartado ofrecemos una lista de los servicios de coordinación más frecuentes. 1. Ontología de protocolos y lenguajes de comunicación de agentes disponibles. El nivel de coordinación ofrece a los agentes una ontología con los protocolos y lenguajes de comunicación que pueden ser empleados en dicha red. 2. Servidor de protocolos. Un servidor de protocolos puede ofrecer a los agentes protocolos de comunicación (negociación, puja, etc.) que son cargados dinámicamente. 3. Gestión de grupos. La gestión de grupos puede requerir que se gestione el turno para comunicarse dentro del grupo, así como la creación de direcciones de grupo, etc. que pueden ser gestionados por agentes de red. 4. Arbitrio. Los agentes pueden desear recurrir a una autoridad con una visión más global del problema para resolver sus conflictos. 5. Detección de agentes maliciosos o mal uso de recursos comunes. Agentes “policía” pueden vigilar la conducta de los agentes para prevenir la presencia de agentes maliciosos o el abuso de recursos comunes. 3.7.7.4 Actividad: Identificación y descripción de agentes de red • Descripción: identificación de los agentes de red necesarios para ofrecer los servicios de red identificados, teniendo en cuenta los agentes y servicios ofrecidos por la plataforma multi-agente. • Estados habilitadores: servicios de red descritos, plataforma identificada. • Estados resultantes: agentes de red para facilidades de red descritos • Técnicas: la descripción de los agentes se realiza empleando las plantillas del modelo de agente. Los agentes de red, debido a su independencia de la red, pueden ser fácilmente reutilizables entre aplicaciones. • Producto: plantillas asociadas. 146

3.7.8 Diseño de la aplicación 3.7.8.1 Actividad: Determinación de la arquitectura de los agentes • Descripción: en esta actividad nos proponemos determinar qué arquitectura es la más adecuada para cada agente. • Estados habilitadores: agentes validados, recursos computacionales descritos, estructura descrita. • Estados resultantes: arquitectura de agente descrita. • Técnicas: la determinación de la arquitectura para cada agente es aún un tema de estudio. Aún no se disponen de bancos de prueba que permitan determinar cuándo una arquitectura es mejor que otra. Podemos enumerar varios aspectos que nos pueden ayudar a seleccionar una arquitectura: - Aspectos derivados de las plataformas disponibles para la arquitectura: los recursos o normas de la organización pueden requerir que los agentes sean programados en un lenguaje o con unos protocolos determinados. - Necesidad de deliberación y reacción: los agentes con capacidades de razonamiento y/o reacción frente al entorno deberán ser modelados con una arquitectura que facilite estas características. La cuestión de utilizar una arquitectura puramente reactiva, puramente deliberativa, o una híbrida, puede basarse en la experiencia de los desarrolladores. La cuestión de en qué nivel de abstracción debe situarse la resolución de un problema (coherencia ascendente ) y que no produzca interacciones dañinas entre diferentes niveles de abstracción (coherencia descendente) es un tema aún en investigación. - Necesidad de paralelismo en la ejecución de acciones: un aspecto relevante para la selección de una arquitectura es si un agente queda bloqueado o no al realizar una tarea. - Problemas de tiempo real: también debemos tener en cuenta si necesitamos que se garantice un tiempo de ejecución para las tareas realizadas por el agente. - Necesidad de movilidad: otro aspecto a tener en cuenta es la necesidad de movilidad de los agentes para trabajar con recursos de otras máquinas. • Producto: plantillas asociadas. 3.7.8.2 Actividad: Revisión de los agentes identificados • Descripción: en esta fase, una vez determinadas las arquitecturas de cada agente identificado en el análisis, se revisan los agentes y se identifican agentes adicionales o se funden agentes identificados. 147

• Estados habilitadores: agentes validados, recursos computacionales descritos, estructura descrita, arquitectura descrita. • Estados resultantes: diseño de agentes validado. • Técnicas: se proponen una serie de heurísticos para identificar nuevos agentes o combinar varios agentes. • Producto: ninguno. 3.7.8.3 Actividad: Diseño detallado de los módulos • Descripción: el objetivo de esta actividad es la especificación de los agentes y de sus principales módulos. Esta especificación debe realizarse con un lenguaje de agentes. • Estados habilitadores: diseño de agentes validado. • Estados resultantes: módulos descritos. • Técnicas: la especificación de cada agente empleando un lenguaje de agentes como lenguaje de diseño detallado, suponiendo que no hay ningún agente adecuado en nuestra biblioteca de agentes. • Producto: plantillas asociadas. 3.7.9 Diseño de la plataforma Basándose en el diseño de la arquitectura, la arquitectura de agente seleccionada y en los requisitos no funcionales, se lleva a cabo la selección del sistema operativo y de la plataforma software y hardware. Las tres decisiones están relacionadas, por lo que no se impone un orden entre ellas. 3.7.9.1 Actividad: Selección del lenguaje de implementación • Descripción: en esta actividad se documentan las razones para seleccionar un lenguaje de implementación. • Estados habilitadores: diseño de agentes validado. Estados resultantes: lenguaje de implementación identificado. • Técnicas: la selección de un lenguaje de implementación dependerá de: - Política general de la organización, recursos disponibles, interoperabilidad con otros sistemas de la organización y previsión de su desarrollo en años posteriores. - Experiencia de los programadores. 148

- Disponibilidad de plataformas multi-agente para la arquitectura de agente deseada en ese lenguaje. • Producto: plantillas asociadas. 3.7.9.2 Actividad: Selección de los recursos software • Descripción: en esta actividad tenemos como objetivo documentar la selección realizada de recursos software. • Estados habilitadores: diseño de agentes validado. • Estados resultantes: servicios de red identificados. • Técnicas: la selección de los recursos software se basará en estudiar qué herramientas están disponibles en la organización o es necesario adquirir para realizar los agentes. De cada herramienta deberemos indicar el nombre, requisitos software y hardware, la versión y las condiciones de operación. • Producto: plantillas asociadas. 3.7.9.3 Actividad: Selección de los recursos hardware • Descripción: esta actividad tiene como objetivo documentar el hardware necesario para ejecutar el sistema multi-agente desarrollado. • Estados habilitadores: diseño de agente validado. • Estados resultantes: hardware identificado. • Técnicas: deberá documentarse qué hardware (tanto ordenadores como robots, sensores, etc.) de la organización es empleado para ejecutar el sistema multiagente y en qué plata formas hardware se puede ejecutar el sistema desarrollado. • Producto: plantillas asociadas.

149

3.8 APLICACION DE CASO DE ESTUDIO “SMA SUBASTAS” EN MAScommonKads En este capítulo se desarrolla el SMA de Subastas Aplicado en la metodología MAS common kads. Para posteriormente compararlo con el hecho en masina. Actividad: Identificación de los actores EL SMA subasta es muy elemental y está pensado para pensado para su posterior aplicación en un lenguaje de agentes, solo interactúan dos tipos de agentes uno postor y otro el subastador. Actividad: Descripción de los actores Nombre Agente postor: encargado de realiar la puja al iniciar una subasta. Nombre Agente subastador: encargado de iniciar y finalizar las subastas, recibe y publica las pujas Actividad: Identificación de los casos de uso Nuestro sistema cuenta con 4 casos de uso. Subastar Artículos: Se incluyen los artículos a subastar y se publican con el tipo de subasta, el agente subastador y el precio base Buscar Artículos: Se realiza una búsqueda del articulo a adquirir al encontrarlo se comprueba que el precio base no sobrepase el precio tope, para nuestro ejemplo todo articulo interesa a nuestros postores. Realizar puja: Se realiza la puja por el artículo seleccionado, según criterios de riesgo beneficio Anunciar puja mayor:

150

Se publica la puja ganadora hasta el momento para que los postores realicen una puja mayor, si no se obtiene una puja mayor de cierto tiempo se declara como la puja final y ganadora.

Notación de los casos de uso Actor Subastador

Postor

Portor

Subastador

Descripción Se incluyen los artículos a subastar y se publican con el tipo de subasta, el agente subastador y el precio base Se realiza una búsqueda del articulo a adquirir al encontrarlo se comprueba que el precio base no sobrepase el precio tope, para nuestro ejemplo todo articulo interesa a nuestros postores. Se realiza la puja por el artículo seleccionado, según criterios de riesgo beneficio Se publica la puja ganadora hasta el momento para que los postores realicen una puja mayor, si no se obtiene una puja mayor de cierto tiempo se declara como la puja final y ganadora.

Caso de uso “Subastar Artículo”

151

Casos de uso Subastar Artículos

Buscar Artículos

Realizar puja

Anunciar Ganador

Descripción:

Actores: Precondición: Excepción: Se toma el articulo seleccionado para subastar se realiza un incremento de ganancia, y se publica en una pizarra para que los postores se enteren de ella. Subastador. Debe existir un artículo a subastar con su respectivo precio, así cono postores registrados. No sé a incluido artículo a subastar.

Caso de uso “Buscar Artículos” Descripción: Actores: Precondición: Excepción: Se identifica la presencia de un artículo y se anuncia el interés de participar en la subasta... Subastador. Debe existir un artículo a subastar con su respectivo precio, y este no sobrepase el dinero disponible. No sé han incluido artículos a subastar. O el precio sobrepasa el monto disponible.

152

Caso de uso “Realizar Puja” Descripción: Actores: Precondición: Excepción: Se realiza la puja por el artículo seleccionado, según criterios de riesgo beneficio. Postor. El precio del artículo aumentado para realizar la puja no sobrepasa el monto disponible. El precio es muy alto para competir.

Caso de uso “Anunciar Ganador”

153

Descripción:

Actores: Precondición: Excepción: Se publica la puja ganadora hasta el momento para que los postores realicen una puja mayor, si no se obtiene una puja mayor de cierto tiempo se declara como la puja final y ganadora. Subastador. Se recibió la puja de un postor, la cual es mayor a la puja o ganadora en el momento.

La etapa de análisis corresponde a la segunda fase de la metodología de desarrollo en la cual se desarrollan los modelos de agente, tareas, comunicación, coordinación e inteligencia, con el fin de obtener las especificaciones y requerimientos del SMA.

3.8.1 Modelo de agentes Con los actores identificados en la fase anterior se identifica los agentes que denotan al DMA de subasta. Cada actor en nuestro caso identifica un agente por lo cual tenemos dos agentes. • Agente postor • Agente Subastador Los modelos de agentes están concretamente establecidos y se definen a través de las tarjetas CRC (Clase / Responsabilidad / Colaboración)

154

AGENTE: SUBASTADOR Objetivo Planes Identificar qué Analizar tipo de subasta articulo se aplicara Ofrecer subasta

Decidir ganador

CLASE: SOFTWARE Conocimiento Colaborador Servicio el Que metodología es la más apropiada según el articulo Ofrecer artículo, Ofrecer subastas con tipo de subasta, precio inicial. Recibir pujas e Tiempo limiten Agente postor Terminar subasta informar la y decidir mayor hasta ganador. cumplir el tiempo limite

Tarjeta CRC para subastador

AGENTE: Objetivo Identificar Subasta

Pujar

POSTOR Planes Reconocer subastas de interés que no sobrepasen el tope. Realizar puja por el articulo

Conocimiento Precio,

formulas para realizar pujas

Tarjeta CRC para postor

155

CLASE: SOFTWARE Colaborador Servicio Inscribirse e la subasta

Pujar

Agente Subastador Tipo Agente software. capacidades-razonamiento Experiencia Conocimiento de las metodologías de subastas, y cual es mejor para el artículo. Descripción Este agente l incluir el articulo decide qué tipo de metodología de subasta aplicara y la publicara con el precio base, y comenzara la subasta, la cual se adjudicara al mejor precio ofrecido. Agente Postor Tipo Agente software Experiencia El agente toma el precio base y puja según la fórmula de incremento, estipulada, para ganar el artículo. Descripción El agente posee formulas matemáticas para saber cuándo realizar la puja y por cuanto será esta. Tras haber asignado las tareas a los agentes, realizaremos una tabla agentes-tareas (tabla A.1) que nos permite comprobar algunos de los criterios de calidad enunciados en la sección 8.6. Por ejemplo, el criterio de cobertura podemos comprobarlo mirando si ninguna fila (tarea) está vacía. También puede realizarse marcando las asignaciones en el árbol del modelo de tareas. Subastador Postor

Pública subasta X

Realiza puja

Decide ganador X

X

Identificación y descripción de objetivos Se pueden identificar objetivos a partir de la asignación de tareas a cada agente (tarjetas CRC), a partir de los objetivos que surgen cuando se da una condición en su entorno (objetivos reactivos), en el estado del agente o para asistir a otros agentes. Para describir estos objetivos utilizamos la plantilla definida en el modelo de agente. Objetivo Publicar subasta Tipo 156

Objetivo persistente. parámetros-entrada Ingreso de tipo de artículo, precio de base parámetros-salida Subasta, con tipo de subasta, numero de subastador, precio... condición-activación Al nacer el agente y recibir el articulo. condición-finalización al terminar subasta y vender el artículo. Descripción El agente decide que subasta es la más adecuada y publica el agente Objetivo Realizar puja Tipo Objetivo persistente Parámetros de entrada Registro de subasta, con tipo de subasta, precio base Parámetros de salida Puja del artículo, con precio inferior al tope Condición de activación Al nacer el agente Condición de finalización Ganar subasta, o sobrepasar el precio tope Descripción El agente postor realiza la punas necesarias hasta que se decrete un ganador o la puja siguiente sobrepase el precio tope propio. 3.8.2 Modelo de Experiencia Los agentes al ser tan sencillos, no son susceptibles a la Experiencia, pues estarán guiados por simples formulas matemáticas, para la toma de decisiones, en cuanto a precio a subastar, precio de oferta de puja y demás. Este maneja una ontología muy básica con lo cual su dominio es completo pues su entorno cambiara en el tiempo Experiencia

157

Representación Tipo Grado de Confiabilidad Esquema de procesamiento Reglas matemáticas De acuerdo al acaso Al utilizar un operador randomico es impreciso. No cambia con el tiempo

Mecanismo de Aprendizaje “Vetado para este ejemplo pues no lo utiliza.” Mecanismo de Razonamiento “Racionamiento estrictamente matemático” Los agentes saben que existen otros agentes a su alrededor pero solo se interesa por que el subastador conozca a los postores y el postor a l subastador Nota: Cabe anotar que en nuestro ejemplo se pretende demostrar la fiabilidad de la metodología más no la complejidad del ejemplo en sí. 3.8.3 Modelo de coordinación Con el modelo de coordinación se describe el esquema de comunicación del SMA; es decir, la conversación, los protocolos y los lenguajes asociados. Identificación de las conversaciones Ya hemos identificado algunas de las conversaciones mantenidas con la técnica de tarjetas CRC. Sin embargo, para ilustrar la técnica de casos de uso internos, realizaremos los mismos casos con esta técnica Descripción de las conversaciones La descripción de las conversaciones se realiza desde dos puntos de vista: • Externo: analizamos cuál es el objetivo de la conversación, su pre y pos condiciones, y qué participantes hay. • Estructural: qué fases tiene la conversación y qué intervenciones se dan en cada fase.

158

La conversación de los agentes es lineal, solo se interesa en hacer llegar el mensaje correspondiente a su destino.

Subasto artículo

Subastador

Postor Pujo

Gana puja

Figura 79: Conversación en subasta

Conversación Subasto articulo Tipo Entrega-de-información. Objetivo Informar la apertura de subasta Agentes Subastador, postor (Grupo). Iniciador Subastador Servicio Articulo a subastar Descripción El agente Subastador anuncia a todos los postores el inicio de un artículo en la subastas Precondición Articulo definido en metodología Pos condición Información ofrecida (de éxito o error). condición-terminación

159

Inicio de puja, o finalización de tiempo. tiempo-ejecución El tiempo de ejecución no debe superar 1 minutos, que es el tiempo máximo recomendado para el uso de recursos. Conversación pujo Tipo Entrega-de-información. Objetivo Realizar una puja por el artículo. Agentes Postor, Subastador Iniciador Postor Servicio Puja (articulo, cantidad, postor) Descripción El agente postor anuncia al agente subastador su oferta por el articulo. Precondición Conocimiento de inicio de subasta Pos condición Información de puja mayor condición-terminación Envió del mensaje. tiempo-ejecución Lance inmediato. Conversación gana puja Tipo Entrega-de-información. Objetivo Informar mayor puja recibida (artículo, puja, postor) Agentes Subastador, postor (Grupo). Iniciador Subastador Servicio Articulo a subastar Descripción El agente Subastador anuncia a todos los postores la puja por el articulo en la subastas Precondición Recepción de puja Pos condición 160

Finalización de subasta condición-terminación Finalización de timer. tiempo-ejecución El tiempo de ejecución no debe superar 1 minutos, que es el tiempo máximo recomendado Para el uso de recursos. Canales básicos de comunicación Una vez desarrolladas todas las conversaciones, se puede determinar qué interacciones (mensajes) son válidas (permitidas) entre los agentes, y representar esta información en un diagrama resumen, como el que se muestra en la Figura.

Ask (art, sub, pre, tip) Subastador

Postor

Tell(art,pos,pre,) Figura 80: Canales de comunicación

Determinación de grupos de agentes Durante la identificación de las conversaciones, se detecta un grupo, denominado postores que describimos a continuación, con la plantilla del modelo de agente: Grupo postores. Tipo Público, dinámico. Componentes Postor. Descripción Grupo formado por agentes que ofrecen pujas. Este grupo es público y realiza las pujas en la subasta Servicio-ofrecido Puja. 161

3.8.4 Modelo de tareas El modelo de tareas permite mostrar la descomposición funcional del sistema, y parte de las áreas funcionales (constituyente función) de la organización en que se va a introducir el sistema inteligente. En nuestro caso, el sistema no es muy inteligente.

Escoger tipo de subasta

Holandesa

Inglesa (Predeterminada)

Sobre cerrado

Figura 81: Descomposición de tarea Escoger tipo de subasta

Tarea Escoger tipo de subasta Objetivo Decidir qué tipo de metodología le conviene al artículo. Descripción En esta tarea se decide, que tipo de metodología aplicar a la subasta del articulo. Entrada Registración de un tipo para subastar Salida Tipo de subasta escogida Precondición Solicitud recibida. Tipo-de-descomposición Temporal. 3.8.5 Modelo de comunicación El desarrollo del modelo de comunicación en un sistema multi-agente puede subdividirse en el conocimiento de la aplicación, el propio agente, el resto de agentes y el entorno.

162

Tomemos, por ejemplo, el agente Subastador. Como el agente Subastador no tiene capacidades reactivas, no seleccionaríamos una arquitectura reactiva ni híbrida, sino una deliberativa. De los módulos identificados en el modelo de diseño, el agente Subastador no tiene interacción con el usuario ni con el exterior. El módulo de comunicación con los agentes está integrado en la plataforma, y dado que Subastador no emplea ningún protocolo especial, no es necesario definirlo, ya que los mensajes intercambiados han sido ya expresados en FIFA. Acto de habla: Nombre del acto de habla Objetivo Tipo Comunicación Agentes Participantes Emisor Receptor Conversación Servicio Datos Intercambios Descripción Precondición Condición de Terminación Per formativa Medio de Comunicación Acto de habla: Nombre del acto de habla Objetivo Tipo Comunicación Agentes Participantes Emisor Receptor Conversación Servicio Datos Intercambios

Objetivo del acto de habla Tipo de acto de habla: asertivo, directivo, compromisivo y declaraciones. Un acto de habla puede ser realizado de manera directa o indirecta. Agentes que participan en el acto de habla. Emisor del mensaje. Receptor del mensaje. Nombre de la conversación donde participa. Nombre del servicio asociado. Descripción de los datos intercambiados en el acto de habla Descripción de intervención en lenguaje natural Condiciones que deben darse en el emisor y receptor para dicha intervención pueda darse con éxito. Condiciones en el emisor y receptor tras el desarrollo de la intervención. Verbo que describe la intención del acto de habla. Vía de comunicación.

Objetivo del acto de habla Tipo de acto de habla: asertivo, directivo, compromisivo y declaraciones. Un acto de habla puede ser realizado de manera directa o indirecta. Agentes que participan en el acto de habla. Emisor del mensaje. Receptor del mensaje. Nombre de la conversación donde participa. Nombre del servicio asociado. Descripción de los datos intercambiados en el acto de habla

163

Descripción Precondición Condición de Terminación Per formativa Medio de Comunicación

Acto de habla: Nombre del acto de habla Objetivo Tipo Comunicación Agentes Participantes Emisor Receptor Conversación Servicio Datos Intercambios Descripción Precondición Condición de Terminación Per formativa Medio de Comunicación

Descripción de intervención en lenguaje natural Condiciones que deben darse en el emisor y receptor para dicha intervención pueda darse con éxito. Condiciones en el emisor y receptor tras el desarrollo de la intervención. Verbo que describe la intención del acto de habla. Vía de comunicación.

Objetivo del acto de habla Tipo de acto de habla: asertivo, directivo, compromisivo y declaraciones. Un acto de habla puede ser realizado de manera directa o indirecta. Agentes que participan en el acto de habla. Emisor del mensaje. Receptor del mensaje. Nombre de la conversación donde participa. Nombre del servicio asociado. Descripción de los datos intercambiados en el acto de habla Descripción de intervención en lenguaje natural Condiciones que deben darse en el emisor y receptor para dicha intervención pueda darse con éxito. Condiciones en el emisor y receptor tras el desarrollo de la intervención. Verbo que describe la intención del acto de habla. Vía de comunicación.

3.8.6 Modelo de Organización

164

El modelo de organización de MAS-CommonKADS tiene como objetivo analizar desde una perspectiva de grupo las relaciones entre los agentes (tanto software como humanos) que interactúan con el sistema. Por lo tanto es exclusividad a tratar a qui la relación agente soft- agente soft, pues no se evidencia interacion humana

La pizarra es una zona de trabajo común que permite a los agentes compartir todo tipo de información. Un sistema multiagente puede tener varias pizarras con distintos agentes registrados en cada una. No hay comunicación directa entre agentes

3.8.7 El Modelo de Red El modelo de red proporciona a los agentes una visión uniforme de la red. Está definido como un modelo en capas, y distingue entre dos tipos de agentes: El modelo de red en este ejemplo se omite pues todos trabajan sobre la misma plataforma JADE, o ZEUS que implementa paquetes de JADE la cual sereige al estándares de comunicación internacionales de la FIPA por lo tanto no hay necesidad de enfocarse en estos para este sensillo caso de ejemplo,

165

CAPITULO IV 4

MASINA: Multi Agent Systems in Automation [22] [23] [24]

MASINA: Una Metodología para Especificar Sistemas Multi-agentes Una metodología para especificar Sistemas Multi-agentes denominada MASINA. La metodología MASINA está fundamentada en MAS-CommonKADS; (p.e., redes neuronales artificiales), y especificar esquemas de coordinación emergentes, entre otras cosas. MASINA está basada en cinco modelos: Modelo de Agente, que describe las características de cada agente, con dos extensiones particulares, una que permitir el uso de modelos de referencia para especificar un agente dato, y otra para modelar los niveles de abstracción del Sistema Multi-agentes; Modelo de Tareas que representa las actividades realizadas por los agentes para alcanzar sus objetivos, en nuestra extensión es posible especificar tareas que requieren el uso de técnicas inteligentes, así como describir el macro algoritmo de la tarea; Modelo de Inteligencia que describe los conocimientos, mecanismo de aprendizaje y métodos de razonamiento necesarios para que los agentes cumplan sus objetivos; Modelo de Coordinación que agrupa las interacciones en conversaciones y define los mecanismos para que esas interacciones se lleven a cabo coherentemente y Modelo de Comunicación que describe los actos de habla (interacciones). (Multi Agent Systems in Automation). Esta metodología usa como base a MASCommonKADS (por ende se detallo exhaustivamente en el capitulo anterior), proponiendo algunas extensiones, modificaciones y sustituciones de los modelos definidos en MAS-CommonKADS. MASINA permite plasmar elementos fundamentales del área de SMA, como representar la noción de inteligencia en un agente (modelado de agentes inteligentes), a nivel colectivo, los mecanismos de coordinación entre agentes (planificación emergente, resolución de conflictos, etc.), la comunicación directa o indirecta, entre otras cosas. Además, es posible representar aspectos como el uso de técnicas inteligentes para realizar tareas, o modelos de referencia para especificar agentes. Finalmente, MASINA permite describir las conversaciones entre los agentes como los actos de habla (interacciones) presentes en las mismas. La metodología MASINA es una extensión del modelo orientado a objetos MASCommonKADS. MASINA se basa en el mismo ciclo de desarrollo del MASCommonKADS, pero reduce a cinco sus siete modelos, con los cuales describe las 166

características básicas de los SMA. Los modelos modificados corresponden a la fase de análisis, y se presentan en la siguientes sub-secciones.

Figura 82: Modelos de MASINA

4.1 Modelo de agentes Se le agregaron 2 extensiones, una para especificar si un agente forma parte de una sociedad de agentes (si forma parte de un SMA), y otro para identificar si el diseño del agente se realizo siguiendo un modelo de referencia de agente. Este modelo especifica, al igual que en el MAS-CommonKADS, las características de un agente como: habilidades, servicios, entre otras. Además, a este modelo se le agregaron dos atributos: "componentes de ese agente", que permite indicar si el mismo es un SMA (permite representar niveles de abstracción o jerarquías en el diseño del SMA); y "marco de referencia", que sirve para indicar si la especificación de ese agente está basada en algún modelo de referencia de SMA existente. De esta forma el modelo de agente permite especificar comunidades de agentes, así un mismo agente podría estar representado por una sociedad de agentes que prestan servicios particulares y pueden especificarse en otro nivel de abstracción siguiendo la misma metodología. 4.2 Modelo de tareas A los agentes se les agregaron nuevos atributos, uno para especificar las propiedades de las tareas que requieren el uso de técnicas inteligentes, y otro para describir el macro-

167

procedimiento que se debe seguir para la ejecución de dicha tarea. Así, los agentes tienen activados su inteligencia en función de tipo de tareas que realizan (sean o no inteligentes). Además, de la misma forma como en MAS-CommonKADS, detalla los objetivos de cada tarea, su descomposición y los ingredientes necesarios para lograr esos objetivos.

Tarea Nombre Objetivo Descripción Precondición Estructura de Control Tiempo de ejecución Frecuencia Tiempo de descomposición Realiza en Entorno Nombre Restricciones Sistemas

Entrada / salida

Requiere

Ingrediente

Capacidades

Nombre Contenido

Habilidades Lenguaje RC Leng. Común

Figura 83: Modelo de tarea

4.3 Modelo de Inteligencia Describe todos los aspectos necesarios para incorporar la noción de inteligencia a un agente. Básicamente, está compuesto por un conjunto de elementos que están en correspondencia con el razonamiento humano. Especifica los conocimientos y métodos de razonamiento necesarios para que los agentes inteligentes cumplan sus objetivos, así como sus mecanismos de aprendizaje.

168

El modelo de inteligencia propuesto es presentado con sus atributos, las relaciones entre ellos, y su interrelación con los demás modelos de MASINA. Se propone un esquema que integra conceptos como experiencia (conocimiento adquirido por el agente durante su funcionamiento), conocimiento de dominio (involucra las variables que usa cada agente), conocimiento estratégico (información asociada al problema y derivada de las actividades hechas por otros agentes), mecanismo de aprendizaje (describe el proceso de acumulación de experiencia y el proceso para adaptar los mecanismos de razonamiento y actualizar el conocimiento estratégico), conocimiento de tareas (proporciona al agente información sobre las tareas y quien puede realizarlas), y mecanismo de razonamiento (utiliza el conocimiento adquirido para razonar e inferir/deducir soluciones. Por ejemplo, el uso de máquinas de aprendizaje). El componente inteligente se percibe como un módulo que puede ser insertado y extraído de la estructura de cada agente, agregándoles de esta forma capacidades inteligentes a los agentes que se deseen, sin que esto comprometa la arquitectura de los agentes.

Figura 84: Modelo de inteligencia

El modelo de inteligencia propuesto se activa a través del modelo de tareas, una tarea inteligente se desarrolla a través de la implementación de los mecanismos necesarios para dotar de inteligencia al agente que la realiza. En la consecución de una tarea que requiera inteligencia, puede ser necesaria la interacción de varios agentes, así el modelo de coordinación entra en juego en el modelo de inteligencia. 4.4 Modelo de coordinación

169

El modelo de coordinación permite al usuario establecer el conjunto de estrategias que las comunidades de agentes usarán para el logro de los objetivos grupales. Estas estrategias, por lo general, imitan actitudes de coordinación de grupos humanos, tales como los procesos de contratación y de subastas, entre otros, donde la interacción y el intercambio de información generan acciones individuales que sumadas permiten alcanzar metas específicas. En otras palabras, este modelo describe los mecanismos que permiten realizar una conversación entre un grupo de agentes: protocolos de negociación y resolución de conflictos, métodos de repartición de tareas y planificación, entre otros. Las interacciones presentes en los agentes involucrados en una conversación dada se representan, a nivel gráfico, a través de un diagrama de interacción UML, y a nivel escrito mediante una plantilla que describe los siguientes atributos relacionados con la conversación: Nombre (nombre de la conversación), Tipo de Conversación (predefinida, emergente, entre otras), Objetivo (objetivos que satisface la conversación), Agentes (agentes participantes en la conversación), Iniciador (agente que inicia la conversación), Servicio (servicios proporcionados), Actos de Habla (actos de habla involucrados en la conversación), Descripción (descripción de la conversación en lenguaje natural), Precondición (condiciones que deben darse en el emisor y receptor para que la conversación pueda darse con éxito) y Condición de Terminación (condiciones en el emisor y receptor tras el desarrollo de la conversación).

Figura 85: Plantilla de una Conversación en el Modelo de Coordinación

Ahora bien, el modelo de coordinación está basado en que se pueden establecer dos tipos de comunicación entre agentes: una directa basada en el pase de mensajes y uso de ontologías, y otra indirecta basada en estrategias de memoria compartida y de métodos estímulo-respuesta. Por eso se requiere de una descripción más detallada del modelo de coordinación en cada conversación. Los atributos de cada componente del modelo

170

permiten especificar el tipo de planificación, el tipo de comunicación con sus detalles, y finalmente, las estrategias de resolución de conflictos. En este modelo se especifica el esquema de coordinación (indica el tipo de coordinación usada: adaptativa o predefinida, objetivo a seguir, procedimiento usado en la coordinación adaptativa, y la planificación por defecto usada en la coordinación predefinida), la planificación (tipo y técnica de planificación usada), el mecanismo de comunicación directa (protocolos usados en la comunicación), o de comunicación indirecta (estrategia de actualización de estímulos y del umbral de respuesta en las comunicaciones), el metalenguaje (define el metalenguaje usado para la comunicación directa entre los agentes), y la ontología (vocabulario manejado).

Figura 86: Modelo de Coordinación

Este modelo estructura las interacciones en conversaciones, las cuales tienen asociado un acto del habla. Dichas conversaciones pueden ser descritas usando diagramas uml y la siguiente figura. Conversación : Nombre de la conversación Objetivo Objetivo de la conversación Agentes participantes Agentes que participan en la conversación Iniciador El agente que inicia la conversación Servicios Nombre de los servicios asociados Actos del habla Actos de habla que intervienen en la conversación Descripción Descripción de la conversación en lenguaje natural Precondición Condiciones que deben darse en los agentes para que la conversación pueda darse con

171

Condición de terminación

éxito. Condiciones entre los agentes tras el desarrollo de la conversación.

Figura 87: Descripción de la conversación de los agentes

4.5 Modelo de Comunicación MASINA plantea que el modelo de comunicación describa los actos de habla involucrados en las conversaciones desarrolladas en el modelo de coordinación. Así, él describe todas las comunicaciones directas a través del intercambio de información usando mecanismos del tipo pase de mensajes, y comunicaciones indirectas a través del depósito de información en objetos (uso de estrategias de tipo memoria compartida y métodos de estímulo-respuesta), que reflejan las interacciones entre los agentes. Los atributos del modelo de comunicación permiten especificar por cada acto de habla involucrado en una conversación, lo siguiente: nombre (Nombre del acto de habla), objetivo (objetivo del acto de habla), Tipo (asertivo, directivo, compromisivo, expresivo o declarativo), Agentes Participantes (agentes que participan en el acto de habla), Comunicación (un acto de habla puede ser realizado de manera directa o indirecta.), Emisor (emisor del mensaje), Receptor (receptor del mensaje), Conversación (nombre de la conversación donde participa), Servicio (nombre del servicio asociado), Datos Intercambiados (descripción de los datos intercambiados en el acto de habla), Descripción (descripción del acto de habla en lenguaje natural), Precondición (condiciones que deben darse en el emisor y receptor para que el acto de habla pueda darse con éxito.), Condición de Terminación (condiciones en el emisor y receptor tras el desarrollo del acto de habla), Per formativa (verbo que describe la intención del acto de habla, por ejemplo per formativas de discurso (ask-if, ask-all, ask-one, tell, deny, achieve, advertise, subscribe, entre otras), per formativas de intervención (error, sorry, ready, next, discard, rest, standby), o per formativas de red (register, forward, broadcast, recommend-one, recruit-all, entre otras)), Medio de Comunicación (vía de comunicación).

172

Figura 88: Plantilla del Modelo de comunicación

Una Variación del modelo de comunicación en el cual se permite realizar una mejor descripción de los actos de habla usados por los agentes en sus conversaciones.

Acto de habla: Nombre del acto de habla Objetivo del acto de habla Tipo de acto de habla: asertivo, directivo, compromisivo y declaraciones. Comunicación Un acto de habla puede ser realizado de manera directa o indirecta. Agentes Participantes Agentes que participan en el acto de habla. Emisor Emisor del mensaje. Receptor Receptor del mensaje. Conversación Nombre de la conversación donde participa. Servicio Nombre del servicio asociado. Datos Intercambios Descripción de los datos intercambiados en el acto de habla Descripción Descripción de intervención en lenguaje natural Precondición Condiciones que deben darse en el emisor y receptor para dicha intervención pueda darse con éxito. Condición de Terminación Condiciones en el emisor y receptor tras el desarrollo de la intervención. Per formativa Verbo que describe la intención del acto de Objetivo Tipo

173

Medio de Comunicación

habla. Vía de comunicación. Figura 89 Modelo de Comunicación]

174

4.6. APLICACION DE CASO DE ESTUDIO “SMA SUBASTAS” EN MASINA En este capítulo se desarrolla el SMA de Subastas Aplicado en la metodología MASINA. 4.6.1 Actores y Casos de uso. EL SMA subasta es muy elemental y está pensado para pensado para su posterior aplicación en un lenguaje de agentes, por lo tanto nuestro sistema cuenta con 4 casos de uso. Subastar Artículos: Se incluyen los artículos a subastar y se publican con el tipo de subasta, el agente subastador y el precio base Buscar Artículos: Se realiza una búsqueda del articulo a adquirir al encontrarlo se comprueba que el precio base no sobrepase el precio tope, para nuestro ejemplo todo articulo interesa a nuestros postores. Realizar puja: Se realiza la puja por el artículo seleccionado, según criterios de riesgo beneficio Anunciar puja mayor: Se publica la puja ganadora hasta el momento para que los postores realicen una puja mayor, si no se obtiene una puja mayor de cierto tiempo se declara como la puja final y ganadora. Actor Subastador

Postor

Descripción Casos de uso Se incluyen los artículos a Subastar Artículos subastar y se publican con el tipo de subasta, el agente subastador y el precio base Se realiza una búsqueda Buscar Artículos

175

Portor

Subastador

del articulo a adquirir al encontrarlo se comprueba que el precio base no sobrepase el precio tope, para nuestro ejemplo todo articulo interesa a nuestros postores. Se realiza la puja por el Realizar puja artículo seleccionado, según criterios de riesgo beneficio Se publica la puja Anunciar Ganador ganadora hasta el momento para que los postores realicen una puja mayor, si no se obtiene una puja mayor de cierto tiempo se declara como la puja final y ganadora.

Caso de uso “Subastar Artículo”

176

Descripción:

Actores: Precondición: Excepción: Se toma el articulo seleccionado para subastar se realiza un incremento de ganancia, y se publica en una pizarra para que los postores se enteren de ella. Subastador. Debe existir un artículo a subastar con su respectivo precio, así cono postores registrados. No sé a incluido artículo a subastar.

Caso de uso “Buscar Artículos” Descripción: Actores: Precondición: Excepción: Se identifica la presencia de un artículo y se anuncia el interés de participar en la subasta... Subastador. Debe existir un artículo a subastar con su respectivo precio, y este no sobrepase el dinero disponible. No sé han incluido artículos a subastar. O el precio sobrepasa el monto disponible.

177

Caso de uso “Realizar Puja” Descripción: Actores: Precondición: Excepción: Se realiza la puja por el artículo seleccionado, según criterios de riesgo beneficio. Postor. El precio del artículo aumentado para realizar la puja no sobrepasa el monto disponible. El precio es muy alto para competir.

Caso de uso “Anunciar Ganador”

178

Descripción:

Actores: Precondición: Excepción: Se publica la puja ganadora hasta el momento para que los postores realicen una puja mayor, si no se obtiene una puja mayor de cierto tiempo se declara como la puja final y ganadora. Subastador. Se recibió la puja de un postor, la cual es mayor a la puja o ganadora en el momento.

La etapa de análisis corresponde a la segunda fase de la metodología de desarrollo en la cual se desarrollan los modelos de agente, tareas, comunicación, coordinación e inteligencia, con el fin de obtener las especificaciones y requerimientos del SMA.

4.6.2 Modelo de agentes Con los actores identificados en la fase anterior se identifica los agentes que denotan al DMA de subasta. Cada actor en nuestro caso identifica un agente por lo cual tenemos dos agentes. • Agente postor • Agente Subastador Los modelos de agentes están concretamente establecidos y se definen a través de las tarjetas CRC (Clase / Responsabilidad / Colaboración)

179

AGENTE: SUBASTADOR Objetivo Planes Identificar qué Analizar tipo de subasta articulo se aplicara Ofrecer subasta

Decidir ganador

CLASE: SOFTWARE Conocimiento Colaborador Servicio el Que metodología es la más apropiada según el articulo Ofrecer artículo, Ofrecer subastas con tipo de subasta, precio inicial. Recibir pujas e Tiempo limiten Agente postor Terminar subasta informar la y decidir mayor hasta ganador. cumplir el tiempo limite

Tarjeta CRC para subastador AGENTE: Objetivo Identificar Subasta

Pujar

POSTOR Planes Reconocer subastas de interés que no sobrepasen el tope. Realizar puja por el articulo

Conocimiento Precio,

formulas para realizar pujas

Tarjeta CRC para postor

180

CLASE: SOFTWARE Colaborador Servicio Inscribirse e la subasta

Pujar

Agente Subastador Tipo Agente software. capacidades-razonamiento Experiencia Conocimiento de las metodologías de subastas, y cual es mejor para el artículo. Descripción Este agente l incluir el articulo decide qué tipo de metodología de subasta aplicara y la publicara con el precio base, y comenzara la subasta, la cual se adjudicara al mejor precio ofrecido. Agente Postor Tipo Agente software Experiencia El agente toma el precio base y puja según la fórmula de incremento, estipulada, para ganar el artículo. Descripción El agente posee formulas matemáticas para saber cuándo realizar la puja y por cuanto será esta. Tras haber asignado las tareas a los agentes, realizaremos una tabla agentes-tareas (tabla A.1) que nos permite comprobar algunos de los criterios de calidad enunciados en la sección 8.6. Por ejemplo, el criterio de cobertura podemos comprobarlo mirando si ninguna fila (tarea) está vacía. También puede realizarse marcando las asignaciones en el árbol del modelo de tareas. Subastador Postor

Pública subasta X

Realiza puja

Decide ganador X

X

Identificación y descripción de objetivos Se pueden identificar objetivos a partir de la asignación de tareas a cada agente (tarjetas CRC), a partir de los objetivos que surgen cuando se da una condición en su entorno (objetivos reactivos), en el estado del agente o para asistir a otros agentes. Para describir estos objetivos utilizamos la plantilla definida en el modelo de agente.

181

Objetivo Publicar subasta Tipo Objetivo persistente. parámetros-entrada Ingreso de tipo de artículo, precio de base parámetros-salida Subasta, con tipo de subasta, numero de subastador, precio... condición-activación Al nacer el agente y recibir el articulo. condición-finalización al terminar subasta y vender el artículo. Descripción El agente decide que subasta es la más adecuada y publica el agente Objetivo Realizar puja Tipo Objetivo persistente Parámetros de entrada Registro de subasta, con tipo de subasta, precio base Parámetros de salida Puja del artículo, con precio inferior al tope Condición de activación Al nacer el agente Condición de finalización Ganar subasta, o sobrepasar el precio tope Descripción El agente postor realiza la punas necesarias hasta que se decrete un ganador o la puja siguiente sobrepase el precio tope propio. 4.6.3 Modelo de Inteligencia Los agentes al ser tan sencillos, no son susceptibles a la inteligencia, pues estarán guiados por simples formulas matemáticas, para la toma de decisiones, en cuanto a precio a subastar, precio de oferta de puja y demás. Experiencia

182

Representación Tipo Grado de Confiabilidad Esquema de procesamiento Reglas matemáticas De acuerdo al acaso Al utilizar un operador randomico es impreciso. No cambia con el tiempo

Mecanismo de Aprendizaje “Vetado para este ejemplo pues no lo utiliza.” Mecanismo de Razonamiento “Racionamiento estrictamente matemático” Nota: Cabe anotar que en nuestro ejemplo se pretende demostrar la fiabilidad de la metodología más no la complejidad del ejemplo en sí. 4.6.4 Modelo de coordinación Con el modelo de coordinación se describe el esquema de comunicación del SMA; es decir, la conversación, los protocolos y los lenguajes asociados. Identificación de las conversaciones Ya hemos identificado algunas de las conversaciones mantenidas con la técnica de tarjetas CRC. Sin embargo, para ilustrar la técnica de casos de uso internos, realizaremos los mismos casos con esta técnica Descripción de las conversaciones La descripción de las conversaciones se realiza desde dos puntos de vista: • Externo: analizamos cuál es el objetivo de la conversación, su pre y pos condiciones, y qué participantes hay. • Estructural: qué fases tiene la conversación y qué intervenciones se dan en cada fase. En este apartado realizamos la descripción “externa” de la conversación, mientras que en el siguiente realizamos la descripción estructural. La descripción “externa” de las

183

conversaciones puede ser gráfica, empleamos los diagramas de caso de uso internos, y textual, con la plantilla del constituyente Conversación.

Subasto artículo

Subastador

Postor Pujo

Gana puja

Figura 90: Conversación en subasta

Conversación Subasto articulo Tipo Entrega-de-información. Objetivo Informar la apertura de subasta Agentes Subastador, postor (Grupo). Iniciador Subastador Servicio Articulo a subastar Descripción El agente Subastador anuncia a todos los postores el inicio de un artículo en la subastas Precondición Articulo definido en metodología Pos condición Información ofrecida (de éxito o error). condición-terminación

184

Inicio de puja, o finalización de tiempo. tiempo-ejecución El tiempo de ejecución no debe superar 1 minutos, que es el tiempo máximo recomendado para el uso de recursos. Conversación pujo Tipo Entrega-de-información. Objetivo Realizar una puja por el artículo. Agentes Postor, Subastador Iniciador Postor Servicio Puja (articulo, cantidad, postor) Descripción El agente postor anuncia al agente subastador su oferta por el articulo. Precondición Conocimiento de inicio de subasta Pos condición Información de puja mayor condición-terminación Envió del mensaje. tiempo-ejecución Lance inmediato. Conversación gana puja Tipo Entrega-de-información. Objetivo Informar mayor puja recibida (artículo, puja, postor) Agentes Subastador, postor (Grupo). Iniciador Subastador Servicio Articulo a subastar Descripción El agente Subastador anuncia a todos los postores la puja por el articulo en la subastas Precondición Recepción de puja Pos condición 185

Finalización de subasta condición-terminación Finalización de timer. tiempo-ejecución El tiempo de ejecución no debe superar 1 minutos, que es el tiempo máximo recomendado Para el uso de recursos. 4.6.4.1 Canales básicos de comunicación Una vez desarrolladas todas las conversaciones, se puede determinar qué interacciones (mensajes) son válidas (permitidas) entre los agentes, y representar esta información en un diagrama resumen, como el que se muestra en la Figura.

Ask (art, sub, pre, tip) Subastador

Postor

Tell(art,pos,pre,) Figura 91: Canales de comunicación

Determinación de grupos de agentes Durante la identificación de las conversaciones, se detecta un grupo, denominado postores que describimos a continuación, con la plantilla del modelo de agente: Grupo postores. Tipo Público, dinámico. Componentes Postor. Descripción Grupo formado por agentes que ofrecen pujas. Este grupo es público y realiza las pujas en la subasta Servicio-ofrecido Puja.

186

4.6.5 Modelo de tareas El modelo de tareas permite mostrar la descomposición funcional del sistema, y parte de las áreas funcionales (constituyente función) de la organización en que se va a introducir el sistema inteligente. En nuestro caso, el sistema no es muy inteligente.

Escoger tipo de subasta

Inglesa (Predeterminada)

Holandesa

Sobre cerrado

Figura 92: Descomposición de tarea Escoger tipo de subasta

Tarea Escoger tipo de subasta Objetivo Decidir qué tipo de metodología le conviene al artículo. Descripción En esta tarea se decide, que tipo de metodología aplicar a la subasta del articulo. Entrada Registración de un tipo para subastar Salida Tipo de subasta escogida Precondición Solicitud recibida. Tipo-de-descomposición Temporal. 4.6.6 Modelo de comunicación El desarrollo del modelo de comunicación en un sistema multi-agente puede subdividirse en el conocimiento de la aplicación, el propio agente, el resto de agentes y el entorno.

187

Tomemos, por ejemplo, el agente Subastador. Como el agente Subastador no tiene capacidades reactivas, no seleccionaríamos una arquitectura reactiva ni híbrida, sino una deliberativa. De los módulos identificados en el modelo de diseño, el agente Subastador no tiene interacción con el usuario ni con el exterior. El módulo de comunicación con los agentes está integrado en la plataforma, y dado que Subastador no emplea ningún protocolo especial, no es necesario definirlo, ya que los mensajes intercambiados han sido ya expresados en FIFA. Acto de habla: Nombre del acto de habla Objetivo del acto de habla Tipo de acto de habla: asertivo, directivo, compromisivo y declaraciones. Comunicación Un acto de habla puede ser realizado de manera directa o indirecta. Agentes Participantes Agentes que participan en el acto de habla. Emisor Emisor del mensaje. Receptor Receptor del mensaje. Conversación Nombre de la conversación donde participa. Servicio Nombre del servicio asociado. Datos Intercambios Descripción de los datos intercambiados en el acto de habla Descripción Descripción de intervención en lenguaje natural Precondición Condiciones que deben darse en el emisor y receptor para dicha intervención pueda darse con éxito. Condición de Terminación Condiciones en el emisor y receptor tras el desarrollo de la intervención. Per formativa Verbo que describe la intención del acto de habla. Medio de Comunicación Vía de comunicación. Objetivo Tipo

Objetivo Tipo Comunicación Agentes Participantes Emisor Receptor Conversación Servicio Datos Intercambios

Acto de habla: Nombre del acto de habla Objetivo del acto de habla Tipo de acto de habla: asertivo, directivo, compromisivo y declaraciones. Un acto de habla puede ser realizado de manera directa o indirecta. Agentes que participan en el acto de habla. Emisor del mensaje. Receptor del mensaje. Nombre de la conversación donde participa. Nombre del servicio asociado. Descripción de los datos intercambiados en el acto de habla

188

Descripción Precondición Condición de Terminación Per formativa Medio de Comunicación

Descripción de intervención en lenguaje natural Condiciones que deben darse en el emisor y receptor para dicha intervención pueda darse con éxito. Condiciones en el emisor y receptor tras el desarrollo de la intervención. Verbo que describe la intención del acto de habla. Vía de comunicación.

Acto de habla: Nombre del acto de habla Objetivo del acto de habla Tipo de acto de habla: asertivo, directivo, compromisivo y declaraciones. Comunicación Un acto de habla puede ser realizado de manera directa o indirecta. Agentes Participantes Agentes que participan en el acto de habla. Emisor Emisor del mensaje. Receptor Receptor del mensaje. Conversación Nombre de la conversación donde participa. Servicio Nombre del servicio asociado. Datos Intercambios Descripción de los datos intercambiados en el acto de habla Descripción Descripción de intervención en lenguaje natural Precondición Condiciones que deben darse en el emisor y receptor para dicha intervención pueda darse con éxito. Condición de Terminación Condiciones en el emisor y receptor tras el desarrollo de la intervención. Per formativa Verbo que describe la intención del acto de habla. Medio de Comunicación Vía de comunicación. Objetivo Tipo

189

CAPITULO V 5 The Zeus Agent Building Toolkit [25] [26] [27] [28] [29] ZEUS es una herramienta para construir aplicaciones multi-agente colaborativas. Que provee un entorno integrado para el desarrollo rápido de sistemas. ZEUS define una metodología de diseño de sistemas multi-agente y lo soporta mediante un entorno visual para capturar las especificaciones de los agentes. Estas especificaciones son luego utilizadas para generar el código fuente en Java. El objetivo del proyecto ZEUS es facilitar el desarrollo rápido de nuevas aplicaciones multi-agente mediante la abstracción de los principios y componentes más comunes a una herramienta. La idea es proveer una herramienta de propósito general y personalizable, que permita la creación de agentes colaborativos y que pueda ser usada por ingenieros de software con poca experiencia en tecnología de agentes para crear sistemas multi-agente. La herramienta ZEUS consiste de un conjunto de componentes, escritas en el lenguaje de programación Java, que puede ser categorizada en tres grupos funcionales o librerías: una librería de componentes de agentes, una herramienta de construcción de agentes y un conjunto de agentes utilitarios entre los cuales podemos encontrar servidores de nombres, facilitadores y agentes visualizadores. A continuación se describe cada una de ellas. Librería de componentes de agentes: es una colección de clases que forman los bloques de construcción de los agentes individuales. El contenido de esta librería muestra los puntos identificados antes: entre ellos la comunicación, ontologías, coordinación, etc. Para la comunicación, la librería de componentes de agentes provee un lenguaje de comunicación entre agentes basado en actos del habla y en performatives, un sistema de pasaje de mensajes asincrónico basado en sockets, un editor para describir ontologías de dominio específico y un lenguaje de representación de conocimiento basado en frames para representar los conceptos del dominio. Para el razonamiento y la coordinación de múltiples agentes, la librería de componentes de agentes provee: - Un planificador de propósito general y un sistema de planificación preparado para dominios típicos de aplicaciones orientadas a tareas, y un mecanismo cooperativo de resolución de problemas de estas aplicaciones. 190

- Un motor de coordinación que controla el comportamiento social de un agente. Herramienta de construcción de agentes: esta herramienta está diseñada para proveer un desarrollo rápido de agentes a alto nivel, ocultando la complejidad de la librería de componentes de agentes. Está conformada por un conjunto de editores diseñados para permitir a los usuarios interactivamente crear agentes mediante una especificación visual de sus atributos. El conjunto actual de editores incluye: - Un editor de Ontologías para definir los ítems de la ontología en un dominio. - Un editor de hechos/variables para describir instancias especificas de hechos y variables, utilizando los templetes creados usando el editor de ontologías. - Un editor de definiciones de agentes para describir los agentes lógicamente. Esto involucra la especificación de las tareas de cada agente, sus recursos iníciales y las dimensiones de su plan. - Un editor de descripción de tareas para especificar los atributos de las tareas y para resúmenes gráficos de las tareas. - Un editor de organización para definir las relaciones organizacionales entre los agentes, y las creencias de los agentes acerca de las habilidades de otros agentes. - Un editor de coordinación para seleccionar el conjunto de protocolos de coordinación con los cuales cada agente estará equipado. Agentes utilitarios ZEUS: consiste de un servidor de nombres, un facilitador para el descubrimiento de información, y un agente para visualizar o realizar un debugging de sociedades de agentes. Una sociedad de agentes en ZEUS puede contener cualquier número de agentes utilitarios, con al menos un servidor de nombres. Todos los agentes utilitarios son construidos utilizando las componentes básicas de la librería de componentes de agentes, y son en realidad simplificaciones del agente genérico ZEUS. El proceso de la realización del agente sigue la etapa del diseño de la metodología del desarrollo del agente de ZEUS. Durante este capítulo será descrito metódicamente como serie de etapas del desarrollo, que consiste en las actividades individuales que ponen aspectos en ejecución particulares de un agente.

191

Un requisito previo para usar este documento es un diseño para el uso que es observado. Además el revelador debe saber cuándo y cómo realizar las actividades necesarias. Pero antes de que consideremos cómo poner un agente en ejecución, necesitamos considerar la base conceptual de los agentes creados con la caja de herramientas de ZEUS. 5.1 El agente conceptual de Zeus En el del más alto nivel de la abstracción, el acercamiento del diseño del agente de ZEUS requiere a reveladores ver un agente como entidad cinco-acodada, según lo ilustrado en el cuadro de abajo.

Capa de Comunicación Mensajes de/hacia otros agentes

Capa de Coordinación Capa de Organización Capa de Definición Capa de Interfaz

Sensores Figura 93:

Efectores La estructura conceptual de un agente de ZEUS

Del fondo para arriba, estas capas son: •

una capa del interfaz, que permite al agente ser ligada a los programas externos que proveen de él los recursos y ponen sus capacidades en ejecución

•

una capa de la definición, donde el agente se ve como entidad autónoma del razonamiento

•

una capa de la organización, donde el agente se ve en términos de sus relaciones con otros agentes 192

•

una capa de la coordinación, donde el agente se ve como entidad social que obre recíprocamente según sus protocolos y estrategias sabidos

•

una capa de la comunicación, que pone los protocolos y los mecanismos en ejecución que apoyan la comunicación del inter-agente

La capa del interfaz recibe la entrada vía sus sensores y puede cambiar el mundo exterior con sus efectores. Por ejemplo, un sensor podía recibir instrucciones de un GUI o de un acto modificando una base de datos, así proporcionando las realizaciones físicas de los recursos y de las habilidades de los agentes. Pues los sensores y los efectores son externos al agente, la configuración de la capa del interfaz consiste en el especificar de interfaces entre ellos y el agente.

En la capa de la definición el agente se ve como una entidad racional autónoma, en términos de sus capacidades del razonamiento, metas, recursos, habilidades, creencia y preferencias. Como esta capa es observada físicamente por las clases de la biblioteca componente del agente de ZEUS, (descrita en el manual técnico), esta etapa de la metodología implica la configuración de estos componentes.

En la capa de la organización el agente se ve en términos de sus relaciones con otros agentes. Esto introduce el concepto de una agencia - grupo de agentes relacionados. Las agencias pueden ser verdaderas, en que son relacionadas en virtud de cualidad común, tal como ser parte de la misma compañía. O las agencias pueden ser virtuales, en que sus componentes comparten un acuerdo de la cooperación. Así este etapa metodología implicar configurar agente en términos de agencia él pertenecer, qué papel él jugar con agencia, qué otro agente él ser enterado, y qué capacidad él saber, otro poseer.

En la capa de la coordinación el agente se considera ser una entidad social que, por lo tanto esta etapa implica el configurar de ella para las formas deseadas de comportamiento social. Esto es alcanzado equipándola de los protocolos y de las estrategias apropiadas de la negociación. La capa de la comunicación proporciona un protocolo y una lengua del transporte permitiendo a agentes enviar mensajes el uno al otro. Para la compatibilidad esta capa debe ser igual en cada agente, y tan allí ninguna necesidad para que los reveladores configuren esta capa.

193

5.2

Metodología Principal de Zeus

La metodología principal de Zeus consiste en explicar el proceso por el cual un agente conceptual es configurado en miembro funcional de una sociedad del multi-agente. Este proceso de la configuración será logrado usando la herramienta del generador del agente de ZEUS, que generará en última instancia el código de fuente del agente. La funcionalidad application-specific el instrumento de la necesidad del revelador solamente de los agentes, y la liga a los agentes que usan los interfaces proporcionados. La metodología es el juego de los métodos y los principios que impulsan el agente proceso de desarrollo. Las metodologías cuidan ser preceptivo en la naturaleza, no sólo facilitar el pensar y el desempeño que necesita llevar a cabo el proceso sino también recomendando los métodos y las técnica que deben ser empleadas para conseguir el proceso. Al desarrollar el juego de herramientas de ZEUS de creó un juego de herramientas que puede ser aplicadas a una gran variedad de problemas, y no solo sobre una aplicación en especial. En común con la mayoría de las otras metodologías de desarrollo estructuradas, el enfoque de ZEUS consta del análisis, el diseño y las actividades de Realización, además de añadir instalaciones de soporte de tiempo de ejecución que permiten que al desarrollador depuren y analicen sus puestas en funcionamiento. La metodología de ZEUS es resumida abajo:

Figura 94: Desarrollo de la metodología Zeus

194

5.3 – Análisis de Dominio El propósito del escenario de análisis inicial es trabajar de modelo y comprender el problema de aplicación. La metodología de ZEUS no prescribe ningún enfoque especial para el análisis del problema, dejando a desarrolladores libres para escoger sus propios enfoques favoritos, de la misma manera que cajas de uso o distancias conceptuales explícitamente; el enfoque recomendado es este documento es modelar en papel. Cuando la técnica de análisis como el modelado de papel son independientes de los medios que los pondrán en funcionamiento en última instancia, los modelos a imitar hablados de en este documento deben ser realizables con cualquier agente desarrollar el sistema. Zeus no ofrece soporte de software actualmente en este escenario 5.4 – Agente Diseño Antes de la época en que el proceso de diseño comienza el desarrollador debe saber qué agentes beben estar presente, y qué responsabilidades cumplirán. Por lo tanto este escenario involucra la traducción de las responsabilidades de papel respecto a los problemas de agente – nivel que representan, y obtener las soluciones apropiadas. Donde el proceso de análisis suponía comprender los requisitos del problema, el proceso de diseño involucra la pericia, sabiendo cuándo y cómo rehusar y adaptar las soluciones demostradas existentes. Cuando estos conocimientos son difíciles de acumular, cada uno de los modelos a imitar viene con un estudio de casos asociado que describe el razonamiento detrás de un diseño para una solicitud de muestra. No hay soporte de software de ZEUS para ello. 5.5 – Comprensión de Agente El objetivo de este proceso es darse cuenta de las puestas en práctica de trabajo de los agentes, diseños conceptuales creados durante la etapa previa. El agente proceso de comprensión consta de algunas etapas, que son acoplado a los niveles del carácter abstracto que existen dentro de un agente Zeus. Este escenario es donde Zeus empieza a ofrecer el soporte de software, suministrando una herramienta, generador de Agente a través de la que los diseños pueden ser ingresados, y luego se puede generar el código fuente de Java para los agentes. 5.6 – Soporte de Tiempo de Ejecución El enfoque de ZEUS no termina con la creación de los Agentes; también hay una suite de herramientas de soporte de tiempo de ejecución que están disponibles a través del 195

Agente Visualizador. Esto refleja el hecho de que el proceso de desarrollo es improbable haber terminado con la puesta en funcionamiento de los Agentes, cuando todavía tienen que ser evaluados, depurado y optimizado. El enfoque de este documento es el primer escenario de análisis problemático, usando un enfoque llamado moldeamiento en papel. Zeus genera las clases y las conexiones necesarias solo le queda al programador crear el entorno visual y el manejo de la aplicación.

A continuación se presenta un estudio más a fondo de La plataforma Zeus. La aplicación ha sido desarrollada junto con el Ing. Simon Thompson miembro de Intelligent Systems Research Group, BT Labs.

196

5.7 Descripción del proceso de la realización del agente El objetivo de este proceso es realiza puestas en práctica de trabajo del agente de los diseños conceptuales creados durante la etapa anterior. El proceso de la realización del agente consiste en varias etapas, (algunas de las cuales se han derivado de los niveles de la abstracción que existen dentro de un agente de ZEUS. Las etapas y la orden en las cuales deben ser procuradas son: 5.7.1 Etapa 1: Creación de Ontología Antes de poner cualesquiera agentes en ejecución el desarrollador debe definir la ontología del uso: el conocimiento declarativo que representa los conceptos significativos dentro del dominio del uso. La herramienta usada para incorporar esta información es el redactor de ZEUS Ontology. O alternativamente, una ontología existente puede ser importada. 5.7.2 Etapa 2: Creación del agente Durante esta etapa el agente genérico de ZEUS se configura para satisfacer sus responsabilidades application-specific, volviendo en un agente de la tarea. Este proceso implica el redactor del agente de ZEUS para terminar hasta cuatro sub-stages (dependiendo de la naturaleza del agente); éstos son: •

Definición del agente – donde se especifican sus tareas, recursos iníciales y capacidades del planeamiento

•

Descripción de la tarea – donde la aplicabilidad y las cualidades de las actividades del agente se especifican

•

Organización del agente – donde el contexto social de cada agente se especifica

•

Coordinación del agente – donde cada agente se equipa de las capacidades sociales para la interacción

5.7.3 Etapa 3: Configuración para uso general del agente Las cualidades de los agentes para uso general que proporcionan la infraestructura de la ayuda para la sociedad del agente. Esta información se incorpora a través del redactor de la generación del código en la preparación para la creación de los agentes para uso general. 5.7.4 Etapa 4: Configuración del agente de la tarea

197

Esta etapa permite a los parámetros run time de los agentes de la tarea ser especificada. Esto implica el proveer de la información tal como los ordenadores centrales que los agentes funcionarán encendido, y los recursos y los programas externos a los cuales los agentes serán ligados. 5.7.5 Etapa 5: Puesta en práctica del agente El generador de código se puede invocar en esta etapa y código fuente del agente generado automáticamente. Esto deja el revelador con el trabajo de proporcionar las puestas en práctica application-specific de las tareas, de los recursos externos, de los programas (tales como interfaces utilizador del agente) y de las estrategias de la interacción. Cada una de estas etapas es el tema de las secciones restantes de este Capítulo. Cada sección contiene las varias actividades que describen cómo configurar aspectos del agente genérico de ZEUS. Por ejemplo, la sección de la coordinación describe cómo solucionar el problema del acoplamiento a un diálogo con otro agente (la solución que es equipa el agente de un protocolo apropiado de la coordinación). Este las entradas del problema la solución se refieren en los estudios de caso que acompañan el papel que modela la guía. Todas las etapas del proceso de la realización se alcanzan a través de la herramienta del generador del agente de ZEUS. Para encender el generador de Zeus tecleamos el comando siguiente: Java Zeus.generator.AgentGenerator

Figura 95:

presentación de Zeus agent Generator 1.2.2

198

La ventana del generador sirve como el punto que lanza para las varias ventanas del edificio del agente, él consiste en cuatro paneles que permitan el acceso a sus funciones, a saber: •

Opciones del proyecto - este panel contiene un toolbar de las opciones de la gerencia, permitiendo a proyectos enteros ser cargado, ser guardado y ser despejado. Los otros botones lanzan las herramientas del espectador de la sociedad y del generador de código. Debajo de está el nombre de fichero del proyecto actualmente en memoria.

•

Opciones de Ontología - este panel proporciona el acceso a la herramienta del redactor de Ontología, permitiendo a ontologías ser cargado, ser guardado, ser despejado y ser corregido. El nombre de la ontología en memoria se demuestra actualmente debajo del toolbar.

•

Opciones del agente - este panel consiste en un toolbar y una tabla que enumere todos los agentes en el proyecto actualmente cargado.

•

Opciones de la tarea - este panel consiste en un toolbar y una tabla que enumere todas las tareas en el proyecto actualmente cargado.

Las secciones subsecuentes describen cómo las instalaciones de la herramienta del generador apoyan las etapas de la metodología de la creación del agente de ZEUS.

5.8 La etapa de la creación de la Ontología

Una ontología es un sistema de conocimiento declarativo que representa cada concepto significativo dentro de un dominio particular del uso. La significación de un concepto se determina fácilmente, si la interacción significativa no puede ocurrir entre los agentes sin ambas partes que están enteradas de ella, después el concepto es significativo y debe ser modelado. Observar que para la conveniencia utilizamos el término “hecho” a través de ZEUS para describir un concepto individual del dominio. Antes de procurar esta etapa se debe haber identificado ya lo siguiente:  los conceptos dominantes dentro del dominio del problema  las cualidades significativas de cada concepto  los tipos de cada cualidad 

cualquier apremios en las cualidades

199

A continuación se describe cómo incorporar esta información en el redactor de ZEUS Ontología. Es lanzada de la herramienta del generador del agente de ZEUS, que exhibe el panel siguiente:

Figura 96: Un screenshot del panel de las opciones de Ontología de la herramienta del generador

Figura 97:

Un Screenshot de uno de los paneles del editor de Ontología.

Para crear una nueva ontología para el caso de estudio seleccionamos una nueva entrada en el editor e incluimos los parámetros que se crean pertinentes, teniendo en cuenta que la ontología se basara en el lenguaje que hablaran los agentes. 3 la etapa de la creación del agente Durante la etapa de la creación del agente el agente genérico de ZEUS se configura para satisfacer sus responsabilidades application-specific. Así para el momento en que se procure esta etapa las decisiones siguientes del diseño deben haber sido tomadas ya: •

¿Cuál es el granularidad del uso?

•

¿Qué agentes existen?

•

¿Qué actividades cada agente realizará?

•

¿Cómo cada agente obrará recíprocamente con otros agentes? 200

•

¿Qué estrategias y maestría cada agente sabe?

En ZEUS la duración de todas las actividades del agente se expresa en el tiempo-grano más bien que los segundos o los minutos, tomando la opción de la longitud del tiempograno una decisión significativa. El factor dominante es cómo ambiente de los agentes el cambia rápidamente. Esto es porque las nuevas actividades se empiezan el principio de un tiempo-grano, significado allí será retrasa entre un acontecimiento que ocurre y que reacciona del agente.

Así pues, por ejemplo, si el tiempo-grano es 1 minuto en longitud, y se detecta un acontecimiento 5 segundos después de que el tiempo-grano comienza, el agente no reaccionará por lo menos otros 55 segundos. Hay otra implicación, si un agente puede realizar una actividad por tiempo-grano, y las tomas de esta actividad en segundos a terminar, él del promedio 1 son ociosas por 59 segundos en cada minuto. El valor prefijado para los usos de ZEUS es 30 segundos, que en nuestra experiencia es suficientemente largo permitir que varios agentes funcionen en la misma máquina y todavía respondan confortablemente. 5.9 Creación de Agentes Las opciones de la creación del agente son accesibles a través “del panel de las opciones del agente” de la herramienta del generador del agente de ZEUS.

Figura 98: Un screenshot del panel de las opciones del agente de la herramienta del generador. La tabla sabida del agente enumera todos los agentes que se han definido en el proyecto actual.

201

Para cada agente se selecciona las teresas que este tendrá que realizar Esta actividad implica el nombrar (pero no todavía realmente el definir) de las tareas application-specific que este agente es capaz de la ejecución. Este proceso por el cual esta información es incorporada.

Figura 99:

Screenshot del panel de la identificación de la tarea.

5.10 Asignación de recurso inicial del agente

Esta actividad implica el enumerar de los recursos que el agente poseerá cuando se inicializa. Esta actividad ocurre a través del panel de los “recursos iníciales” donde la tabla del alto enumera los hechos poseídos, y la tabla más baja permite a las cualidades de los hechos ser corregida.

202

Figura 100: El panel inicial de los recursos del agente, y cómo utilizarlo

Naturalmente, antes de que un recurso se pueda asignar a un agente debe primero haber sido definido como parte del Ontología del uso, (esto se debe haber hecho durante la etapa anterior). En ZEUS, una tarea primitiva es una representación de una cierta actividad (nodivisible) atómica del agente en el redactor primitivo de la tarea (PTE) representa cada tarea como flujo del recurso, adonde los hechos fluyen en una tarea, con lo cual se transforman en nuevos hechos.

Figura 101 Un Screenshot del redactor primitivo de la tarea con las actividades principales de la etapa de la definición de la tarea demostrada]

Usando el PTE, los aspectos siguientes de una tarea primitiva pueden ser configurados: •

Condiciones previas - los recursos necesitaron para la ejecución de la tarea

•

Efectos - los recursos que serán producidos sobre la ejecución de la tarea

•

Coste - una expresión dada el coste de ejecutar la tarea

•

Duración - una expresión que da el tiempo tomado para ejecutar la tarea

•

El ordenar de la condición previa - la secuencia en la cual las condiciones previas deben ser alcanzadas

203

•

Apremios - restricciones de la aplicabilidad en ejecutar la tarea

Como algunos de estos aspectos es dependiente en uno a, su definición se procura lo más mejor posible en la orden enumerada arriba. Los modificantes aplicables a las condiciones previas se describen en la tabla Modificante

Explicación

Ejemplos del uso

No

La tarea se realizó solamente si el hecho no está presente adentro localmente

Para los factores inhibitorios, e.g. un hecho producido que inhibirá la producción hasta que se quita

Se lee El hecho no se consume, es decir sobrevive ejecución de la solamente tarea, pero mientras tanto no se asigna exclusivamente a la tarea Debe estar en El hecho debe estar en propia base de datos posesión local del agente, previene el agente que la obtiene de otro local

Para los artículos de la información, e.g. un expediente del empleado

Para los artículos que no deben ser comprados adentro, e.g. impulsión a agente trabajar si un coche está presente, pero no comprar uno El hecho será asignado a la tarea Para las entidades Es el uso para la duración de su ejecución, persistentes capaces de posterior pero no consumido tarea de la porción una a la substituido vez, e.g. empleados o vehículos Figura 102: Los modificantes de la condición previa] Por el defecto que no se selecciona ningunos de estos modificantes, él es asumido que todas las condiciones previas son reservadas para el uso exclusivo de la tarea, con lo cual serán consumidas. 5.11 Interacciones del agente Pero antes de procurar esta etapa el revelador debe tener una idea clara de cómo los agentes obrarán recíprocamente en el curso de satisfacer sus papeles. Todas las interacciones del agente de ZEUS son variaciones en el contrato-red multi-redondo, [x], que implica unos o más iniciadores que publiquen una llamada para las ofertas (el CFP), y unos o más respondedores que contestan. Si eres inseguro si es un papel particular un iniciador o un respondedor consulta el modelo apropiado del papel para la dirección. 204

Figura 103: Un diagrama de la estado-transición de una negociación típica de la red del contrato]

Este cuadro también ilustra la relación entre los protocolos y las estrategias de la interacción. En cada estado el agente puede necesitar tomar decisiones sobre cómo comportarse o responder a sus circunstancias actuales, estas decisiones son decididas por estrategias. Esto se ilustra lo más mejor posible con un ejemplo. Considerar un agente que necesite obtener un recurso, porque no puede producirlo localmente debe entrar en contacto con otro agente para proveerlo. Por lo tanto el iniciador comienza en el estado de la inicialización analizando sus requisitos y determinándose cuánto está dispuesto a pagar el recurso y cómo lo necesita rápidamente. Usando la maestría codificada en su estrategia de ofrecimiento formula un mensaje del CFP que contiene sus requisitos, ésta es entonces difusión a los partidos todo potencialmente interesados y el agente se mueve en el estado de la negociación para aguardar respuestas. La llegada de un mensaje del CFP hace a respondedor moverse en su estado de la inicialización. Si el respondedor decide contestar (está bajo ninguna obligación de hacer así que) se moverá en su estado de la negociación. El respondedor ahora utilizará su estrategia de la evaluación para formular una contrapropuesta a la oferta inicial, que entonces se envía de nuevo al iniciador bajo la forma de mensaje del proponer. El respondedor entonces se mueve en un estado de espera por un período de la hora finito de aguardar una respuesta, no se asume ninguna respuesta sin embargo, y si no se recibe 205

nada para el final de su período del descanso el agente terminará su parte de la conversación. Cuando el iniciador recibe una propuesta es analizado usando su propia estrategia de evaluación, esto puede tener tres resultados: 1. Si la propuesta es aceptable la conversación termina. El iniciador no se ha cometido sin embargo, y enviará un mensaje en algún momento en el futuro tampoco aceptando o rechazando la propuesta. 2. Si la propuesta no es aceptable y el iniciador decide que no hay un pequeño punto para negociar más lejos puede terminar la conversación inmediatamente. 3. Si la propuesta no es aceptable el iniciador puede enviar un nuevo mensaje de CFP modificado al encuestado en cuestión, en un estado de espera hasta que una respuesta llega o su período del tiempo muerto pasa. En la caja última, el encuestado es despertado por la llegada de un nuevo mensaje de CFP, que es analizado usando su estrategia de evaluación de la junta local. Esto causará que el encuestado haga uno de lo siguiente: •

No decidirá no licitar otra vez y terminará su equipo de la conversación.

•

Formulará un nuevo mensaje de propuesta, lo devolverá al iniciador, y se mudará a un estado de espera hasta que una respuesta llegue o time out.

Habiendo visto cómo interactúan los Agentes, está claro que los factores de tecla son la estrategia de protocolo y lo interacción. Por lo tanto el propósito del agente escenario de coordinación es especificar qué aspectos del protocolo de red de contrato will estar asequible al agente tanto, y escoger la estrategia que determinará el comportamiento del agente durante la interacción. Esto es reflejado en las tres actividades que pueden ser llevadas a cabo durante esta etapa.

5.12 Uso general de la configuración del agente

Ahora los agentes tarea-específicos habrán sido definidos, saliendo de nosotros para considerar los agentes que proporcionarán la infraestructura de la ayuda: éstos se conocen como los agentes para uso general. Esta etapa requiere que las decisiones siguientes del diseño sean tomadas ya: •

cómo el servicio del name resolution será observado

•

si habrá un Facilitador, y si es así cuáles son sus cualidades

206

•

si habrá un Visualizador.

•

si la actividad del agente será almacenada persistente

El número y la naturaleza de los agentes para uso general necesitados son dependientes en el uso. El papel que modela la guía y sus estudios de caso proporcionan ejemplos de cómo configurar agentes para uso general apropiadamente. Cada tipo de agente para uso general se puede configurar a través del cristal del “agente para uso general” de la ventana del generador de código. 5.13 Cómo crear un agente con un GUI del espectador del agente El GUI del espectador del agente es una herramienta especializada que exhibe la información detallada sobre los componentes internos del agente. Ésta es independiente de cualquier otro uso anticipado y proporciona los mejores medios para entender cómo los trabajos del agente, así como ser una ayuda que elimina errores excelente. Si un agente de la tarea está creado con este GUI se va a la discreción del revelador.

El paso siguiente es decidir a donde el código de fuente será escrito. Pues el generador sobre escribirá archivos previamente generados en la misma localización esto se debe elegir cuidadosamente. La acción siguiente es especificar qué sistema operativo serán lanzados los agentes. Aunque los agentes se ponen en ejecución totalmente en Java, y funcionarán así en cualquier plataforma con una máquina virtual de Java, hay diferencias sutiles entre las plataformas de Windows y del Unix cuando viene a crear las escrituras del comando que comienzan los agentes. El comando que lanza cada agente se demuestra en la “línea de comando” campo de cada entrada del agente en el cuadro 6.1. Éstos son los comandos que serán escritos en las escrituras durante el proceso de generación. Del cuadro 6.1 debe ser evidente que los comandos de comenzar agentes son bastante simples y fáciles corregir de todos modos, así que la producción de escrituras es realmente justa proporcionada para ayudar usuarios.

207

Figura 104: El panel del plan de la generación, y cómo utilizarlo

Para cambiar el tipo de escrituras creadas, Pulsar el radio Button Windows o del Unix.

208

CAPITULO VI 6.

JADE [30][31][32][33]

JADE (Java Agent DEvelopment Framework) es un middleware que proporciona tanto un entorno de desarrollo como un entorno de ejecución para la realización y mantenimiento de sistemas multiagente. El entorno de desarrollo está formado por una serie de librerías en Java que permiten la implementación de agentes de manera limpia e independiente de la plataforma sobre la que se va a ejecutar. El entorno de ejecución permite a los agentes vivir y comunicarse entre ellos. Está realizado enteramente en Java y proporciona una serie de herramientas que permiten al desarrollador controlar y depurar a los agentes en tiempo real. Este capítulo es una síntesis de los artículos presentes en las referencias y de la experiencia del autor en el entorno de ejecución y pretende proporcionar una visión de JADE. La documentación que proporciona JADE: http://sharon.cselt.it/projects/jade/ donde también se encontrará la última versión del entorno. El Capitulo se divide en tres partes. La primera ("Tecnología") muestra la tecnología sobre la que se asienta JADE. La segunda ("JADE") explica la arquitectura de JADE y los entornos de desarrollo junto con el entorno de ejecución y por último, a modo de conclusión se dan unas ventajas del uso de JADE para el desarrollo de sistemas multiagente ("Razones para el uso de JADE"). 6.1 FIPA FIPA (Foundation for Intelligent Physical Agents) es una organización que se encarga de desarrollar especificaciones estándar para los sistemas basados en agentes. Con esto se pretende facilitar la interconexión entre plataformas de diferentes empresas y organizaciones. El objetivo de FIPA es definir la interoperabilidad entre los sistemas basados en agentes, dejando fuera la implementación interna. Define el modelo de una

209

plataforma basada en agentes, el conjunto de servicios que debe proveer y la interfaz entre los servicios. 6.2 JADE JADE es un middleware desarrollado por TILAB para el desarrollo de aplicaciones distribuidas multi-agente. JADE proporciona tanto el entorno de desarrollo para la creación de aplicaciones basadas en agentes como el entorno de ejecución. JADE presenta las siguientes características: P2P: Arquitectura peer-to-peer, cada agente puede tomar la iniciativa en una comunicación o bien responder a peticiones que le hagan otros agentes. Interoperabilidad: JADE cumple con las especificaciones FIPA, por lo que los agentes desarrollados en JADE pueden interactuar con otros agentes que no tienen porque estar desarrollados con JADE, aunque si deben seguir las especificaciones FIPA. Portabilidad La API que proporciona JADE es independientemente de la red sobre la que va a operar, así como de la versión de Java utilizada, teniendo la misma API para J2EE, J2SE y J2ME. Intuitiva: JADE se ha desarrollado para ofrecer una API fácil de aprender y sencilla de manejar. Los agentes JADE tienen nombres únicos y se permite a cada agente descubrir a otros agentes y comunicarse con ellos mediante comunicaciones punto a punto. Los agentes proporcionan servicios, cada agente puede buscar a otros dependiendo de los servicios que proporcionen otros agentes. La comunicación entre agentes se lleva a cabo a través de mensajes asíncronos, es decir, el agente que envía el mensaje y el destinatario del mensaje no tienen porqué estar disponibles al mismo tiempo. Es más, el destinatario no tiene porqué existir en ese instante. Los mensajes se pueden enviar a un agente en concreto o se pueden enviar a agentes que se desconocen pero se sabe que poseen unas ciertas características. JADE proporciona mecanismos de seguridad, ya que habrá agentes a los que no se les esté permitido comunicarse con otros agentes, de manera que una aplicación puede verificar la identidad del receptor y del agente que envía el mensaje y no dejar realizar actuaciones no permitidas para un determinado agente. La estructura de los mensajes se basa en el lenguaje ACL (Agent Communication Lenguaje) que ha sido definido por la FIPA. JADE también permite a los agentes cambiar de Host (en J2SE). Un agente puede interrumpir en un momento dado su ejecución, migrar a otro host (sin necesidad de que 210

el código esté previamente en el host destino) y continuar la ejecución en el mismo punto en el que la interrumpió. Esto permite un balanceo de carga ya que permite a los agentes migrar hosts menos cargados. El entorno de ejecución proporciona un marco donde poder ejecutar los agentes y herramientas gráficas para su monitorización y depuración. 6.3 Arquitectura Los agentes JADE necesitan del entorno de ejecución donde poder "vivir". Cada instancia del entorno de ejecución se denomina contenedor (container). Al conjunto de los contenedores se le denomina plataforma (platform) y proporciona una capa que oculta a los agentes (y al desarrollador) el entorno donde se ha decidido ejecutar la aplicación. En cada plataforma debe existir un contenedor especial denominado contenedor principal (main container). La principal diferencia del contenedor principal respecto al resto de contenedores es que alberga dos agentes especiales: AMS (Agent Management System): Este agente proporciona el servicio de nombres asegurando que cada agente en la plataforma disponga de un nombre único. También representa la autoridad, es posible crear y matar agentes en contenedores remotos requiriéndoselo al agente AMS. DF (Directory Facilitator): Proporciona el servicio de Páginas Amarillas. Gracias al agente DF, un agente puede encontrar otros agentes que provean los servicios necesarios para lograr sus objetivos. La arquitectura se puede observar en la figura 2, donde aparecen dos plataformas diferentes (platform1 y platform2), cada una con sus contenedores principales y contenedores normales.

211

Figura 105: Esquema de distribución de los containers y las plataformas.

6.4 Programación de Agentes en JADE JADE ofrece al desarrollador las siguientes funciones y ventajas: Ejecución distribuida. Interfaz gráfica para monitorización y depuración de agentes, incluyendo los que se encuentran en hosts remotos. Creación de agentes móviles. Ejecución de actividades en paralelo, según el paradigma de behaviours. Cumple con las especificaciones FIPA. Intercambio de mensajes ACL entre agentes. Registro automático de agentes (via AMS).

212

Servicio de nombres. El kit de desarrollo proporcionado por JADE cuenta con las clases necesarias para la creación de agentes. Un agente simplemente es una clase que hereda de la clase jade.core.Agent. Existen dos métodos que hay que reescribir:

Figura 106: Ejecución de dos agentes en dispositivos móviles y su arquitectura vista en el RMA.

Setup (): En este método se deben definir las inicializaciones correspondientes a nuestro agente ya que se invoca nada más comenzar la ejecución de este. takeDown(): Este método es invocado cuando se da por finalizada la ejecución del agente por lo que se debe realizar las tareas de limpieza de memoria. Se da por finalizado la ejecución de un agente cuando se llama al método doDelete(). JADE facilita mecanismos para el desarrollo de los objetivos que deben alcanzar los agentes: Los comportamientos (behaviours) y la comunicación entre los agentes (junto con el servicio de páginas amarillas) proporcionan los recursos necesarios para programar un sistema multi-agente. El esquema básico de un agente lo tenemos en la figura 6, que representa el flujo de control de un agente básico: Inicialización, realización de la tarea y limpieza y finalización.

213

Figura 107: Flujo de ejecución de un agente básico en JADE.

Los métodos setup(), y takedown() del agente deben se rescritos, así como action() y done() de cada comportamiento. 6.5 Comportamientos Un comportamiento es un conjunto de acciones que debe tomar el agente para lograr su objetivo. Los comportamientos se implementan como un objeto de la clase jade.core.behaviours.Behaviour. Los objetos Behaviour describen pequeñas tareas que debe realizar el agente ejecutándose según un planificador que se encuentra implementado en la clase Agent. El planificador va ejecutando según una política roundrobin los objetos behaviour que se encuentran en una cola FIFO, existiendo dos métodos, addBehaviour(behaviourObjebct) y removeBehaviour(behaviourObject), que permiten gestionar la entrada y salida de los objetos behaviour en la cola del planificador. 214

Los objetos behaviour tienen dos métodos que se deben reescribir, action() y done(). El método action() es en donde se deben desarrollar las tareas que debe realizar el agente, mientras que el método done() es llamado cuando action() finaliza. El planificador va ejecutando uno a uno los métodos action() de la cola y cuando el método action() de un objeto finaliza se llama al método done(), este debe retornar un booleano, si retorna true, el objeto es sacado fuera del planificador ya que se da por concluida su tarea, mientras que si retorna false se vuelve a planificar. Si en algún momento de la ejecución del método action() se requiere esperar por la llegada de un mensaje, existe el método block() para mandar a una cola de bloqueados cuando el método action() finaliza (no cuando se llama a block()). Cuando se produce la llegada de un mensaje, todos los objetos en la cola de bloqueados se planifican y deben comprobar si el mensaje llegado es para ellos o no. En caso de que un objeto no sea el destinatario del mensaje debe volver a bloquearse. Es importante que los métodos action() sean cortos, de esta forma se permite un cierto grado de paralelismo. Si se necesita realizar una tarea que va a requerir un largo periodo de tiempo, entonces el desarrollador deberá dividir la tarea en subtareas y cada una de ellas implementarla mediante un objeto behaviour. Con el fin de ayudar en esta labor, JADE proporciona una jerarquía de clases Behaviour, que nos permitirán hasta simular Máquinas de Estados Finitos. Clase SimpleBehaviour: Representa un comportamiento atómico. Clase OneShotBehaviour: Representa un comportamiento que se debe ejecutar solo una vez, por eso, su método done() retorna true, si no es redefinido. Clase CyclicBehaviour: Representa un comportamiento que debe ejecutarse una serie de veces. El método done, si no es redefinido, devuelve false. Clase CompositeBehaviour: Esta clase se compone de diferentes sub-behaviours que se pueden ejecutar siguiendo diferentes políticas de planificación. Las diferentes políticas vienen determinadas por la subclase elegida, SequentialBehaviour, ParallelBehaviour y FSMBehavior.

215

Clase SequentialBehaviour: Esta clase deriva de CompositeBehaviour y ejecuta subbehaviours de forma secuencial, y termina cuando todos los métodos action() han terminado. Clase ParallelBehaviour: Esta clase deriva de CompositeBehaviour y ejecuta los subbehaviours de manera concurrente. En el constructor de la clase se puede especificar cuando se desea que acabe la ejecución: Cuando todos los sub-behaviours lo han hecho, cuando uno termine, o cuando un número especificado lo logre. Clase FSMBehaviour: Esta clase permite definir una Máquina de Estados Finita mediante sub-behaviours. Cada sub-comportamiento representa un estado de la máquina, y las transiciones se van produciendo según la salida de dichos estados. La finalización se alcanza cuando se termine de ejecutar algún sub-behaviour que se haya registrado como estado final. Clase SenderBehaviour: Encapsula la acción de envío de un mensaje ACL. Este mensaje se le debe especificar en el constructor. Clase ReceiverBehaviour: Encapsula la acción de recepción de un mensaje ACL. Termina cuando se recibe el mensaje o cuando pasa una cierta cantidad de tiempo especificada en el constructor. Clase WakerBehaviour: Implementa un comportamiento Honesto que se ejecuta justo después de que se haya pasado un tiempo especificado. 6.5.1. Comunicación La comunicación entre los agentes es una de las más importantes características que aporta JADE. Se basa en un modelo de paso de mensajes asíncrono. Cada agente tiene un buzón en el cual se van almacenando los mensajes enviados por otros agentes. Cuando llega un mensaje nuevo, se le notifica al agente que lo ha recibido para que lo procese.

216

Los mensajes intercambiados entre los agentes siguen un formato concreto que ha sido definido por la FIPA denominado ACL. El formato ACL define los diversos campos que debe constar un mensaje: sender: El remitente del mensaje. receivers: La lista de destinatarios. Performative: El objetivo de la comunicación. El remitente debe indicar si la intención de la comunicación que se va a establecer es comunicar un suceso al destinatario (INFORM), solicitar que el destinatario realice una acción determinada (REQUEST), preguntar por una condición (QUERY-IF ), o establecer una comunicación algo más compleja (CFP1, PROPOSE, ACCEPT_PROPOSAL, REJECT_PROPOSAL) content: El contenido del mensaje. language: El tipo de sintaxis utilizado en content. ontology: El diccionario de símbolos usados en content. Campos de control usados para controlar conversaciones concurrentes y timeouts. Los mensajes son implementados como objetos de la clase jade.lang.acl.ACLMessage y proporciona métodos get y set para acceder a los diversos campos de un mensaje. 6.6. Entorno de ejecución La característica más importante del entorno de ejecución es la interfaz gráfica que proporciona, desde la que podemos controlar y depurar los agentes existentes. Todas las herramientas han sido desarrolladas como agentes y siguen sus mismas reglas.

6.6.1. Interfaz RMA El agente RMA (Remote Monitoring Agent) permite controlar al resto de agentes en una plataforma. Provee una interfaz gráfica que facilita las funciones de monitorización y control. Solo puede existir un agente RMA por container, aunque puede haber varios por plataforma. La interfaz gráfica permite las siguientes acciones, todas ellas llevadas a cabo a través de un sistema de menús: 217

Terminar la ejecución del agente RMA (se invoca al método doDelete ()). Terminar con la ejecución del agente RMA y de todos los agentes del container donde se encuentre RMA. Terminar con la ejecución de la plataforma en la que se encuentra. Comenzar un nuevo agente. Terminar con las ejecuciones agentes. La terminación se realiza internamente llamando al método doDelete (). Detener la ejecución de los agentes. Internamente se realiza una llamada al método doSuspend. Continuar la ejecución de agentes suspendidos. Los pone en estado Activo y llama al método doActivate (). Mandar un mensaje (formato ACL) a agentes seleccionados. Esta función se realiza mediante un cuadro de diálogo en el cual se tendrán que rellenar los campos del mensaje. Migrar un agente de un contenedor a otro. Clonar un agente, introduciendo el nombre del nuevo agente y el container donde se encontrará. 6.6.2. Agente Dummy

Figura 108: Interfaz gráfica del agente Dummy.]

218

El agente Dummy permite interactuar con otros agentes. Proporciona un interfaz gráfico que nos permite construir mensajes ACL, mandarlos, almacenarlos (también los que nos envíen a nuestro agente Dummy), y verlos en detalle. 6.6.3 Interfaz DF El agente DF, Directory Facilitator, proporciona también una interfaz gráfica. Este Agente es el que provee los servicios de Páginas Amarillas. A través de la interfaz gráfica se pueden ver descripciones de los agentes registrados, registrar y quitar agentes, buscar descripciones y modificarlas.

Figura 109: Interfaz gráfica del agente DF.]

A través de la GUI también podemos combinar nuestro DF con otros DF y crear dominios y subdominios de páginas amarillas. 6.6.4. Agente Sniffer Gracias al agente Sniffer se pueden monitorizar todos los mensajes que un agente, o un grupo de ellos, intercambian. Existen opciones para poder monitorizar mensajes con un performative exclusivo.

219

Figura 110 Interfaz gráfica del agente sniffer.]

6.6.5. Agente Instrospector Permite monitorizar la ejecución de un agente, y los mensajes intercambiados por este. También permite la monitorización de sus comportamientos

Figura 111: Interfaz gráfica del agente introspector.]

Y la ejecución paso a paso de estos.

220

6.7. Razones para el uso de JADE Una pregunta que puede surgir es el por qué de usar JADE para desarrollar sistemas multi-agente. La razón fundamental es porque es un middleware que oculta una arquitectura distribuida donde va a residir la aplicación, permitiendo al desarrollador centrarse solo en el aspecto lógico dejando de lado el desarrollo de las comunicaciones entre los diferentes hosts. En [2] se da además una de razones por las que es aconsejable usar JADE: JADE simplifica la comunicación y la cooperación entre los agentes, que tienen de forma distribuida la lógica de control para alcanzar el objetivo de la aplicación. Los agentes JADE pueden controlar su propio ciclo de vida, y pueden Ser programados para que dejen de funcionar o empiecen a hacerlo dependiendo del estado del sistema y de la función que debe realizar el agente. JADE cumple con la especificación de FIPA, luego puede comunicarse con agentes realizados en otros entornos que sigan FIPA. Es código abierto. Multitud de personas colaboran en la realización y mantenimiento de JADE. La evolución de JADE es controlada por el JADE Governing Board, para que su crecimiento no se realice de forma desordenada. Los agentes JADE pueden correr en las diferentes versiones de Java: J2EE, J2SE y J2ME. El API proporcionado por JADE es intuitivo, fácil de aprender y sencillo de usar, haciendo que el desarrollo se produzca de manera más rápida que si no se utilizase. Por estas características, los principales campos de aplicación son: Aplicaciones móviles: Facilita la búsqueda y procesamiento de la información. Internet: Desarrollo de aplicaciones P2P. 6.8

Implementación del caso de estudio

Con la colaboración del Ing. Julián Moreno Cadavi integrante de GIDIA: Grupo de I + D en Inteligencia Artificial Escuela de Ingeniería de Sistemas, Universidad Nacional de Colombia – Sede Medellín. Quien me aconsejo y guió en el desarrollo de esta aplicación en jade.

221

Como ya se ha hablado de la forma de realizar un agente en esta aplicación a continuación se muestran unos screenshot de la aplicación, y el código fuente se incluye en el anexo 3.

Figura 112 Archivos de Subasta en jade]

Se selecciona el ejecutor de la plataforma que simplemente está construido por la orden de: “java jade.Boot -gui pizarra:subasta.pizarra Postor1:subasta.comprador(3100.0) Postor2:subasta.comprador(3600.0) Postor3:subasta.comprador(3300.0) Suvastador:subasta.vendedor(Producto2 3100)”. Se pueden variar los agentes que la componen, lo importante es que exista lógicamente el agente pizarra y al menos un subastador y un postor. El hecho de la realización del agente pizarra era la facilidad de crear la presentación de nuestra aplicación, dado que ya el grupo GIDAI realizado prototipos de subastas en jade y no existe la necesidad de “redescubrir la rueda”. Una de las principales características de la plataforma es que los desarrollos se encontrarán dentro del estándar FIPA. El intercambio de mensajes entre agentes, así como las per formativas empleadas se corresponderán con lo especificado con este estándar. JADE viene acompañado de una gran cantidad de documentos. El problema es que la información para la creación de un sistema multi-agente utilizando las herramientas proporcionadas por la plataforma se encuentra repartida y dispersa entre toda esta documentación, siendo inexistente la presencia de algún tutorial básico que permita a los neófitos iniciarse en esta plataforma. El presente documento trata de cumplir el papel de tutorial, tanto de uso de la plataforma como de creación de un sistema multi-agente.

222

Por último cabe destacar que JADE es Software Libre y que se distribuye bajo los términos de la licencia LGPL (Lesser General Public License Versión 2). Al ser una plataforma desarrollada en Java será posible utilizarla en cualquier sistema operativo que disponga de una máquina virtual de Java (la versión mínima es la 1.2). Por lo tanto, podremos utilizarlo tanto en sistemas Windows como en sistemas Linux o *BSD. La página del proyecto la podemos encontrar en http://sharon.cselt.it/projects/jade/. Es desde esta página, en la sección Download, desde donde podremos obtener el archivo .Zip de instalación. Para poder descargarlo se nos pedirán una serie de datos. A la hora de escribir este documento la última versión oficial de JADE es la 3.0b1. Desde la página de descarga podremos acceder a cuatro archivos con extensión .Zip que se corresponderán con cada uno de los elementos de la plataforma (binarios, documentación, ejemplos, fuentes) o podremos obtener el archivo JADE-all-version.zip, que contendrá todos ellos. Una vez descargado el archivo anterior, la instalación será tan sencilla como descomprimirlo en el directorio que deseemos, utilizando herramientas como Winzip (Windows) o unzip (que podemos encontrar en la mayoría de las distribuciones de Linux). Al hacer esto, obtendremos como resultado otros cuatro archivos .Zip, que deberemos descomprimir de la misma forma. Lo siguiente es añadir a la variable de entorno CLASSPATH los archivos .jar del directorio lib, así como el directorio actual. Por ejemplo, en Windows utilizaríamos el siguiente comando:

set CLASSPATH=%CLASSPATH%;.;c:\jade\lib\jade.jar; c:\jade\lib\jadeTools.jar; c:\jade\lib\Base64.jar; 223

c:\jade\lib\iiop.jar La clase que nos va a permitir iniciar la plataforma de JADE es jade.Boot. Según los parámetros que le pasemos se realizará una acción u otra. Lo primero que podemos hacer es ejecutar la interfaz gráfica de JADE que nos muestra los agentes presentes en el sistema multi-agente, así como su localización. Para ello, dentro del directorio donde hayamos descomprimido JADE, deberemos teclear lo siguiente: java jade.Boot –gui

Tal como se ha visto anteriormente, para iniciar la ejecución de la plataforma debemos ejecutar, mediante la máquina virtual de java, el objeto jade.Boot. Este objeto acepta una serie de parámetros que permitirán indicar los agentes que se desean ejecutar, los contenedores a crear, el host donde ejecutar los agentes, si mostrar la interfaz gráfica asociada al agente RMA, etc.

Para una descripción más detallada de los distintos parámetros con los que se puede llamar a jade.Boot podremos consultar el JADE's Administrator Guide que encontraremos entre la documentación presente en la distribución de JADE. Para que un agente o un conjunto de agentes sean creados al inicializar la plataforma JADE deberemos ejecutar jade.Boot de la siguiente forma: java jade.Boot nombre1:clase1 nombre2:clase2 ... Para cada agente deberemos indicar su nombre y la clase a la que instancia (recordemos que cada agente será la instancia de una determinada clase) separado por dos puntos. Así, para crear un agente de la clase ClaseAgente con el nombre agenteEjemplo, se procede a realizar lo siguiente:

224

java jade.Boot agenteEjemplo:ClaseAgente Si además quisiéramos que se mostrara la interfaz del agente RMA para poder depurar nuestro sistema multi-agente, se puede teclear lo siguiente:

java jade.Boot -gui agenteEjemplo:ClaseAgente Como se puede observar, primero se indican las opciones y después la lista de agentes a crear. En los anexos esta el código fuente debidamente comentado.

225

CAPITULO VII 7. CONCLUCIONES Se puede observar en los puntos anteriores el rango que existe a la hora de diseñar arquitecturas para agentes. Mientras que en la mayoría de ellas se dispone de elementos que permitan la percepción y actuación en el entorno, tal y como aparece en la práctica totalidad de definiciones de agentes, la existencia de elementos más complejos, como el aprendizaje o la relación entre agentes varía de unas arquitecturas a otras. Las metodologías estudiadas son representantes de diferentes líneas de investigación en agentes: Agentes como sistemas basados en conocimiento (MAS-CommonKADS, INGENIAS), agentes BDI (BDI, ZEUS), agentes según la definición de Newell (INGENIAS). La aplicación de estas metodologías depende mucho de la formación que tenga su usuario final. Esto quiere decir que son interpretadas en función de los intereses de quien las aplica. De momento, no hay soluciones que fuercen un uso concreto. El proceso de desarrollo que propone INGENIAS es excesivo cuando se trata de desarrollos reducidos. A diferencia de MAS-CommonKADS y MASINA que dota de procesos de desarrollo adaptados al tamaño del problema, INGENIAS da la impresión de dedicarse exclusivamente a desarrollos de gran tamaño. INGENIAS es bastante reciente. Aunque se apoya en MESSAGE y dispone de varios desarrollos donde se experimenta con ella, queda por demostrar su viabilidad real. Como MAS-CommonKADS, INGENIAS dispone de una cantidad ingente de entidades y relaciones. Su uso mediante la herramienta de soporte INGENIAS IDE, se facilita pero se sigue requiriendo que el desarrollador revise la documentación del grupo GRASIA para entender qué hace cada entidad y cuál es el propósito de cada relación. En Ingenias IDE, el proceso de generación de código es más flexible que el ofrecido en ZEUS. La principal diferencia consiste en que los desarrolladores pueden configurarlo a voluntad y adaptarlo a sus necesidades sin tener que modificar la herramienta de análisis/diseño.

226

Esta metodología ha sido la primera en incorporar la idea de proceso de ingeniería en el sentido de Pressman [Pressman 82]. De hecho, describe con bastante detalle cómo se debe definir el sistema teniendo en cuenta las dependencias entre los modelos. El principal inconveniente de MÁS CommonKADS En es que el nivel de detalle alcanzado en la descripción no es realizable sin el apoyo de herramientas de soporte. Lo que propone MAS-CommonKADS, entre otras cosas, no es una notación sino una lista detallada de elementos y relaciones a identificar en el sistema. Un desarrollador puede seguir la lista y generar la documentación requerida de forma manual, sin embargo el proceso es demasiado costoso y dado a errores. En la versión actual de MAS-CommonKADs, la información que hay que obtener se expresa con lenguaje natural. A pesar del apoyo de una herramienta de soporte que se encuentra en desarrollo, al tener la especificación en lenguaje natural, se dificulta el análisis automático de la especificación generada. Así pues, para averiguar si existen elementos no utilizados o si existen contradicciones hay que revisar la documentación a mano. Para lograr lo mismo en MAS-CommonKADS habría que restringir el uso de lenguaje natural o bien incluir formalismos que logren una definición más precisa y menos ambigua del SMA. A pesar de estos inconvenientes, MAS-CommonKADs como INGENIAS constituye un ejemplo a seguir en lo que a metodologías se refiere. Es exhaustiva como pocas a la hora de detallar el sistema y además es consecuente con que el proceso de desarrollo en la mayoría de los casos es más complejo que un conjunto de pasos. De hecho, las ideas de MASCommonKADS han estado presentes en casi todos los trabajos referentes a metodologías desde hace años. ZEUS se orienta más a las prácticas de ingeniería convencional. El modelado de roles, propuesto, no profundiza en la aplicación de la herramienta dentro del proceso de desarrollo. El ámbito de la metodología se limita a estudiar cómo agrupar la funcionalidad del sistema dentro de cada rol, dejando aparte consideraciones acerca de cómo organizar las tareas, definir las ontologías y las dependencias sociales, aspectos que son modelables dentro de la herramienta. Detallar todos los elementos requeridos por la herramienta ZEUS requeriría un artículo entero. El uso de esta herramienta no es trivial. Presenta tantas posibilidades que a un desarrollador con pocos conocimientos en agentes puede hacerle dudar. ¿Por dónde empezar? Por ello, se echa más en falta un proceso de desarrollo más detallado que indique en qué aspectos de la herramienta hay que concentrarse en cada momento.

227

La opinión del autor es que las herramientas de soporte no tienen que condicionar la metodología y para ello, metodología y herramientas han de ser independientes. En cada uno de los temas relacionados con agentes y SMA se puede profundizar tanto como se quiera, pero a veces se llega a problemas que no son relevantes en el contexto de SMA. Lo importante, es entender que la noción de agente es tan amplia o ten reducida como se quiera y/o se necesite. Una de las características más importantes de un SMA es que el grupo de agentes que lo integran debe trabajar de manera cooperativa e individual. Los agentes trabajan de manera cooperativa para satisfacer las metas globales que se derivan de la búsqueda de las soluciones a los problemas globales y de manera individual, porque las metas globales son descompuestas en submetas, generando metas locales para los agentes que participarán en el desarrollo de las soluciones a los problemas. Cuando dos o más entidades trabajan en grupo, se presentan conflictos de intereses de manera natural. Es necesario que el ambiente en el que se desenvuelven provea procesos para la resolución de tales conflictos. En este documento se propone como mecanismo básico para manejar este aspecto, la negociación en grupo. Este mecanismo puede ser visto como un proceso de toma de decisiones en el cual dos o más entidades, representando sus propios intereses, se ponen de acuerdo acerca de cómo resolver un conflicto de preferencias. Algunas de estas tareas de decisión están caracterizadas por las relaciones cooperativas entre los miembros del grupo, en las cuales los individuos trabajan por el desempeño del grupo en general; o por relaciones competitivas en las cuales los miembros del grupo plantean posiciones definidas y discuten entre sí, defendiendo sus propios intereses. Un SMA es un sistema distribuido, por ello, en él nunca se cuenta con información global consolidada totalmente actualizada. Por esta razón, los agentes deberían reevaluar las decisiones tomadas, a la luz de cada nueva información obtenida, generando sobre costos de comunicación. Es importante que los mecanismos de negociación y control sean coherentes con las necesidades de los sistemas a los que pertenecen, es decir, ser sofisticados si el sobre costo generado es menor que el sobre costo generado con la implementación de un SMA sencillo, para la resolución de un problema. Los meta-modelos presentados sirven como guía para construir modelos durante el desarrollo de un SMA. Por eso los meta-modelos deben comprender toda la información que a tener en cuenta en para especificar un SMA, aunque manteniendo abiertas distintas estrategias de llevar el desarrollo. Es decisión del desarrollador decidir en qué orden se generan los modelos y con qué nivel de detalle. A este respecto, no existe ninguna restricción.

228

7.1 Criterios de examen En esta parte presentaremos los diferentes criterios extraídos desde las etapas de desarrollo presentadas anteriormente. 7.1.1. Cuatro cualidades de las etapas de desarrollo El proceso de extraer las cualidades comunes desde las cuatro etapas de construcción no es evidente. Por cualidad, entendemos una característica distintiva que caracteriza un aspecto positivo o negativo en la realización práctica de una etapa particular. Hemos determinado cuatro cualidades que parecen relevantes en todas etapas: - Completitud: el grado de cobertura que la plataforma provee para esta etapa. Consideramos la cantidad y la calidad de la documentación y herramientas que se proporcionan. - Aplicabilidad: el alcance de la etapa propuesta, en otras palabras la gama de las posibilidades ofrecidas y las restricciones impuestas por la etapa propuesta. - Complejidad: la dificultad para completar la etapa. Esto incluye la competencia requerida al desarrollador y la cantidad de trabajo que requiere la tarea. - Reusabilidad: la cantidad de trabajo ganada al reutilizar trabajos previos. 7.1.2. Aplicación de las cualidades a las etapas Las cuatro cualidades aplicadas a las cuatro etapas de desarrollo resultan en dieciséis criterios para evaluar cualquier plataforma.

229

Análisis Los criterios del Análisis incluyen: - Completitud: ¿el método de análisis es útil, y está bien documentado?

Ingenias MascommonKads

Masina Zeus Jade

Como MAS-CommonKADS, INGENIAS dispone de una cantidad ingente de entidades y relaciones. Su uso mediante la herramienta de soporte INGENIAS IDE, se encuentra bien documentada, por el equipo GRASIA MAS-CommonKADS ha sido la primera en plantear un desarrollo de SMA integrado con un ciclo de vida de software, concretamente el espiral dirigido por riesgos, bien documentada en su tesis y trabajos que lo han aplicado.

Poco documentada por no abrece liberado la metodología, pero fuerte al ser una extensión de Mas commonKads. El análisis se debe a voluntad del desarrollador Basado en el modelado de roles, utilizando diagramas de clase UML y patrones. Jade es una plataforma exclusiva para el desarrollo.

- Aplicabilidad: ¿a qué dominios y problemas se aplica este método? Ingenias MascommonKads

Masina

Zeus Jade

A todo tipo de problemas, puesto que combina el esfuerzo metodológico con el desarrollo de la herramienta. Tiene un rango muy amplio de aplicabilidad, por su capacidad de especificar Sistemas Multi agentes. Una Metodología para Especificar Sistemas Multi-agentes, usa los modelos presentados en ésta para proponer algunas extensiones, modificaciones y sustituciones que permiten describir las características inteligentes en un agente o en el colectivo, utilizar técnicas inteligentes para la realización de tareas Es una herramienta para construir aplicaciones multi-agente colaborativas. Que provee un entorno integrado para el desarrollo rápido de sistemas Jade es una plataforma exclusiva para el desarrollo.

- Complejidad: ¿es el método de análisis fácil de comprender y de aplicar? Ingenias Mas-

Es un esfuerzo arduo, para poder entenderlo, para aplicarlo pero después de comprenderlo, resulta muy completo y eficiente. Muy engorroso pero al entenderlo se puede moldear para adecuarlo al

230

commonKads

Masina Zeus Jade

problema a enfocar. Al igual que más commonKads, es muy flexible y se puede adecuar al problema. El método es arbitrario, y escogido por el desarrollador. Jade es una plataforma exclusiva para el desarrollo.

- Reusabilidad: ¿existe una manera de explotar el análisis previo de problemas similares o de dominios similares? ¿Suministra el análisis de ejemplos? Diseño Los criterios de Diseño incluyen: - Completitud: ¿el método de diseño es útil y está bien documentado? ¿Existen herramientas para apoyar el proceso de diseño? Ingenias MascommonKads

Masina Zeus Jade

Muy documentado y respaldado por el grupo GRASIA. La herramienta INGENIAS IDE. Documentado en la tesis doctoral de Carlos Ángel Iglesias Fernández, y posterior mente por otros estudios, existe una herramienta en desarrollo. Poco documentada, solo mencionada en algunas tesis, se espera la liberación de la metodología por completo. El método es arbitrario, y escogido por el desarrollador. Jade es una plataforma exclusiva para el desarrollo.

- Aplicabilidad: ¿qué tipo de MAS puede ser diseñado utilizando este método? Ingenias Mas-

No se han dado limitantes a los tipos de MAS No se han dado limitantes a los tipos de MAS

commonKads

Masina Zeus Jade

No se han dado limitantes a los tipos de MAS, se enfoca hacia la inteligencia de los agentes. No se han dado limitantes a los tipos de MAS Jade es una plataforma exclusiva para el desarrollo.

- Complejidad: ¿el método de diseño es fácil de comprender y de aplicar? Ingenias MascommonKads

Masina Zeus

El método está bien guiado para su entendimiento y tiene excelente enfoque para su aplicabilidad Es algo extenso para entender, después de comprender este método es muy flexible. El método está enfocado tal como Más comonkads con la variante de su enfoque a sistemas más inteligentes. El diseño esta enfocado ha roles por ende es de importancia enfocarse en ellos.

231

Jade

Jade es una plataforma exclusiva para el desarrollo.

- Reusabilidad: ¿existe alguna forma de reutilizar los diseños existentes? ¿Soporta utilidades de diseño? Ingenias Mas-

La reusabilidad es grande pues está basado en meta-modelos, hasta el momento que se enfoca al problema específico de allí cada problema es individual. La reusabilidad es grande pues sus modelos permiten la reutilización.

commonKads

Masina Zeus Jade

La reusabilidad es grande pues sus modelos permiten la reutilización. Poca es manual. Jade es una plataforma exclusiva para el desarrollo.

Desarrollo Los criterios de Desarrollo incluyen: - Completitud: ¿cuán útiles son las herramientas de desarrollo proporcionadas? Ingenias MascommonKads

Masina Zeus Jade

INGENIAS IDE, excelente herramienta permite el modelado como la exportación para generar código. Herramientas en desarrollo no se ha liberado, por lo tanto esta parte de desarrollo es enfocado a desarrollo manual. Sin herramientas. Zeus Agent Building Toolkit, excelente utilidad vasada en roles que facilita la creación de los armazones. Herramienta de desarrollo basada en java, por lo tanto extensible y flexible, siguiendo todos los estándares de FIPA, con un impresionante paquete de clases para su utilización.

- Aplicabilidad: ¿existe alguna funcionalidad imposible de lograr con las herramientas de desarrollo? Ingenias MascommonKads

Masina Zeus Jade

Si se posee un gran conocimiento de la metodología así como de su herramienta el grupo GRASIA no ha encontrado limitantes ha esta. Aborda con su extensa especificación y el desarrollo de los MAS, la limitante es su especificación que depende de la habilidad del desarrollador. Enfocada a la inteligencia como eje fundamental. Limita la construcción su enfoque de metodología de roles al pasarlos a la herramienta, puesta que esta aunque muy completa, encajona al desarrollador a su uso, preferible JADE. Excelente Herramienta con la libertad de crear el código, el respaldo de FIPA, es para juicio del autor la mejor pues cuenta con todos los protocolos, y se puede manejar tal como jade.

232

- Complejidad: ¿son las herramientas de desarrollo y los lenguajes fáciles de utilizar? ¿Cómo es de popular el lenguaje utilizado? Ingenias MascommonKads

Masina Zeus Jade

Posee un manual el cual es muy completo pero largo, el grupo Grasia lo promueve por su completitud y constante desarrollo. Herramienta en desarrollo, muy popular pues ha sido base para implementación y guía de otras metodologías. No posee, herramienta. En su comienzo fue muy popular, pero poco a poco ha descendido su uso y en la actualidad es recomendado para el uso de prototipos. Es fundamental conocer el lenguaje java y entender la cantidad de clases existentes, muy popular y adoptada por muchos grupos de investigación.

Despliegue Los criterios de Despliegue incluyen: - Completitud: ¿existe un soporte para el despliegue del MAS? Ingenias Mas-

El grupo GRASIA ofrece su apoyo, para dar soporte a aquellos que se interesen en empezar esta práctica. No posee soporte, además de la ayuda del propio autor.

commonKads

Masina Zeus Jade

No posee soporte, además de la ayuda del propio autor. Soporte directo con el grupo Intelligent Systems Research Group, BT Labs. Existen muchos grupos de investigación que prestarían su apoyo.

- Aplicabilidad: ¿tiene la herramienta de despliegue soporte para visualización, perfiles, mantenimiento on-line, etc.? Ingenias Mas-

Si No

commonKads

Masina Zeus Jade

No Limitada, En la actualidad se trabaja con la versión zeus-2-0-e. Constante , en http://jade.tilab.com/

- Complejidad: ¿son las herramientas de despliegue fácil de usar y de comprender? Ingenias Mas-

Son extensas y engorrosas, pero al fin entenderlas poseen gran capacidad. --

commonKads

233

Masina Zeus Jade

-Es complicado el estudio y extenso sus manuales, pero unas ves comprendido fácil uso. Es complicado el estudio y extenso sus manuales, pero unas ves comprendido fácil uso.

7.1.3 Otros criterios Podemos considerar también algunos otros criterios prácticos que hay que tomar en cuenta al elegir una plataforma. En particular, estos criterios pueden condicionar la adopción de una plataforma para un proyecto particular: - Disponibilidad: ¿es una versión de prueba?, ¿tiene cláusulas confidenciales?, ¿está disponible el código original? ¿Cuánto cuesta? Ingenias Mas-

Libre, free Libre, free

commonKads

Masina Zeus Jade

Libre, free GNU LGPL (Lesser General Public License Versión 2).

- Soporte: ¿cuáles son los futuros desarrollos de esta plataforma? ¿Se utiliza esta plataforma a gran escala? Ingenias Mas-

Si por el grupo GRASIA, y pequeños grupos de investigación. Si

commonKads

Masina Zeus Jade

Poco, pues no se ha liberado la metodología a la fecha de esta tesis Estancada, su uso primordial es para la creación de prototipos. Extendida, y en expansión por tratarse de código java

A un nivel más fino, podríamos explorar aspectos más técnicos, tales como la manipulación de procesos, movilidad, seguridad, estandarización, etc. pero limitaremos nuestro análisis al nivel más conceptual.

234

En Conclusión general: Ingenias

Mas commonKads

Masina

Zeus

Jade

ANALISIS

Completitud Aplicabilidad Complejidad Reusabilidad DISEÑO

Completitud Aplicabilidad Complejidad Reusabilidad DESARROLLO

Completitud Aplicabilidad Complejidad Reusabilidad DESPLIEGUE

Completitud Aplicabilidad Complejidad Reusabilidad OTROS CRITERIOS

Disponibilidad Soporte

-Nada

-Poco

-Regular

-Mucho

Figura 113: Cuadro comparativo

Si hubiera que elegir una metodología, ¿cuál sería la ganadora? Con esta Pregunta se comenzó esta tesis y la respuesta es que cada metodología, por el bagaje de sus creadores, se especializa en áreas concretas. Si se está acostumbrado a trabajar con sistemas basados en conocimiento como con la metodología CommonKADS, lo lógico es que se elija MASCommonKADS. Si por el contrario está interesado en un enfoque más orientado a agentes, puede seleccionar ZEUS, INGENIAS. Y si lo que se quiere es tener un soporte de herramientas, la lista de metodologías válidas se: ZEUS, INGENIAS.

235

En los casos en que se requiera un proceso de desarrollo robusto, detallado y ensayado en desarrollos reales, la recomendación sería MASCommonKADS o INGENIAS. Otra opción que tienen los desarrolladores es quedarse con lo que más les interese de cada metodología. Una recomendación sería utilizar la técnica de modelado de INGENIAS junto con su herramienta de especificación e implementar con JADE. Las metodologías estudiadas son representantes de diferentes líneas de investigación en agentes: Agentes como sistemas basados en conocimiento (MAS-CommonKADS), agentes BDI (BDI, ZEUS), agentes según la definición de Newell (INGENIAS). La aplicación de estas metodologías depende mucho de la formación que tenga su usuario final. Esto quiere decir que son interpretadas en función de los intereses de quien las aplica. De momento, no hay soluciones que fuercen un uso concreto. Es de destacar que la mayoría de las metodologías expuestas carecen de ejemplos detallados y suficientemente extensos que expliquen cómo se aplica. La presentación de una metodología debería de acompañarse con desarrollos que la avalen y muestren su utilidad. Finalmente, solo mencionar que la experiencia en otros paradigmas, como el estructurado y el de objetos, dice que los que verdaderamente perduran son la notación y las herramientas. Así pues, estos dos elementos deberían cuidarse en cualquier propuesta. La realidad, en la mayoría de los casos, es que no se cuidan. El tiempo dirá, de las metodologías existentes, qué persiste y qué no. La opinión del autor es que debido al incremento de investigadores con fuerte formación en ingeniería del software, los próximos años van a marcar cambios importantes en esta área. Muchas de las notaciones y herramientas que hoy en día se están aceptando como válidas, sufrirán importante cambios y algunas incluso desaparecerán. Es el precio a pagar en el camino hacia la madurez de la tecnología de agentes.

236

BIBLIOGRAFIA •

[1]

Subrahmanian V.S. et al., "Heterogeneous agent systems", MIT Press, 2000.

•

[3]

Knapik M., Johnson J., “Developing Intelligent Agents for

Distributed Systems”, McGraw Hill, 1998. •

[4]

M. R. Genesereth, N. P. Singh, and M. A. Syed. A distributed and

anonymous knowledge sharing approach to software interoperation. In Proceedings of the Third International Conference on Information and Knowledge Management (CIKM’94), Nov. 1994 •

[5]

Y. Shoham. Agent-oriented programming. Artificial Intelligence,

60(1):51–92, Mar. 1993. •

[10]

icordel,

P.

M.:

Programmation

Orientée

Multi-Agents

,

Développement et Déploiement de Systèmes Multi-Agents Voyelles. Tesis doctoral. INSTITUT NATIONAL POLYTECHNIQUE DE GRENOBLE. 2001. •

[19]

MODELADO DE SISTEMAS MULTI-AGENTE,

TESIS

DOCTORAL AUTOR : Doctor Jorge J. Gómez Sanz, Universidad Complutense de Madrid Junio 2002 •

[20]

DEFINICIÓN

DE

UNA

METODOLOGÍA

PARA

EL

DESARROLLO DE SISTEMAS MULTIAGENTE, TESIS DOCTORAL, AUTOR Carlos Ángel Iglesias Fernández Ingeniero de Telecomunicación, Enero 1998 •

[22]

Aguilar, J. “Especificación Detallada de los Agentes del SCDIA –

MASINA CommonKADS”. Reporte Técnico del 3er. Año, Proyecto Agenda Petróleo Nro. 97003817, 2003 •

[23]

Aguilar, J., Ferrer, E., Perozo, N., Vizcarrondo, J. "Propuesta de un

Sistema Operativo WEB", Proceedings of the TECNOCOM 20003, 3era Feria y Seminario de Informática, Electrónica y Telecomunicaciones, Medellín, Colombia, Mayo 2003.

i

•

[24]

MASINA: A Methodology to Specify Multiagent In this paper we

presented a methodology to specify Multiagent Systems called MASINA. MASINA is based on MAS-CommonKADS; it uses. Systems Aguilar Josea ,Cerrada Marielaa, Hidrobo Franciscob*, Mousalli Gloriac, Rivas Francklind Universidad de Los Andes. 5101. Mérida, Venezuela 2005 •

[36]

Gat. E. “Integrating Planning and Reacting in a Heterogeneus

Asynchronous Architecture for mobile robots”. SIGART bulletin 2, 71-74. 1991. • • Integrated Intelligent Architecture s_ Stanford_ CA_ ____

•

[40] A Design for the Icarus Architecture To appear in Proceedings of the AAAI Spring Symposium on Integrated Intelligent Architectures_ Stanford_ CA 1991 [41] Drummond, M.; Bresina, J.; Kedar, S. “The Entropy Redution Engine: Integrating Planning, Scheduling and Control”. SIGART bulletin 2, 61-65. 1991

BIBLIOGRAFIA WEB •

[2]

MultiRobot Labs, Computer Science Department and Robotics

Institute, Carnegie Mellon University http://www-2.cs.cmu.edu/~multirobotlab/ Visitada : mayo 2006 •

[6]

Agentes inteligentes, Universidad nacional de Colombia En

muchas aplicaciones es necesario tener sistemas que puedan decidir por … http://www.virtual.unal.edu.co/cursos/ingenieria/2001394/docs_curso/principal.h tml Visitada: mayo 2006 •

[7]

Tecnología de agentes y sus aplicaciones

Telecomunicaciones

de

Alcatel,

Primer

trimestre

Revista de de

1999

http://www.mipagina.cantv.net/vmendillo/Tesis/Agentes.htm Visitada: Octubre 2006 •

[8]

Universidad

de

Concepción,

Sistemas

[email protected] Jornadas Chilenas de Computación, Noviembre 2005, Valdivia *

ii

multiagente,

http://jcc2005.inf.uach.cl/documentos/tutorialAtkinson.pdf?PHPSESSID=de8e8ç fdf68d1c49cebbb1feeea918cb2#search=%22Arquitectura%20Abstracta%20De% 20Agentes%2Bestados%20instant%C3%A1neos%20discretos%22 Visitada: Octubre 2006. •

[9]

Sistemas tutoriales multiagentes con modelado del estudiante y del

autor http:// ltcs.uned.es:8080/aepia/Uploads/18/38.pdf Visitada: junio 2006 •

[11]

Multiagent & Cooperative Robotics Laboratory. Multiagent

Systems Engineering This research project attempts to define a methodology for designing

and

developing

multi-agent

systems

(MAS)

http://macr.cis.ksu.edu/projects/mase.htm Visitada mayo 2006 •

[12]

The Gaia Methodology for Agent-Oriented Analysis and Design

Gaia deals with both the macro (societal) level and the micro (agent) level aspects ... The purpose of the Gaia agent model is to document the various agent www.ecs.soton.ac.uk/~nrj/download-files/jaamas2000.pdf Visited may 2006 •

[13]

The Gaia Methodology For Agent-Oriented Analysis And Design

... - [ Traduzca esta página ]This article presents Gaia a methodology for agent oriented analysis and design. The Gaia methodology is both general, in that it is applicable to a wide ... www.citeseer.ist.psu.edu/wooldridge00gaia.htm Visited may 2006 •

[14]

JACK. JACK Intelligent Agents. Agent Oriented Software Pty.

Ltd., http://www.agent-software.com/ Visitada junio 2006 •

[15]

MADKIT. Multi-Agent Development KIT. http://www.madkit.org

Visitada Julio 2006. •

[16]

JAFMAS

(Java

Framework

for

Multi-agent

http://www.emis.de/journals/SADIO/vol.3.1/Avancini.pdf

iii

Systems)

Visitada octubre 2006 •

[17]

Grasshopper - A Universal Agent Platform Based on OMG

MASIF and ]This chapter is about the Grasshopper agent platform developed by GMD FOKUS and IKV++, ... Today, Grasshopper is the agent platform of choice in

multiple

.http://www.cordis.europa.eu/infowin/acts/analysys/products/thematic/agents/ch4 /ch4.htm Visitada octubre 2006 •

[18]

Tutorial-iiwas-ludwig Grasshopper. Building an Agent with

Grasshopper. DBagents. [email protected] ... Grasshopper Agent Model II. ■Place. Runtime environment for agents. ■Agent ... http://iiwas.comp.nus.edu.sg/presentation/klug.pdf Visitada octubre 2006 •

[21]

A Methodological Proposal for Multiagent Systems Development

extending CommonKADS Dep. de Ingeniería de Sistemas Telemáticos, E.T.S.I. Telecomunicación Universidad Politécnica de Madrid, E-28040 Madrid, Spain http://ksi.cpsc.ucalgary.ca/KAW/KAW96/iglesias/Iglesias.html Visitada abril 2006 •

[25]

The Zeus Agent Building Toolkit1. © British Telecommunications

plc 2001-. The Zeus Agent Building Toolkit. Jamie Stark, [email protected]. Intelligent System Lab, BTexacT ... www.upv.es/sma/plataformas/zeus/Zeus-lessonone.pdf Visitada marzo 2006 •

[26]

IngentaConnect

ZEUS:

A

TOOLKIT

FOR

BUILDING

DISTRIBUTED MULTIAGENT ... - [ Traduzca esta página ] ZEUS: A TOOLKIT FOR BUILDING DISTRIBUTED MULTIAGENT SYSTEMS ... The ZEUS toolkit is a syçnthesis of established agent technologies with some novel solutions

...

www.ingentaconnect.com/content/tandf/uaai/1999/00000013/00000001/art00007 iv

Visitada marzo 2006 •

[27]

[PDF] ZEUS: An Advanced Tool-Kit for Engineering Distributed

Multi-Agent ... developing a clear methodology for building distributed multiagent

systems

and

the.

ZEUS

tool-kit

to

support/instantiate

it,

...

www.agent.ai/download.php?ctag=download&docID=56 Visitada abril 2006 •

[28]

The Zeus Technical Manual - Components of the ZEUS agent

building toolkit. The ZEUS toolkit consists of a set of components, written in the Java programming language, ... www.labs.bt.com/projects/agents/zeus/techmanual/part3.html Visitada Mayo 2006 •

[29]

The Application Realisation Guide ZEUS REALISTION GUIDE.

The Zeus Agent Building Toolkit. ZEUS Methodology Documentation Part III. The Application. Realisation Guide ... www.upv.es/sma/plataformas/zeus/agentRealisation.pdf Visitada mayo 2006 •

[30]

Pagina principal de JADE (incluyendo pepers, documentos de

instalacion) http://jade.tilab.com/ Visitada mayo 2006 •

[31]

Tutorial basico de JADE

Escuela de Primavera de Agentes,

http://imaginatica.eii.us.es/2005/agentes/info/material-botia/jade_texto.pdf Visitada abril 2006 •

[32]

Plates-formes des systèmes multi-agents Systèmes multi-agents

Professeur

:

J-P.

SANSONNET

http://www.limsi.fr/~jps/enseignement/examsma/2005/1.plateformes_2/SAIDNA %20Said/Jade.htm Visited September 2006 •

[33]

TUTORIAL JADE Pablo Suau Pérez

http://www.dccia.ua.es/~pablo/tutorial_agentes/index.html

v

Visitada marzo 2006. •

[34]

MESSAGE Methodology - the Initial version These pages present

the initial version of the MESSAGE methodology as described in project … http://www.eurescom.de/~public-webspace/P900-series/P907/D1/ Visitada abril 2006 •

[35]

UNA ARQUITECTURA PARA SISTEMAS INTELIGENTES

ADAPTATIVOS http://tvdi.det.uvigo.es/tesispdfs/tesis-manuel.pdf Visitada Octubre de 2006 •

[37]

You Sense, I'll Act: Coordinated Preemption in Multi-Agent

CIRCA ... - [ Traduzca esta página ]We are extending the real time performance guarantees provided by CIRCA into distributed multi agent systems. In particular, we are developing methods for http://citeseer.ist.psu.edu/correct/471165 Visitada Noviembre 2006 •

[38]

MASA-CIRCA: Multi-Agent Self-Adaptive Control for Mission-

Critical ... - [ Traduzca esta página ]The goal of this contract effort was to begin extending the Cooperative Intelligent Real-Time Control Architecture (CIRCA) with abilities to automatically ... Http://www.stormingmedia.us/74/7471/A747124.html Visitada Noviembre 2006 •

[39]

Homer keeps an agent time, which is the number of seconds

elapsed since 1-JAN-1900; The agent time factor can be altered, causing agent time to pass faster ... http://ai.eecs.umich.edu/cogarch3/Homer/Homer_AgentTime.html Visitada: Noviembre 2006 •

[42]

EKSL Research: Phoenix - The Phoenix agent architecture

includes several innovative features that support adaptable planning under realtime constraints, ...

vi

http://eksl.cs.umass.edu/research/phoenix.html Visitada Octubre 2006 •

[43]

Agent Architectures -Comparisons with Other Systems; BB1 as an

Agent Architecture ... Definitions in PRODIGY; Hypotheses of PRODIGY; PRODIGY as an Integrated Architecture ... http://www.cs.dartmouth.edu/~brd/Teaching/AI/Lectures/Summaries/architectures.ht ml Visitada Noviembre 2006 •

[44]

Procedural Reasoning System User's Guide Each agent has the

basic architecture described in Figure 1.1, with its own set of ACTs ... Research on procedural reasoning systems. Final Report, Phase 1, ... http://www.ai.sri.com/~prs/prs-manual.pdf Visitada Octubre 2006 •

[45]

Soar: Home We intend ultimately to enable the Soar architecture

to:. work on the full range of tasks expected of an intelligent agent, from highly routine to extremely ... http://ai.eecs.umich.edu/soar/ Visitada octubre 2006

REFERENCIAS DE CONTACTOS Simon. : [email protected] http://labs.bt.com/projects/agents/zeus/ creadores de la herramienta Zeus

vii

viii

ANEXO I Documentación generada por ingenias IDE

Specification Diagrams are: o

Project     

Diagram name: Agent Rol asosiacion type : AgentModel Diagram name: Ojetivos y tareas type : TasksAndGoalsModel Diagram name: modelo de interaccion type : InteractionModel Diagram name: flujo de evento type : InteractionModel Diagram name: Ambiente type : EnvironmentModel

Document generated automatically with the Ingenias Development Kit IDE 2.1

Diagram name : Agent Rol asosiacion Diagram type : AgentModel Description :

1

Entities appearing in this diagram :

NAME Postor

TYPE Agent

Subastador Agent

Vender

Compar

Role

Role

DESCRIPTION It appears in diagrams:

• •

Agent Rol asosiacion: AgentModel Ojetivos y tareas: TasksAndGoalsModel

•

Ambiente: EnvironmentModel

It appears in diagrams:

• •

Agent Rol asosiacion: AgentModel Ojetivos y tareas: TasksAndGoalsModel

•

Ambiente: EnvironmentModel

It appears in diagrams:

• •

Agent Rol asosiacion: AgentModel modelo de interaccion: InteractionModel

•

flujo de evento: InteractionModel

It appears in diagrams:

• •

Agent Rol asosiacion: AgentModel modelo de interaccion: InteractionModel

•

flujo de evento: InteractionModel

Relationships appearing in this diagram:

WFPlays WFPlays WFPlays WFPlays

TYPE Postor Vender Vender Postor

SOURCE TARGET Compar Subastador Subastador Compar

Diagram name : Ojetivos y tareas Diagram type : TasksAndGoalsModel Description :

2

Entities appearing in this diagram :

NAME TYPE Maximizar precio Goal

DESCRIPTION It appears in diagrams:

•

Pujar bajo

Suba precio

Postor

Subastador

Goal

Goal

Agent

Agent

Minimizar precio Goal

Ojetivos y tareas: TasksAndGoalsModel

It appears in diagrams:

•

Ojetivos y tareas: TasksAndGoalsModel

•

flujo de evento: InteractionModel

It appears in diagrams:

•

Ojetivos y tareas: TasksAndGoalsModel

•

flujo de evento: InteractionModel

It appears in diagrams:

• •

Agent Rol asosiacion: AgentModel Ojetivos y tareas: TasksAndGoalsModel

•

Ambiente: EnvironmentModel

It appears in diagrams:

• •

Agent Rol asosiacion: AgentModel Ojetivos y tareas: TasksAndGoalsModel

•

Ambiente: EnvironmentModel

It appears in diagrams:

•

Ojetivos y tareas: TasksAndGoalsModel

Relationships appearing in this diagram:

3

Contribute GTPursues Contribute GTPursues Contribute GTPursues GTPursues Contribute

TYPE Suba precio Postor Pujar bajo Suba precio Suba precio Postor Suba precio Pujar bajo

SOURCE TARGET Maximizar precio Pujar bajo Minimizar precio Subastador Maximizar precio Pujar bajo Subastador Minimizar precio

Diagram name : modelo de interaccion Diagram type : InteractionModel Description :

Entities appearing in this diagram :

NAME Vender

TYPE Role

DESCRIPTION It appears in diagrams:

• •

4

Agent Rol asosiacion: AgentModel modelo de interaccion:

InteractionModel •

UMLSpecification22 UMLSpecification

It appears in diagrams:

•

Subasta en ejecucion Interaction

Role

modelo de interaccion: InteractionModel

It appears in diagrams:

•

Compar

flujo de evento: InteractionModel

modelo de interaccion: InteractionModel

It appears in diagrams:

• •

Agent Rol asosiacion: AgentModel modelo de interaccion: InteractionModel

•

flujo de evento: InteractionModel

Relationships appearing in this diagram:

IInitiates IHasSpec IHasSpec IInitiates IInitiates IInitiates

TYPE Subasta en ejecucion Subasta en ejecucion Subasta en ejecucion Subasta en ejecucion Subasta en ejecucion Subasta en ejecucion

SOURCE TARGET Vender UMLSpecification22 UMLSpecification22 Vender Compar Compar

Diagram name : flujo de evento Diagram type : InteractionModel Description :

5

Entities appearing in this diagram :

NAME informar venta

TYPE MessagePassing

DESCRIPTION It appears in diagrams:

•

Vender

Compar

Role

Role

informar compra MessagePassing

It appears in diagrams:

• •

Agent Rol asosiacion: AgentModel modelo de interaccion: InteractionModel

•

flujo de evento: InteractionModel

It appears in diagrams:

• •

Agent Rol asosiacion: AgentModel modelo de interaccion: InteractionModel

•

flujo de evento: InteractionModel

It appears in diagrams:

•

Suba precio

Goal

flujo de evento: InteractionModel

flujo de evento: InteractionModel

It appears in diagrams:

•

Ojetivos y tareas: TasksAndGoalsModel

•

flujo de evento: InteractionModel

Comprar articulo Task

It appears in diagrams:

Pujar bajo

It appears in diagrams:

•

Goal

•

flujo de evento: InteractionModel Ojetivos y tareas: TasksAndGoalsModel

6

•

flujo de evento: InteractionModel

Comienza subasta Interaction

It appears in diagrams:

vender articulo

It appears in diagrams:

•

Task

•

flujo de evento: InteractionModel flujo de evento: InteractionModel

Relationships appearing in this diagram:

UIPrecedes UIInitiates GTPursues UIInitiates UIInitiates GTPursues UIInitiates UIPrecedes GTPursues UIInitiates GTPursues UIPrecedes UIPrecedes UIInitiates

TYPE Comienza subasta vender articulo Suba precio vender articulo Compar Compar Compar informar compra Suba precio Compar Compar informar compra Comienza subasta vender articulo

SOURCE informar venta Vender Vender Vender Comprar articulo Pujar bajo Comprar articulo Comienza subasta Vender Comprar articulo Pujar bajo Comienza subasta informar venta Vender

Diagram name : Ambiente Diagram type : EnvironmentModel Description :

7

TARGET informar venta informar venta informar compra informar compra

informar compra

informar venta

Entities appearing in this diagram :

NAME TYPE SubastaEnvironment EnvironmentApplication

DESCRIPTION It appears in diagrams:

•

Postor

It appears in diagrams:

Agent

• •

•

Articulos

Agent Rol asosiacion: AgentModel Ojetivos y tareas: TasksAndGoalsModel Ambiente: EnvironmentModel

Resource

It appears in diagrams:

Agent

It appears in diagrams:

•

Subastador

Ambiente: EnvironmentModel

• •

•

Ambiente: EnvironmentModel Agent Rol asosiacion: AgentModel Ojetivos y tareas: TasksAndGoalsModel Ambiente: EnvironmentModel

Relationships appearing in this diagram:

ApplicationBelongsTo ApplicationBelongsTo ApplicationBelongsTo EResourceBelongsTo

TYPE SubastaEnvironment Postor Postor Articulos

8

SOURCE TARGET Subastador SubastaEnvironment SubastaEnvironment Subastador

EResourceBelongsTo Articulos Subastador ApplicationBelongsTo SubastaEnvironment Subastador

9

ANEXO II Codigo fuente de JADE Para poder trabajar con jade previamente instalado, desde consola de comados tipear lo siguiente: java -classpath .;../../lib/jade.jar;../../lib/jadeTools.jar;../../lib/iiop.jar;../../lib/commonscodec/commons-codec-1.3.jar jade.Boot %1 %2 %3 %4 %5 %6 %7 %8 %9 -gui pizarra:subasta.pizarra comprador1:subasta.comprador(4500.0) comprador2:subasta.comprador(3600.0) comprador3:subasta.comprador(3550.0) vendedor1:subasta.vendedor(SAMSUNG 2500.0 IBM 2000.0 HACER 2200.0 CLON 1500.0)

A continuación el código fuente, cuenta con 7 clases: • Agente.java • Compredor.java • Vendedor.java • Oferta.java • Pizarra.java • intefazPizarra.java • contraOferta.java

10

•

Agente.java

package subasta; public class Agente { static int consecutivo=0; public static int TIPO_COMPRADOR=1; public static int TIPO_VENDEDOR=2; public static int TIPO_PIZARRA=3; private private private private

int numero; int tipo; //Comprador-Vendedor-Pizarra String nombre=""; Double precioBase;

/** Creates a new instance of Agente */ public Agente() { this.numero = consecutivo++; } /** * Crea un objeto de tipo Agente * @param int tipo tipo de agente que se llama * @param String nombre nombre caracteristoco del agente * @param Double precioBase precio con el cual se comensara la subasta de un artiulo */ public Agente(int tipo, String nombre, Double precioBase){ this.numero=consecutivo++; this.tipo=tipo; this.nombre=nombre; this.precioBase=precioBase; } public int getTipo(){ return this.tipo; } public void setTipo(int tipo){ this.tipo=tipo; } public String getNombre(){ return this.nombre; } public void setNombre(String nombre){

11

}

this.nombre=nombre;

public Double getPrecioBase(){ return this.precioBase; } public void setPrecioBase(Double precioBase){ this.precioBase=precioBase; } } Oferta.java /***************************************************************** Esta clase se utiliza de platilla para las ofertas *****************************************************************/ package subasta; public class oferta { Long ID_oferta; String oferente; String producto; Float precio; oferta(Long ID, String ofte, String pdto, Float prc){ ID_oferta = ID; oferente = ofte; producto = pdto; precio = prc; } public Long getID_oferta(){ return ID_oferta; } public String getOferente(){ return oferente; } public String getProducto(){ return producto; } public Float getPrecio(){ return precio; } public void setID_oferta(Long ID){ ID_oferta = ID; }

12

public String toString(){ return ID_oferta.toString() + " " + oferente + " " + producto + " " + precio.toString(); } }

Contraoferta.java /***************************************************************** Esta clase se utiliza de platilla para las ofertas *****************************************************************/ package subasta; public class contraOferta { Long ID_oferta; String oferente; String producto; Float precio; contraOferta() { ID_oferta = new Long(-1); oferente = ""; producto = ""; precio = new Float(0); } contraOferta(Long ID, String ofte, String pdto, Float prc) { ID_oferta = ID; oferente = ofte; producto = pdto; precio = prc; } public Long getID_oferta() { return ID_oferta; } public String getOferente() {

13

return oferente; } public String getProducto() { return producto; } public Float getPrecio() { return precio; } public void setID_oferta(Long ID) { ID_oferta = ID; } public String toString() { return ID_oferta.toString() + " " + oferente + " " + producto + " " + precio.toString(); } }

Comprador.java /***************************************************************** Este agente implementa la funcionalidad de un comprador en un proceso de subasta tipo americana *****************************************************************/ package subasta; import java.util.*; import import import import import import import

java.io.StringReader; java.io.OutputStreamWriter; java.io.BufferedWriter; java.io.BufferedReader; java.io.InputStreamReader; java.io.InterruptedIOException; java.io.IOException; 14

import java.io.PrintWriter; import java.lang.Math; import jade.core.*; import jade.core.behaviours.*; import jade.lang.acl.ACLMessage; import import import import import import

jade.domain.FIPAAgentManagement.ServiceDescription; jade.domain.FIPAAgentManagement.DFAgentDescription; jade.domain.FIPAAgentManagement.SearchConstraints; jade.domain.DFService; jade.domain.FIPAException; jade.domain.FIPANames;

public class comprador extends Agent { AID agentePizarra; // Identificador de la pizarra de ofertas Float precioCompraBase; Float precioActual; // *********************************************************************** *****// protected Float getPrecioCompraBase() { return precioCompraBase; } protected void setPrecioCompraBase(Float p) { precioCompraBase = p; } // *********************************************************************** *****// /** * El comportamiento mas fácil de usar es CyclicBehaviour pues ejecuta una * tarea de forma cíclica, deteniendola algunos segundos si asi se le 15

* indica. El segmento de código para ejecutar un comportamiento cícliclo */ class RecibirMensajesBehaviour extends CyclicBehaviour { AID emisor; String contenido = ""; StringTokenizer cadenaTexto; public RecibirMensajesBehaviour(Agent a) { super(a); } /** * Un agente que desee enviar un mensaje deberá crear un nuevo objeto * ACLMessage, rellenar sus atributos con valores apropiados y * finalmente llamar al método Agent.send() (receive() o * blockingReceive() en caso de esperar por algún mensaje). */ public void action() { ACLMessage mensajeEntrante = blockingReceive(); ACLMessage mensajeSaliente = mensajeEntrante.createReply(); if (mensajeEntrante != null && mensajeEntrante.getPerformative() == ACLMessage.INFORM && mensajeEntrante.getProtocol() == FIPANames.InteractionProtocol.FIPA_ENGLISH_AUCTION) { if (mensajeEntrante.getContent().equals("inicio de subasta")) { System.out.println(getLocalName() + "-> Recibiendo mensaje de inicio de subasta"); }

16

else if (mensajeEntrante.getContent().indexOf("fin de subasta") != -1) { System.out.println(getLocalName() + "-> " + mensajeEntrante.getContent()); inicializar(); } else { System.out.println(getLocalName() + "-> Recibiendo oferta: " + mensajeEntrante.getContent()); contenido = mensajeEntrante.getContent(); cadenaTexto = new StringTokenizer(contenido); oferta ofta = new oferta(new Long(cadenaTexto.nextToken()), cadenaTexto.nextToken(), cadenaTexto.nextToken(), new Float(cadenaTexto.nextToken())); // Si va ganando no aumenta el precio if (ofta.getOferente().equals(getLocalName())) { precioActual = ofta.getPrecio(); } else if (ofta.getPrecio() <= getPrecioCompraBase()) { precioActual = new Float(ofta.getPrecio() + Math.random() * 100); } contraOferta cOfta = new contraOferta(ofta.getID_oferta(),

17

getLocalName(), ofta.getProducto(), precioActual); mensajeSaliente.setPerformative(ACLMessage.PROPOSE); mensajeSaliente . setProtocol(FIPANames.InteractionProtocol.FIPA_ENGLISH_AUCTION); mensajeSaliente.setContent(cOfta.toString()); send(mensajeSaliente); } } } } // Fin de la clase RecibirMensajesBehaviour // *********************************************************************** *****// /** * Clase OneShotBehaviour Esta clase modela tareas atómicas y que deben ser * ejecutadas solamente una vez y no pueden ser bloqueadas. De esta manera * sumétodo done() devuelve siempre true. */ class EnviarRegistroBehaviour extends OneShotBehaviour {// OneShotBehaviour: // Sólo se registra // una vez Agent agenteSolicitante; public EnviarRegistroBehaviour(Agent a) { super(a); agenteSolicitante = a; } public void action() { // Busca el agente que presta el servicio de pizarra 18

try { // Se construye la descripcion usada como plantilla para la // busqueda DFAgentDescription template = new DFAgentDescription(); ServiceDescription templateSD = new ServiceDescription(); templateSD.setType("mecanismo de subasta"); template.addServices(templateSD); // Solo se desea recibir un resultado a lo sumo SearchConstraints SC = new SearchConstraints(); SC.setMaxResults(new Long(1)); DFAgentDescription[] resultados = DFService.search( agenteSolicitante, template, SC); if (resultados.length == 1) { DFAgentDescription dfd = resultados[0]; agentePizarra = dfd.getName(); System.out.println(getLocalName() + "-> Encontro el agente de pizarra: " + agentePizarra.getName()); } else { System.out.println(getLocalName() + "-> No se econtro el servicio de pizarra"); } } catch (FIPAException fe) { fe.printStackTrace(); } // Manda el mensaje de registro ACLMessage mensajeRegistro = new ACLMessage(ACLMessage.SUBSCRIBE); mensajeRegistro.setContent("comprador"); mensajeRegistro . setProtocol(FIPANames.InteractionProtocol.FIPA_SUBSCRIBE); mensajeRegistro.addReceiver(agentePizarra); send(mensajeRegistro); 19

ACLMessage mensajeRespuesta = blockingReceive(); if (mensajeRespuesta != null) { if (mensajeRespuesta.getProtocol() == FIPANames.InteractionProtocol.FIPA_SUBSCRIBE && mensajeRespuesta.getPerformative() == ACLMessage.CONFIRM) {// Mensaje // de // confirmación System.out.println(getLocalName() + "-> Se ha registrado correctamente"); } else if (mensajeRespuesta.getProtocol() == FIPANames.InteractionProtocol.FIPA_SUBSCRIBE && mensajeRespuesta.getPerformative() == ACLMessage.DISCONFIRM) { System.out.println(getLocalName() + "-> No pudo registrarse"); } } } } // Fin de la clase RecibirMensajesBehaviour // *********************************************************************** *****// private void inicializar() { Object[] args = getArguments();// recibe los argumentos if (args != null && args.length > 0) { setPrecioCompraBase(new Float(args[0].toString())); } } /**

20

* La clase Agent proporciona dos métodos: addBehaviour(Behaviour) y * removeBehabiour(Behaviour), que permiten gestionar la cola de tareas de * un agente específico añadiendo o eliminando tareas de ella. Obsérvese que * las tareas y subtareas se pueden añadir en el momento en que sean * necesarias y no solo dentro del método Agent.setup(). * */ protected void setup() { System.out.println(getLocalName() + "-> Registrando el servicio: comprador"); inicializar(); // Registrar el servicio try { // Se crea una lista de servicios de agente DFAgentDescription dfd = new DFAgentDescription(); dfd.setName(getAID()); // Se crea una descripcion de servicio ServiceDescription sd = new ServiceDescription(); sd.setName("comprador"); // Se define el tipo de servicio sd.setType("agente del mercado"); // Se define la ontología de los agentes que utilizaran el servicio sd.addOntologies("comercio"); // Se agrega el servicio a la lista de servicios dfd.addServices(sd); DFService.register(this, dfd); } catch (FIPAException fe) { fe.printStackTrace(); }

21

// Se crea un comportamiento para el recibir registros y ofertas de los // participantes EnviarRegistroBehaviour ERBehaviour = new EnviarRegistroBehaviour(this); RecibirMensajesBehaviour RMBehaviour = new RecibirMensajesBehaviour( this); addBehaviour(ERBehaviour); addBehaviour(RMBehaviour); } } Vendedor.java /***************************************************************** Este agente implementa la funcionalidad de un comprador en un proceso de subasta tipo americana *****************************************************************/ package subasta; import java.util.*; import import import import import import import import import

java.io.StringReader; java.io.OutputStreamWriter; java.io.BufferedWriter; java.io.BufferedReader; java.io.InputStreamReader; java.io.InterruptedIOException; java.io.IOException; java.io.PrintWriter; java.lang.*;

import jade.core.*; import jade.core.behaviours.*; import jade.lang.acl.ACLMessage; import jade.domain.FIPAAgentManagement.ServiceDescription; import jade.domain.FIPAAgentManagement.DFAgentDescription; 22

import import import import import

jade.domain.FIPAAgentManagement.SearchConstraints; jade.domain.DFService; jade.domain.FIPAException; jade.domain.FIPANames; subasta.*;

public class vendedor extends Agent { int actual = 0; AID agentePizarra; // Identificador de la pizarra de ofertas String producto[]; // Nombre del producto a ofrecer Float precioVentaBase[]; // Precio minimo de venta int numeroOfertas = 0; //********************************************************************* *******// protected String getProducto(){ return producto[actual]; } protected void setProducto(String[] pdtos){ producto = new String[(pdtos.length / 2)]; precioVentaBase = new Float[(pdtos.length / 2)]; for(int i = 0, k = 0; i < pdtos.length; i += 2, k++){ producto[k] = pdtos[i]; precioVentaBase[k] = new Float(pdtos[i + 1]); } } protected Float getPrecioVentaBase(){ return precioVentaBase[actual]; } //********************************************************************* *******// class RecibirMensajesBehaviour extends CyclicBehaviour { 23

AID emisor; String contenido = ""; public RecibirMensajesBehaviour(Agent a) { super(a); } public void action() { ACLMessage mensajeEntrante = blockingReceive(); ACLMessage mensajeSaliente = mensajeEntrante.createReply(); if(mensajeEntrante != null && mensajeEntrante.getPerformative()==ACLMessage.INFORM && mensajeEntrante.getProtocol() == FIPANames.InteractionProtocol.FIPA_ENGLISH_AUCTION && mensajeEntrante.getContent().equals("inicio de subasta")){ System.out.println(getLocalName() + "-> Recibiendo mensaje de inicio de subasta"); if(actual < producto.length){ mensajeSaliente.setPerformative(ACLMessage.INFORM); Float precio = new Float(getPrecioVentaBase()+Math.random()*50); oferta ofta = new oferta(new Long(numeroOfertas),getLocalName(),getProducto(),precio); mensajeSaliente.setContent(ofta.toString()); mensajeSaliente.setProtocol(FIPANames.InteractionProtocol.FIPA_ENGL ISH_AUCTION); send(mensajeSaliente); numeroOfertas++; } else{ mensajeSaliente.setPerformative(ACLMessage.DISCONFIRM); mensajeSaliente.setContent("SE ME ACABARON LOS PRODUCTOS");

24

mensajeSaliente.setProtocol(FIPANames.InteractionProtocol.FIPA_ENGL ISH_AUCTION); send(mensajeSaliente); } } if(mensajeEntrante != null && mensajeEntrante.getPerformative()==ACLMessage.DISCONFIRM && mensajeEntrante.getProtocol() == FIPANames.InteractionProtocol.FIPA_ENGLISH_AUCTION){ System.out.println(getLocalName() + "-> " + mensajeEntrante.getContent()); } if(mensajeEntrante != null && mensajeEntrante.getPerformative()==ACLMessage.INFORM && mensajeEntrante.getProtocol() == FIPANames.InteractionProtocol.FIPA_ENGLISH_AUCTION && mensajeEntrante.getContent().indexOf("fin de subasta") != -1){ System.out.println(getLocalName() + "-> " + mensajeEntrante.getContent()); actual++; numeroOfertas = 0;

} } } // Fin de la clase RecibirMensajesBehaviour //********************************************************************* *******// class EnviarRegistroBehaviour extends OneShotBehaviour { Agent agenteSolicitante; public EnviarRegistroBehaviour(Agent a) { super(a); agenteSolicitante = a; 25

} public void action() { // Busca el agente que presta el servicio de pizarra try { // Se construye la descripcion usada como plantilla para la busqueda DFAgentDescription template = new DFAgentDescription(); ServiceDescription templateSD = new ServiceDescription(); templateSD.setType("mecanismo de subasta"); template.addServices(templateSD); // Solo se desea recibir un resultado a lo sumo SearchConstraints SC = new SearchConstraints(); SC.setMaxResults(new Long(1)); DFAgentDescription[] resultados = DFService.search(agenteSolicitante, template, SC); if (resultados.length == 1) { DFAgentDescription dfd = resultados[0]; agentePizarra = dfd.getName(); System.out.println(getLocalName() + "-> Encontro el agente de pizarra: " + agentePizarra.getName()); } else { System.out.println(getLocalName() + "-> No se econtro el servicio de pizarra"); } } catch (FIPAException fe) { fe.printStackTrace(); } // Manda el mensaje de registro ACLMessage mensajeRegistro = new ACLMessage(ACLMessage.SUBSCRIBE); mensajeRegistro.setProtocol(FIPANames.InteractionProtocol.FIPA_SUBS CRIBE); 26

mensajeRegistro.setContent("vendedor"); mensajeRegistro.addReceiver(agentePizarra); send(mensajeRegistro); ACLMessage mensajeRespuesta = blockingReceive(); if(mensajeRespuesta != null){ if(mensajeRespuesta.getProtocol() == FIPANames.InteractionProtocol.FIPA_SUBSCRIBE && mensajeRespuesta.getPerformative()== ACLMessage.CONFIRM){ System.out.println(getLocalName() + "-> Se ha registrado correctamente"); } else if(mensajeRespuesta.getProtocol() == FIPANames.InteractionProtocol.FIPA_SUBSCRIBE && mensajeRespuesta.getPerformative() == ACLMessage.DISCONFIRM){ System.out.println(getLocalName() + "-> No pudo registrarse"); } } } } // Fin de la clase RecibirMensajesBehaviour //********************************************************************* *******// protected void setup() { System.out.println(getLocalName() + "-> Registrando el servicio: vendedor"); // Le obtienen los parametros del agente Object[] args = getArguments(); if (args != null && args.length > 0 && (args.length) % 2 == 0){ String[] s = new String[args.length]; for(int i = 0; i < args.length; i++){ s[i] = args[i].toString(); //System.out.println(s[i]); 27

} setProducto(s); //setPrecioVentaBase(new Float(args[1].toString())); } for (int i=0; i<args.length; i++){ System.out.println(getLocalName() + "-> Parametro (" + i + "): " + args[i].toString()); } // Registrar el servicio try { // Se crea una lista de servicios de agente DFAgentDescription dfd = new DFAgentDescription(); dfd.setName(getAID()); // Se crea una descripcion de servicio ServiceDescription sd = new ServiceDescription(); sd.setName("vendedor"); // Se define el tipo de servicio sd.setType("agente del mercado"); // Se define la ontología de los agentes que utilizaran el servicio sd.addOntologies("comercio"); // Se agrega el servicio a la lista de servicios dfd.addServices(sd); DFService.register(this, dfd); } catch (FIPAException fe) { fe.printStackTrace(); } // Se crea un comportamiento para el recibir registros y ofertas de los participantes EnviarRegistroBehaviour ERBehaviour = new EnviarRegistroBehaviour(this); RecibirMensajesBehaviour RMBehaviour = new RecibirMensajesBehaviour(this); addBehaviour(ERBehaviour); addBehaviour(RMBehaviour); 28

} } Pizarra.java /***************************************************************** Este agente implementa la funcionalidad de una pizarra en un proceso de subasta tipo americana *****************************************************************/ package subasta; import java.util.*; import import import import import import import import

java.io.StringReader; java.io.OutputStreamWriter; java.io.BufferedWriter; java.io.BufferedReader; java.io.InputStreamReader; java.io.InterruptedIOException; java.io.IOException; java.io.PrintWriter;

import jade.core.*; import jade.core.behaviours.*; import jade.lang.acl.ACLMessage; import import import import import

jade.domain.FIPAAgentManagement.ServiceDescription; jade.domain.FIPAAgentManagement.DFAgentDescription; jade.domain.DFService; jade.domain.FIPAException; jade.domain.FIPANames;

/* *Cuando mande un vendedor: publicar la oferta *Cuando mande un comprador: almacena el numero de contraofertas y en numeroro de pujas *el ej está dado por el nro de pujas * **/ public class pizarra extends Agent { 29

AID[] agentesCompradoresRegistrados = new AID[20]; // Arreglo con los agentes compradores registrados AID[] agentesVendedoresRegistrados = new AID[20]; // Arreglo con los agentes vendedores registrados int numeroAgentesCompradores = 0; // Numero de agentes compradores registrados int numeroAgentesVendedores = 0; // Numero de agentes vendedores registrados oferta[] ofertas = new oferta[20]; // Ofertas para una subasta determinada contraOferta[] contraOfertas = new contraOferta[20]; // Contra ofertas para una subasta determinada int numeroOfertas = 0; // Numero de ofertas en una subasta int numeroContraOfertas = 0; // Numero de contra ofertas en una subasta long tiempoSubasta = 20000; // Duracion de cada subasta (en milisegundos) int numeroMaximoPujas; // Numero maximo de pujas durante una subasta interfazPizarra interfaz = new interfazPizarra(); // Se crea una interfaz para la pizarra boolean iniciada = false; //********************************************************************* *******// class RecibirMensajesBehaviour extends SimpleBehaviour { AID emisor; String contenido = ""; StringTokenizer cadenaTexto; boolean finalizar = false; contraOferta ofertaGanadora = new contraOferta(); contraOferta ofertaActual = new contraOferta(); int numeroPujas; public RecibirMensajesBehaviour(Agent a) { super(a); } public void action() {

30

ACLMessage mensajeEntrante = blockingReceive(1000); if(mensajeEntrante != null && mensajeEntrante.getProtocol() == FIPANames.InteractionProtocol.FIPA_SUBSCRIBE && mensajeEntrante.getPerformative()==ACLMessage.SUBSCRIBE){ contenido = mensajeEntrante.getContent(); ACLMessage mensajeSaliente = mensajeEntrante.createReply(); if (contenido != null && contenido.equals("vendedor")){ emisor = mensajeEntrante.getSender(); System.out.println(getLocalName() + "-> Recibiendo registro de: " + emisor.getName()); mensajeSaliente.setPerformative(ACLMessage.CONFIRM); mensajeSaliente.setProtocol(FIPANames.InteractionProtocol.FIPA_SUBS CRIBE); mensajeSaliente.setContent("registro exitoso en la pizarra de ofertas"); // Se adiciona el agente al vector de agentes registrados agentesVendedoresRegistrados[numeroAgentesVendedores] = emisor; interfaz.adicionarTextoAgentesRegistrados("Agente vendedor: " + agentesVendedoresRegistrados[numeroAgentesVendedores].getLocal Name()); numeroAgentesVendedores++; } else if (contenido != null && contenido.equals("comprador")){ emisor = mensajeEntrante.getSender(); System.out.println(getLocalName() + "-> Recibiendo registro de: " + emisor.getName()); mensajeSaliente.setPerformative(ACLMessage.CONFIRM);

31

mensajeSaliente.setProtocol(FIPANames.InteractionProtocol.FIPA_SUBS CRIBE); mensajeSaliente.setContent("registro exitoso en la pizarra de ofertas"); // Se adiciona el agente al vector de agentes registrados agentesCompradoresRegistrados[numeroAgentesCompradores] = emisor; interfaz.adicionarTextoAgentesRegistrados("Agente comprador: " + agentesCompradoresRegistrados[numeroAgentesCompradores].getLo calName()); numeroAgentesCompradores++; } else{ mensajeSaliente.setPerformative(ACLMessage.DISCONFIRM); mensajeSaliente.setProtocol(FIPANames.InteractionProtocol.FIPA_SUBS CRIBE); mensajeSaliente.setContent("Se esperaba un mensaje de registro"); } send(mensajeSaliente); } if(mensajeEntrante != null && mensajeEntrante.getProtocol() == FIPANames.InteractionProtocol.FIPA_ENGLISH_AUCTION && mensajeEntrante.getPerformative() == ACLMessage.DISCONFIRM){ System.out.println("---SE ACABO LA SUBASTA--"); finalizar = true; } if(mensajeEntrante != null && mensajeEntrante.getProtocol() == 32

FIPANames.InteractionProtocol.FIPA_ENGLISH_AUCTION && mensajeEntrante.getPerformative()==ACLMessage.INFORM){ contenido = mensajeEntrante.getContent(); ACLMessage mensajeSaliente = mensajeEntrante.createReply(); if (contenido != null){ cadenaTexto = new StringTokenizer(contenido); ofertas[numeroOfertas] = new oferta(new Long(cadenaTexto.nextToken()), cadenaTexto.nextToken(), cadenaTexto.nextToken(), new Float(cadenaTexto.nextToken())); ofertas[numeroOfertas].setID_oferta(new Long(numeroOfertas)); emisor = mensajeEntrante.getSender(); System.out.println(getLocalName() + "-> Recibiendo oferta de: " + emisor.getName() + " (" + ofertas[numeroOfertas].toString() +")"); // Se muestra en la interfaz interfaz.adicionarTextoAreaOfertas(ofertas[numeroOfertas].toString());

mensajeSaliente.setProtocol(FIPANames.InteractionProtocol.FIPA_ENGL ISH_AUCTION); mensajeSaliente.setPerformative(ACLMessage.ACCEPT_PROPOSAL); mensajeSaliente.setContent("oferta registrada"); send(mensajeSaliente); numeroOfertas++; // Mandar mensaje a los compradores if (numeroOfertas == numeroAgentesVendedores){ ACLMessage mensajeOfertas = new ACLMessage(ACLMessage.INFORM); 33

mensajeOfertas.setProtocol(FIPANames.InteractionProtocol.FIPA_ENGLI SH_AUCTION); for (int i=0; i
34

cadenaTexto = new StringTokenizer(contenido); contraOfertas[numeroContraOfertas] = new contraOferta(new Long(cadenaTexto.nextToken()), cadenaTexto.nextToken(), cadenaTexto.nextToken(), new Float(cadenaTexto.nextToken())); ofertaActual = contraOfertas[numeroContraOfertas]; emisor = mensajeEntrante.getSender(); System.out.println(getLocalName() + "-> Recibiendo contra oferta de: " + emisor.getName() + " (" + contraOfertas[numeroContraOfertas].toString() +")"); // Se muestra en la interfaz interfaz.adicionarTextoAreaContraOfertas(contraOfertas[numeroContr aOfertas].toString());

mensajeSaliente.setProtocol(FIPANames.InteractionProtocol.FIPA_ENGL ISH_AUCTION); mensajeSaliente.setPerformative(ACLMessage.ACCEPT_PROPOSAL); mensajeSaliente.setContent("contra oferta registrada"); send(mensajeSaliente); if (ofertaActual.getPrecio() > ofertaGanadora.getPrecio()){ ofertaGanadora = ofertaActual; } numeroContraOfertas++; numeroPujas++; // Informar la contra oferta ganadora al final de la subasta //AQUI TERMINA LA SUBASTA if (numeroPujas == numeroMaximoPujas){ iniciada = false; 35

ACLMessage mensajeFinSubasta = new ACLMessage(ACLMessage.INFORM); mensajeFinSubasta.setProtocol(FIPANames.InteractionProtocol.FIPA_EN GLISH_AUCTION); for (int k=0; k
36

if (numeroContraOfertas == numeroAgentesCompradores){ ACLMessage mensajeOfertas = new ACLMessage(ACLMessage.INFORM); mensajeOfertas.setProtocol(FIPANames.InteractionProtocol.FIPA_ENGLI SH_AUCTION); for (int i=0; i Oferta ganadora: " + ofertaGanadora.toString()); for (int j=0; j
37

public boolean done(){ return finalizar; } } // Fin de la clase RecibirMensajesBehaviour //********************************************************************* *******// //INICIO DE SUBASTA public void EnviarInicioSubasta() { //randomize(); numeroOfertas = 0; numeroContraOfertas = 0; numeroMaximoPujas = (int) (Math.random() * 30) + 20; int n = numeroAgentesCompradores + numeroAgentesVendedores; System.out.println(getLocalName() + "-> Numero de pujas: " + numeroMaximoPujas); ACLMessage mensajeInicioSubasta = new ACLMessage(ACLMessage.INFORM); mensajeInicioSubasta.setProtocol(FIPANames.InteractionProtocol.FIPA_ ENGLISH_AUCTION); mensajeInicioSubasta.setContent("inicio de subasta"); for (int i=0; i
38

} // Fin del metodo EnviarInicioSubasta //INICIO DE SUBASTA //********************************************************************* *******// protected void setup() { // Registrar el servicio System.out.println(getLocalName() + "-> Registrando el servicio: pizarra de ofertas"); try { // Se crea una lista de servicios de agente DFAgentDescription dfd = new DFAgentDescription(); dfd.setName(getAID()); // Se crea una descripcion de servicio ServiceDescription sd = new ServiceDescription(); sd.setName("pizarra de ofertas"); // Se define el tipo de servicio sd.setType("mecanismo de subasta"); // Se define la ontología de los agentes que utilizaran el servicio sd.addOntologies("comercio"); // Se agrega el servicio a la lista de servicios dfd.addServices(sd); DFService.register(this, dfd); } catch (FIPAException fe) { fe.printStackTrace(); } // Se muestra la interfaz interfaz.show(); // Se crea un comportamiento para el recibir registros y ofertas de los participantes RecibirMensajesBehaviour RMBehaviour = new RecibirMensajesBehaviour(this);

39

addBehaviour(new TickerBehaviour(this,tiempoSubasta){//reinicia la subasta cada tiempoSubasta protected void onTick(){//para llamar el métodos TickerBehaviour EnviarInicioSubasta(); iniciada = true; //}

} } ); addBehaviour(RMBehaviour); } // Fin del método setup } interfazPizrra.java package subasta; public class interfazPizarra extends javax.swing.JFrame { /** Constructor de la clase interfazPizarra*/ public interfazPizarra() { initComponents(); setLocation(0, 300); } /** * Método llamado con el constructor para inicializar los componentes de la * ventana. */ // <editor-fold defaultstate="collapsed" desc=" Generated Code ">//GEN-BEGIN:initComponents private void initComponents() { java.awt.GridBagConstraints gridBagConstraints; DatosSimulacion = new javax.swing.JTabbedPane(); 40

jPanel5 = new javax.swing.JPanel(); jTextAreaRestricciones = new javax.swing.JTextArea(); jPanel1 = new javax.swing.JPanel(); jLabel4 = new javax.swing.JLabel(); TextAreaAgentesRegistrados = new java.awt.TextArea(); jPanel2 = new javax.swing.JPanel(); jLabel1 = new javax.swing.JLabel(); TextAreaOfertas = new java.awt.TextArea(); jPanel3 = new javax.swing.JPanel(); jLabel2 = new javax.swing.JLabel(); TextAreaContraOfertas = new java.awt.TextArea(); jPanel4 = new javax.swing.JPanel(); jLabel3 = new javax.swing.JLabel(); TextAreaResultados = new java.awt.TextArea(); getContentPane().setLayout(new java.awt.GridBagLayout()); setTitle("Listados"); addWindowListener(new java.awt.event.WindowAdapter() { public void windowClosing(java.awt.event.WindowEvent evt) { closeDialog(evt); } }); DatosSimulacion.setBorder(new javax.swing.border.EtchedBorder()); jPanel5.setLayout(new java.awt.GridBagLayout()); jTextAreaRestricciones.setBackground(new java.awt.Color(255, 255, 234)); jTextAreaRestricciones.setColumns(30); jTextAreaRestricciones.setFont(new java.awt.Font("Arial", 1, 12)); jTextAreaRestricciones.setForeground(new java.awt.Color(0, 0, 153)); jTextAreaRestricciones.setRows(10); //jTextAreaRestricciones.setText("El sistema toma en cuenta las siguientes consideraciones: . "); //jPanel5.add(jTextAreaRestricciones, new java.awt.GridBagConstraints()); // DatosSimulacion.addTab("Restricciones del Sistema", jPanel5); //jPanel1.setLayout(new java.awt.GridBagLayout()); 41

jLabel4.setBackground(new java.awt.Color(255, 255, 204)); jLabel4.setForeground(new java.awt.Color(0, 0, 153)); jLabel4.setText("Los agentes registrados en el sistema son:"); gridBagConstraints = new java.awt.GridBagConstraints(); gridBagConstraints.insets = new java.awt.Insets(0, 0, 7, 0); jPanel1.add(jLabel4, gridBagConstraints); TextAreaAgentesRegistrados.setBackground(new java.awt.Color(255, 255, 255)); TextAreaAgentesRegistrados.setColumns(90); TextAreaAgentesRegistrados.setFont(new java.awt.Font("Dialog", 1, 12)); TextAreaAgentesRegistrados.setRows(20); gridBagConstraints = new java.awt.GridBagConstraints(); gridBagConstraints.gridx = 0; gridBagConstraints.gridy = 1; jPanel1.add(TextAreaAgentesRegistrados, gridBagConstraints); DatosSimulacion.addTab("Agentes Registrados", jPanel1); jPanel2.setLayout(new java.awt.GridBagLayout()); jLabel1.setBackground(new java.awt.Color(255, 255, 204)); jLabel1.setForeground(new java.awt.Color(0, 0, 153)); jLabel1.setText("Las ofertas ingresadas al sistema son:"); gridBagConstraints = new java.awt.GridBagConstraints(); gridBagConstraints.insets = new java.awt.Insets(0, 0, 7, 0); jPanel2.add(jLabel1, gridBagConstraints); TextAreaOfertas.setColumns(90); TextAreaOfertas.setFont(new java.awt.Font("Dialog", 1, 12)); TextAreaOfertas.setRows(20); gridBagConstraints = new java.awt.GridBagConstraints(); gridBagConstraints.gridx = 0; gridBagConstraints.gridy = 1; jPanel2.add(TextAreaOfertas, gridBagConstraints); DatosSimulacion.addTab("Ofertas", jPanel2); jPanel3.setLayout(new java.awt.GridBagLayout()); jLabel2.setBackground(new java.awt.Color(255, 255, 204)); jLabel2.setForeground(new java.awt.Color(0, 0, 153)); 42

jLabel2.setText("Las contraofertas recibidas son:"); gridBagConstraints = new java.awt.GridBagConstraints(); gridBagConstraints.insets = new java.awt.Insets(0, 0, 7, 0); jPanel3.add(jLabel2, gridBagConstraints); TextAreaContraOfertas.setColumns(90); TextAreaContraOfertas.setFont(new java.awt.Font("Dialog", 1, 12)); TextAreaContraOfertas.setRows(20); gridBagConstraints = new java.awt.GridBagConstraints(); gridBagConstraints.gridx = 0; gridBagConstraints.gridy = 1; jPanel3.add(TextAreaContraOfertas, gridBagConstraints); DatosSimulacion.addTab("ContraOfertas", jPanel3); jPanel4.setLayout(new java.awt.GridBagLayout()); jLabel3.setBackground(new java.awt.Color(255, 255, 204)); jLabel3.setForeground(new java.awt.Color(0, 0, 153)); jLabel3.setText("Las Contraofertas que ganaron son:"); gridBagConstraints = new java.awt.GridBagConstraints(); gridBagConstraints.insets = new java.awt.Insets(0, 0, 7, 0); jPanel4.add(jLabel3, gridBagConstraints); TextAreaResultados.setColumns(90); TextAreaResultados.setFont(new java.awt.Font("Dialog", 1, 12)); TextAreaResultados.setRows(20); gridBagConstraints = new java.awt.GridBagConstraints(); gridBagConstraints.gridx = 0; gridBagConstraints.gridy = 1; jPanel4.add(TextAreaResultados, gridBagConstraints); DatosSimulacion.addTab("Resultados Pizarra", jPanel4); getContentPane().add(DatosSimulacion, new java.awt.GridBagConstraints()); pack(); } // //GEN-END:initComponents private void closeDialog(java.awt.event.WindowEvent evt) {//GENFIRST:event_closeDialog 43

setVisible(false); dispose(); }//GEN-LAST:event_closeDialog /** * Permite limpiar las areas de texto asignandoles un caracter vacio... */ public void limpiarAreasTexto(){ TextAreaAgentesRegistrados.setText(""); TextAreaOfertas.setText(""); TextAreaContraOfertas.setText(""); TextAreaResultados.setText(""); } /** * Permite adicionar una linea de texto a la lista de los agentes registrados. */ public void adicionarTextoAgentesRegistrados(String texto){ TextAreaAgentesRegistrados.append(texto+" \n"); } /** * Permite adicionar una linea de texto a la lista de los ofertas. */ public void adicionarTextoAreaOfertas(String texto){ TextAreaOfertas.append(texto+" \n"); } /** * Permite adicionar una linea de texto a la lista de las Contra ofertas. */ public void adicionarTextoAreaContraOfertas(String texto){ TextAreaContraOfertas.append(texto+" \n"); } /** * Permite adicionar una linea de texto a la lista de las restricciones */ public void adicionarTextoAreaRestricciones(String texto){ jTextAreaRestricciones.append(texto+" \n"); } 44

/** * Permite adicionar una linea de texto a la lista de los resultados */ public void adicionarTextoAreaResultados(String texto){ TextAreaResultados.append(texto+" \n"); } // Variables declaration - do not modify//GEN-BEGIN:variables private javax.swing.JTabbedPane DatosSimulacion; private java.awt.TextArea TextAreaAgentesRegistrados; private java.awt.TextArea TextAreaContraOfertas; private java.awt.TextArea TextAreaOfertas; private java.awt.TextArea TextAreaResultados; private javax.swing.JLabel jLabel1; private javax.swing.JLabel jLabel2; private javax.swing.JLabel jLabel3; private javax.swing.JLabel jLabel4; private javax.swing.JPanel jPanel1; private javax.swing.JPanel jPanel2; private javax.swing.JPanel jPanel3; private javax.swing.JPanel jPanel4; private javax.swing.JPanel jPanel5; private javax.swing.JTextArea jTextAreaRestricciones; // End of variables declaration//GEN-END:variables } Algunas impresiones de pantalla de la aplicación en ejecución:

45

ANEXO III Código creado para Zeus postorBot.java /* This software was produced as a part of research activities. It is not intended to be used as commercial or industrial software by any organisation. Except as explicitly stated, no guarantees are given as to its reliability or trustworthiness if used for purposes other than those for which it was originally intended. (c) British Telecommunications plc 1999. */ /*

46

This code was automatically generated by ZeusAgentGenerator version 1.2.2 DO NOT MODIFY!! */ import import import import import import

java.util.*; java.io.*; zeus.util.*; zeus.concepts.*; zeus.actors.*; zeus.agents.*;

public class PostorBot { protected static void version() { System.err.println("ZeusAgent - PostorBot version: 1.2.2"); System.exit(0); } protected static void usage() { System.err.println("Usage: java PostorBot -s -o [-gui ViewerProg] [-e <ExternalProg>] [-r ResourceProg] [-name ] [-debug] [-h] [-v]"); System.exit(0); } public static void main(String[] arg) { try { ZeusAgent agent; String external = null; String dns_file = null; String resource = null; String gui = null; String ontology_file = null; Vector nameservers = null; String name = new String ("PostorBot"); Bindings b = new Bindings("PostorBot"); FileInputStream stream = null; ZeusExternal user_prog = null; for( int j = 0; j < arg.length; j++ ) { if ( arg[j].equals("-s") && ++j < arg.length ) dns_file = arg[j]; else if ( arg[j].equals("-e") && ++j < arg.length ) 47

external = arg[j]; else if ( arg[j].equals("-r") && ++j < arg.length ) resource = arg[j]; else if ( arg[j].equals("-o") && ++j < arg.length ) ontology_file = arg[j]; else if ( arg[j].equals("-gui") && ++j < arg.length ) gui = arg[j]; else if ( arg[j].equals("-debug") ) { Core.debug = true; Core.setDebuggerOutputFile("PostorBot.log"); } else if ( arg[j].equals("-v") ) version(); else if ( arg[j].equals("-name") && ++j < arg.length ) name = name + arg[j]; else if ( arg[j].equals("-h") ) usage(); else usage(); } b = new Bindings(name); if ( ontology_file == null ) { System.err.println("Ontology Database file must be specified with -o option"); usage(); } if ( dns_file == null ) { System.err.println("Domain nameserver file must be specified with -s option"); usage(); } nameservers = ZeusParser.addressList(new FileInputStream(dns_file)); if ( nameservers == null || nameservers.isEmpty() ) throw new IOException(); agent = new ZeusAgent(name,ontology_file,nameservers,1,20,false,false); AgentContext context = agent.getAgentContext(); OntologyDb db = context.OntologyDb();

48

/* Initialising Extensions */ Class c; if ( resource != null ) { c = Class.forName(resource); ExternalDb oracle = (ExternalDb) c.newInstance(); context.set(oracle); oracle.set(context); } if ( gui != null ) { c = Class.forName(gui); ZeusAgentUI ui = (ZeusAgentUI)c.newInstance(); context.set(ui); ui.set(context); } /* Initialising ProtocolDb */ ProtocolInfo info; info = ZeusParser.protocolInfo(db,"(:name \"zeus.actors.graphs.ContractNetRespondent\" :type Respondent :constraints ((:fact (:type ZeusFact :id var182 :modifiers 1) :type 0 :strategy \"zeus.actors.graphs.LinearRespondentEvaluator\" :parameters (\"noquibble.range\" \"0.3\" \"max.percent\" \"125\" \"min.percent\" \"110\"))))"); if ( info.resolve(b) ) agent.addProtocol(info); info = ZeusParser.protocolInfo(db,"(:name \"zeus.actors.graphs.ContractNetInitiator\" :type Initiator :constraints ((:fact (:type ZeusFact :id var180 :modifiers 1) :type 0 :strategy \"zeus.actors.graphs.LinearInitiatorEvaluator\" :parameters (\"noquibble.factor\" \"0.2\" \"max.percent\" \"120\" \"min.percent\" \"70\"))))"); if ( info.resolve(b) ) agent.addProtocol(info); /* Initialising OrganisationalDb */ AbilityDbItem item; 49

/* Initialising ResourceDb */ Fact f1; f1 = ZeusParser.fact(db,"(:type apple :id appleStock :modifiers 0 :attributes ((unit_cost 5)(number 0)))"); if ( f1.resolve(b) ) agent.addFact(f1); f1 = ZeusParser.fact(db,"(:type orange :id orangeStock :modifiers 0 :attributes ((unit_cost 5)(number 0)))"); if ( f1.resolve(b) ) agent.addFact(f1); f1 = ZeusParser.fact(db,"(:type Money :id cash :modifiers 0 :attributes ((amount 500)))"); if ( f1.resolve(b) ) agent.addFact(f1); /* Initialising External User Program */ if ( external != null ) { c = Class.forName(external); user_prog = (ZeusExternal) c.newInstance(); context.set(user_prog); } /* Activating External User Program */ if ( user_prog != null ) user_prog.exec(context); } catch (ClassNotFoundException cnfe) { System.out.println("Java cannot find some of the classes that are needed to run this agent. Please ensure that you have the followingin your classpath : zeus_install_dir\\lib\\zeus.jar, zeus_install_dir\\lib\\gnuregexp.jar, java_install_dir\\jre\\rt.jar Where zeus_install_dir is the directory that you have installed Zeus in , and java_install_dir is the directory that you have installed Java in"); 50

cnfe.printStackTrace();} catch(Exception e) { e.printStackTrace(); } } } postorUI.java /********************************************************************** ******* * postorUI.java * * Interface between ShopBot and its TraderFrontEnd GUI *********************************************************************** ******/ import zeus.actors.*; import zeus.agents.*; public class postorUI implements ZeusExternal { public void exec(AgentContext agent) { TraderFrontEnd thiswin = new TraderFrontEnd(agent); } public void showMsg(String message) { } public static void main(String[] args) { postorUI win = new postorUI(); win.exec(null); } } StockPanel.java /********************************************************************** ******* * StockPanel.java * Jaron Collis ([email protected]), March 1999 51

* Provides an example of how to interact with agent resources *********************************************************************** ******/ import import import import import import

java.util.*; java.awt.*; java.awt.event.*; java.io.*; javax.swing.*; javax.swing.border.*;

import import import import import

zeus.util.*; zeus.concepts.*; zeus.actors.*; zeus.actors.event.*; zeus.concepts.fn.*;

public class StockPanel extends JPanel implements FactMonitor, ActionListener { protected JLabel appleLabel = new JLabel(); protected JLabel orangeLabel = new JLabel(); protected JLabel pearLabel = new JLabel(); protected JLabel bananaLabel = new JLabel(); protected JLabel melonLabel = new JLabel(); protected protected protected protected protected protected protected

JButton moreApplesBtn; JButton moreOrangesBtn; JButton morePearsBtn; JButton moreBananasBtn; JButton moreMelonsBtn; JLabel cashLabel; TraderFrontEnd UI;

public StockPanel(TraderFrontEnd frontend) { UI = frontend; GridBagLayout gb = new GridBagLayout(); GridBagConstraints gbc = new GridBagConstraints(); setLayout(gb); setBackground(Color.lightGray); setBorder(BorderFactory.createBevelBorder(BevelBorder.LOWERED)) ; 52

moreApplesBtn = new JButton("Supply"); moreApplesBtn.addActionListener(this); gbc.insets = new Insets(4,8,4,0); gbc.gridwidth = 1; gbc.fill = GridBagConstraints.NONE; gbc.anchor = GridBagConstraints.WEST; gb.setConstraints(appleLabel,gbc); add(appleLabel); gbc.gridwidth = GridBagConstraints.REMAINDER; gbc.fill = GridBagConstraints.NONE; gbc.anchor = GridBagConstraints.EAST; gbc.insets = new Insets(4,16,4,8); gb.setConstraints(moreApplesBtn, gbc); add(moreApplesBtn); moreOrangesBtn = new JButton("Supply"); moreOrangesBtn.addActionListener(this); gbc.insets = new Insets(4,8,4,0); gbc.gridwidth = 1; gbc.fill = GridBagConstraints.NONE; gbc.anchor = GridBagConstraints.WEST; gb.setConstraints(orangeLabel,gbc); add(orangeLabel); gbc.gridwidth = GridBagConstraints.REMAINDER; gbc.fill = GridBagConstraints.NONE; gbc.anchor = GridBagConstraints.EAST; gbc.insets = new Insets(4,16,4,8); gb.setConstraints(moreOrangesBtn, gbc); add(moreOrangesBtn); morePearsBtn = new JButton("Supply"); morePearsBtn.addActionListener(this); gbc.insets = new Insets(4,8,4,0); gbc.gridwidth = 1; gbc.fill = GridBagConstraints.NONE; gbc.anchor = GridBagConstraints.WEST; gb.setConstraints(pearLabel,gbc); add(pearLabel); 53

gbc.gridwidth = GridBagConstraints.REMAINDER; gbc.fill = GridBagConstraints.NONE; gbc.anchor = GridBagConstraints.EAST; gbc.insets = new Insets(4,16,4,8); gb.setConstraints(morePearsBtn, gbc); add(morePearsBtn); moreBananasBtn = new JButton("Supply"); moreBananasBtn.addActionListener(this); gbc.insets = new Insets(4,8,4,0); gbc.gridwidth = 1; gbc.fill = GridBagConstraints.NONE; gbc.anchor = GridBagConstraints.WEST; gb.setConstraints(bananaLabel,gbc); add(bananaLabel); gbc.gridwidth = GridBagConstraints.REMAINDER; gbc.fill = GridBagConstraints.NONE; gbc.anchor = GridBagConstraints.EAST; gbc.insets = new Insets(4,16,4,8); gb.setConstraints(moreBananasBtn, gbc); add(moreBananasBtn); moreMelonsBtn = new JButton("Supply"); moreMelonsBtn.addActionListener(this); gbc.insets = new Insets(4,8,4,0); gbc.gridwidth = 1; gbc.fill = GridBagConstraints.NONE; gbc.anchor = GridBagConstraints.WEST; gb.setConstraints(melonLabel,gbc); add(melonLabel); gbc.gridwidth = GridBagConstraints.REMAINDER; gbc.fill = GridBagConstraints.NONE; gbc.anchor = GridBagConstraints.EAST; gbc.insets = new Insets(4,16,4,8); gb.setConstraints(moreMelonsBtn, gbc); add(moreMelonsBtn); Fact[] tmp = UI.agent.ResourceDb().all(OntologyDb.MONEY); double cash = 0; 54

for(int i = 0; i < tmp.length; i++ ) { tmp[i].resolve(new Bindings()); PrimitiveNumericFn numFn = (PrimitiveNumericFn)tmp[i].getFn(OntologyDb.AMOUNT); cash += numFn.doubleValue(); } cashLabel = new JLabel("Bank Balance: " + Misc.decimalPlaces(cash,2)); cashLabel.setFont(new Font("Helvetica",Font.PLAIN, 12)); gbc.insets = new Insets(4,8,4,0); gbc.gridwidth = 1; gbc.fill = GridBagConstraints.NONE; gbc.anchor = GridBagConstraints.WEST; gb.setConstraints(cashLabel, gbc); add(cashLabel); UI.agent.ResourceDb().addFactMonitor(this, FactEvent.ADD_MASK|FactEvent.DELETE_MASK, true); } protected void update(Fact f) { Fact[] tmp = UI.agent.ResourceDb().all(f.getType()); int num = 0; for(int i = 0; i < tmp.length; i++ ) num += tmp[i].getNumber(); if (f.getType().equals("apple")) appleLabel.setText("Boxes of apples in stock: " + num); else if (f.getType().equals("orange")) orangeLabel.setText("Boxes of oranges in stock: " + num); else if (f.getType().equals("pear")) pearLabel.setText("Boxes of pears in stock: " + num); else if (f.getType().equals("banana")) bananaLabel.setText("Boxes of bananas in stock: " + num); else if (f.getType().equals("melon")) melonLabel.setText("Boxes of melons in stock: " + num); } public void actionPerformed(ActionEvent evt) { String fruit = null; if (evt.getSource() == moreApplesBtn) 55

fruit = "apple"; if (evt.getSource() == fruit = "orange"; if (evt.getSource() == fruit = "pear"; if (evt.getSource() == fruit = "banana"; if (evt.getSource() == fruit = "melon";

moreOrangesBtn) morePearsBtn) moreBananasBtn) moreMelonsBtn)

UI.display("A box of " + fruit + "s arrives."); Fact[] tmp = UI.agent.ResourceDb().all(fruit); if ( tmp.length > 0 ) { Fact f2 = new Fact(tmp[0]); int no = f2.getNumber(); f2.setNumber(++no); UI.agent.ResourceDb().modify(tmp[0], f2); } } public void factAddedEvent(FactEvent event) { Fact fact = event.getFact(); if ( fact.getType().equals(OntologyDb.MONEY) ) { Fact[] tmp = UI.agent.ResourceDb().all(OntologyDb.MONEY); double cash = 0; for(int i = 0; i < tmp.length; i++ ) { tmp[i].resolve(new Bindings()); PrimitiveNumericFn numFn = (PrimitiveNumericFn)tmp[i].getFn(OntologyDb.AMOUNT); cash += numFn.doubleValue(); } cashLabel.setText("Bank Balance: " + Misc.decimalPlaces(cash,2)); } else update(fact); } public void factModifiedEvent(FactEvent event) {} // kill this? public void factAccessedEvent(FactEvent event) {} public void factDeletedEvent(FactEvent event) { Fact fact = event.getFact(); if ( fact.getType().equals(OntologyDb.MONEY) ) { 56

Fact[] tmp = UI.agent.ResourceDb().all(OntologyDb.MONEY); double cash = 0; for(int i = 0; i < tmp.length; i++ ) { tmp[i].resolve(new Bindings()); PrimitiveNumericFn numFn = (PrimitiveNumericFn)tmp[i].getFn(OntologyDb.AMOUNT); cash += numFn.doubleValue(); } cashLabel.setText("Bank Balance: " + Misc.decimalPlaces(cash,2)); } else update(fact); } } SubasradorBot.java /* This software was produced as a part of research activities. It is not intended to be used as commercial or industrial software by any organisation. Except as explicitly stated, no guarantees are given as to its reliability or trustworthiness if used for purposes other than those for which it was originally intended. (c) British Telecommunications plc 1999. */ /* This code was automatically generated by ZeusAgentGenerator version 1.2.2 DO NOT MODIFY!! */ import import import import import import

java.util.*; java.io.*; zeus.util.*; zeus.concepts.*; zeus.actors.*; zeus.agents.*;

public class SubasradorBot { protected static void version() { 57

System.err.println("ZeusAgent - SubasradorBot version: 1.2.2"); System.exit(0); } protected static void usage() { System.err.println("Usage: java SubasradorBot -s -o [-gui ViewerProg] [-e <ExternalProg>] [-r ResourceProg] [-name ] [-debug] [-h] [-v]"); System.exit(0); } public static void main(String[] arg) { try { ZeusAgent agent; String external = null; String dns_file = null; String resource = null; String gui = null; String ontology_file = null; Vector nameservers = null; String name = new String ("SubasradorBot"); Bindings b = new Bindings("SubasradorBot"); FileInputStream stream = null; ZeusExternal user_prog = null; for( int j = 0; j < arg.length; j++ ) { if ( arg[j].equals("-s") && ++j < arg.length ) dns_file = arg[j]; else if ( arg[j].equals("-e") && ++j < arg.length ) external = arg[j]; else if ( arg[j].equals("-r") && ++j < arg.length ) resource = arg[j]; else if ( arg[j].equals("-o") && ++j < arg.length ) ontology_file = arg[j]; else if ( arg[j].equals("-gui") && ++j < arg.length ) gui = arg[j]; else if ( arg[j].equals("-debug") ) { Core.debug = true; Core.setDebuggerOutputFile("SubasradorBot.log"); } else if ( arg[j].equals("-v") ) version(); else if ( arg[j].equals("-name") && ++j < arg.length ) 58

name = name + arg[j]; else if ( arg[j].equals("-h") ) usage(); else usage(); } b = new Bindings(name); if ( ontology_file == null ) { System.err.println("Ontology Database file must be specified with -o option"); usage(); } if ( dns_file == null ) { System.err.println("Domain nameserver file must be specified with -s option"); usage(); } nameservers = ZeusParser.addressList(new FileInputStream(dns_file)); if ( nameservers == null || nameservers.isEmpty() ) throw new IOException(); agent = new ZeusAgent(name,ontology_file,nameservers,1,20,false,false); AgentContext context = agent.getAgentContext(); OntologyDb db = context.OntologyDb(); /* Initialising Extensions */ Class c; if ( resource != null ) { c = Class.forName(resource); ExternalDb oracle = (ExternalDb) c.newInstance(); context.set(oracle); oracle.set(context); } if ( gui != null ) { c = Class.forName(gui); 59

ZeusAgentUI ui = (ZeusAgentUI)c.newInstance(); context.set(ui); ui.set(context); } /* Initialising ProtocolDb */ ProtocolInfo info; info = ZeusParser.protocolInfo(db,"(:name \"zeus.actors.graphs.ContractNetRespondent\" :type Respondent :constraints ((:fact (:type ZeusFact :id var178 :modifiers 1) :type 0 :strategy \"zeus.actors.graphs.LinearRespondentEvaluator\" :parameters (\"noquibble.factor\" \"0.3\" \"max.percent\" \"125\" \"min.percent\" \"105\"))))"); if ( info.resolve(b) ) agent.addProtocol(info); info = ZeusParser.protocolInfo(db,"(:name \"zeus.actors.graphs.ContractNetInitiator\" :type Initiator :constraints ((:fact (:type ZeusFact :id var176 :modifiers 1) :type 0 :strategy \"zeus.actors.graphs.LinearInitiatorEvaluator\" :parameters (\"noquibble.factor\" \"0.2\" \"max.percent\" \"120\" \"min.percent\" \"70\"))))"); if ( info.resolve(b) ) agent.addProtocol(info); /* Initialising OrganisationalDb */ AbilityDbItem item; /* Initialising ResourceDb */ Fact f1; f1 = ZeusParser.fact(db,"(:type apple :id appleStock :modifiers 0 :attributes ((unit_cost 5)(number 30)))"); if ( f1.resolve(b) ) agent.addFact(f1); f1 = ZeusParser.fact(db,"(:type orange :id orangeStock :modifiers 0 :attributes ((unit_cost 5)(number 30)))"); if ( f1.resolve(b) ) agent.addFact(f1); f1 = ZeusParser.fact(db,"(:type Money :id cash :modifiers 0 :attributes ((amount 500)))"); 60

if ( f1.resolve(b) ) agent.addFact(f1); /* Initialising External User Program */ if ( external != null ) { c = Class.forName(external); user_prog = (ZeusExternal) c.newInstance(); context.set(user_prog); } /* Activating External User Program */ if ( user_prog != null ) user_prog.exec(context); } catch (ClassNotFoundException cnfe) { System.out.println("Java cannot find some of the classes that are needed to run this agent. Please ensure that you have the followingin your classpath : zeus_install_dir\\lib\\zeus.jar, zeus_install_dir\\lib\\gnuregexp.jar, java_install_dir\\jre\\rt.jar Where zeus_install_dir is the directory that you have installed Zeus in , and java_install_dir is the directory that you have installed Java in"); cnfe.printStackTrace();} catch(Exception e) { e.printStackTrace(); } } } subastadorUI.java /********************************************************************** ******* * supplyUI.java * * Interface between SupplyBot and its TraderFrontEnd GUI 61

*********************************************************************** ******/ import zeus.actors.*; import zeus.agents.*; public class subastadorUI implements ZeusExternal { public void exec(AgentContext agent) { TraderFrontEnd thiswin = new TraderFrontEnd(agent); } public void showMsg(String message) { } public static void main(String[] args) { subastadorUI win = new subastadorUI(); win.exec(null); } } testForward.java /* This software was produced as a part of research activities. It is not intended to be used as commercial or industrial software by any organisation. Except as explicitly stated, no guarantees are given as to its reliability or trustworthiness if used for purposes other than those for which it was originally intended. (c) British Telecommunications plc 1999. */ /* This code was automatically generated by ZeusAgentGenerator version 1.1 DO NOT MODIFY!! */ import java.util.*; 62

import import import import import

java.io.*; zeus.util.*; zeus.concepts.*; zeus.actors.*; zeus.agents.*;

public class testForward { protected static void version() { System.err.println("ZeusAgent - testForward version: 1.1"); System.exit(0); } protected static void usage() { System.err.println("Usage: java testForward -s -o [-gui ViewerProg] [-e <ExternalProg>] [-r ResourceProg] [-name ] [-debug] [-h] [-v]"); System.exit(0); } public static void main(String[] arg) { try { ZeusAgent agent; String external = null; String dns_file = null; String resource = null; String gui = null; String ontology_file = null; Vector nameservers = null; String name = new String ("testForward"); Bindings b = new Bindings("testForward"); FileInputStream stream = null; ZeusExternal user_prog = null; for( int j = 0; j < arg.length; j++ ) { if ( arg[j].equals("-s") && ++j < arg.length ) dns_file = arg[j]; else if ( arg[j].equals("-e") && ++j < arg.length ) external = arg[j]; else if ( arg[j].equals("-r") && ++j < arg.length ) resource = arg[j]; else if ( arg[j].equals("-o") && ++j < arg.length ) ontology_file = arg[j]; else if ( arg[j].equals("-gui") && ++j < arg.length ) 63

gui = arg[j]; else if ( arg[j].equals("-debug") ) { Core.debug = true; Core.setDebuggerOutputFile("testForward.log"); } else if ( arg[j].equals("-v") ) version(); else if ( arg[j].equals("-name") && ++j < arg.length ) name = name + "_" + arg[j]; else if ( arg[j].equals("-h") ) usage(); else usage(); } b = new Bindings(name); if ( ontology_file == null ) { System.err.println("Ontology Database file must be specified with -o option"); usage(); } if ( dns_file == null ) { System.err.println("Domain nameserver file must be specified with -s option"); usage(); } nameservers = ZeusParser.addressList(new FileInputStream(dns_file)); if ( nameservers == null || nameservers.isEmpty() ) throw new IOException(); agent = new ZeusAgent(name,ontology_file,nameservers,1,20,false,false); AgentContext context = agent.getAgentContext(); OntologyDb db = context.OntologyDb(); /* Initialising Extensions */ Class c;

64

if ( resource != null ) { c = Class.forName(resource); ExternalDb oracle = (ExternalDb) c.newInstance(); context.set(oracle); oracle.set(context); } if ( gui != null ) { c = Class.forName(gui); ZeusAgentUI ui = (ZeusAgentUI)c.newInstance(); context.set(ui); ui.set(context); } /* Initialising ProtocolDb */ ProtocolInfo info; /* Initialising OrganisationalDb */ AbilityDbItem item; /* Initialising ResourceDb */ Fact f1; f1 = ZeusParser.fact(db,"(:type test :id fact58 :modifiers 0 :attributes ((data Test)))"); if ( f1.resolve(b) ) agent.addFact(f1); /* Initialising External User Program */ if ( external != null ) { c = Class.forName(external); user_prog = (ZeusExternal) c.newInstance(); context.set(user_prog); } /* 65

Activating External User Program */ if ( user_prog != null ) user_prog.exec(context); } catch (ClassNotFoundException cnfe) { System.out.println("Java cannot find some of the classes that are needed to run this agent. Please ensure that you have the followingin your classpath : zeus_install_dir\\lib\\zeus.jar, zeus_install_dir\\lib\\gnuregexp.jar, java_install_dir\\jre\\rt.jar Where zeus_install_dir is the directory that you have installed Zeus in , and java_install_dir is the directory that you have installed Java in"); cnfe.printStackTrace();} catch(Exception e) { e.printStackTrace(); } } } TraderFrontEnd.java /********************************************************************** ******* * TraderFrontEnd.java * Jaron Collis ([email protected]), March 1999 * Implementation of the FruitMarket Trading GUI *********************************************************************** ******/ import import import import import import

java.util.*; java.awt.*; java.awt.event.*; java.io.*; javax.swing.*; javax.swing.border.*;

import import import import import

zeus.util.*; zeus.concepts.*; zeus.gui.fields.*; zeus.actors.*; zeus.actors.event.*; 66

import zeus.generator.util.*; public class TraderFrontEnd extends JFrame implements WindowListener, ConversationMonitor { // the root class of the GUI, contains the main display area protected JTabbedPane tabbedPane; protected JPanel sellPanel; protected JPanel buyPanel; protected JPanel stockPanel; public JTextArea infoArea; public AgentContext agent; public JScrollPane scrollPane; public TraderFrontEnd(AgentContext ac) { agent = ac; setTitle(agent.whoami() + " Trade Window"); addWindowListener(this); // register GUI's interest in conversation events agent.Engine().addConversationMonitor(this, ConversationEvent.INITIATE_MASK | ConversationEvent.CONTINUE_MASK); getContentPane().setBackground(java.awt.Color.gray); String path = "gifs" + System.getProperty("file.separator"); ImageIcon icon = new ImageIcon(path + "banana.gif"); setIconImage(icon.getImage()); GridBagLayout gridBagLayout = new GridBagLayout(); GridBagConstraints gbc = new GridBagConstraints(); getContentPane().setLayout(gridBagLayout); JLabel header = new JLabel(new ImageIcon(path + "header.gif")) { public void paint(Graphics g) { Dimension size = getSize(); g.setColor(java.awt.Color.white); g.fillRect(0, 0, size.width, size.height); getIcon().paintIcon(this, g, 0, 0); } }; header.setBorder(new BevelBorder(BevelBorder.RAISED)); 67

gbc.gridwidth = GridBagConstraints.REMAINDER; gbc.anchor = GridBagConstraints.NORTH; gbc.fill = GridBagConstraints.HORIZONTAL; gbc.weightx = gbc.weighty = 0; gbc.insets = new Insets(0,0,0,0); ((GridBagLayout)getContentPane().getLayout()).setConstraints(hea der, gbc); getContentPane().add(header); infoArea = new JTextArea(6,60); infoArea.setForeground(Color.black); infoArea.setBackground(Color.white); infoArea.setEditable(true); scrollPane = new JScrollPane(infoArea); scrollPane.setBorder(new BevelBorder(BevelBorder.LOWERED)); scrollPane.setPreferredSize(new Dimension(300,100)); infoArea.setText(agent.whoami() + " is awaiting your instructions...\n"); infoArea.setCaretPosition(infoArea.getDocument().getLength()); gbc.anchor = GridBagConstraints.WEST; gbc.fill = GridBagConstraints.HORIZONTAL; gbc.weightx = gbc.weighty = 0; gbc.insets = new Insets(8,8,0,8); ((GridBagLayout)getContentPane().getLayout()).setConstraints(scrol lPane, gbc); getContentPane().add(scrollPane); tabbedPane = new JTabbedPane(); sellPanel = new TradePanel(false, this); buyPanel = new TradePanel(true, this); stockPanel = new StockPanel(this); tabbedPane.addTab("Inventory", stockPanel); tabbedPane.addTab("Sell Fruit", sellPanel); tabbedPane.addTab("Buy Fruit", buyPanel); tabbedPane.setSelectedIndex(0); tabbedPane.setTabPlacement(JTabbedPane.BOTTOM); gbc.anchor = GridBagConstraints.SOUTH; gbc.fill = GridBagConstraints.BOTH; 68

gbc.weightx = gbc.weighty = 1; gbc.insets = new Insets(8,8,0,8); ((GridBagLayout)getContentPane().getLayout()).setConstraints(tabb edPane, gbc); getContentPane().add(tabbedPane); pack(); setResizable(false); show(); } public void windowClosed(WindowEvent event) {} public void windowDeiconified(WindowEvent event) {} public void windowIconified(WindowEvent event) {} public void windowActivated(WindowEvent event) {} public void windowDeactivated(WindowEvent event) {} public void windowOpened(WindowEvent event) {} public void windowClosing(WindowEvent event) { this.setVisible(false); this.dispose(); System.exit(0); } public void display(String message) { infoArea.append(message + "\n"); infoArea.setCaretPosition(infoArea.getDocument().getLength()); } public void conversationInitiatedEvent(ConversationEvent event) { String correspondent = event.getReceiver(); String mode = " to "; if (correspondent.equals(agent.whoami())) { correspondent = event.getSender(); mode = " from "; } Goal g = (Goal)(event.getData().elementAt(0)); double cost = g.getCost(); String f = g.getFactType(); display("Conversation started..."); display("[" + event.getMessageType() + "]" + mode + correspondent + 69

" >> " + f + " @ " + Misc.decimalPlaces(cost,3)); } public void conversationContinuedEvent(ConversationEvent event) { String correspondent = event.getReceiver(); String mode = " to "; if (correspondent.equals(agent.whoami())) { correspondent = event.getSender(); mode = " from "; } if ( event.isGoalEventType() ) { Goal g = (Goal)(event.getData().elementAt(0)); double cost = g.getCost(); String f = g.getFactType(); display("[" + event.getMessageType() + "]" + mode + correspondent + " >> " + f + " @ " + Misc.decimalPlaces(cost,3)); } else { Fact f = (Fact)(event.getData().elementAt(0)); display("[" + event.getDataType() + "]" + mode + correspondent); } } }

class TradePanel extends JPanel implements ActionListener, FactSelector { // the panel through which buying and selling preferences are entered protected protected protected protected protected protected protected

FactDialog factWin; NameField fruitField; WholeNumberField askPriceField; WholeNumberField timeField; JButton chooseBtn; JButton tradeBtn; TraderFrontEnd UI;

protected boolean

buying;

70

public TradePanel(boolean b, TraderFrontEnd frontend) { buying = b; UI = frontend; GridBagLayout gb = new GridBagLayout(); GridBagConstraints gbc = new GridBagConstraints(); setLayout(gb); setBackground(Color.lightGray); setPreferredSize(new Dimension(360,220)); setBorder(BorderFactory.createBevelBorder(BevelBorder.LOWERED)) ; askPriceField = new WholeNumberField(0, 9999); askPriceField.setBackground(Color.white); askPriceField.setPreferredSize(new Dimension(60,20)); askPriceField.setValue(10); // or get value from DB timeField = new WholeNumberField(0, 9999); timeField.setBackground(Color.white); timeField.setPreferredSize(new Dimension(60,20)); timeField.setValue(3); fruitField = new NameField(7); fruitField.setBackground(Color.white); chooseBtn = new JButton("Choose"); chooseBtn.addActionListener(this); JLabel label0 = new JLabel("Commodity to Trade: "); label0.setFont(new Font("Helvetica",Font.PLAIN, 12)); label0.setToolTipText("The type of fruit that will be traded"); gbc.insets = new Insets(4,8,4,0); gbc.gridwidth = 1; gbc.fill = GridBagConstraints.NONE; gbc.anchor = GridBagConstraints.WEST; gb.setConstraints(label0,gbc); add(label0); gbc.gridwidth = 1; gbc.fill = GridBagConstraints.NONE; gbc.insets = new Insets(4,8,4,8); 71

gb.setConstraints(fruitField, gbc); add(fruitField); gbc.gridwidth = GridBagConstraints.REMAINDER; gbc.fill = GridBagConstraints.NONE; gbc.anchor = GridBagConstraints.EAST; gbc.insets = new Insets(4,8,4,8); gb.setConstraints(chooseBtn, gbc); add(chooseBtn); String q = "Reserve price: "; if (buying) q = "Maximum offer price: "; JLabel label1 = new JLabel(q); label1.setFont(new Font("Helvetica",Font.PLAIN, 12)); label1.setToolTipText("The initial offer price"); gbc.insets = new Insets(4,8,4,0); gbc.gridwidth = 1; gbc.fill = GridBagConstraints.NONE; gbc.anchor = GridBagConstraints.WEST; gb.setConstraints(label1,gbc); add(label1); gbc.gridwidth = GridBagConstraints.REMAINDER; gbc.fill = GridBagConstraints.NONE; gbc.insets = new Insets(4,8,4,8); gb.setConstraints(askPriceField, gbc); add(askPriceField); JLabel label3 = new JLabel("Deadline (time-grains): "); label3.setFont(new Font("Helvetica",Font.PLAIN, 12)); label3.setToolTipText("The deadline by which trading should have concluded"); gbc.gridwidth = 1; gbc.fill = GridBagConstraints.NONE; gbc.insets = new Insets(4,8,4,0); gb.setConstraints(label3, gbc); add(label3); gbc.gridwidth = GridBagConstraints.REMAINDER; gbc.fill = GridBagConstraints.NONE; gbc.insets = new Insets(4,8,4,8); gbc.weightx = 1; 72

gb.setConstraints(timeField, gbc); add(timeField); tradeBtn = new JButton("Trade"); tradeBtn.addActionListener(this); gbc.gridwidth = GridBagConstraints.REMAINDER; gbc.fill = GridBagConstraints.NONE; gbc.insets = new Insets(16,8,8,8); gbc.weightx = 1; gb.setConstraints(tradeBtn, gbc); add(tradeBtn); factWin = new FactDialog((Frame)SwingUtilities.getRoot(this), UI.agent.OntologyDb()); } public void factSelected(String[] names) { // get selected fact type and display name String str = names[0]; if (str.equals("ZeusFact") || str.equals("Money")) return; fruitField.setText(str); } public void actionPerformed(ActionEvent evt) { if (UI.agent == null ) return; if (evt.getSource() == chooseBtn) { factWin.setLocationRelativeTo(chooseBtn); factWin.display(this); } else if (evt.getSource() == tradeBtn) { // trade button pressed: do some error checking first String fruit = fruitField.getText(); if (!UI.agent.OntologyDb().hasFact(fruit)) { UI.display("** Error: " + fruit + " does not exist in the ontology."); return; } Fact[] tmp = UI.agent.ResourceDb().all(fruit); 73

if (!buying && tmp[0].getNumber() == 0) { UI.display("Ooops, we're out of " + tmp[0].getType() + "s !"); return; } // transaction is valid: commence trading Long askl = askPriceField.getValue(); Long timel = timeField.getValue(); int ask = (int)askl.longValue(); int time = (int)timel.longValue(); if (buying) beginBuy(fruit, ask, time); else beginSell(fruit, ask, time); } } public void beginBuy(String fruit, int ask, int time) { UI.display("\nAttempting to buy: " + fruit); UI.display("My preferences: price= " + ask + ", within " + time + " time-grains"); Fact fact = UI.agent.OntologyDb().getFact(Fact.VARIABLE, fruit); fact.setNumber(1); int now = (int)UI.agent.now(); Goal g = new Goal(UI.agent.newId("goal"), fact, now+time, ask, UI.agent.whoami(), (double)(now+time-0.5)); UI.agent.Engine().buy(g); } public void beginSell(String fruit, int ask, int time) { UI.display("\nAttempting to sell: " + fruit); UI.display("My preferences: price= " + ask + ", within " + time + " time-grains"); Fact fact = UI.agent.OntologyDb().getFact(Fact.VARIABLE, fruit); fact.setNumber(1); int now = (int)UI.agent.now(); 74

Goal g = new Goal(UI.agent.newId("goal"), fact, now+time, ask, UI.agent.whoami(), (double)(0)); UI.agent.Engine().sell(g); } }

75