Está en la página 1de 337

UNIVERSIDAD 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 ...................................................................................................... - 1 -
JUSTIFICACION ....................................................................................................... - 4 -
MARCO TEORICO ................................................................................................... - 5 -

CAPITULO I ............................................................................................................... - 5 -

¿AGENTE?.................................................................................................................. - 5 -
1.1 Qué es un Agente?................................................................................................. - 5 -
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.1 Inteligencia: ...................................................................................................... - 13 -
1.5.2 Autonomía ........................................................................................................ - 14 -
1.5.3 Racionalidad: ................................................................................................... - 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.5.10 Benevolencia ................................................................................................... - 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 ............................................................................. - 19 -
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 -
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 ..................................................................................................... - 52 -
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.5 Protocolo de negociación: .............................................................................. - 54 -
1.14.6 Estrategia de negociación:............................................................................. - 55 -
1.14.7 Riesgo de conflicto ......................................................................................... - 55 -

CAPITULO II ........................................................................................................... - 56 -

2. INGENIAS [ .......................................................................................................... - 56 -
2.1 Nomenclatura ..................................................................................................... - 57 -
2.1.1 Entidades básicas ............................................................................................. - 58 -
2.1.2 Notación ........................................................................................................... - 59 -
2.2 META-MODELOS DEL SISTEMA MULTI AGENTE ................................ - 61 -
2.2.1 Modelo de organización................................................................................... - 62 -
2.2.2 Modelo de agente ............................................................................................. - 64 -
2.2.3 Modelo de objetivos y tareas .......................................................................... - 66 -
2.2.4 Modelo de interacciones .................................................................................. - 69 -
2.2.5 Modelo de entorno ........................................................................................... - 71 -
2.3 CASO DE ESTUDIO SUBASTA EN INGENIAS ........................................... - 73 -
2.3.1 Casos de uso asociados al problema ............................................................... - 73 -
2.3.1.1 Definir tipo de subasta: ............................................................................... - 74 -
2.3.1.2 Subastar Artículos: ...................................................................................... - 74 -
2.3.1.3 Buscar Artículos: ......................................................................................... - 74 -
2.3.1.4 Realizar puja: ............................................................................................... - 74 -
2.3.1.5 Anunciar puja mayor: ................................................................................. - 74 -
2.4 FUNCIONAMIENTO DEL IDK ...................................................................... - 74 -
2.4.1. Partes del editor ............................................................................................. - 75 -
2.4.2 proyecto y visualización de proyecto ............................................................ - 76 -
2.4.3 la vista de Entidades ....................................................................................... - 77 -
2.4.4 Editor de diagrama ......................................................................................... - 77 -
2.4.5. Módulos........................................................................................................... - 80 -
2.5 RESULTADO FINAL DE IMPLEMENTACION DE CASO DE ESTUDIO EN
LA METODOLOGIA INGENIAS IDK ............................................................. - 80 -

CAPITULO III ......................................................................................................... - 84 -

3. MAS-commonKads ............................................................................................... - 84 -
3.1 Ciclo de desarrollo de los casos de uso .............................................................. - 85 -
3.1.1 Actividad: Identificación de los actores ........................................................ - 85 -
3.1.2 Actividad: Descripción de los actores ........................................................... - 86 -
3.1.3 Actividad: Identificación de los casos de uso................................................ - 86 -
3.1.4 Actividad: Descripción de los casos de uso ................................................... - 86 -
3.1.4.1 Notación de los casos de uso ......................................................................... - 86 -
3.1.4.1.1 Notación textual ......................................................................................... - 87 -
3.1.5 Notación gráfica .............................................................................................. - 87 -
3.1.6 Actividad: Descripción de las intervenciones de los casos de uso............... - 88 -
3.1.7 Actividad: Descripción de las relaciones entre casos de uso ....................... - 88 -
3.2 Modelo de Agente.............................................................................................. - 88 -
3.2.1 Antecedentes históricos .................................................................................. - 89 -
3.2.2 Fundamentos del modelo de agente ............................................................. - 89 -
3.2.2.1 ¿Qué problemas de IAD deben ser resueltos en el desarrollo del modelo de
agente? ................................................................................................................... - 89 -
3.2.2.2 ¿Cuándo es el modelo útil, y cuándo debe ser incluido en el conjunto de
modelos? ................................................................................................................ - 90 -
3.2.3 Dependencias en la construcción del modelo ............................................... - 90 -
3.2.3.1 Modelo de Tareas .......................................................................................... - 90 -
3.2.3.2 Modelo de Comunicación ............................................................................. - 90 -
3.2.3.3 Modelo de Coordinación .............................................................................. - 90 -
3.2.3.4 Modelo de la Experiencia ............................................................................. - 90 -
3.2.3.5 Modelo de Organización .............................................................................. - 91 -
3.2.4 Ciclo de desarrollo del modelo de agente....................................................... - 91 -
3.2.5 Relación entre el modelo de agente ................................................................ - 92 -
3.3 Modelo de Tareas ............................................................................................... - 93 -
3.3.2 Entidades del modelo de tareas ...................................................................... - 93 -
3.4 Modelo de Experiencia ....................................................................................... - 97 -
3.4.1 Fundamentos del modelo de la experiencia ................................................... - 97 -
3.4.2 Estructura del modelo de la experiencia........................................................ - 97 -
3.4.3 Conocimiento del dominio............................................................................... - 97 -
3.4.4 Notación del modelo de la experiencia ........................................................... - 98 -
3.4.5 Técnicas de adquisición del conocimiento ..................................................... - 99 -
3.4.6 Desarrollo del modelo de la experiencia ........................................................ - 99 -
3.4.7 Actividades de construcción del esqueleto del modelo ............................... - 100 -
3.4.8 Actividades de instanciación ......................................................................... - 100 -
3.4.9 Particularización para sistemas multiagente .............................................. - 100 -
3.5 Modelo de Coordinación .................................................................................. - 101 -
3.5.1 Antecedentes históricos ................................................................................. - 102 -
3.5.2 Por último, ...................................................................................................... - 102 -
3.5.2.1 Teoría de los actos de habla ....................................................................... - 103 -
3.5.2.2 Teoría del discurso ...................................................................................... - 103 -
3.5.2.3 El lenguaje de comunicación KQML ........................................................ - 103 -
3.5.2.4 La especificación de la FIPA ...................................................................... - 104 -
3.5.3 Fundamentos del modelo de coordinación .................................................. - 105 -
3.5.3.1 ¿Qué problemas de la IAD deben ser resueltos en el desarrollo del modelo
de coordinación? ................................................................................................. - 106 -
3.5.3.2 ¿Cuándo es el modelo útil, y cuándo debe ser incluido en el conjunto de
modelos? .............................................................................................................. - 106 -
3.5.3.3 Restricciones: ¿qué no puede ser modelado? ........................................... - 107 -
3.5.4 Estructura del modelo ................................................................................... - 107 -
3.5.4.1 Constituyentes del modelo.......................................................................... - 107 -
3.5.4.2 Plantilla del modelo de Coordinación ....................................................... - 108 -
3.5.5 Ciclo del desarrollo del modelo..................................................................... - 110 -
3.5.5.1 Desarrollo estándar del modelo de coordinación ..................................... - 110 -
3.5.5.2 Ciclos de desarrollo no estándar del modelo de coordinación ................ - 112 -
3.5.6 Dependencias en la construcción del modelo .............................................. - 113 -
3.5.7 Evaluación del modelo ................................................................................... - 113 -
3.6 Modelo de Organización .................................................................................. - 119 -
3.6.1 Antecedentes históricos ................................................................................. - 120 -
3.6.2 Bases teóricas del modelo .............................................................................. - 120 -
3.6.2.1 Relaciones de herencia en un sistema multiagente .................................. - 120 -
3.6.2.1.1 ¿Entre qué constituyentes se establece una relación de herencia? ...... - 120 -
3.6.2.1.2 ¿Cómo se define la relación de herencia? .............................................. - 120 -
3.6.3 Fundamentos del modelo de organización................................................... - 122 -
3.6.3.1 ¿Qué problemas de IAD deben ser resueltos en el desarrollo del modelo de
organización? ...................................................................................................... - 122 -
3.6.3.2 ¿Cuándo es el modelo útil, y cuándo debe ser incluido en el conjunto de
modelos? .............................................................................................................. - 122 -
3.6.3.3 Restricciones: ¿qué no puede ser modelado? ........................................... - 123 -
3.6.4 Estructura del modelo ................................................................................... - 123 -
3.6.4.1 Constituyentes del modelo.......................................................................... - 123 -
3.6.4.2 Notación gráfica del modelo....................................................................... - 124 -
3.6.5 Ciclo de desarrollo del modelo ...................................................................... - 125 -
3.6.5.1 Desarrollo estándar del modelo de organización ..................................... - 125 -
3.6.6 Actividades de construcción del modelo de organización .......................... - 125 -
3.6.7 Actividades de modelado de la organización ............................................... - 126 -
3.6.7.1 Modelado de la situación actual ................................................................ - 127 -
3.6.7.2 Actividad: Introducción en la organización ............................................. - 127 -
3.6.7.3 Actividad: Comprensión de la organización ............................................ - 127 -
3.6.7.4 Actividad: Análisis detallado ..................................................................... - 127 -
3.6.7.5 Actividad: Evaluación del análisis............................................................. - 128 -
3.6.7.6 Modelado de la situación futura ............................................................... - 128 -
3.6.7.7 Actividad: Identificación de soluciones..................................................... - 128 -
3.6.7.8 Actividad: Investigación de viabilidad ...................................................... - 129 -
3.6.7.9 Actividad: Preparación para la toma de decisiones ................................ - 129 -
3.6.7.10 Actividad: Evaluación de soluciones ....................................................... - 130 -
3.6.8 Actividades de modelado de la organización multiagente ......................... - 130 -
3.6.8.1 Actividad: Identificación de las relaciones de herencia .......................... - 130 -
3.6.8.2 Actividad: Identificación de objetos del entorno ..................................... - 130 -
3.6.8.3 Actividad: Identificación y descripción de estructuras organizativas ... - 130 -
3.6.9 Dependencias en la construcción del modelo .............................................. - 131 -
3.6.9.1 Modelo de Agente........................................................................................ - 131 -
3.6.9.2 Modelo de Tareas ........................................................................................ - 131 -
3.6.9.3 Modelo de Comunicación ........................................................................... - 131 -
3.6.9.4 Modelo de Coordinación ............................................................................ - 131 -
3.7 Modelo de Diseño ............................................................................................. - 132 -
3.7.1 Antecedentes históricos ................................................................................. - 132 -
3.7.2 Bases teóricas.................................................................................................. - 132 -
3.7.2.1 El Modelo de Red ........................................................................................ - 133 -
3.7.2.1.1 Facilidades de red .................................................................................... - 134 -
3.7.2.1.2 Facilidades de coordinación .................................................................... - 135 -
3.7.2.1.3 Facilidades de conocimiento ................................................................... - 135 -
3.7.3 Fundamentos del modelo de diseño .............................................................. - 136 -
3.7.3.1 ¿Qué problemas de IAD deben ser resueltos en el desarrollo del modelo de
diseño?.................................................................................................................. - 136 -
3.7.3.2 ¿Cuándo el modelo es útil, y cuándo debe ser incluido en el conjunto de
modelos? .............................................................................................................. - 136 -
3.7.3.3 Restricciones: ¿qué no puede ser modelado? ........................................... - 136 -
3.7.4 Estructura del modelo ................................................................................... - 137 -
3.7.4.1 Diseño del modelo de red............................................................................ - 137 -
3.7.4.2 Constituyentes del modelo.......................................................................... - 138 -
3.7.4.2.1 Constituyentes del diseño de red ............................................................ - 138 -
3.7.4.3 Diseño de los agentes................................................................................... - 139 -
3.7.4.4 Diseño de la plataforma .............................................................................. - 140 -
3.7.5 Ciclo de desarrollo del modelo ...................................................................... - 140 -
3.7.6 Dependencias en la construcción del modelo .............................................. - 141 -
3.7.6.1 Modelo de agente ........................................................................................ - 141 -
3.7.6.2 Modelo de comunicación ............................................................................ - 141 -
3.7.6.3 Modelo de tareas ......................................................................................... - 142 -
3.7.6.4 Modelo de la experiencia ............................................................................ - 142 -
3.7.6.5 Modelo de organización.............................................................................. - 142 -
3.7.6.6 Modelo de coordinación ............................................................................. - 142 -
3.7.6.7 Actividades de desarrollo del modelo de diseño ....................................... - 142 -
3.7.7 Diseño de la red .............................................................................................. - 142 -
3.7.7.1 Actividad: Identificación y descripción de las facilidades de red ........... - 142 -
3.7.7.1.2 Servicios de red básicos ........................................................................... - 143 -
3.7.7.1.3 Servicios de red avanzados...................................................................... - 143 -
3.7.7.1.4 Servicios de red no funcionales ............................................................... - 143 -
3.7.7.2 Actividad: Identificación y descripción de las facilidades de conocimiento .... -
144 -
3.7.7.2.1 Servicios de conocimiento básicos .......................................................... - 144 -
3.7.7.3 Actividad: Identificación y descripción de las facilidades de coordinación .... -
144 -
3.7.7.3.1 Servicios de coordinación ........................................................................ - 145 -
3.7.7.4 Actividad: Identificación y descripción de agentes de red ...................... - 145 -
3.7.8 Diseño de la aplicación .................................................................................. - 146 -
3.7.8.1 Actividad: Determinación de la arquitectura de los agentes .................. - 146 -
3.7.8.2 Actividad: Revisión de los agentes identificados ...................................... - 146 -
3.7.8.3 Actividad: Diseño detallado de los módulos ............................................. - 147 -
3.7.9 Diseño de la plataforma ................................................................................. - 147 -
3.7.9.1 Actividad: Selección del lenguaje de implementación ............................. - 147 -
3.7.9.2 Actividad: Selección de los recursos software .......................................... - 148 -
3.7.9.3 Actividad: Selección de los recursos hardware ........................................ - 148 -
3.8 APLICACION DE CASO DE ESTUDIO .................................................... - 149 -
3.8.1 Modelo de agentes .......................................................................................... - 152 -
3.8.2 Modelo de Experiencia ................................................................................. - 155 -
3.8.3 Modelo de coordinación ................................................................................ - 156 -
3.8.4 Modelo de tareas ............................................................................................ - 159 -
3.8.5 Modelo de comunicación .............................................................................. - 160 -
3.8.6 Modelo de Organización .............................................................................. - 162 -
3.8.7 El Modelo de Red .......................................................................................... - 163 -

CAPITULO IV ........................................................................................................ - 164 -

4 MASINA: MultiAgent Systems in Automation.............................................. - 164 -


4.1 Modelo de agentes ............................................................................................ - 165 -
4.2 Modelo de tareas .............................................................................................. - 165 -
4.3 Modelo de Inteligencia..................................................................................... - 166 -
4.4 Modelo de coordinación .................................................................................. - 167 -
4.5 Modelo de Comunicación ................................................................................ - 170 -
4.6. APLICACION DE “SMA SUBASTAS” EN MASINA ............................... - 172 -
4.6.1 Actores y Casos de uso.................................................................................. - 172 -
4.6.2 Modelo de agentes .......................................................................................... - 174 -
4.6.2.1 Canales básicos de comunicación .............................................................. - 181 -
4.6.3 Modelo de Inteligencia................................................................................... - 177 -
4.6.4 Modelo de coordinación ................................................................................ - 178 -
4.6.4 Modelo de tareas ............................................................................................ - 182 -
4.6.5 Modelo de comunicación ............................................................................... - 182 -

CAPITULO V ......................................................................................................... - 185 -

5 The Zeus Agent Building Toolkit ....................................................................... - 185 -


5.1 El agente conceptual de Zeus ........................................................................... - 187 -
5.2 Metodología Principal de Zeus ........................................................................ - 188 -
5.3 – Análisis de Dominio ....................................................................................... - 189 -
5.4 – Agente Diseño ................................................................................................. - 190 -
5.5 – Agente Comprensión ..................................................................................... - 190 -
5.6 – Soporte de Tiempo de Ejecución .................................................................. - 190 -
5.7 Descripción del proceso de la realización del agente ..................................... - 192 -
5.7.1 Etapa 1: Creación de Ontología ................................................................... - 192 -
5.7.2 Etapa 2: Creación del agente ........................................................................ - 192 -
5.7.3 Etapa 3: Configuración para uso general del agente.................................. - 192 -
5.7.4 Etapa 4: Configuración del agente de la tarea ............................................ - 192 -
5.7.5 Etapa 5: Puesta en práctica del agente ........................................................ - 193 -
5.8 La etapa de la creación de la Ontología .......................................................... - 194 -
5.9 Creación de Agentes ......................................................................................... - 196 -
5.10 Asignación de recurso inicial del agente ....................................................... - 197 -
5.11 Interacciones del agente ................................................................................ - 200 -
5.12 Uso general de la configuración del agente ................................................. - 202 -
5.13 Cómo crear un agente con un GUI del espectador del agente ................... - 203 -

CAPITULO VI ........................................................................................................ - 205 -

6. JADE .................................................................................................................... - 205 -


6.1 FIPA ................................................................................................................... - 205 -
6.2 JADE .................................................................................................................. - 206 -
6.3 Arquitectura ...................................................................................................... - 207 -
6.4 Programación de Agentes en JADE ................................................................ - 208 -
6.5 Comportamientos.............................................................................................. - 210 -
6.5.1. Comunicación ................................................................................................ - 212 -
6.6. Entorno de ejecución ....................................................................................... - 213 -
6.6.1. Interfaz RMA ................................................................................................ - 213 -
6.6.2. Agente Dummy .............................................................................................. - 214 -
6.6.3 Interfaz DF ..................................................................................................... - 215 -
6.6.4. Agente Sniffer ................................................................................................ - 215 -
6.6.5. Agente Instrospector..................................................................................... - 216 -
6.7. Razones para el uso de JADE ......................................................................... - 216 -
6.8 Implementación del caso de estudio ................................................................ - 217 -

CAPITULO VII ...................................................................................................... - 222 -

7.CONCLUCIONES ............................................................................................... - 222 -


7.1 Criterios de examen .......................................................................................... - 225 -
7.1.1. Cuatro cualidades de las etapas de desarrollo ........................................... - 225 -
7.1.2. Aplicación de las cualidades a las etapas .................................................... - 225 -
7.1.3 Otros criterios ................................................................................................ - 229 -

BIBLIOGRAFIA .............................................................................................................. i

ANEXO I Documentación generada por ingenias IDE ................................................ 1

ANEXO II Codigo fuente de JADE.............................................................................. 10

ANEXO III Código creado para Zeus ........................................................................ 51


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 ................................................................................................ ‐ 57 ‐ 
Figura 22: Expresión BNF para la los nombres de las relaciones ............................................................ ‐ 58 ‐ 
Figura 23: Entidades básicas de la metodología ..................................................................................... ‐ 58 ‐ 
Figura 24: Notación empleada en la representación de los modelos ..................................................... ‐ 60 ‐ 
Figura 25: Estructura de cuatro niveles utilizada en el meta‐modelado ................................................ ‐ 61 ‐ 
Figura 26: Descripción estructural .......................................................................................................... ‐ 62 ‐ 
Figura 27: Descripción social ................................................................................................................... ‐ 63 ‐ 
Figura 28: Descripción funcional ............................................................................................................. ‐ 63 ‐ 
Figura 29: Elementos del modelo de agente ........................................................................................... ‐ 65 ‐ 
Figura 30: Diagrama del modelo de agente ........................................................................................... ‐ 65 ‐ 
Figura 31: Agente planificador ............................................................................................................... ‐ 66 ‐ 
Figura 32: Ciclo de vida de un objetivo ................................................................................................... ‐ 67 ‐ 
Figura 33: Árboles Y/O ............................................................................................................................ ‐ 67 ‐ 
Figura 34: Elementos de definición de tareas ......................................................................................... ‐ 68 ‐ 
Figura 35: Una tarea afecta a un objetivo .............................................................................................. ‐ 68 ‐ 
Figura 36: Ejemplo de Tareas .................................................................................................................. ‐ 69 ‐ 
Figura 37: Protocolos FIPA_CONTRCTNET .............................................................................................. ‐ 70 ‐ 
Figura 38: Entorno de asistente de ficheros de un pc ............................................................................. ‐ 72 ‐ 
Figura 39: Casos de usos subasta ........................................................................................................... ‐ 73 ‐ 
Figura 40: IDE pantalla principal ............................................................................................................. ‐ 75 ‐ 
Figura 41: Partes del editor ..................................................................................................................... ‐ 76 ‐ 
Figura 42: pasos para crear una relación de dos entidades.................................................................... ‐ 79 ‐ 
Figura 43: Relación entre el IDE, modelos y componentes ..................................................................... ‐ 80 ‐ 
Figura 44: Asociación de agentes ........................................................................................................... ‐ 81 ‐ 
Figura 45: Ambientes de agentes ........................................................................................................... ‐ 81 ‐ 
Figura 46: Objetivos y tareas .................................................................................................................. ‐ 82 ‐ 
Figura 47: Modelo de interacción ........................................................................................................... ‐ 82 ‐ 
Figura 48: Flujo de eventos ..................................................................................................................... ‐ 83 ‐ 
Figura 49: modelos de Mas commonKads .............................................................................................. ‐ 85 ‐ 
Figura 50: Notación de los casos de uso ................................................................................................. ‐ 88 ‐ 
Figura 51: Modelo de Agente.................................................................................................................. ‐ 89 ‐ 
Figura 52: Tarjetas CRC para agentes ..................................................................................................... ‐ 91 ‐ 
Figura 53: Constituyentes y relaciones del modelo de agentes .............................................................. ‐ 92 ‐ 
Figura 54: Modelo de tarea .................................................................................................................... ‐ 93 ‐ 
Figura 55: Diagrama entidad‐relación del modelo de tareas de CommonKADS .................................... ‐ 93 ‐ 
Figura 56: Notación estándar para indicar descomposición de tareas ................................................... ‐ 94 ‐ 
Figura 57: Notación alternativa para representar la descomposición de tareas .................................... ‐ 95 ‐ 
Figura 58: Principales componentes del modelo de la experiencia ......................................................... ‐ 97 ‐ 
Figura 59: Ontología ............................................................................................................................... ‐ 98 ‐ 
Figura 60: Nivel de dominio y inferencia ................................................................................................. ‐ 98 ‐ 
Figura 61: Adquisición de conocimiento ................................................................................................. ‐ 99 ‐ 
Figura 62: Ejemplo de diagrama de inferencia de un agente ............................................................... ‐ 101 ‐ 
Figura 63: Objetos del modelo de coordinación ................................................................................... ‐ 109 ‐ 
Figura 64: Descomposición del objeto Intervención ............................................................................. ‐ 110 ‐ 
Figura 65: Orden de los hitos del modelo de coordinación ................................................................... ‐ 111 ‐ 
Figura 66: Estados hito en el desarrollo del modelo de Coordinación .................................................. ‐ 112 ‐ 
Figura 67: Notación Agentes MSC ........................................................................................................ ‐ 115 ‐ 
Figura 68: Estructuras extremas de diagramas de interacción ............................................................. ‐ 116 ‐ 
Figura 69: Constituyentes del modelo de organización de CommonKADS ........................................... ‐ 119 ‐ 
Figura 70: Representación de herencia entre agentes .......................................................................... ‐ 121 ‐ 
Figura 71: Modelo de organización de CommonKADS .......................................................................... ‐ 124 ‐ 
Figura 72: Notación gráfica del modelo de organización ..................................................................... ‐ 125 ‐ 
Figura 73: Arquitectura multi‐agente genérica .................................................................................... ‐ 133 ‐ 
Figura 74: El modelo de red .................................................................................................................. ‐ 134 ‐ 
Figura 75: Descomposición del modelo de diseño ................................................................................ ‐ 137 ‐ 
Figura 76: Constituyentes del diseño de red ......................................................................................... ‐ 138 ‐ 
Figura 77: Constituyentes del diseño de los agentes ............................................................................ ‐ 139 ‐ 
Figura 78: Diseño de la plataforma ...................................................................................................... ‐ 140 ‐ 
Figura 79: Modelos de MASINA ............................................................................................................ ‐ 165 ‐ 
Figura 80: Modelo de tarea .................................................................................................................. ‐ 166 ‐ 
Figura 81: Modelo de inteligencia ........................................................................................................ ‐ 167 ‐ 
Figura 82: Plantilla de una Conversación en el Modelo de Coordinación ............................................. ‐ 168 ‐ 
Figura 83: Modelo de Coordinación ...................................................................................................... ‐ 169 ‐ 
Figura 84: Descripción de la conversación de los agentes .................................................................... ‐ 169 ‐ 
Figura 85: Plantilla del Modelo de comunicación ................................................................................. ‐ 170 ‐ 
Figura 86 Modelo de Comunicación] .................................................................................................... ‐ 171 ‐ 
Figura 87: Conversación en subasta ..................................................................................................... ‐ 179 ‐ 
Figura 88: Canales de comunicación ..................................................................................................... ‐ 181 ‐ 
Figura 89: Descomposición de tarea Escoger tipo de subasta .............................................................. ‐ 182 ‐ 
Figura 90: La estructura conceptual de un agente de ZEUS ................................................................. ‐ 187 ‐ 
Figura 91: Desarrollo de la metodología Zeus ...................................................................................... ‐ 189 ‐ 
Figura 92: presentación de Zeus agent Generator 1.2.2 ....................................................................... ‐ 193 ‐ 
Figura 93: Un screenshot del panel de las opciones de Ontología de la herramienta del generador ... ‐ 195 ‐ 
Figura 94: Un Screenshot de uno de los paneles del editor de Ontología. ............................................ ‐ 195 ‐ 
Figura 95: 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. .................. ‐ 196 ‐ 
Figura 96: Screenshot del panel de la identificación de la tarea........................................................... ‐ 197 ‐ 
Figura 97: El panel inicial de los recursos del agente, y cómo utilizarlo ............................................... ‐ 198 ‐ 
Figura 98 Un Screenshot del redactor primitivo de la tarea con las actividades principales de la etapa de 
la definición de la tarea demostrada] ................................................................................................... ‐ 198 ‐ 
Figura 99: Los modificantes de la condición previa] ............................................................................. ‐ 199 ‐ 
Figura 100: Un diagrama de la estado‐transición de una negociación típica de la red del contrato] .. ‐ 200 ‐ 
Figura 101: El panel del plan de la generación, y cómo utilizarlo ......................................................... ‐ 203 ‐ 
Figura 102: Esquema de distribución de los containers y las plataformas. .......................................... ‐ 207 ‐ 
Figura 103: Ejecución de dos agentes en dispositivos móviles y su arquitectura vista en el RMA. ....... ‐ 208 ‐ 
Figura 104: Flujo de ejecución de un agente básico en JADE. ............................................................... ‐ 209 ‐ 
Figura 105: Interfaz gráfica del agente Dummy.] ................................................................................. ‐ 213 ‐ 
Figura 106: Interfaz gráfica del agente DF.] ......................................................................................... ‐ 214 ‐ 
Figura 107 Interfaz gráfica del agente sniffer.] .................................................................................... ‐ 215 ‐ 
Figura 108: Interfaz gráfica del agente introspector.] .......................................................................... ‐ 215 ‐ 
Figura 109 Archivos de Subasta en jade] .............................................................................................. ‐ 217 ‐ 
Figura 110: Cuadro comparativo .......................................................................................................... ‐ 230 ‐ 
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.

-1-
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

-2-
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.

-3-
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.

-4-
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.”

-5-
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:

-6-
• 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:

-7-
• 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

-8-
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)?

-9-
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:

- 10 -
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.

- 11 -
• 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.

- 12 -
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:

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

1.5 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".

- 13 -
1.5.2 Autonomía: Existen diferentes formas de entender el término "autono-
mí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 eje-


cució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 flexi-
bilidad 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)

- 14 -
[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:

- 15 -
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).

Formalmente, un ambiente Env es una tripleta,


Env =< E, e0,τ >, donde: E es el conjunto

de estados ambientales
e0 ∈ E Es el estado inicial τ Es una función de transformación
de estados

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

- 16 -
R ( Ag , Env )

Formalmente, una secuencia

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


Env =< E, e0,τ > si:
e0 es el estado inicial de Env

α0 = Ag(e0 )

- 17 -
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 OBJETOS
Autonomía de decisión Ejecuta modelos invocados
Flujo de control propio Flujo de control del llamante
Encapsula la activación del comportamiento Encapsula estado y comportamiento
Estado mental: objetivos, creencias Estado: Valor de las variables
Comportamiento: como decir lo que hacer Comportamiento: salida a partir de una
entrada
Interacciones: actos de habla (intencionalidad) Mensajes invocan procedimiento
Organización: relaciones sociales 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 SISTEMAS EXPERTOS


Interactúan con el entorno Sistemas cerrados
Distribución de la toma de decisiones: Sistemas de decisión centralizados
Comportamiento emergente
Mayor grado de interacción con el usuario Interacción con el usuario bajo petición del
usuario
Interacción con otros agentes Normalmente carecen de habilidades sociales
(cooperación).

- 18 -
1.8 CONSTRUCCIÓN DE SMA

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

- 19 -
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

- 20 -
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

- 21 -
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.

- 22 -
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

- 23 -
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.

- 24 -
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.

- 25 -
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

- 26 -
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

- 27 -
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.

- 28 -
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

- 29 -
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 test-
acció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 sub-objetivos, 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.

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

- 50 -
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
1.14.3 Negociación

- 52 -
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 hacerlo
de esa forma.

1.14.3.1 Atributos de la negociación

Eficiente: Optimo de Pareto


Estable: No hay incentivo para desviarse
Simple: Bajo costo computacional y de comunicación
Distribuida: No hay toma de decisiones centralizada
Simétrica: Agentes toman roles equivalentes.

1.14.4 TIPOS DE SUBASTA

1.14.4.1 Subasta inglesa

Características habituales:
primer precio
abierta
ascendente

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

- 53 -
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.

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

- 54 -
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.

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.

- 55 -
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 meta-
modelos 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.

- 56 -
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).

- 57 -
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

- 58 -
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.

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

- 60 -
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

- 61 -
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

- 62 -
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

- 63 -
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.

- 64 -
Figura 29: Elementos del modelo de agente

Figura 30: Diagrama del modelo de agente

- 65 -
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?

- 66 -
Figura 32: Ciclo de vida de un objetivo

Descomposición de objetivos

Figura 33: Árboles Y/O

- 67 -
Figura 34: Elementos de definición de tareas

Relaciones entre tareas y objetivos

Figura 35: Una tarea afecta a un objetivo

- 68 -
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

- 69 -
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

- 70 -
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

- 71 -
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)

- 72 -
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

- 73 -
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.

- 74 -
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.

- 75 -
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.

- 76 -
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

- 77 -
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

- 78 -
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.

- 79 -
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

- 80 -
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

- 81 -
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

- 82 -
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)

- 83 -
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

- 84 -
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 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.

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

- 85 -
• 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

- 86 -
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.

- 87 -
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.

- 88 -
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

- 89 -
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.

- 90 -
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.

- 91 -
3.2.5 Relación entre el modelo de agente

Figura 53: Constituyentes y relaciones del modelo de agentes

- 92 -
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

- 93 -
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).

- 94 -
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:

- 95 -
• 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.

- 96 -
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

- 97 -
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

- 98 -
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.

- 99 -
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

- 100 -
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

- 101 -
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 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.

- 102 -
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

- 103 -
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.

- 104 -
• 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.

- 105 -
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

- 106 -
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).

- 107 -
• 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,

- 108 -
Figura 63: Objetos del modelo de coordinación

- 109 -
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.

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

- 111 -
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.

- 112 -
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

- 113 -
• 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).

- 114 -
Figura 67: Notación Agentes MSC

Actividad: Identificación de las intervenciones que constituyen las


conversaciones y de los servicios requeridos en cada conversación

• 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.

- 115 -
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.

- 116 -
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.

- 117 -
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.

- 118 -
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

- 119 -
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.

- 120 -
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

- 121 -
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.

- 122 -
• 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.

- 123 -
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

- 124 -
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
asimismo la modificación de los modelos relacionados y, en especial, del modelo de

- 125 -
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.

- 126 -
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.

- 127 -
• 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.

- 128 -
• 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.

- 129 -
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.

- 130 -
• 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.

- 131 -
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.

- 132 -
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.

- 133 -
• 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.

- 134 -
• 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

- 135 -
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.

- 136 -
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:

- 137 -
• ¿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.

- 138 -
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.

- 139 -
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,

- 140 -
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.

- 141 -
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.

- 142 -
• 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.

- 143 -
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.

- 144 -
• 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.

- 145 -
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.

- 146 -
• 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.

- 147 -
- 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.

- 148 -
3.8 APLICACION DE CASO DE ESTUDIO “SMA SUBASTAS” EN MAS-
commonKads

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:

- 149 -
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 Descripción Casos de uso


Subastador 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
Postor Se realiza una búsqueda Buscar Artículos
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.
Portor Se realiza la puja por el Realizar puja
artículo seleccionado,
según criterios de riesgo
beneficio
Subastador 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”

Descripció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.
Actores: Subastador.
Precondición: Debe existir un artículo a subastar

- 150 -
con su respectivo precio, así cono
postores registrados.
Excepción: No sé a incluido artículo a
subastar.

Caso de uso “Buscar Artículos”

Descripción: Se identifica la presencia de un


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

Caso de uso “Realizar Puja”

Descripción: Se realiza la puja por el artículo


seleccionado, según criterios de
riesgo beneficio.
Actores: Postor.
Precondición: El precio del artículo aumentado
para realizar la puja no sobrepasa
el monto disponible.
Excepción: El precio es muy alto para
competir.

Caso de uso “Anunciar Ganador”

Descripció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.
Actores: Subastador.
Precondición: Se recibió la puja de un postor, la
cual es mayor a la puja o ganadora

- 151 -
en el momento.
Excepción:

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)

AGENTE: SUBASTADOR CLASE: SOFTWARE


Objetivo Planes Conocimiento Colaborador Servicio
Identificar qué Analizar el Que metodología
tipo de subasta articulo es la más
se aplicara apropiada según
el articulo
Ofrecer subasta Ofrecer artículo, Ofrecer subastas
con tipo de
subasta, precio
inicial.
Decidir ganador Recibir pujas e Tiempo limiten Agente postor Terminar subasta
informar la y decidir
mayor hasta ganador.
cumplir el
tiempo limite

Tarjeta CRC para subastador

- 152 -
AGENTE: POSTOR CLASE: SOFTWARE
Objetivo Planes Conocimiento Colaborador Servicio
Identificar Reconocer Precio, Inscribirse e la
Subasta subastas de subasta
interés que no
sobrepasen el
tope.
Pujar Realizar puja por formulas para Pujar
el articulo realizar pujas

Tarjeta CRC para postor

- 153 -
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.

Pública subasta Realiza puja Decide ganador


Subastador X X
Postor 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

- 154 -
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

Representación Reglas matemáticas


Tipo De acuerdo al acaso
Grado de Confiabilidad Al utilizar un operador randomico es
impreciso.
Esquema de procesamiento No cambia con el tiempo

- 155 -
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.

La conversación de los agentes es lineal, solo se interesa en hacer llegar el mensaje


correspondiente a su destino.

- 156 -
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
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.

- 157 -
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
Finalización de subasta
condición-terminación
Finalización de timer.
tiempo-ejecución

- 158 -
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.

- 159 -
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.

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

- 160 -
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 Objetivo del acto de habla
Tipo 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.

Acto de habla: Nombre del acto de habla


Objetivo Objetivo del acto de habla
Tipo 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

- 161 -
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.

Acto de habla: Nombre del acto de habla


Objetivo Objetivo del acto de habla
Tipo 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.

3.8.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.
Por lo tanto es exclusividad a tratar a qui la relación agente soft- agente soft, pues no se
evidencia interacion humana

- 162 -
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,

- 163 -
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 MAS-
CommonKADS (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 MAS-


CommonKADS. MASINA se basa en el mismo ciclo de desarrollo del MAS-
CommonKADS, pero reduce a cinco sus siete modelos, con los cuales describe las
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.

- 164 -
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-
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

- 165 -
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 Entrada / Requiere


salida
Entorno
Ingrediente Capacidades
Nombre
Nombre Habilidades
Restricciones
Contenido Lenguaje RC
Sistemas
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.

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

- 166 -
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

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

- 167 -
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
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

- 168 -
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
éxito.
Condición de terminación Condiciones entre los agentes tras el
desarrollo de la conversación.
Figura 87: Descripción de la conversación de los agentes

- 169 -
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).

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.

- 170 -
Acto de habla: Nombre del acto de habla
Objetivo Objetivo del acto de habla
Tipo 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.
Figura 89 Modelo de Comunicación]

- 171 -
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 Descripción Casos de uso


Subastador 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
Postor Se realiza una búsqueda Buscar Artículos

- 172 -
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.
Portor Se realiza la puja por el Realizar puja
artículo seleccionado,
según criterios de riesgo
beneficio
Subastador 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”

Descripció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.
Actores: Subastador.
Precondición: Debe existir un artículo a subastar
con su respectivo precio, así cono
postores registrados.
Excepción: No sé a incluido artículo a
subastar.

Caso de uso “Buscar Artículos”

Descripción: Se identifica la presencia de un


artículo y se anuncia el interés de
participar en la subasta...
Actores: Subastador.
Precondición: Debe existir un artículo a subastar
con su respectivo precio, y este no

- 173 -
sobrepase el dinero disponible.
Excepción: No sé han incluido artículos a
subastar. O el precio sobrepasa el
monto disponible.

Caso de uso “Realizar Puja”

Descripción: Se realiza la puja por el artículo


seleccionado, según criterios de
riesgo beneficio.
Actores: Postor.
Precondición: El precio del artículo aumentado
para realizar la puja no sobrepasa
el monto disponible.
Excepción: El precio es muy alto para
competir.

Caso de uso “Anunciar Ganador”

Descripció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.
Actores: Subastador.
Precondición: Se recibió la puja de un postor, la
cual es mayor a la puja o ganadora
en el momento.
Excepción:

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

- 174 -
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)

AGENTE: SUBASTADOR CLASE: SOFTWARE


Objetivo Planes Conocimiento Colaborador Servicio
Identificar qué Analizar el Que metodología
tipo de subasta articulo es la más
se aplicara apropiada según
el articulo
Ofrecer subasta Ofrecer artículo, Ofrecer subastas
con tipo de
subasta, precio
inicial.
Decidir ganador 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: POSTOR CLASE: SOFTWARE


Objetivo Planes Conocimiento Colaborador Servicio
Identificar Reconocer Precio, Inscribirse e la
Subasta subastas de subasta
interés que no
sobrepasen el
tope.
Pujar Realizar puja por formulas para Pujar
el articulo realizar pujas

Tarjeta CRC para postor

- 175 -
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.

Pública subasta Realiza puja Decide ganador


Subastador X X
Postor 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.

- 176 -
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

Representación Reglas matemáticas


Tipo De acuerdo al acaso
Grado de Confiabilidad Al utilizar un operador randomico es
impreciso.
Esquema de procesamiento No cambia con el tiempo

- 177 -
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
conversaciones puede ser gráfica, empleamos los diagramas de caso de uso internos, y
textual, con la plantilla del constituyente Conversación.

- 178 -
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
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.

- 179 -
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
Finalización de subasta
condición-terminación
Finalización de timer.
tiempo-ejecución

- 180 -
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.

- 181 -
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

Holandesa Inglesa (Predeterminada) 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.

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

- 182 -
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 Objetivo del acto de habla
Tipo 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.

Acto de habla: Nombre del acto de habla


Objetivo Objetivo del acto de habla
Tipo 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

- 183 -
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.

Acto de habla: Nombre del acto de habla


Objetivo Objetivo del acto de habla
Tipo 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.

- 184 -
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.

- 185 -
- 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.

- 186 -
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 Efectores
Figura 93: 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

- 187 -
• 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.

- 188 -
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

- 189 -
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
Agente Visualizador. Esto refleja el hecho de que el proceso de desarrollo es

- 190 -
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.

- 191 -
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

- 192 -
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

- 193 -
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

- 194 -
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?

- 195 -
• ¿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 tiempo-
grano 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.

- 196 -
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.

- 197 -
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 (no-
divisible) 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

- 198 -
• 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 Para los factores inhibitorios,


hecho no está presente adentro e.g. un hecho producido que
localmente inhibirá la producción hasta
que se quita
Se lee El hecho no se consume, es Para los artículos de la
solamente decir sobrevive ejecución de la información, e.g. un
tarea, pero mientras tanto no se expediente del empleado
asigna exclusivamente a la
tarea
Debe estar en El hecho debe estar en propia Para los artículos que no
base de datos posesión local del agente, previene deben ser comprados
el agente que la obtiene de otro adentro, e.g. impulsión a
local
agente trabajar si un coche está
presente, pero no comprar
uno
Es el uso El hecho será asignado a la tarea Para las entidades
posterior para la duración de su ejecución, persistentes capaces de
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.

- 199 -
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

- 200 -
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

- 201 -
• 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.

- 202 -
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.

- 203 -
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 multi-
agente ("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

- 204 -
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

- 205 -
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.

- 206 -
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).

- 207 -
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.

- 208 -
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 round-
robin 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.

- 209 -
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.

- 210 -
Clase SequentialBehaviour: Esta clase deriva de CompositeBehaviour y ejecuta sub-
behaviours de forma secuencial, y termina cuando todos los métodos action() han
terminado.

Clase ParallelBehaviour: Esta clase deriva de CompositeBehaviour y ejecuta los sub-


behaviours 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.

- 211 -
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:

- 212 -
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.]

- 213 -
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.

- 214 -
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.

- 215 -
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.

- 216 -
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.

- 217 -
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;

- 218 -
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:

- 219 -
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.

- 220 -
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.

- 221 -
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.

- 222 -
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.

- 223 -
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.

- 224 -
Análisis

Los criterios del Análisis incluyen:

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

Ingenias 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- MAS-CommonKADS ha sido la primera en plantear un desarrollo de SMA
commonKads 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.
Masina Poco documentada por no abrece liberado la metodología, pero fuerte al ser
una extensión de Mas commonKads.
Zeus El análisis se debe a voluntad del desarrollador Basado en el modelado de
roles, utilizando diagramas de clase UML y patrones.
Jade Jade es una plataforma exclusiva para el desarrollo.

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

Ingenias A todo tipo de problemas, puesto que combina el esfuerzo metodológico con
el desarrollo de la herramienta.
Mas- Tiene un rango muy amplio de aplicabilidad, por su capacidad de especificar
commonKads Sistemas Multi agentes.
Masina 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
Zeus Es una herramienta para construir aplicaciones multi-agente colaborativas.
Que provee un entorno integrado para el desarrollo rápido de sistemas
Jade Jade es una plataforma exclusiva para el desarrollo.

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

Ingenias Es un esfuerzo arduo, para poder entenderlo, para aplicarlo pero después de
comprenderlo, resulta muy completo y eficiente.

- 225 -
Mas- Muy engorroso pero al entenderlo se puede moldear para adecuarlo al
commonKads problema a enfocar.
Masina Al igual que más commonKads, es muy flexible y se puede adecuar al
problema.
Zeus El método es arbitrario, y escogido por el desarrollador.
Jade 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 Muy documentado y respaldado por el grupo GRASIA. La herramienta


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

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

Ingenias No se han dado limitantes a los tipos de MAS


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

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

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

- 226 -
ellos.
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 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.
Mas- La reusabilidad es grande pues sus modelos permiten la reutilización.
commonKads
Masina La reusabilidad es grande pues sus modelos permiten la reutilización.
Zeus Poca es manual.
Jade 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 INGENIAS IDE, excelente herramienta permite el modelado como la


exportación para generar código.
Mas- Herramientas en desarrollo no se ha liberado, por lo tanto esta parte de
commonKads desarrollo es enfocado a desarrollo manual.
Masina Sin herramientas.
Zeus Zeus Agent Building Toolkit, excelente utilidad vasada en roles que facilita
la creación de los armazones.
Jade 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 Si se posee un gran conocimiento de la metodología así como de su


herramienta el grupo GRASIA no ha encontrado limitantes ha esta.
Mas- Aborda con su extensa especificación y el desarrollo de los MAS, la
commonKads limitante es su especificación que depende de la habilidad del desarrollador.
Masina Enfocada a la inteligencia como eje fundamental.
Zeus 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.
Jade Excelente Herramienta con la libertad de crear el código, el respaldo de

- 227 -
FIPA, es para juicio del autor la mejor pues cuenta con todos los protocolos,
y se puede manejar tal como jade.

- Complejidad: ¿son las herramientas de desarrollo y los lenguajes fáciles de utilizar?


¿Cómo es de popular el lenguaje utilizado?

Ingenias Posee un manual el cual es muy completo pero largo, el grupo Grasia lo
promueve por su completitud y constante desarrollo.
Mas- Herramienta en desarrollo, muy popular pues ha sido base para
commonKads implementación y guía de otras metodologías.
Masina No posee, herramienta.
Zeus 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.
Jade 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 El grupo GRASIA ofrece su apoyo, para dar soporte a aquellos que se
interesen en empezar esta práctica.
Mas- No posee soporte, además de la ayuda del propio autor.
commonKads
Masina No posee soporte, además de la ayuda del propio autor.
Zeus Soporte directo con el grupo Intelligent Systems Research Group, BT Labs.
Jade 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 Si
Mas- No
commonKads
Masina No
Zeus Limitada, En la actualidad se trabaja con la versión zeus-2-0-e.
Jade Constante , en http://jade.tilab.com/

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

- 228 -
Ingenias Son extensas y engorrosas, pero al fin entenderlas poseen gran capacidad.
Mas- --
commonKads
Masina --
Zeus Es complicado el estudio y extenso sus manuales, pero unas ves
comprendido fácil uso.
Jade 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 Libre, free


Mas- Libre, free
commonKads
Masina Libre, free
Zeus GNU
Jade 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 Si por el grupo GRASIA, y pequeños grupos de investigación.


Mas- Si
commonKads
Masina Poco, pues no se ha liberado la metodología a la fecha de esta tesis
Zeus Estancada, su uso primordial es para la creación de prototipos.
Jade 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.

- 229 -
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.

- 230 -
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.

- 231 -
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.
[40] A Design for the Icarus Architecture To appear in Proceedings of
the AAAI Spring Symposium on Integrated Intelligent Architectures_ Stanford_
Integrated Intelligent Architectures_ Stanford_ CA_ ____
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/principa
l.html
Visitada: mayo 2006
[7] Tecnología de agentes y sus aplicaciones Revista de
Telecomunicaciones de Alcatel, Primer trimestre de 1999
http://www.mipagina.cantv.net/vmendillo/Tesis/Agentes.htm
Visitada: Octubre 2006
[8] Universidad de Concepción, Sistemas multiagente,
atkinson@inf.udec.cl
Jornadas Chilenas de Computación, Noviembre 2005, Valdivia
http://jcc2005.inf.uach.cl/documentos/tutorialAtkinson.pdf?PHPSESSID=de8e8ç

ii
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 Systems)
http://www.emis.de/journals/SADIO/vol.3.1/Avancini.pdf
Visitada octubre 2006

iii
[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. dbagents@scch.at ... 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, jamie.stark@bt.com.
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
Visitada marzo 2006

iv
[27] [PDF] ZEUS: An Advanced Tool-Kit for Engineering Distributed
Multi-Agent ... developing a clear methodology for building distributed multi-
agent 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
Visitada marzo 2006.

v
[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 real-
time constraints, ...
http://eksl.cs.umass.edu/research/phoenix.html
Visitada Octubre 2006

vi
[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/architecture
s.html
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. : simon.2.thompson@bt.com
http://labs.bt.com/projects/agents/zeus/ creadores de la herramienta Zeus

vii
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 :

A1
Entities appearing in this diagram :

NAME TYPE DESCRIPTION


It appears in diagrams:
Postor Agent
• Agent Rol asosiacion: AgentModel
• Ojetivos y tareas: TasksAndGoalsModel
• Ambiente: EnvironmentModel

It appears in diagrams:
Subastador Agent
• Agent Rol asosiacion: AgentModel
• Ojetivos y tareas: TasksAndGoalsModel
• Ambiente: EnvironmentModel

It appears in diagrams:
Vender Role
• Agent Rol asosiacion: AgentModel
• modelo de interaccion: InteractionModel
• flujo de evento: InteractionModel

It appears in diagrams:
Compar Role
• Agent Rol asosiacion: AgentModel
• modelo de interaccion: InteractionModel
• flujo de evento: InteractionModel

Relationships appearing in this diagram:

TYPE SOURCE TARGET


WFPlays Postor Compar
WFPlays Vender Subastador
WFPlays Vender Subastador
WFPlays Postor Compar

Diagram name : Ojetivos y tareas


Diagram type : TasksAndGoalsModel
Description :

A2
Entities appearing in this diagram :

NAME TYPE DESCRIPTION


It appears in diagrams:
Maximizar precio Goal
• Ojetivos y tareas: TasksAndGoalsModel

It appears in diagrams:
Pujar bajo Goal
• Ojetivos y tareas: TasksAndGoalsModel
• flujo de evento: InteractionModel

It appears in diagrams:
Suba precio Goal
• Ojetivos y tareas: TasksAndGoalsModel
• flujo de evento: InteractionModel

It appears in diagrams:
Postor Agent
• Agent Rol asosiacion: AgentModel
• Ojetivos y tareas: TasksAndGoalsModel
• Ambiente: EnvironmentModel

It appears in diagrams:
Subastador Agent
• Agent Rol asosiacion: AgentModel
• Ojetivos y tareas: TasksAndGoalsModel
• Ambiente: EnvironmentModel

It appears in diagrams:
Minimizar precio Goal
• Ojetivos y tareas: TasksAndGoalsModel

A3
Relationships appearing in this diagram:

TYPE SOURCE TARGET


Contribute Suba precio Maximizar precio
GTPursues Postor Pujar bajo
Contribute Pujar bajo Minimizar precio
GTPursues Suba precio Subastador
Contribute Suba precio Maximizar precio
GTPursues Postor Pujar bajo
GTPursues Suba precio Subastador
Contribute Pujar bajo Minimizar precio

Diagram name : modelo de interaccion


Diagram type : InteractionModel
Description :

A4
Entities appearing in this diagram :

NAME TYPE DESCRIPTION


It appears in diagrams:
Vender Role
• Agent Rol asosiacion: AgentModel
• modelo de interaccion:
InteractionModel
• flujo de evento: InteractionModel

It appears in diagrams:
UMLSpecification22 UMLSpecification
• modelo de interaccion:
InteractionModel

It appears in diagrams:
Subasta en Interaction
ejecucion
• modelo de interaccion:
InteractionModel

It appears in diagrams:
Compar Role
• Agent Rol asosiacion: AgentModel
• modelo de interaccion:
InteractionModel
• flujo de evento: InteractionModel

Relationships appearing in this diagram:

TYPE SOURCE TARGET


IInitiates Subasta en ejecucion Vender
IHasSpec Subasta en ejecucion UMLSpecification22
IHasSpec Subasta en ejecucion UMLSpecification22
IInitiates Subasta en ejecucion Vender
IInitiates Subasta en ejecucion Compar
IInitiates Subasta en ejecucion Compar

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

Entities appearing in this diagram :

NAME TYPE DESCRIPTION


It appears in diagrams:
informar venta MessagePassing
• flujo de evento: InteractionModel

It appears in diagrams:
Vender Role
• Agent Rol asosiacion: AgentModel
• modelo de interaccion: InteractionModel
• flujo de evento: InteractionModel

It appears in diagrams:
Compar Role
• Agent Rol asosiacion: AgentModel
• modelo de interaccion: InteractionModel
• flujo de evento: InteractionModel

It appears in diagrams:
informar compra MessagePassing
• flujo de evento: InteractionModel

It appears in diagrams:
Suba precio Goal
• Ojetivos y tareas: TasksAndGoalsModel

A6
• flujo de evento: InteractionModel

It appears in diagrams:
Comprar articulo Task
• flujo de evento: InteractionModel

It appears in diagrams:
Pujar bajo Goal
• Ojetivos y tareas: TasksAndGoalsModel
• flujo de evento: InteractionModel

It appears in diagrams:
Comienza Interaction
subasta
• flujo de evento: InteractionModel

It appears in diagrams:
vender articulo Task
• flujo de evento: InteractionModel

Relationships appearing in this diagram:

TYPE SOURCE TARGET


UIPrecedes Comienza subasta informar venta
UIInitiates vender articulo Vender informar venta
GTPursues Suba precio Vender
UIInitiates vender articulo Vender informar venta
UIInitiates Compar Comprar articulo informar compra
GTPursues Compar Pujar bajo
UIInitiates Compar Comprar articulo informar compra
UIPrecedes informar compra Comienza subasta
GTPursues Suba precio Vender
UIInitiates Compar Comprar articulo informar compra
GTPursues Compar Pujar bajo
UIPrecedes informar compra Comienza subasta
UIPrecedes Comienza subasta informar venta
UIInitiates vender articulo Vender informar venta

A7
Diagram name : Ambiente
Diagram type : EnvironmentModel
Description :

Entities appearing in this diagram :

NAME TYPE DESCRIPTION


It appears in diagrams:
SubastaEnvironment EnvironmentApplication
• Ambiente:
EnvironmentModel

It appears in diagrams:
Postor Agent
• Agent Rol asosiacion:
AgentModel
• Ojetivos y tareas:
TasksAndGoalsModel
• Ambiente:
EnvironmentModel

It appears in diagrams:
Articulos Resource
• Ambiente:
EnvironmentModel

It appears in diagrams:
Subastador Agent
• Agent Rol asosiacion:
AgentModel
• Ojetivos y tareas:
TasksAndGoalsModel

A8
• Ambiente:
EnvironmentModel

Relationships appearing in this diagram:

TYPE SOURCE TARGET


ApplicationBelongsTo SubastaEnvironment Subastador
ApplicationBelongsTo Postor SubastaEnvironment
ApplicationBelongsTo Postor SubastaEnvironment
EResourceBelongsTo Articulos Subastador
EResourceBelongsTo Articulos Subastador
ApplicationBelongsTo SubastaEnvironment Subastador

A9
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/commons-


codec/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

A10
• 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 INT NUMERO;


PRIVATE INT TIPO; //COMPRADOR-VENDEDOR-PIZARRA
PRIVATE STRING NOMBRE="";
PRIVATE 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;
}

A11
PUBLIC STRING GETNOMBRE(){
RETURN THIS.NOMBRE;
}

PUBLIC VOID SETNOMBRE(STRING NOMBRE){


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;
}

A12
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();
}

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);

A13
}

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() {


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();
}

A14
Comprador.java

/*****************************************************************
ESTE AGENTE IMPLEMENTA LA FUNCIONALIDAD DE UN COMPRADOR EN UN
PROCESO DE SUBASTA TIPO AMERICANA
*****************************************************************/

PACKAGE SUBASTA;

IMPORT JAVA.UTIL.*;

IMPORT JAVA.IO.STRINGREADER;
IMPORT JAVA.IO.OUTPUTSTREAMWRITER;
IMPORT JAVA.IO.BUFFEREDWRITER;
IMPORT JAVA.IO.BUFFEREDREADER;
IMPORT JAVA.IO.INPUTSTREAMREADER;
IMPORT JAVA.IO.INTERRUPTEDIOEXCEPTION;
IMPORT JAVA.IO.IOEXCEPTION;
IMPORT JAVA.IO.PRINTWRITER;

IMPORT JAVA.LANG.MATH;

IMPORT JADE.CORE.*;
IMPORT JADE.CORE.BEHAVIOURS.*;

IMPORT JADE.LANG.ACL.ACLMESSAGE;

IMPORT JADE.DOMAIN.FIPAAGENTMANAGEMENT.SERVICEDESCRIPTION;
IMPORT JADE.DOMAIN.FIPAAGENTMANAGEMENT.DFAGENTDESCRIPTION;
IMPORT JADE.DOMAIN.FIPAAGENTMANAGEMENT.SEARCHCONSTRAINTS;
IMPORT JADE.DOMAIN.DFSERVICE;
IMPORT JADE.DOMAIN.FIPAEXCEPTION;
IMPORT JADE.DOMAIN.FIPANAMES;

PUBLIC CLASS COMPRADOR EXTENDS AGENT {

AID AGENTEPIZARRA; // IDENTIFICADOR DE LA PIZARRA DE OFERTAS

A15
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
* 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

A16
* 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");
}

ELSE IF
(MENSAJEENTRANTE.GETCONTENT().INDEXOF("FIN DE SUBASTA") != -1) {
SYSTEM.OUT.PRINTLN(GETLOCALNAME() + "-
>"
+
MENSAJEENTRANTE.GETCONTENT());
INICIALIZAR();

ELSE {
SYSTEM.OUT.PRINTLN(GETLOCALNAME()

A17
+ "-> 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(),
GETLOCALNAME(),
OFTA.GETPRODUCTO(), PRECIOACTUAL);

MENSAJESALIENTE.SETPERFORMATIVE(ACLMESSAGE.PROPOSE);
MENSAJESALIENTE

.SETPROTOCOL(FIPANAMES.INTERACTIONPROTOCOL.FIPA_ENGLISH_A
UCTION);

A18
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
TRY {
// SE CONSTRUYE LA DESCRIPCION USADA COMO
PLANTILLA PARA LA

A19
// 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);

A20
MENSAJEREGISTRO.SETCONTENT("COMPRADOR");
MENSAJEREGISTRO

.SETPROTOCOL(FIPANAMES.INTERACTIONPROTOCOL.FIPA_SUBSCRIBE)
;
MENSAJEREGISTRO.ADDRECEIVER(AGENTEPIZARRA);
SEND(MENSAJEREGISTRO);

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

// ****************************************************************************//

A21
PRIVATE VOID INICIALIZAR() {
OBJECT[] ARGS = GETARGUMENTS();// RECIBE LOS
ARGUMENTOS
IF (ARGS != NULL && ARGS.LENGTH > 0) {
SETPRECIOCOMPRABASE(NEW
FLOAT(ARGS[0].TOSTRING()));
}

/**
* 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();

A22
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();
}

// 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
*****************************************************************/

A23
PACKAGE SUBASTA;

IMPORT JAVA.UTIL.*;

IMPORT JAVA.IO.STRINGREADER;
IMPORT JAVA.IO.OUTPUTSTREAMWRITER;
IMPORT JAVA.IO.BUFFEREDWRITER;
IMPORT JAVA.IO.BUFFEREDREADER;
IMPORT JAVA.IO.INPUTSTREAMREADER;
IMPORT JAVA.IO.INTERRUPTEDIOEXCEPTION;
IMPORT JAVA.IO.IOEXCEPTION;
IMPORT JAVA.IO.PRINTWRITER;
IMPORT JAVA.LANG.*;

IMPORT JADE.CORE.*;
IMPORT JADE.CORE.BEHAVIOURS.*;

IMPORT JADE.LANG.ACL.ACLMESSAGE;

IMPORT JADE.DOMAIN.FIPAAGENTMANAGEMENT.SERVICEDESCRIPTION;
IMPORT JADE.DOMAIN.FIPAAGENTMANAGEMENT.DFAGENTDESCRIPTION;
IMPORT JADE.DOMAIN.FIPAAGENTMANAGEMENT.SEARCHCONSTRAINTS;
IMPORT JADE.DOMAIN.DFSERVICE;
IMPORT JADE.DOMAIN.FIPAEXCEPTION;
IMPORT JADE.DOMAIN.FIPANAMES;
IMPORT 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(){

A24
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 {

AID EMISOR;
STRING CONTENIDO = "";

PUBLIC RECIBIRMENSAJESBEHAVIOUR(AGENT A) {
SUPER(A);
}

PUBLIC VOID ACTION() {

ACLMESSAGE MENSAJEENTRANTE =
BLOCKINGRECEIVE();
ACLMESSAGE MENSAJESALIENTE =
MENSAJEENTRANTE.CREATEREPLY();

A25
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.INTERACTIONPROTOCO
L.FIPA_ENGLISH_AUCTION);
SEND(MENSAJESALIENTE);
NUMEROOFERTAS++;
}
ELSE{

MENSAJESALIENTE.SETPERFORMATIVE(ACLMESSAGE.DISCONFIRM);
MENSAJESALIENTE.SETCONTENT("SE ME
ACABARON LOS PRODUCTOS");

MENSAJESALIENTE.SETPROTOCOL(FIPANAMES.INTERACTIONPROTOCO
L.FIPA_ENGLISH_AUCTION);
SEND(MENSAJESALIENTE);

}
}

IF(MENSAJEENTRANTE != NULL &&


MENSAJEENTRANTE.GETPERFORMATIVE()==ACLMESSAGE.DISCONFIRM &&

A26
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;
}

PUBLIC VOID ACTION() {

// BUSCA EL AGENTE QUE PRESTA EL SERVICIO DE


PIZARRA

A27
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);

A28
MENSAJEREGISTRO.SETPROTOCOL(FIPANAMES.INTERACTIONPROTOCO
L.FIPA_SUBSCRIBE);
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();

A29
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]);
}
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

A30
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);

}
}

Pizarra.java

/*****************************************************************
ESTE AGENTE IMPLEMENTA LA FUNCIONALIDAD DE UNA PIZARRA EN UN
PROCESO DE SUBASTA TIPO AMERICANA
*****************************************************************/

PACKAGE SUBASTA;

IMPORT JAVA.UTIL.*;

IMPORT JAVA.IO.STRINGREADER;
IMPORT JAVA.IO.OUTPUTSTREAMWRITER;
IMPORT JAVA.IO.BUFFEREDWRITER;
IMPORT JAVA.IO.BUFFEREDREADER;
IMPORT JAVA.IO.INPUTSTREAMREADER;
IMPORT JAVA.IO.INTERRUPTEDIOEXCEPTION;
IMPORT JAVA.IO.IOEXCEPTION;
IMPORT JAVA.IO.PRINTWRITER;

A31
IMPORT JADE.CORE.*;
IMPORT JADE.CORE.BEHAVIOURS.*;

IMPORT JADE.LANG.ACL.ACLMESSAGE;

IMPORT JADE.DOMAIN.FIPAAGENTMANAGEMENT.SERVICEDESCRIPTION;
IMPORT JADE.DOMAIN.FIPAAGENTMANAGEMENT.DFAGENTDESCRIPTION;
IMPORT JADE.DOMAIN.DFSERVICE;
IMPORT JADE.DOMAIN.FIPAEXCEPTION;
IMPORT 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 {

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)

A32
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() {

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();

A33
SYSTEM.OUT.PRINTLN(GETLOCALNAME() + "-
> RECIBIENDO REGISTRO DE: " + EMISOR.GETNAME());

MENSAJESALIENTE.SETPERFORMATIVE(ACLMESSAGE.CONFIRM);

MENSAJESALIENTE.SETPROTOCOL(FIPANAMES.INTERACTIONPROTOCO
L.FIPA_SUBSCRIBE);
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].GETLO
CALNAME());
NUMEROAGENTESVENDEDORES++;
}
ELSE IF (CONTENIDO != NULL &&
CONTENIDO.EQUALS("COMPRADOR")){
EMISOR = MENSAJEENTRANTE.GETSENDER();
SYSTEM.OUT.PRINTLN(GETLOCALNAME() + "-
> RECIBIENDO REGISTRO DE: " + EMISOR.GETNAME());

MENSAJESALIENTE.SETPERFORMATIVE(ACLMESSAGE.CONFIRM);

MENSAJESALIENTE.SETPROTOCOL(FIPANAMES.INTERACTIONPROTOCO
L.FIPA_SUBSCRIBE);
MENSAJESALIENTE.SETCONTENT("REGISTRO
EXITOSO EN LA PIZARRA DE OFERTAS");
// SE ADICIONA EL AGENTE AL VECTOR DE
AGENTES REGISTRADOS

AGENTESCOMPRADORESREGISTRADOS[NUMEROAGENTESCOMPRADOR
ES] = EMISOR;

A34
INTERFAZ.ADICIONARTEXTOAGENTESREGISTRADOS("AGENTE
COMPRADOR: " +
AGENTESCOMPRADORESREGISTRADOS[NUMEROAGENTESCOMPRADORES].GE
TLOCALNAME());
NUMEROAGENTESCOMPRADORES++;
}
ELSE{

MENSAJESALIENTE.SETPERFORMATIVE(ACLMESSAGE.DISCONFIRM);

MENSAJESALIENTE.SETPROTOCOL(FIPANAMES.INTERACTIONPROTOCO
L.FIPA_SUBSCRIBE);
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() ==
FIPANAMES.INTERACTIONPROTOCOL.FIPA_ENGLISH_AUCTION &&
MENSAJEENTRANTE.GETPERFORMATIVE()==ACLMESSAGE.INFORM){

CONTENIDO = MENSAJEENTRANTE.GETCONTENT();
ACLMESSAGE MENSAJESALIENTE =
MENSAJEENTRANTE.CREATEREPLY();

A35
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[NUMEROOFERT
AS].TOSTRING());

MENSAJESALIENTE.SETPROTOCOL(FIPANAMES.INTERACTIONPROTOCO
L.FIPA_ENGLISH_AUCTION);

MENSAJESALIENTE.SETPERFORMATIVE(ACLMESSAGE.ACCEPT_PROPO
SAL);
MENSAJESALIENTE.SETCONTENT("OFERTA
REGISTRADA");
SEND(MENSAJESALIENTE);

NUMEROOFERTAS++;

// MANDAR MENSAJE A LOS COMPRADORES


IF (NUMEROOFERTAS ==
NUMEROAGENTESVENDEDORES){
ACLMESSAGE MENSAJEOFERTAS =
NEW ACLMESSAGE(ACLMESSAGE.INFORM);

A36
MENSAJEOFERTAS.SETPROTOCOL(FIPANAMES.INTERACTIONPROTOCO
L.FIPA_ENGLISH_AUCTION);
FOR (INT I=0; I<NUMEROOFERTAS;
I++){

MENSAJEOFERTAS.SETCONTENT(OFERTAS[I].TOSTRING());
FOR (INT J=0;
J<NUMEROAGENTESCOMPRADORES; J++){

MENSAJEOFERTAS.ADDRECEIVER(AGENTESCOMPRADORESREGISTRA
DOS[J]);
}
}
SEND(MENSAJEOFERTAS);
}

}
ELSE{

MENSAJESALIENTE.SETPROTOCOL(FIPANAMES.INTERACTIONPROTOCO
L.FIPA_ENGLISH_AUCTION);

MENSAJESALIENTE.SETPERFORMATIVE(ACLMESSAGE.DISCONFIRM);
MENSAJESALIENTE.SETCONTENT("SE
ESPERABA UN MENSAJE DE OFERTA");
SEND(MENSAJESALIENTE);
}

IF(MENSAJEENTRANTE != NULL && INICIADA &&


MENSAJEENTRANTE.GETPROTOCOL() ==
FIPANAMES.INTERACTIONPROTOCOL.FIPA_ENGLISH_AUCTION &&
MENSAJEENTRANTE.GETPERFORMATIVE()==ACLMESSAGE.PROPOSE){

CONTENIDO = MENSAJEENTRANTE.GETCONTENT();
ACLMESSAGE MENSAJESALIENTE =
MENSAJEENTRANTE.CREATEREPLY();

A37
IF (CONTENIDO != NULL){

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
[NUMEROCONTRAOFERTAS].TOSTRING());

MENSAJESALIENTE.SETPROTOCOL(FIPANAMES.INTERACTIONPROTOCO
L.FIPA_ENGLISH_AUCTION);

MENSAJESALIENTE.SETPERFORMATIVE(ACLMESSAGE.ACCEPT_PROPO
SAL);
MENSAJESALIENTE.SETCONTENT("CONTRA
OFERTA REGISTRADA");
SEND(MENSAJESALIENTE);

IF (OFERTAACTUAL.GETPRECIO() >
OFERTAGANADORA.GETPRECIO()){
OFERTAGANADORA =
OFERTAACTUAL;
}

NUMEROCONTRAOFERTAS++;
NUMEROPUJAS++;

A38
// INFORMAR LA CONTRA OFERTA
GANADORA AL FINAL DE LA SUBASTA
//AQUI TERMINA LA SUBASTA
IF (NUMEROPUJAS ==
NUMEROMAXIMOPUJAS){
INICIADA = FALSE;
ACLMESSAGE MENSAJEFINSUBASTA =
NEW ACLMESSAGE(ACLMESSAGE.INFORM);

MENSAJEFINSUBASTA.SETPROTOCOL(FIPANAMES.INTERACTIONPROTO
COL.FIPA_ENGLISH_AUCTION);
FOR (INT K=0; K<NUMEROOFERTAS;
K++){

MENSAJEFINSUBASTA.SETCONTENT("FIN DE SUBASTA,
CONTRAOFERTA GANADORA: " + OFERTAGANADORA.TOSTRING());
// SE MUESTRA EN LA
INTERFAZ

INTERFAZ.ADICIONARTEXTOAREARESULTADOS("CONTRA OFERTA
GANADORA: " + OFERTAGANADORA.TOSTRING());
FOR (INT I=0;
I<NUMEROAGENTESVENDEDORES; I++){

MENSAJEFINSUBASTA.ADDRECEIVER(AGENTESVENDEDORESREGISTR
ADOS[I]);
}
FOR (INT J=0;
J<NUMEROAGENTESCOMPRADORES; J++){

MENSAJEFINSUBASTA.ADDRECEIVER(AGENTESCOMPRADORESREGIST
RADOS[J]);
}
NUMEROPUJAS = 0;
NUMEROOFERTAS = 0;
NUMEROCONTRAOFERTAS = 0;
OFERTAGANADORA = NEW
CONTRAOFERTA();

A39
SEND(MENSAJEFINSUBASTA);

MENSAJEFINSUBASTA.CLEARALLRECEIVER();

}
//AQUI TERMINA LA SUBASTA
// MANDAR MENSAJE A LOS COMPRADORES
SOBRE LA CONTRA OFERTA GANADORA HASTA EL MOMENTO
IF (NUMEROCONTRAOFERTAS ==
NUMEROAGENTESCOMPRADORES){
ACLMESSAGE MENSAJEOFERTAS =
NEW ACLMESSAGE(ACLMESSAGE.INFORM);

MENSAJEOFERTAS.SETPROTOCOL(FIPANAMES.INTERACTIONPROTOCO
L.FIPA_ENGLISH_AUCTION);
FOR (INT I=0; I<NUMEROOFERTAS;
I++){

MENSAJEOFERTAS.SETCONTENT(OFERTAGANADORA.TOSTRING());

SYSTEM.OUT.PRINTLN(GETLOCALNAME() + "-> OFERTA GANADORA: " +


OFERTAGANADORA.TOSTRING());
FOR (INT J=0;
J<NUMEROAGENTESCOMPRADORES; J++){

MENSAJEOFERTAS.ADDRECEIVER(AGENTESCOMPRADORESREGISTRA
DOS[J]);
}
}
SEND(MENSAJEOFERTAS);
NUMEROCONTRAOFERTAS = 0;
}

}
ELSE{

A40
MENSAJESALIENTE.SETPROTOCOL(FIPANAMES.INTERACTIONPROTOCO
L.FIPA_ENGLISH_AUCTION);

MENSAJESALIENTE.SETPERFORMATIVE(ACLMESSAGE.REJECT_PROPO
SAL);
MENSAJESALIENTE.SETCONTENT("SE
ESPERABA UN MENSAJE DE CONTRA OFERTA");
SEND(MENSAJESALIENTE);
}

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);

A41
MENSAJEINICIOSUBASTA.SETPROTOCOL(FIPANAMES.INTERACTIONPRO
TOCOL.FIPA_ENGLISH_AUCTION);
MENSAJEINICIOSUBASTA.SETCONTENT("INICIO DE
SUBASTA");
FOR (INT I=0; I<NUMEROAGENTESVENDEDORES; I++){

MENSAJEINICIOSUBASTA.ADDRECEIVER(AGENTESVENDEDORESREGIS
TRADOS[I]);
}
FOR (INT J=0; J<NUMEROAGENTESCOMPRADORES; J++){

MENSAJEINICIOSUBASTA.ADDRECEIVER(AGENTESCOMPRADORESREGI
STRADOS[J]);
}
SEND(MENSAJEINICIOSUBASTA);

} // 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");

A42
// 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);
ADDBEHAVIOUR(NEW
TICKERBEHAVIOUR(THIS,TIEMPOSUBASTA){//REINICIA LA SUBASTA CADA
TIEMPOSUBASTA
PROTECTED VOID ONTICK(){//PARA LLAMAR EL
MÉTODOS TICKERBEHAVIOUR

ENVIARINICIOSUBASTA();
INICIADA = TRUE;
//}

}
}
);
ADDBEHAVIOUR(RMBEHAVIOUR);

A43
} // 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();


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();

A44
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());

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);

A45
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));
JLABEL2.SETTEXT("LAS CONTRAOFERTAS RECIBIDAS SON:");

A46
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();

A47
}
// </EDITOR-FOLD>//GEN-END:INITCOMPONENTS

PRIVATE VOID CLOSEDIALOG(JAVA.AWT.EVENT.WINDOWEVENT EVT)


{//GEN-FIRST:EVENT_CLOSEDIALOG
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.
*/

A48
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");
}

/**
* 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

A49
Algunas impresiones de pantalla de la aplicación en ejecución:

A50
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.


*/

/*
THIS CODE WAS AUTOMATICALLY GENERATED BY ZEUSAGENTGENERATOR
VERSION 1.2.2
DO NOT MODIFY!!
*/

IMPORT JAVA.UTIL.*;
IMPORT JAVA.IO.*;
IMPORT ZEUS.UTIL.*;
IMPORT ZEUS.CONCEPTS.*;
IMPORT ZEUS.ACTORS.*;
IMPORT 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 <DNS_FILE> -O
<ONTOLOGY_FILE> [-GUI VIEWERPROG] [-E <EXTERNALPROG>] [-R
RESOURCEPROG] [-NAME <AGENTNAME>] [-DEBUG] [-H] [-V]");
SYSTEM.EXIT(0);
}

A51
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 )
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();

A52
}

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);

A53
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;
/*
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);

A54
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\\GNU-REGEXP.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) {

A55
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 (JARON@INFO.BT.CO.UK), MARCH 1999

A56
* PROVIDES AN EXAMPLE OF HOW TO INTERACT WITH AGENT RESOURCES
*****************************************************************************/

IMPORT JAVA.UTIL.*;
IMPORT JAVA.AWT.*;
IMPORT JAVA.AWT.EVENT.*;
IMPORT JAVA.IO.*;
IMPORT JAVAX.SWING.*;
IMPORT JAVAX.SWING.BORDER.*;

IMPORT ZEUS.UTIL.*;
IMPORT ZEUS.CONCEPTS.*;
IMPORT ZEUS.ACTORS.*;
IMPORT ZEUS.ACTORS.EVENT.*;
IMPORT 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 JBUTTON MOREAPPLESBTN;


PROTECTED JBUTTON MOREORANGESBTN;
PROTECTED JBUTTON MOREPEARSBTN;
PROTECTED JBUTTON MOREBANANASBTN;
PROTECTED JBUTTON MOREMELONSBTN;
PROTECTED JLABEL CASHLABEL;
PROTECTED TRADERFRONTEND UI;

PUBLIC STOCKPANEL(TRADERFRONTEND FRONTEND) {


UI = FRONTEND;

GRIDBAGLAYOUT GB = NEW GRIDBAGLAYOUT();


GRIDBAGCONSTRAINTS GBC = NEW GRIDBAGCONSTRAINTS();

A57
SETLAYOUT(GB);
SETBACKGROUND(COLOR.LIGHTGRAY);

SETBORDER(BORDERFACTORY.CREATEBEVELBORDER(BEVELBORDER.LOWE
RED));

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);

A58
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);

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);

A59
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;
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());

A60
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)
FRUIT = "APPLE";
IF (EVT.GETSOURCE() == MOREORANGESBTN)
FRUIT = "ORANGE";
IF (EVT.GETSOURCE() == MOREPEARSBTN)
FRUIT = "PEAR";
IF (EVT.GETSOURCE() == MOREBANANASBTN)
FRUIT = "BANANA";
IF (EVT.GETSOURCE() == MOREMELONSBTN)
FRUIT = "MELON";

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);
}
}

A61
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) ) {
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);
}

A62
}

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 JAVA.UTIL.*;
IMPORT JAVA.IO.*;
IMPORT ZEUS.UTIL.*;
IMPORT ZEUS.CONCEPTS.*;
IMPORT ZEUS.ACTORS.*;
IMPORT ZEUS.AGENTS.*;

PUBLIC CLASS SUBASRADORBOT {


PROTECTED STATIC VOID VERSION() {
SYSTEM.ERR.PRINTLN("ZEUSAGENT - SUBASRADORBOT VERSION: 1.2.2");
SYSTEM.EXIT(0);
}

PROTECTED STATIC VOID USAGE() {


SYSTEM.ERR.PRINTLN("USAGE: JAVA SUBASRADORBOT -S <DNS_FILE> -O
<ONTOLOGY_FILE> [-GUI VIEWERPROG] [-E <EXTERNALPROG>] [-R
RESOURCEPROG] [-NAME <AGENTNAME>] [-DEBUG] [-H] [-V]");
SYSTEM.EXIT(0);

A63
}

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 )
NAME = NAME + ARG[J];
ELSE IF ( ARG[J].EQUALS("-H") )
USAGE();
ELSE

A64
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 ) {

A65
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 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);

A66
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)))");
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\\GNU-REGEXP.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) {

A67
E.PRINTSTACKTRACE();
}
}
}

subastadorUI.java

/*****************************************************************************
* SUPPLYUI.JAVA
*
* INTERFACE BETWEEN SUPPLYBOT AND ITS TRADERFRONTEND GUI
*****************************************************************************/

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

A68
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.*;
IMPORT JAVA.IO.*;
IMPORT ZEUS.UTIL.*;
IMPORT ZEUS.CONCEPTS.*;
IMPORT ZEUS.ACTORS.*;
IMPORT 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 <DNS_FILE> -O
<ONTOLOGY_FILE> [-GUI VIEWERPROG] [-E <EXTERNALPROG>] [-R
RESOURCEPROG] [-NAME <AGENTNAME>] [-DEBUG] [-H] [-V]");
SYSTEM.EXIT(0);
}

PUBLIC STATIC VOID MAIN(STRING[] ARG) {


TRY {
ZEUSAGENT AGENT;
STRING EXTERNAL = NULL;
STRING DNS_FILE = NULL;

A69
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 )
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");

A70
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);
ZEUSAGENTUI UI = (ZEUSAGENTUI)C.NEWINSTANCE();
CONTEXT.SET(UI);
UI.SET(CONTEXT);
}

/*

A71
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);
}

/*
ACTIVATING EXTERNAL USER PROGRAM
*/

IF ( USER_PROG != NULL )
USER_PROG.EXEC(CONTEXT);

}
CATCH (CLASSNOTFOUNDEXCEPTION CNFE) {

A72
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\\GNU-REGEXP.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 (JARON@INFO.BT.CO.UK), MARCH 1999
* IMPLEMENTATION OF THE FRUITMARKET TRADING GUI
*****************************************************************************/

IMPORT JAVA.UTIL.*;
IMPORT JAVA.AWT.*;
IMPORT JAVA.AWT.EVENT.*;
IMPORT JAVA.IO.*;
IMPORT JAVAX.SWING.*;
IMPORT JAVAX.SWING.BORDER.*;

IMPORT ZEUS.UTIL.*;
IMPORT ZEUS.CONCEPTS.*;
IMPORT ZEUS.GUI.FIELDS.*;
IMPORT ZEUS.ACTORS.*;
IMPORT ZEUS.ACTORS.EVENT.*;
IMPORT ZEUS.GENERATOR.UTIL.*;

PUBLIC CLASS TRADERFRONTEND EXTENDS JFRAME

A73
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);
}

A74
};
HEADER.SETBORDER(NEW BEVELBORDER(BEVELBORDER.RAISED));

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(H
EADER, 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(S
CROLLPANE, GBC);
GETCONTENTPANE().ADD(SCROLLPANE);

TABBEDPANE = NEW JTABBEDPANE();


SELLPANEL = NEW TRADEPANEL(FALSE, THIS);
BUYPANEL = NEW TRADEPANEL(TRUE, THIS);

A75
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;
GBC.WEIGHTX = GBC.WEIGHTY = 1;
GBC.INSETS = NEW INSETS(8,8,0,8);

((GRIDBAGLAYOUT)GETCONTENTPANE().GETLAYOUT()).SETCONSTRAINTS(T
ABBEDPANE, 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");

A76
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 +
" >> " + 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 {

A77
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 FACTDIALOG FACTWIN;


PROTECTED NAMEFIELD FRUITFIELD;
PROTECTED WHOLENUMBERFIELD ASKPRICEFIELD;
PROTECTED WHOLENUMBERFIELD TIMEFIELD;
PROTECTED JBUTTON CHOOSEBTN;
PROTECTED JBUTTON TRADEBTN;
PROTECTED TRADERFRONTEND UI;

PROTECTED BOOLEAN BUYING;

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.LOWE
RED));

A78
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);
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);

A79
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;
GB.SETCONSTRAINTS(TIMEFIELD, GBC);
ADD(TIMEFIELD);

TRADEBTN = NEW JBUTTON("TRADE");

A80
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;
}

A81
FACT[] TMP = UI.AGENT.RESOURCEDB().ALL(FRUIT);
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);

A82
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)(0));
UI.AGENT.ENGINE().SELL(G);
}
}

A83