modelo de referencia para simulación con agentes y...

M O D E L O D E R E F E R E N C I A PA R A S I M U L A C I N C O N A G E N T E SY B A S E S D E D AT O S

virginia padilla sifontes

Integrando el simulador GALATEA con un sistema de informacin geogrfica

tutor Dr. Jacinto Dvila Q.

Centro de Simulacin y ModelosFacultad de Ingeniera

Universidad de los AndesMrida, Venezuela

Departamento de Ciencia y Tecnologarea de Informtica

Universidad Nacional Experimental de GuayanaCiudad Guayana

junio 2013

Virginia Padilla Sifontes: Modelo de Referencia para Simulacin conAgentes y Bases de Datos, Integrando el simulador GALATEA conun sistema de informacin geogrfica, Universidad NacionalExperimental de Guayana, Departamento de Ciencia y Tecnologa,Ciudad Guayana; Universidad de los Andes, Centro de Simulaciny Modelos , Mrida, Venezuela. junio 2013

A mis padres, Virgilio y Thais.

A mis hijas, Ana Virginia y Andrea Isabel.

R E S U M E N

Este trabajo de investigacin tiene como objetivo proponer unmodelo de referencia de un geosimulador multiAgentes que describaqu es un agente, en qu consiste un sistema constitudo por agentes,y como se integran los agentes, y las bases de datos en un sistemade simulacin. El propsito es que este modelo de referencia de ungeosimulador multiAgentes sirva para, ambos aspectos, especificar ycomo gua de desarrollo de aquellos sistemas que usan la tecnologade agentes para prestar servicios inditos como los que requierengrandes almacenes de conocimiento, los simuladores de sistemascomplejos y los sistemas basados en ontologas.

Los sistemas de geosimulacin multiAgentes son sistemas infor-mticos para modelado de los fenmenos que tienen lugar en zonasgeogrficas a travs del uso del enfoque basado en agente. Estos sis-temas se han utilizado para solucionar problemas de planificacinterritorial, fenomenos ambientales y ecolgicos, fenomenos sociales,entre otros(Murgante et al. [121]).

Nuestra hiptesis fundamental de trabajo es que la mejor manerade construir tales herramientas es a partir de una conceptualizacinde nociones como bases de datos, sistema de informacin geogrficay agentes adaptable a este dominio de aplicacin y servicio. Bsi-camente las investigaciones en estos sistemas han estado enfocadashacia su arquitectura, sobre cmo lograr su construccin.

Para probar los conceptos expresados en el modelo formal propues-to se presenta el diseo de un sistema en el dominio de la gestin dedesastres y reduccin del riesgo, orientado al servicio pblico y quesimular la ocurrencia de cambios en la dinmica de lluvias sobre unageografa determinada que podran significar perodos de sequa. Laconstruccin del sistema es un proceso planificado de reuso de otrossistemas. Por ello se han utilizado sistema de simulacin funcionalescomo el software de simulacin de sistemas hidraulicos, EpaNet,y el software para sistemas multiAgentes, GALATEA, sistema deinformacin geogrfica con una interfaz verstil como la propuestapor gvSIG y arquitecturas para integracin de sistemas de simulacindistribuidos como la arquitectura de alto nivel, HLA.

vii

A B S T R A C T

This research aims to propose a reference model of a multiagentgeosimulador that allow describing what an agent is, what a systemcomposed of agents, and how to integrate the agents, and databasesin a simulation system. The purpose is that this reference model of amultiagent geosimulador serves to both aspects, specify and guidedevelopment of those systems using agent technology to provideunprecedented services as requiring large stores of knowledge,systems simulators complex systems based on ontologies.

Geosimulacin multiagent systems are systems for modelingphenomena that occur in geographic areas through the use of agentbased approach. These systems have been used to solve problems ofterritorial planning, environmental and ecological phenomena, socialphenomena, among others (Murgante et al. [121]).

Our working hypothesis is essential that the best way to build suchtools is based on a conceptualization of notions such as databases,GIS and agents suitable for this application domain and service.Basically, investigations in these systems have been focused towardsits architecture, how to achieve their construction.

To show the application of the proposed formal model we presentsthe design of a system in the field of Disaster Management andRisk Reduction, public service oriented and will simulate theoccurrence of changes in the dynamics of rain on a particulargeography that could mean periods of drought. The constructionof the system is a planned process of reuse of complete and entirearchitectures. For this purpose have been used for the constructionof the experimental framework, functional simulation system asEpaNet and GALATEA, GIS such as gvSIG, and system integrationarchitectures for distributed simulation such as HLA.

viii

We have seen that computer programming is an art,because it applies accumulated knowledge to the world,

because it requires skill and ingenuity, and especiallybecause it produces objects of beauty.

Donald E. Knuth Knuth [97]

R E C O N O C I M I E N T O S

Quisiera agradecer el apoyo de mi tutor, el prof. Jacinto Dvila, unmaestro y gua excepcional, generoso y gentil.

A la prof. Magdiel Ablan por las horas dedicadas al estudio de lossistemas hidrolgicos y por sus consejos que ayudaron a darle formaa este trabajo.

A los miembros del CESIMO por el apoyo que me prestarondurante mi estada en ese centro de investigacin.

Y a todas aquellas personas que de una u otra manera me hanayudado en el logro de este objetivo.

A todos, muchas gracias.

ix

N D I C E G E N E R A L

i introduccin y objetivos 11 introduccin y objetivos 3

1.1 Introduccin 31.2 Justificacin 41.3 Antecedentes 51.4 Preguntas de Investigacin 51.5 Objetivos 61.6 Descripcin breve de cada captulo 8

ii marco terico 152 fundamento terico 17

2.1 Agentes. 172.2 Metodologas para desarrollo de sistemas multiAgen-

tes. 192.2.1 Australian AI Institute (AAII). 202.2.2 GAIA. 222.2.3 Multiagent System Engineering (MaSE). 252.2.4 Prometheus. 272.2.5 MESSAGE extends UML (MESSAGE/UML). 302.2.6 INGENIAS. 322.2.7 Tropos. 332.2.8 Multi Agent System- CommonKADS (MAS-CommonKADS).

352.2.9 Open-Multiagent System Engineering (O-MaSE). 37

2.3 Teora de Simulacin multiAgentes. 402.3.1 Una primera aproximacin a un modelo formal

de un sistema multiagentes. 412.3.2 El comportamiento de un agente como una

funcin matemtica. 422.3.3 Agentes reactivos y racionales. 432.3.4 Un agente con racionalidad acotada. 432.3.5 El Marco de Referencia de Agentes (MRA) y El

Modelo Formal de Agentes. 442.4 GeoSimulacin. 45

2.4.1 Sistema de Informacin Geogrfica (SIG) y mo-delado basado en agentes 47

2.4.2 Una visin orientada a agente en un SIG conSistemas urbanos y ambientales. 49

2.4.3 Agentes mviles con inteligencia espacial. 502.4.4 Simulacin basado en agentes para la toma de

decisiones y cambio de uso del suelo. 51

xiii

xiv ndice general

2.4.5 Infraestructura de simulacin multiAgente paraplanificacin. 51

2.5 Computacin Orientada a Servicios. 522.5.1 Computacin Orientada a Servicios. 532.5.2 Que es un Servicio? 532.5.3 Arquitectura orientada a Servicios. 542.5.4 Que es un Servicio Web? 54

3 una nueva aproximacin a la teora de simula-cin multiagentes . 573.1 El Modelo Formal de Geosimulacin multiAgen-

tes. 573.1.1 Teora de Geosimulacin multiAgentes 60

3.2 Bases de Datos 633.2.1 Modelo Formal de una Base de Datos y el

Modelo Formal del Agente. 653.2.2 El Modelo de Formal del Agente y otros

modelos de Bases de Datos. 663.2.3 La Relacin entre agentes y bases de da-

tos. 67

iii aplicacin prctica 694 validacin experimental del modelo formal de

geosimulacin multiagentes 714.1 El dominio de la Gestin de Desastres y Reduccin de

Riesgo 714.2 Diseo General del Sistema para la Gestin de Desas-

tres y Reduccin de Riesgo. 724.2.1 Historia de Usuario 734.2.2 El Modelo de Geosimulacin multiAgentes y el

Predictor de Servicio de Agua Potable. 744.3 Desarrollar el modelo de simulacin para el predictor

de servicio de agua potable. 774.3.1 Implementar el modelo de simulacin del acue-

ducto. 774.3.2 Integracin del Predictor de Servicio de Agua

Potable (PSAP) en un SIG . 844.3.3 Evaluar la construccin de un servicio con el SIG

y el PSAP. 924.4 Disear un agente gestionador de la salida del acue-

ducto 944.4.1 Construccin de la federacin. 954.4.2 Construccin del agente regulador. 1054.4.3 Integracin de la federacin en el SIG. 1104.4.4 Ejecucin de la federacin con el agente regula-

dor. 112

ndice general xv

4.5 Disear un agente que gestione los escenarios desimulacin del acueducto. 1174.5.1 Construccin de la interfaz grfica para el

escenario climtico. 117

iv conclusiones y recomendaciones 1215 conclusiones y trabajos futuros . 123

5.1 Conclusiones Generales. 1235.2 Contribuciones principales. 1275.3 Trabajos Futuros. 128

v apndices 131a arquitectura de alto nivel 133

a.1 Breve Introduccin a la HLA. 134a.1.1 La Arquitectura de HLA . 134a.1.2 OMT 141a.1.3 Actualizaciones e Interacciones 147a.1.4 Mecanismo de Publicacin y Suscripcin 148a.1.5 Time Stamp Ordered (TSO) y recepcin de

actualizaciones ordenadas 149a.1.6 Regulacin del Tiempo y restriccin del tiempo

en los federados 150a.1.7 Declaracin y Administracin de Objetos. 151a.1.8 Administracin del Tiempo en Simulaciones

High Level Architecture (HLA) 155a.1.9 Estndard Institute of Electrical and Electronics

Engineers (IEEE) 1516 156a.1.10 Estndard IEEE 1516-Evolved 156

a.2 Construccin de un federado para el escenario clim-tico. 158a.2.1 Construccin del agente consultor. 163

a.3 Evaluacin de software para HLA. 164b evaluacin de software para sistema de infor-

macin geogrfica . 165b.1 Evaluacin de software para SIG. 166

b.1.1 Evaluacin revisitada: 167c modelos de simulacin 169

c.1 Modelo de Simulacin Acueducto La Ceibita 170c.2 Modelo de Simulacin Acueducto La Ceibita extendido

175c.3 Modelo de Simulacin del Agente Regulador 181

d gua de instalacin del psap 187d.1 Configurar entorno de desarrollo para gvSIG 1.11

desktop en el IDE Eclipse Juno 188d.2 Gua de Instalacin del Predictor de Servicio de Agua

Potable en gvSIG Mobile. 194

xvi ndice general

d.3 Gua de instalacin de extensin PSAP en gvSIGDesktop 207

bibliografa 209

L I S TA D E F I G U R A S

Figura 2.1 Sistemas multiAgentes como OrganizacinComputacional (tomado de Zambonelli et al.[171]Jennings [91]) 22

Figura 2.2 Modelos de la metodologa GAIA y su relacinen el proceso GAIA. (tomado de Zambonelliet al. [171]) 23

Figura 2.3 La metodologa MaSE. (tomado de Wood andDeLoach [166]) 25

Figura 2.4 Metodologa Prometheus (tomado de Padg-ham and Winikoff [128]) 28

Figura 2.5 Conceptos de MESSAGE/UML (tomado de Caireet al. [22]) 31

Figura 2.6 Esquema del Simulador GALATEA 40Figura 3.1 Esquema del Geosimulador GALATEA 58Figura 3.2 El mundo Real y el mundo de la Simulacin

en el Geosimulador 59Figura 3.3 Funcin Evolucin en el Geosimulador 59Figura 3.4 Agentes y Bases de Datos 65Figura 4.1 Poblaciones del Municipio Santos Marquina,

Mrida. 74Figura 4.2 Plan de suministro. 74Figura 4.3 Diseo del sistema para Gestin de Desastres

y Reduccin de Riesgo (GDRR) 76Figura 4.4 Acueducto La Ceibita. 79Figura 4.5 Acueducto La Ceibita extendido. 80Figura 4.6 Opciones de Anlisis para sistema simulacin

Acueducto La Ceibita 83Figura 4.7 Resultados del simulador EpaNet 84Figura 4.8 Edicin de las propiedades del proyecto en

gvSIG 86Figura 4.9 Capa Raster proporcionada por el servicio Web

Map Service (WMS) del Instituto GeogrficoVenezolano Simn Bolvar (IGVSB). 86

Figura 4.10 Capa vectorial con los sectores poblacionales87

Figura 4.11 Estructura de una extensin en gvSIG 87Figura 4.12 config.xml 89Figura 4.13 Consulta los datos de una poblacin. 90Figura 4.14 Consulta Demanda Promedio 92Figura 4.15 Clase de Objetos de Mi_Federacin 100Figura 4.16 Clase Interaccin de Mi_Federacin 101

xvii

xviii Lista de Figuras

Figura 4.17 Mi_Federacin. Tomado de Kuhl et al. [105] 102Figura 4.18 Diseo de los Federados. Tomado de DoD

[50]. 103Figura 4.19 Ciclo vida de la federacin. Tomado de DoD

[50]. 104Figura 4.20 Caso Uso del agente Regulador 107Figura 4.21 El archivo config.xml con las opciones de la

federacin 111Figura 4.22 Estructura extensin generalitat valenciana

SIG (gvSIG) para Mi Federacin 111Figura 4.23 Evolucin en el tiempo del Nodo DesArena-

dor. Escenario1. 112Figura 4.24 Evolucin en el tiempo del Estanque de Alma-

cenamiento. Escenario 1. 113Figura 4.25 Salida Simulacin Escenario 1. 114Figura 4.26 Evolucin en el tiempo del Nodo DesArena-

dor. Escenario 2. 115Figura 4.27 Evolucin en el tiempo del Estanque de Alma-

cenamiento. Escenario 2. 115Figura 4.28 Salida Simulacin Escenario 2. 116Figura 4.29 Escenario climtico. 119Figura A.1 Visin Lgica de los Componentes del RTI.

Tomado de Crosbie and Zenor [31]. 138Figura A.2 Interfaz entre el RTI y los Federados. Tomado

de Kuhl et al. [105]. 139Figura A.3 Componentes de un Federado. Tomado de

DoD [50]. 140Figura A.4 Responsabilidad del cdigo. Tomado de Cros-

bie and Zenor [31] 141Figura A.5 Administracin de Declaracin de Objetos.

Tomado de Crosbie and Zenor [31], DoD[50]. 152

Figura A.6 Administracin de Declaracin de Interaccio-nes. Tomado de Crosbie and Zenor [31], DoD[50]. 152

Figura A.7 Metodologa para Administracin de Objetos.Tomado de Crosbie and Zenor [31], DoD[50]. 153

Figura A.8 Administracin de Actualizaciones de Objetos.Tomado de Crosbie and Zenor [31], DoD[50]. 154

Figura A.9 Administracin de Interacciones de Objetos.Tomado de Crosbie and Zenor [31], DoD[50]. 154

Figura A.10 Clase de Objetos de Mi_Federacin 161Figura A.11 Clase Interaccin de Mi_Federacin 162

L I S TA D E C U A D R O S

Cuadro 2.1 Comparacin rpida de tres visiones para in-tegracin de software. (Aparece en Westervelt[163] ) 48

Cuadro 2.2 Comparacin de dos visiones ProcesamientoDistribuido (PD) y Orientado a Objetos (OO) se-gn la clasificacin de Westervelt [163] 49

Cuadro 4.1 Caractersticas de los Nodos y Embalse delAcueducto La Ceibita. 80

Cuadro 4.2 Caractersticas de las Conducciones del Acue-ducto La Ceibita. 81

Cuadro 4.3 Caractersticas de los Depsitos del AcueductoLa Ceibita. 82

Cuadro 4.4 Demanda de la comunidad El Murcilago.Tomado de Ramrez [136]. 82

Cuadro 4.5 Identificacin del modelo de objeto. 97Cuadro 4.6 Estructura de clase de objetos. 97Cuadro 4.7 Estructura de clase de interaccin. 97Cuadro 4.8 Tabla de Atributos de la Federacin. 98Cuadro 4.9 Tabla de Parmetros de la Federacin. 99Cuadro 4.10 Lxico SOM/FOM. 100Cuadro 4.11 Observaciones del agente 107Cuadro 4.12 Base de Conocimiento del Agente Regula-

dor. 108Cuadro 4.13 Medidas del tiempo de la simulacin. 117Cuadro A.1 Ejemplo de la Identificacin del modelo de

objeto. 143Cuadro A.2 Ejemplo estructura de clase de objetos. 143Cuadro A.3 Ejemplo de estructura de clase de interac-

cin. 144Cuadro A.4 Tabla de Atributos. 145Cuadro A.5 Tabla de Atributos. 146Cuadro A.6 Lxico SOM/FOM. 147Cuadro A.7 Estructura de clase de objetos. 158Cuadro A.8 Estructura de clase de interaccin. 158Cuadro A.9 Tabla de Atributos. 159Cuadro A.10 Tabla de Parmetros. 160Cuadro A.11 Lxico SOM/FOM. 161Cuadro A.12 Comparacin software para HLA 164Cuadro B.1 Comparacion de software para SIG 168

xix

L I S TA D E P R O G R A M A S

Programa 4.1 Clase PoblacionInfoExtension.java 88Programa 4.2 Clase InfobyPointListener.java 88Programa 4.3 Clase InfoByDemandaListener.java 90Programa 4.4 Clase DemandaPointListener.java 93Programa 4.5 Archivo suministro.fed 101Programa 4.6 Archivo Delta.java 109Programa A.1 Archivo suministro.fed modificado 162Programa C.1 AgenteAdministrador.java 181Programa C.2 Delta.java 182Programa C.3 GUI.java 183Programa C.4 Interfaz.java 185

xx

A B R E V I AT U R A S

AC Autmata Celular

API Application Programming Interface

AUML Agent Unified Modeling Language

AAII Australian AI Institute

BD Base de Datos

BDA Base de Datos Activas

BDD Base de Datos Deductiva

BDI Belief, Desire e Intention

BDOOA Base de Datos Orientada a Objeto Activa

CommonKADS Common Knowledge Acquisition Design System

CORBA Common Object Request Broker Architecture

CDDL Common Development and Distribution License

CQL Contextual Query Language

DIAS Dynamic Information Architecture System

DIF Data Interchange Format

DEVS Discrete Event System Specification

DM Declaration Management

DDM Data Distribution Management

D-W Darcy-Weisbach

ECQL Extend Contextual Query Language

EDLC Evolved Dynamic Link Compatible

E/S Entrada/Salida

ECA Evento, Condicin, Accin

EM Empirical Modelling

EpaNet Environmental Protection Agency NETwork

EPSG European Petroleum Survey Group

xxi

xxii abreviaturas

FED Federation Execution Data

FEDEP Federation Development and Execution Process

FOM Federation Object Model

GALATEA GLIDER with Autonomous Logic-based Agents, TEmporalreasoning and Abduction

GDAL Geospatial Data Abstraction Library

GLIDER Gate, Line, Input, Decision, Exit, Resource

GDRR Gestin de Desastres y Reduccin de Riesgo

GNU GNU is Not Unix

GOPRR Graph, Object, Property, Relationship, and Role

GPL General Public License

GRASS Geographic Resources Analysis Support System

gvSIG generalitat valenciana SIG

HLA High Level Architecture

IA Inteligencia Artificial

IDE Integrated Development Environment

IEEE Institute of Electrical and Electronics Engineers

I/O Input/Output

IGVSB Instituto Geogrfico Venezolano Simn Bolvar

INIA Instituto Nacional de Investigaciones Agrcolas

JAI Java Advanced Imaging

JDE The JACK Development Enviroment

JVM Java Virtual Machine

LBTS Lower Bound Time Stamp

LUCITA Land-Use Change in the Amazon

MaSE Multiagent System Engineering

MAGI Multi-Agent Geosimulation Infrastructure

MAS-CommonKADS Multi Agent System- CommonKADS

MESSAGE/UML MESSAGE extends UML

abreviaturas xxiii

MOM Management Object Model

MRA Marco de Referencia de Agentes

MSC Message Sequence Charts

MSNM Metros Sobre el Nivel del Mar

mseg mili segundos

OO Orientado a Objetos

OGC Open Geospatial Consortium

O-MaSE Open-Multiagent System Engineering

OMT Object Model Template

OPF OPEN Process Framework

PD Procesamiento Distribuido

PDA Personal Digital Assistant

PDT The Prometheus Design Tool

PSAP Predictor de Servicio de Agua Potable

QGIS Quantum Geographic Information System

RBSIM Recreation Behavior Simulation

RI Restricciones de Integridad

REST Representational State Transfer

RO Receive Order

RTI Run-Time Infrastructure

SDL Specification and Description Language

SMA Sistema Multi Agentes

SIG Sistema de Informacin Geogrfica

SISO Simulation Interoperability Standards Organization

SOA Service Oriented Architecture

SOC Service Oriented Computing

SOM Simulation Object Model

TSO Time Stamp Ordered

UML Unified Modeling Language

xxiv abreviaturas

USDP Unified Software Development Process

XML eXtensible Markup Language

WMS Web Map Service

WFS Web Feature Service

WCS Web Coverage Service

WSDL Web Service Description Language

Parte I

I N T R O D U C C I N Y O B J E T I V O S

1I N T R O D U C C I N Y O B J E T I V O S

1.1 introduccin

Un modelo de referencia es la base epistmica de una ontologa,se hace referencia a la ontologa en su sentido histrico, ms queel sentido tcnico moderno. Es la descripcin de cosas y conceptosque habitan cierto dominio del conocimiento. El modelo de referenciade un geosimulador multiAgente tiene que describir qu es unagente, en qu consiste un sistema constitudo por agentes, y comose integran los agentes, y las Base de Datos (BD) en un sistema desimulacin.

La nocin de agentes ha comenzado a ser extremadamente popularen el mundo tecnolgico en tiempos recientes. La InteligenciaArtificial (IA) gira alrededor de este concepto Russell and Norvig[147] y existen proyectos para desarrollar un nuevo paradigmaorientado a agentes con el fin de reforzar el paradigma de la OORumbaugh et al. [146]. En ese contexto, un agente es concebido comoun objeto con una interface a su ambiente a travs del cual lleganentradas al objeto y hay salidas desde el objeto. Es una capsulaen el sentido usual de la OO. Lo que hace a los agentes un objetoactivo y especial es su dinmica interna, la cual opera sobre susestados internos y conecta significativamente sus entradas con susalida. Cuando esta conexin produce cierto tipo de comportamiento,se habla acerca de agentes inteligentes. Se puede decir que el objetivodel proyecto total de la IA es definir ciertos tipos de comportamientosy encontrar la manera de generarlos.

Los investigadores han buscado la ayuda de avanzadas tecnologasinformticas en el desarrollo de sistemas integrados de modelado ysimulacin basado en agentes y SIG, para adquirir una comprensinms profunda de la complejidad de los sistemas naturales, sistemassociales y de planificacin urbana. Evidencia de esta afirmacindescansa en una rea de investigacin muy dinmica expresada enlos trabajos de Gimblett [73], Gilbert and Troitzsch [71], Batty et al.[7], Murgante et al. [121], Torrens [158]. La integracin de estastres tecnologas, modelado y simulacin, agentes de software y SIG,ha sido llamada por Benenson and M.Torrens [10]: geosimulacin,reconociendola adems como un nuevo campo de investigacin

3

4 introduccin y objetivos

y una oportunidad para contribuir con el desarrollo de nuevasherramientas.

Este trabajo de investigacin tiene como objetivo proponer unmodelo de referencia de un geosimulador multiAgente que sirvapara, ambos aspectos, especificar y como gua de desarrollo desistemas de geosimulacin multiagente. El modelo de referencia deun sistema multiagente es un intento de generalizar las caractersticasde GALATEA1 (GLIDER with Autonomous Logic-based Agents,TEmporal reasoning and Abduction (GALATEA))[38, 42, 43, 44, 36],un sistema de simulacin basado en multiagentes, dirigido a lograruna plataforma ms integral, uniforme y bien fundamentada, paraservicios de gestin del conocimiento como una manera de superarla . . . debilidad relativa de la ingeniera de software en el lado de lossistemas multiagentes: existen muchas metodologas o disponibilidadde lenguajes orientados a objetos, pero no un fuerte compromiso conuna semntica operacional determinada Drogoul et al. [52].

GALATEA es un software de simulacin que propone integrar, enuna misma plataforma computacional, las herramientas conceptualesy concretas para simulacin de eventos discretos, sistemas continuosy sistemas multiAgentes; de forma distribuida e interactiva. Este soft-ware de simulacin fue desarrollado en los lenguajes de programa-cin como JAVA [90] y SWI-Prolog [156], y proporciona a modelistasy simulistas una herramienta computacional para la simulacin desistemas por eventos discretos, continuos y multiAgentes. El softwa-re de simulacin est basado en el formalismo general del modeladoy simulacin de eventos discretos, Discrete Event System Specifica-tion (DEVS) Zeigler et al. [172], Wainer [162], y en una teora de Si-mulacin de Sistemas multiAgentes que puede consultarse en Dvilaet al. [44]. El estudio y la extensin de esta teora de simulacin paraincluir sistemas de BD, es el objeto en este trabajo.

GALATEA es heredera de la semntica y buena parte de la sintaxisde la plataforma de simulacin GLIDER: Gate, Line, Input, Decision,Exit, Resource (GLIDER)2, desarrollado por Domingo et al. [51],que contiene un simulador DEVS, Zeigler et al. [172], Wainer [162].Partiendo de GLIDER, GALATEA incorpora a los agentes en la semnticadel lenguaje de simulacin, Dvila et al. [41].

1.2 justificacin

La principal motivacin para realizar esta tesis doctoral es la deproponer un modelo de referencia que sirva como base para ladescripcin de sistemas que utilizan la tecnologa de agentes con elobjeto de prestar servicios inditos como los que requieren grandes

1 est en: http://galatea.sourceforge.net/Principal.htm2 GLIDER fue desarrollado en el lenguaje de programacin PASCAL

1.3 antecedentes 5

almacenes de conocimiento, los simuladores de sistemas complejos ylos sistemas basados en ontologas.

1.3 antecedentes

Como trabajos similares a esta propuesta se puede mencionarlos realizado por Beynon and Cartwright [12], Beynon et al. [13],en su propuesta de Modelado Emprico, Empirical Modelling (EM),que es un enfoque para el modelado de sistemas de simulacincomputacionales basado en observaciones empricas. El grupo deinvestigacin, EM [55], hace nfasis en el desarrollo de herramientasexperimentales como base para el modelado de sistemas, y enese sentido ha propuesto una serie de herramientas de softwareorientadas con ese fin. Aunque no es un antecedente relacionadodirectamente con la investigacin, s lo es la dea de proponer unmodelo que sirva como gua y especificacin al desarrollo de sistemasde simulacin computacionales complejos

Tambin podemos mencionar los trabajos de Bailey et al. [5]y de Kowalski et al. [104], Kowalski [98], Kowalski and Sadri[101, 102], Kowalski [99], Kowalski and Sadri [103], Kowalski [100],que proporcionan una visin, desde el modelo de agentes, de lossistemas de BD y establecen la similitud entre ambos paradigmas.Estos trabajos nos permiten establecer que es posible proponer unmodelo integrador de sistemas de BD y agentes que integre estosconceptos en un modelo formal ms amplio, como el que se proponeen este trabajo de investigacin.

Tambin como antecedente a la propuesta de extender el simuladorGALATEA con una extensin geogrfica, est el trabajo de Daz [46], unexperimento limitado donde se present un ejercicio de integracinde la plataforma GALATEA con el software para SIG, GeographicResources Analysis Support System (GRASS), GRASS DevelopmentTeam [75].

1.4 preguntas de investigacin

Esta tesis doctoral pretende analizar los siguientes aspectosreferidos a la geosimulacin multiAgentes:

Con respecto al modelo formal : Puede extenderse la teorade simulacin de GALATEA para integre estructuras de datoscomplejas como las BD? si es as, entonces:

Cul sera el modelo formal de un geosimulador multi-Agente?

Cmo se describen formalmente una Base de DatosActivas (BDA) y una Base de Datos Deductiva (BDD)?Estn las bases de datos dentro de los agentes? Son los


agentes un tipo de sistema manejador de BD? Cul es ladinmica de los agentes y las BD? Estn conectados? Secomplementan?

Con respecto a una aplicacin de ejemplo: Cul es la dinmicade los sistemas de simulacin con los agentes y las BD?Qudebe tener en cuenta un desarrollador de aplicaciones desoftware para construir sistemas de geosimulacin y agentes?Puede el modelo formal de geosimulacin multiagentes, serusado como soporte en el proceso de diseo de sistemascomplejos? Cules servicios se pueden ofrecer con sistemas desimulacin integrados a SIG y agentes?

Con respecto a los agentes y Sistema Multi Agentes (SMA):Cmo las metodologas de desarrollo de SMA describena los agentes y a los SMA? Qu lenguajes utilizan lasdiferentes metodologas para describir un SMA? Se puedeestablecer un modelo general de agentes que incluya lasdiversas caracterizaciones que presentan las metodologas paraSMA?

Con respecto a la teora de simulacion multiAgentes: Cul esel modelo formal en el que se basa el software para simulacinGALATEA?

Con respecto a la geosimulacin multiAgentes: Existen unmodelo formal que describa un geosimulador multiAgente?Qu tipo de limitaciones se busca superar al integrar sistemasde simulacin con SIG y agentes?

Con respecto a la computacin orientada a servicios (ServiceOriented Computing (SOC)): Qu es la SOC? Cules son losconceptos asociados a la SOC? Estn los SMA relacionados conla SOC?

1.5 objetivos

Objetivo General:

Disear un Modelo de Referencia para un sistema de simulacinintegrado con agentes y bases de datos.

Objetivos Especficos:

En trminos generales se exploran las reas de conocimiento invo-lucradas en la investigacin. Esto proporciona el soporte apropiadopara integrar estos conceptos en un modelo comn. Luego, se pro-pone un modelo formal que abarque estos conceptos. Por ltimo se

1.5 objetivos 7

analiza y disea una aplicacin representativa del tipo de situacinque se quiere abordar con el modelo propuesto.

A continuacin se formalizan los objetivos especficos:

Establecer una caracterizacin de los agente de software.

Investigar el fundamento terico de los agentes de softwarepara conocer los conceptos que caracterizn la arquitectura deun agente. Establecer un modelo general que caracterize a losagentes de software.

Determinar cmo caracterizan a los agentes las diversasmetodologas para desarrollo de SMA.

Se evaluan metodologas reconocidas para determinar comoestas metodologas para desarrollo de SMA definen a losagentes y que tipo de lenguaje usan para su formalizacin.Se comparan las metodologas para desarrollo de SMA conel modelo propuesto en el objetivo anterior con el objeto deestablecer el caracter general de la caracterizacin realizada.

Investigar teoras multiAgentes para sistema de simulacin.

Consiste en estudiar la base terica que fundamenta unsistema de simulacin, especificamente el simulador GALATEApropuesta por Dvila and Uzctegui [39], y su descripcinformal, para determinar si los modelos asociados con agentesy BD estn explicados en el modelo formal de un sistema desimulacin.

Investigar los avances en la integracin de SIG, agentes desoftware y sistemas de simulacin.

Consiste en revisar los avances que ha habido en el rea dede los SIG y agentes de software, aplicaciones que se handesarrollado, software utilizado, entre otros aspectos relevantes.

Proponer un modelo de referencia que incluya los conceptosasociados a agentes, bases de datos y sistemas de simulacin.

Presentar el modelo de referencia para un geosimulador queexplique como este modelo incluye los modelos formaleselaborados previamente.

Demostrar que el modelo de referencia del geosimuladorexplica los modelos formales que describen a las BDA y BDD.

Determinar qu modelos formales se usan para describirBDA y BDD con el propsito de determinar la posibilidadde integrar ambos modelos en un modelo comn que lascaracterize.


Comparar este modelo formal de base de datos conel modelo formal del geosimulador para establecer lafactibilidad de que el modelo formal del geosimulador seaun modelo ms general.

Evaluar el modelo de referencia propuesto en este trabajo.

Se disea una aplicacin que se usa para determinar si el mo-delo de referencia propuesto explica los conceptos involucradosen la aplicacin. El resultado de esta evaluacin ser muy im-portante porque serve para identificar las ventajas y desventajasdel modelo de referencia, y tambin, el planteamiento de futu-ras lneas de investigacin que puedan derivarse para mejorareste trabajo.

Se disea un servicio asociado a la aplicacin para evaluarque tipo de tecnologa puede usarse para el desarrollo deaplicaciones orientadas a servicios que contemplen simuladores,SIG y agentes.

1.6 descripcin breve de cada captulo

A continuacin se har un breve descripcin de los captulos queconforman esta memoria.

El captulo 2 tiene tres secciones: Agentes, Metodologas para desa-rrollo de sistemas multiAgentes, Teora de Simulacin multiAgentes yGeosimulacin multiAgentes.

Agentes inicia con el estudio de estudia la base terica de losagentes de software y se define un MRA.

Luego en Metodologas para desarrollo de sistemas multiAgentes,se usa el MRA como un marco comparativo para evaluarmetodologas industriales, tratando de mostrar como cadaconcepto est representado por la metodologa. La meta(ambiciosa de por s) es el de aproximarse a una meta-metodologa, basada en una teora multiagentes general (Dvila[33], Dvila and Tucci [37], Dvila and Uzctegui [38, 39], Dvilaet al. [43], Dvila and Uzctegui [40], Dvila et al. [42, 44]) quepermita explorar estrategias concretas para disear, generar ycontrolar sistemas multiagentes basados en conocimiento.

Las metodologas bajo escrutinio han sido:

AAII propuesta por Kinny et al. [96], Kinny [95]

GAIA propuesta por Zambonelli et al. [171]

MaSE propuesta por Mark [113]

Prometheus propuesta por Padgham and Winikoff [127]

MESSAGE/UML propuesta por Caire et al. [21]

1.6 descripcin breve de cada captulo 9

INGENIAS propuesta por Gmez-Sanz and Pavn [74]

Tropos propuesta por Bresciani et al. [18]

MAS-CommonKADS propuesto por Iglesias et al. [83], y

O-MaSE propuesta por Garcia-Ojeda et al. [68].

En Teora de Simulacin multiAgentes se presenta la teora desimulacin usada en la construccin de GALATEA. La teorade simulacin multiAgentes propuesta por Dvila et al. [44]es un modelo formal construidos sobre trabajos previos en IA(Ferber and Muller [61]) y Simulacin (Dvila and Uzctegui[39, 40], Dvila et al. [43, 42]). Esta teora ha sido plasmadaen el desarrollo del sistema simulador multiAgentes, GALATEApropuesta por Dvila and Uzctegui [39], Dvila et al. [44].

En Geosimulacin multiAgentes, se hace referencia a esta rea deinvestigacin que integra tres tecnologas: modelado y simula-cin, agentes de software y SIG. La integracin de la tecnologade agentes con los SIG esta siendo propuesta como una solucinpara superar las limitaciones de los SIG. Entre estas limitacio-nes atribuidas a los SIG estn limitados para el uso en mode-lado de sistemas dinmicos, el manejo del tiempo, necesidadde incorporar fenmenos de comportamiento humano y datosproveniente de las ciencias sociales em modelos espaciales. Fi-nalmente, se hace referencia a trabajos de investigacin en geo-simulacin multiAgentes, ellos son:

SIG y modelado basado en agentes de Westervelt [163],se establecen criterios para evaluar la integracin de los SIGy sistemas de simulacin

Una visin orientada a agente en un SIG con Sistemasurbanos y ambientales de Jiang and Gimblett [92], dondeexplora el paradigma basado en agente para modelarsistemas y ambientes urbanos.

Agentes mviles con inteligencia espacial presentadopor Itami [87], y donde se describe el sistema llamadoRecreation Behavior Simulation (RBSIM), un programa decomputadora que simula el comportamiento recreativo de loshumanos en ambientes naturales.

Simulacin basado en agentes para la toma dedecisiones y cambio de uso del suelo donde Lim et al.[107] presenta el sistema de simulacin LUCITA: Land-Use Change in the Amazon (LUCITA), un sistema desimulacin multiAgentes compuesto de dos sub-modelosque interactan a travs de un ambiente raster referenciadoespacialmente.

Infraestructura de simulacin multiAgente para pla-nificacin, donde Blecic et al. [14] presenta a MA-


GI: Multi-Agent Geosimulation Infrastructure (MAGI), unmeta-modelo que representa una teora formal de unageografa con agentes y objetos en ella. Posteriormente,usaremos MAGI para ampliar la teora de simulacin deGALATEA.

Y por ltimo, en Computacin Orientada a Servicios, se presentanlos conceptos bsicos asociados a este paradgma.

El captulo 3 est compuesto de dos secciones: El Modelo Formalpara geosimulacin multiAgentes y Bases de Datos.

En El Modelo Formal para geosimulacin multiAgentes, se proponeun modelo formal derivado de la integracin de la teoramultiagentes para simulacin de GALATEA, presentada porDvila et al. [44], y la teora de MAGI presentada por Blecic et al.[14] para producir una teora multiAgentes para geosimulacin,la cual explica la relacin entre agentes y SIG; como unaherramienta para simular sistemas espaciales complejos.

En la siguiente seccin, Bases de Datos, se dedica a clarificar,por medio del modelo de referencia, la relacin entre sistemasmultiagentes y un modelo formal de BD que incluya lascaractersticas de las BDA y BDD para demostrar que el modeloformal de geosimulacin multiAgentes es un modelo msgeneral que contiene BD y agentes.

En el captulo 4 se realiza la validacin experimental del ModeloFormal de Geosimulacin multiAgentes.

En este cpitulo se presenta el diseo de un sistema desimulacin con BD, SIG y agentes, con el objeto de mostrarcomo el modelo formal expuesto en el captulo Captulo 3 es unsoporte para el proceso de modelado de un sistema complejo.

El marco experimental se ha pensado como un procesoplanificado de reuso de sistemas completos y arquitecturasenteras. El uso de sistemas y arquitecturas existentes permiteasegurar la validez cientfica en los resultados obtenidos, ascomo los aspectos referidos al control y la verificacin de lossistemas.

Se inicia este captulo presentando el dominio de la aplicacinque es el rea de la GDRR, Valds [159], Cushla and Ochoa [32],Lavell [106]. Luego se presenta el diseo general del sistemapara GDRR y los objetivos establecidos para el desarrollo delsistema. Siguiendo la metodologa de la programacin extremase construy una historia de usuario y con ayuda del modelode formal de geosimulacin multiAgentes, se establecieron tresobjetivos para la construccin del sistema: (1) Desarrollar unainterfaz al usuario que muestre al PSAP, (3) Codificar un agenteque en la simulacin sea el encargado de gestionar la salida del


estanque de almacenamiento y (4) Diseo de la interfaz grficapara la descripcin del escenario climtico.

(1) En la fase Desarrollar una interfaz al usuario que muestreal PSAP , se establecieron tres sub-objetivos: (a) Implementarel modelo de simulacin de la dinmica del acueducto, (b)Integracin del PSAP en un SIG, y (c) Evaluar la construccin deun servicio con SIG y el PSAP.

En Implementar el modelo de simulacin de la dinmica delacueducto se construye el modelo de simulacin parael Acueducto La Ceibita, usando el software de si-mulacin Environmental Protection Agency NETwork(EpaNet), EpaNet [56] . Luego, se generan dos modelode simulacin del Acueducto La Ceibita .

En Integracin del PSAP en un SIG, se ha construidouna interfaz grfica usando el software gvSIG, gv-SIG [77], usando servicios remotos de tipo WMS delIGVSB, IGVSB [84]; y usando, tambin, la versatilidaddel software para la construccin de la capa vecto-rial para sealizar los poblados que se surten delacueducto. Esta interfaz grfica forma parte de la ex-tensin en gvSIG para el PSAP que fue desarrolladaen esta fase. La extensin permite al usuario con-sultar cuanto es la demanda promedio semanal deagua potable, medida en lts/seg, que el acueductoproporciona a una determinada poblacin. La exten-sin PSAP para gvSIG versin 1.11 puede descargar-se desde https://simulants.svn.sourceforge.net/svnroot/simulants/ y las instrucciones para su insta-lacin pueden verse en Seccin D.3.

En Evaluar la construccin de un servicio con SIG y el PSAP,se estableci que existe dos maneras de desarrollar unservicio en la Web con gvSIG:

1. La integracin del PSAP con otras tecnologas comoService Oriented Architecture (SOA) SOA [155], Ja-vaScript Flanagan [65] y Extend Contextual QueryLanguage (ECQL) este ltimo es una versin ex-tendida del estndard Contextual Query Langua-ge (CQL) CQL [30].

2. Desarrollar un servicio usando la extensin queofrece gvSIG para desarrollo de cliente mviles,gvSIG Mobile. Este desarrollo, servicio PSAP mvil,puede descargarse desde https://simulants.svn.sourceforge.net/svnroot/simulants/ y las ins-trucciones para su instalacin pueden verse en Sec-
https://simulants.svn.sourceforge.net/svnroot/simulants/https://simulants.svn.sourceforge.net/svnroot/simulants/https://simulants.svn.sourceforge.net/svnroot/simulants/https://simulants.svn.sourceforge.net/svnroot/simulants/


cin D.2. EL servicio PSAP mvil se ejecuta en unemulador.

(3) En la fase Disear un agente que en la simulacin sea el en-cargado de gestionar la salida del tanque de almacenamiento seconsider que la integracin de diversos simuladores, co-mo el caso de EpaNet y GALATEA requerira una plataformade integracin que puede ser proporcionada por el estn-dard para arquitecturas de alto nivel como HLA, DoD [48].Bajo estas consideraciones, se establecieron los siguientessub-objetivos para esta fase:

En el sub-objetivo Construccin de la federacin, seevaluaron diversas implementaciones del estndardHLA y se decidio usar PoRTIco, PoRTIco [132], paracrear una federacin constituida de dos federados:Mi Acueducto y Mi Administrador. En el federado MiAcueducto est contenido el modelo del AcueductoLa Ceibita, y el federado Mi Administrador es laestructura que servir al agente gestionador de lasalida del tanque de almacenamiento.

En el sub-objetivo Integrar de la federacin en el SIG, seintegra la federacin, desarrollada en el paso anterior,en el software gvSIG.

En el sub-objetivo Construccin del agente gestionador dela salida del tanque de almacenamiento, se disea y cons-truye el agente que se ha llamado agente regulador. Elagente regulador es un agente reactivo que observa sumedio ambiente y acta en consecuencia.

(4) En la fase Disear un agente que gestione los escenariosde simulacin del acueducto, se disea la interfaz grfica lepermite al usuario escoger un escenario climtico y, a partirdel escenario climtico seleccionado, un agente consultorconstruye los escenarios de simulacin que van a generardiversos datos que se utilizan como entrada al procesode simulacin del acueducto La Ceibita. Para integrarlos datos seleccionado por el usuario con la plataformaconstruida se ha diseado el federado Mi Consultor quese integra con la federacin Mi Federacin.

El agente consultor tiene como funcin la de gestionar elescenario climtico construido.

El captulo 5 se presentan las conclusiones que se han obtenidoy las lneas de investigacin que surgen de este trabajo. stasson el resultado, tanto del estudio de los agentes de software,de las metodologas para desarrollo de SMA, de la teora desimulacin multiAgentes, de la geosimulacin multiAgentes y


de la SOC. La conclusin principal del trabajo es que El ModeloFormal de Geosimulacin multiAgente es un soporte en el proceso dedesarrollo de sistemas de simulacin complejos que integren a los SIGy los agentes de software.

Adicionalmente, se presentan los trabajos futuros y las lneasde trabajo que se abren para complementar el alcance de estainvestigacin.

Parte II

M A R C O T E R I C O

2F U N D A M E N T O T E R I C O

Las claves para el planteamiento del modelo de referencia quepermite describir un sistema de simulacin con agentes y BD son:

Los agentes de software. Es un recorrido por diversas metodo-logas que nos permite evaluar como definen a los agentes desoftware, que mtodos usan para desarrollar SMA y que tipo delenguaje utilizan para formalizar el diseo del sistema.

Teora de simulacin. Especficamente se revisa el modeloformal propuesto por Dvila et al. [44] para sustentar eldesarrollo del sistema simulador GALATEA .

GeoSimulacin. Es una revisin de los avances en esta reaque integra a los SIG, agentes de software y Sistemas demodelado y simulacin; los tipos de aplicaciones desarrolladas,metodologas y el tipo de lenguaje utilizado para formalizar elsistema.

SOC. Es una revisin de los conceptos asociados a los serviciospara establecer si hay relacin con los agentes de software.

2.1 agentes .

La nocin de agentes ha llegado a ser extremadamente popularen el mundo tecnolgico en tiempos recientes. La IA gira alrededorde este concepto Russell and Norvig [147] y existen proyectos paradesarrollar un nuevo paradigma orientado a agentes con el fin dereforzar el paradigma de la orientacin a objetos, OO, Rumbaugh et al.[146]. En ese contexto, Russell and Norvig [147] concibe a una agentecomo un objeto con una interface a su ambiente a travs del cualllegan entradas al objeto y hay salidas desde el objeto. Es una cpsulaen el sentido usual de la OO.

Lo que hace a un agente un objeto activo y especial es sudinmica interna, la cual opera sobre sus estados internos yconecta significativamente sus entradas con sus salidas. Cuando estaconexin produce cierto tipo de comportamiento, entonces, Russelland Norvig [147] hablan acerca de agentes inteligentes Se puede decir

17

18 fundamento terico

que el objetivo del proyecto total de la IA es definir ciertos tipos decomportamientos y encontrar la manera de generarlos.

Para hacer que un agente sea un objeto de un tipo especfico, elparadigma de la orientacin a agentes (Kowalski and Sadri [101],Bratman [17], Shoham [151], Russell and Norvig [147]) prescribe unconjunto de estructuras para ese estado interno. A continuacin semostrar un conjunto de definiciones de esas estructuras internas yexternas (con respecto al agente) descritas por Russell and Norvig[147], Bradshaw [16] y Dvila [33]; y que definen a un SMA, a partirde un modelo de un agente racional. Es importante destacar quela estructura es un esquema de un modelo que se ha descrito envarias formalizaciones por Kowalski and Sadri [101, 102], Kowalski[99], Kowalski and Sadri [103], Kowalski [100].

MRA:

Estructuras de estado interna :

creencias: lo que el agente conoce acerca de su ambiente yde otros agentes

metas: objetivos o situaciones que al agente o a sudiseadora le gustara lograr o causar, usualmente pormedio de la ejecucin de un plan. Estas pueden clasificarseen:

metas de mantenimiento, que representan una relacinpermanente entre el agente y su ambiente, en la formade reglas condicionales.

metas de logro, son objetivos particulares que el agentetrata de lograr en algn punto del tiempo.

intenciones: metas.

preferencias: un distinguido conjunto de metas. Las prefe-rencias de un agente para cierto estado pueden ser incor-poradas como parte de una funcin de utilidad, a la cualse le asigna valores para expresar cuan deseable es cadaestado o meta.

compromisos: las obligaciones (metas) adquiridas por unagente o acordadas con otro agente y a las cuales el agenteest sujeto.

planes: las sequencias de acciones que un agente puedeejecutar con el objeto de lograr sus metas.

historia: el agente guarda informacin concerniente a supropio registro de percepciones.

Dinmica Interna:

mecanismo de actualizacin.

mecanismo de activacin del agente.

2.2 metodologas para desarrollo de sistemas multiagentes . 19

mecanismo de planificacin y ejecucin del agente, el cualincluye un motor de inferencia y un mecanismo de tomade decisiones.

Estado Externo:

roles: funciones organizacionales realizadas por el agenteen un sistema multiagente. Usualmente estan representa-dos por medio de las metas.

casos de uso: descripcin del comportamiento del agente.

Interfaz:

aptitudes: el agente posee la funcionalidad e informacincorrecta con el objeto de ser capaz de interrelacionarse conel medio ambiente que lo rodea. Est definido por dosatributos:

habilidades: lo que el agente sabe que puede hacercomo resultado de la combinacin de sus percepcionesy creencias

capacidades: el conjunto de acciones que el agente pue-de realizar, bajo ciertas precondiciones proporciona-das.

Se ha usado este MRA como un marco comparativo para evaluarmetodologas industriales, tratando de mostrar como cada conceptoest representado por la metodologa. La meta (ambiciosa de por s)es el de aproximarse a una meta-metodologa, basada en una teoramultiagentes general con base en los trabajos de Dvila [33], Dvilaand Uzctegui [38], Dvila and Tucci [37], Dvila and Uzctegui[39], Dvila et al. [42, 43], Dvila and Uzctegui [40], Dvila et al.[44], que permita explorar estrategias concretas para disear, generary controlar sistemas multiagentes.

2.1.0.1 Conclusin.

El MRA propuesto es un modelo amplio que incluye las diversascaraterizaciones asociados a los agentes de software. En la siguienteseccin se demostrar como este MRA propuesto es un modelo queincluye las definiciones establecidas por diversas metodologas paradesarrollo de sistemas multiAgentes.

2.2 metodologas para desarrollo de sistemas multi-agentes .

En esta parte se describen un conjunto de metodologa reconocidascon el objeto de establecer si los conceptos descriptores de un agente,descritos en 2.1, estn contemplados dentro de las metodologas.


Las metodologas bajo escrutinio han sido: AAII propuesta porKinny et al. [96], Kinny [95], GAIA propuesta por Zambonelli et al.[171], MaSE propuesta por Mark [113] , Prometheus propuesta porPadgham and Winikoff [127], MESSAGE/UML propuesta por Caire et al.[21], INGENIAS propuesta por Gmez-Sanz and Pavn [74], Tropospropuesta por Bresciani et al. [18], MAS-CommonKADS propuesto porIglesias et al. [83], y finalmente O-MaSE propuesta por Garcia-Ojedaet al. [68].

2.2.1 AAII.

La metodologa AAII fue propuesta por Kinny et al. [96], Kinny [95].AAII modela agentes del tipo Belief, Desire e Intention (BDI) elaboradopor Rao and Georgeff [140, 139, 138]. El modelo de agente BDI tienesu base filosfica en las teoras de la intencin de Bratman [17]. Lametodologa AAII ofrece una teora lgica que define creencias, deseose intenciones usando lgica modal.

Para la metodologa AAII las creencias representan la informacinacerca del ambiente que puede tener el agente, los deseos correspon-den con el conjunto de las metas del agente y los eventos que puederesponder, y las intenciones son los planes para alcanzar una meta,todos estos atributos estn incluidos en el MRA descrito en 2.1.

AAII describe a los agentes a travs de dos modelos:

Modelo Externo: consiste en la descomposicin del sistema enagentes y sus interacciones. Se definen los roles que cumplenlos agente, sus responsabilidades y los servicios que prestan.Para ello se construye un:

Modelo de Agentes que describe la relacin jerrquicaentre agentes y las relaciones entre agentes.

Modelo de Interaccin que describe las responsabilida-des, servicios e interacciones entre agentes y sistemas ex-ternos.

Modelo Interno: el modelo interno esta relacionado con lascreencias, deseos e intenciones del agente. Los agentes BDI estndefinidos travs de tres modelos:

Modelo de Creencias: describe las informacin delagente acerca del ambiente y el estado interno que unagente puede mantener, y las acciones que puede realizar.

Modelo de Metas: describe las metas que puede perse-guir el agente, as como los eventos que un agente puederesponder.

Modelo de Planes: describe los planes que un agente usapara alcanzar sus metas.


Los pasos de la metodologa son los siguientes:

Con los roles (funcionales y organizacionales) relevantes enel dominio de la aplicacin, se identifican los agentes, y sedesarrolla una jerarqua de clases de agentes.

Se identifican las responsabilidades asociadas con cada rol, losservicios requeridos y suministrados por el rol y se determinanlas metas asociadas con cada servicio.

Para cada meta, se determina el plan que se puede usar paralograrlas y las condiciones del contexto bajo el cual cada planes apropiado.

Se construye las creencias del sistema analizando los contextosy las condiciones que controlan la ejecucin de actividadesy acciones, y se descomponen en partes de las creencias delsistema.

Estos pasos se repiten en un proceso de interactivo e incremental conrealimentacin, hasta obtener un modelo ms refinado y elaborado.

La metodologa AAII usa diagramas provenientes de las tcnicas demodelado de objetos, (Object Modelling Technique) de Jacobson [89],para describir el Modelo de Creencias. Las clases de agentes tieneasociado creencias, metas y planes, pero no poseen operaciones. ElModelo de Creencias extiende el Modelo de Agentes al agregarleun conjunto de creencias y uno o ms estados de creencias. Los conjuntosde creencias son predicados, cuyos argumentos son trminos deun universo predefinidos, y smbolos de funciones definidas por elusuario. Los predicados y las funciones se derivan de la definicinde clases e instancias. Un estado de creencias es un conjunto dediagramas de instancias que definen una instancia particular de unconjunto de creencias.

El Modelo de Planes usa diagramas de Harel [79] al cual sele aade la nocin de falla del plan. Este modelo son grafos contres nodos: estado inicial, estado final (con dos estado: pasa o falla) yestado interno (caracterizado como estado pasivo y como actividad si esun estado activo). La metodologa usa el lenguaje de comunicacinde agentes KQML de Finin and Fritzson [63], Kinny [95] paradocumentar el protocolo de interaccin entre agentes.

Conclusin.

La metodologa AAII caracteriza al agente por medio de un ModeloExterno y un Modelo Interno. En el Modelo Externo se definenroles, responsabilidades, y servicios. En el MRA descrito en 2.1, los rolesson parte del estado externo del agente; las responsabilidades sonobligaciones del agente, que estn definidad en su estado interno; y


los servicios forman parte de la definicin de la interfaz del agente. ElModelo Interno hace nfasis a tres aspectos que contempla el nivelinterno del MRA: creencias que representan la informacin acerca delambiente que puede tener el agente, deseos que corresponden conlas metas del agente, y las intenciones como los planes que el agentepuede emplear para lograr sus metas.

2.2.2 GAIA.

GAIA es un metodologa con un alto nivel de abstraccin propuestapor Zambonelli et al. [171]. Para modelar SMA, la metodologaGAIA utiliza el concepto de Metfora Organizacional , esquematizadoen la figura 2.1, para describir a los agentes inmersos en una ovarias organizaciones, jugando uno o varios roles, con mltiplesinteracciones entre los agentes, e interactuando con su medioambiente.

Figura 2.1: Sistemas multiAgentes como Organizacin Computacional(tomado de Zambonelli et al. [171]Jennings [91])

Un rol se define por cuatro atributos: responsabilidad, permisos,actividades y protocolos:

La responsabilidad determina el comportamiento esperado delrol y es el atributo clave asociado con el rol. Esta caracterizadopor: propiedad de vitalidad y propiedad de seguridad Manna andPnueli [112].

La propiedad de vitalidad describe aquellos estados queun agente debe causar, bajo ciertas condiciones (estadosdonde algo bueno pasa).


La propiedad de seguridad, son aquellos estados que perma-necen invariantes, estados donde nada malo pasa.

Los permisos que son los derechos asociados con el rol paracumplir con las responsabilidades.

Las actividades de un rol son clculos asociados al rol quedefinen las acciones de un agente sin interactuar con otrosagente.

Los protocolos establecen la interaccin entre los agentes.

La metodologa comprende la etapas de Anlisis y Diseo de laArquitectura y Diseo Detallado. La relacin entre los modelos que seproducen en cada etapa de la metodologa GAIA pueden verse en lafigura 2.2.

Figura 2.2: Modelos de la metodologa GAIA y su relacin en el procesoGAIA. (tomado de Zambonelli et al. [171])

Los modelos por etapa son los siguientes:

Anlisis: en esta etapa se construyen las especificaciones de losmodelos que conforman el sistema MultiAgente:

Modelo Organizacional describe la organizacin (uorganizaciones) que co-existen en el sistema


Modelo Ambiental modela el ambiente en el cual estainmerso el sistema multiagente

Modelo Preliminar de Roles describe los roles a travsde sus atributos descriptores

Modelo Preliminar de Interaccin muestra las depen-dencias e interacciones entre los diferentes roles del siste-ma Multiagente

Reglas Organizacionales establecen una relacin msgeneral entre roles, protocolos y entre ambos; se clasificancomo reglas organizacionales de supervivencia y seguri-dad.

Diseo de la Arquitectura: incluye la definicin de la estructuraorganizacional del sistema; y la culminacin del Modelo Pre-liminar de Roles y del Modelo Preliminar de Interaccin.

Diseo Detallado: en esta etapa se disea el Modelo deAgentes y el Modelo de Servicio.

Modelo de Agentes se identifican las clases de Agentes ylas instancias de agentes que sern instanciadas a partir deesa clase.

Modelo de Servicio que sn las servicios requeridos,entendidos como un conjunto de actividades, para que unagente cumpla con el rol asignado.

La metodologa no provee un lenguaje grfico propio como apoyo almodelaje del sistema multiAgentes, pero s una serie de formalismos,adems del lenguaje natural, para describir los modelos del sistema.Estos formalismos provienen de FUSION de Coleman et al. [28] y dela lgica temporal. GAIA sugiere usar esquemas grficos diseadospor el usuario para documentar el sistema y la notacin AgentUnified Modeling Language (AUML)1 Odell et al. [123, 124] paradefiniciones ms detalladas del Modelo de Interaccin.

Conclusin.

GAIA modela un agente por medio de dos modelos con unalto nivel de abstraccin: el Modelo de Agentes y el Modelode Servicios. La metodologa se enfoca en definir los agentes queintegran el sistema y como estos interactan. No detalla la arquitecturainterna del agente y la interfaz del Agente. GAIA contempla elconcepto de roles al cual se le asocian atributos descriptivos como:

1 est en: http://www.auml.org/auml/main.shtml.Los diagramas de AUML ya estn contenidos en UML 2.1.


responsabilidad, permisos, actividades y protocolos. El MRA descrito en2.1 preve que el concepto de rol est descrito a travs de metas delagente, que a su vez se describen por un conjunto de planes quetienen actividades y por reglas de condicin-accin; por lo que lospermisos y las actividades del rol de GAIA estn incluidas en el modelo.Los protocolos se describen en el MRA como casos de usos en el estadoexterno. Las responsabilidades del rol de GAIA estan definidad en MRAcomo parte del estado interno del agente.

2.2.3 MaSE.

La metodologa MaSE de Mark [113], inicia a partir de los requeri-mientos iniciales del sistema y produce una serie de documentos dediseo formales en un estilo grfico. La figura 2.3 se refleja una visinbreve de la metodologa y sus modelos.

Figura 2.3: La metodologa MaSE.(tomado de Wood and DeLoach [166])


La metodologa tiene dos etapas: Anlisis y Diseo.

Anlisis: consta de tres fases:

Capturando Metas que transforma las especificacionesiniciales del sistema, producto del Anlisis de Requeri-mientos, en un conjunto de metas estructuradas del sistema.

Casos de Usos, en esta fase se extraen el conjunto de casosde usos desde el contexto inicial y se crean un conjuntode diagramas de sequencia de Rumbaugh et al. [146] paraayudar al analista de sistema en la identificacin delconjunto inicial de roles y formas de comunicacin dentrodel sistema.

Refinando Roles, su objetivo es la transformacin de lasmetas estructuradas y diagramas de sequencia en roles y entareas asociadas a los roles.

Diseo: comprende cuatro fases:

Creando Clases de Agentes donde se identifican lasclases de agentes a partir de los componentes de un rol,y las conversaciones entre los agentes.

Construyendo Conversaciones, se define el protocolode coordinacin entre dos agentes.

Ensamblando Clases de Agentes. El diseador definela arquitectura del agente y sus componentes internos.Se tiene la opcin de crear su propia arquitectura ousar plantillas pre-definidas de estilo de arquitecturasproporcionadas por Robinson [142]:

Creencias-Deseo-Intenciones(BDI) Reactivos Planificadores Basado en Conocimiento

Diseo del Sistema las clases de agentes son instanciada comoagentes.

Los diagramas utilizados por MaSE provienen de Kendall en Kendalland Zhao [94], Kendall et al. [93], y de la Tcnicas de Modeladode Objetos, (Object Modelling Technique, OMT) de Rumbaughet al. [146]. La metodologa MaSE proporciona una herramienta paradesarrollo del software, AgentTool desarrollados por DeLoach [45],que da soporte a los pasos de la metodologa. Cada paso de lametodologa genera los siguientes productos:

Capturando Metas, las metas del sistema se representanen el Diagrama Jerrquico de Metas de Kendall and Zhao [94],creandose una jerarqua de metas donde cada nivel de lajerarqua contiene una meta y las submetas relacionadas.


Aplicando Casos de Usos, se dibujan los Casos de Usos que seusan para construir los Diagramas de Secuencia Rumbaugh et al.[146], en el cual se representa la secuencia de mensajes entre losdiferentes roles de los agentes.

Refinando Roles, se construye un Modelo de Rol Tradicional deKendall and Zhao [94] que proporciona una visin de alto niveldel sistema donde cada rol se diagrama con sus metas asociadas.Luego, se agrega las tareas de los roles. Para culminar estafase, se construye el Diagrama de Tareas que es un Diagramade Estado de Rumbaugh et al. [146] donde se esquematiza lascomunicaciones de las tareas asociadas a los roles.

Creando Clase de Agentes, se presenta por medio de unDiagrama de Clase de Agentes que representa las clases de agentesy las conversaciones entre ellos.

Construyendo Conversaciones, se construyen dos Diagramasde Clases de Comunicacin: uno para el que inicia la conversacin,y otro para el que responde. Un Diagrama de Clases deComunicacin es un par de Diagrama de Mquina de Estado Finitoque define el estado de la conversacin de las dos clases deagentes participantes.

Ensamblando Clases de Agentes, el componente interno delagente puede representarse como diagramas de estado querepresenten los eventos que se pasan entre componentes.

Diseo del Sistema, las clases instanciadas se diagraman en unDiagrama de Desarrollo que muestra nmeros, tipos y ubicacinde los agentes dentro del sistema.

Conclusin.

La metodologa MaSE modela distintos tipos de agente proporcio-nando plantillas de estilos de arquitectura. El MRA descrito en 2.1, ensu estado interno considera una serie de conceptos por medio delcual pueden definirse diferentes tipos de agente. El estado externodel agente definido en roles y casos de uso, de igual manera, MaSElo modela por medio de roles y casos de uso. El agente que se modelacon la metodologa MaSE est definido dentro del modelo de agentepropuesto en MRA.

2.2.4 Prometheus.

La metodologa Prometheus propuesta por Padgham and Winikoff[127], consta de tres fases: Especificacin del Sistema, Diseo dela Arquitectura y Diseo Detallado. Una relacin entre los pasos


de la metodologa y sus productos se muestran en la figura 2.4. Cadafase se describe como sigue a continuacin.

Figura 2.4: Metodologa Prometheus(tomado de Padgham and Winikoff [128])

Especificacin del Sistema: esta fase inicia con la identifica-cin de los perceptos y las acciones de los agentes. El autor de-fine, de acuerdo con Russell and Norvig [147], perceptos comola informacin que proviene del ambiente, y acciones como losmecanismos para afectar al ambiente. Establece, a partir de Wi-nikoff et al. [165], la distincin entre perceptos y eventos: un eventoes una ocurrencia significante para el sistema de agente mien-tras que los perceptos es informacin en bruto disponible parael sistema de agentes. Luego se identifica las funcionalidades delagente, en trminos de nombre, descripcin, acciones, perceptos, da-tos usados y producidos, e interacciones, con otras funcionalidadesdel sistema.

Diseo de la Arquitectura: usa la salida de la fase anteriorpara definir los tipos de agentes, disear la estructura delsistema y definir las interacciones entre los agentes. En estaetapa del diseo tambin se identifican que eventos serngenerados como resultado de la informacin proveniente delmedio ambiente, la informacin que ser enviada entre losmensajes que intercambia los agentes y los objetos de datoscompartidos. Estos ltimos son estructuras de datos.

Diseo Detallado: se desarrolla la estructura interna de cadaagente y como ste cumple sus tareas dentro del sistema. Esto


se logra mediante la definicin de las capacidades, definidascomo mdulos dentro del agente, eventos internos, planes ylas estructuras de datos detalladas para cada tipo de agenteidentificado en la etapa previa.

La metodologa Prometheus puede ser soportada por dos herramien-tas: The JACK Development Enviroment (JDE)2 y The Prometheus De-sign Tool (PDT)3. PDT, desarrollado por los autores de la metodologa,permite ingresar y editar un diseo en trminos de los conceptos quemaneja Prometheus, y genera, adems de los diagramas de acuerdo ala metodologa, una descripcin del diseo LATEX con sus descriptores,y un diccionario de datos.

La metodologa utiliza varias notaciones como lenguaje grfico:

Especificacin del Sistema: las funcionalidades del sistema sediagraman mediante casos de uso y escenarios de casos de uso deUnified Modeling Language (UML).

Diseo de la Arquitectura: construye cuatro diagramas:

Diagrama de los Agentes Conocidos: se dibujan los agentes ylos enlaces entre los agentes que interactuan.

Diagrama General del Sistema: une a los agentes, eventos yobjetos de datos compartidos en un solo esquema.

Diagramas de Interaccin: se diagrama la interaccin entreagentes.

Protocolos de Interaccin.:se construyen los protocolos deinteraccin usando AUML.

Diseo Detallado: en esta etapa se construyen dos diagramas:

Diagrama General de Agentes , que suministra una visin dealto nivel de las internalidades de los agentes.

Diagrama de Capacidad donde se describen el detalle de cadacapacidad que poseen los agentes.

Conclusin.

Prometheus describe el sistema desde dos niveles: Interno yExterno. El nivel Interno especifica las capacidades del agente, queson eventos internos, planes y las estructuras de datos detalladas, y puedeincluir preceptos y acciones. En MRA descrito en 2.1 los perceptos sonlas creencias del agente, que es lo que el agente conoce acerca desu ambiente y de otros agentes. Las acciones y eventos internos estn

2 JDE est en www.agent-software.com3 PDT est en http://macr.cis.ksu.edu/index.php


incluidas dentro de los planes del agente definidas en la estructurainterna del MRA. En el nivel Externo, Prometheus, usa casos de usopara definir las conversaciones del agente; de igual manera, en el MRAeste concepto esta definido en el nivel externo del agente.

2.2.5 MESSAGE/UML.

MESSAGE/UML aparecida en Caire et al. [21], conceptualiza un SMAcategorizandolo en dos niveles: nivel de datos y nivel de conocimiento.El nivel de conocimiento esta compuesto de entidades a las cuales se leasocian conceptos.

Las entidades a nivel de conocimiento se clasifican en EntidadesConcretas, Actividades y Entidades de Estado Mental. A a continuacinse detallan los conceptos asociados a cada entidad:

Entidades Concretas:

Agentes: es una entidad autnoma y atmica que es capazde realizar alguna funcin. La capacidad funcional estdescrita en el servicio y la motivacin del agente estrepresentada en el atributo propsito.

Organizacin: es un grupo de agentes que trabajan juntospara un propsito comn. Est representado a travs de lasrelaciones de subordinacin o jerarqua y los mecanismosde comportamiento-coordinacin establecidos por mediode las interacciones entre los agentes.

Rol: describe las caractersticas externas de un agente enun contexto en particular.

Recursos: representa entidades no-autnomas como basesde datos o programas externos usados por agentes.

Actividades:

Tareas: es una unidad de actividades a nivel de conocimien-to, con ejecuciones sencillas.

Interaccin y Protocolos de Interaccin: el concepto de inter-accin, MESSAGE/UML lo toma de la metodologa GAIA deWooldridge et al. [167]. El Protocolo de Interaccin defineun patrn de intercambio de mensaje asociado con la inter-accin.

Estado Mental:

Metas: una meta asocia un agente con una situacin. Lasmetas pueden ser intrnsicas, que persisten en la vidadel agente, tcticas, que no persisten durante la vidadel agente. Las metas son expresada en trminos de unafuncin de utilidad y su funcin objetivo se estima demanera de que se maximice la utilidad.


La figura 2.5 proporciona una visin informal centrada en el agente,de como se interrelacionan los conceptos de MESSAGE/UML , y surelacin con el concepto de agente.

Figura 2.5: Conceptos de MESSAGE/UML(tomado de Caire et al. [22])

MESSAGE/UML define un conjunto de vistas o perpectivas, queproporciona un mayor nivel de entendimiento del sistema. Esteconjunto es similar al usado en la metodologa MAS-CommonKADSde Iglesias et al. [83]:

Vista de la Organizacin: muestra entidades concretas en elsistema y su ambiente y las relaciones entre ellos (agregacin,poder, y relaciones conocidas).

Vista Meta/Tarea: muestra metas, tareas, situaciones y lasdependencias entre ellos.

Vista Agente/Rol: se enfoca en especificar a los agentes y susroles asociados.

Vista Interaccin: por cada interaccin entre agentes-roles, semuestra el iniciador, el colaborador, el motivador, la informacinrelevante suministrada/lograda por cada participante, eventosque activ la interaccin, entre otros aspectos.

Vista del Dominio: muestra dominio y relaciones que sonrelevantes para el sistema en desarrollo.

Durante el Proceso de Anlisis se genera un modelo del sistema y suambiente, utilizando refinamiento de manera gradual. El nivel msalto de descomposicin esta referido como un nivel 0. En este nivel elproceso de modelaje comienza con la construccin de las Vistas deOrganizacin, Vista Metas/Tareas, Vista Agente/Rol y Vista


del Dominio. Finalmente, la Vista de Interaccin se construyeusando los otros modelos. A partir de los modelos de nivel 0 secrean los modelos de nivel 1, donde se definen las estructuras yel comportamiento de entidades como Organizacin, Agentes, Tareas,Metas, Dominios. No se sugiere alguna estrategia en particular pararefinar los modelos de nivel 0, va a depender de diferentes enfoquespara analizar las propiedades del sistema.

MESSAGE/UML usa el diagrama de clases de UML y lo extiendecon los conceptos de orientacin a Agentes para construir todas lasvista del sistema. El diagrama de Clases se le agregan tres conceptos:Recursos, Organizacin y Rol; cada uno representado con un conoen particular.

Conclusin.

MESSAGE/UML construye un agente con estado interno, cuyosatributos internos son propsitos y metas, y considera que el estadoexterno del agente esta descrito a travs de roles. Ambos estadointernos y externos, descritos en MESSAGE/UML estan previstos en elMRA descrito en 2.1.

2.2.6 INGENIAS.

La metodologa INGENIAS propuesta por Gmez-Sanz and Pavn[74], re-usa el trabajo de la metodologa MESSAGE/UML para establecersu propuesta. INGENIAS ofrece tres elementos de ayuda para eldesarrollo de un sistema multiAgentes:

Un lenguaje visual: utiliza GOPRR (Graph, Object, Property,Relationship, and Role (GOPRR)) de Lyytinen and Rossi [109]como lenguaje de meta-modelos.

Integracin con el ciclo de vida de desarrollo de software:la metodologa est embebida en un proceso de desarrolloindustrial, Unified Software Development Process (USDP) deJacobson et al. [88]

Herramienta de desarrollo: usa una herramienta, METAEDIT+de Lyytinen and Rossi [109], como ambiente de anlisis/diseo.

Para describir un sistema multiAgentes, INGENIAS proporciona lossiguientes modelos:

Modelo de Agentes: describe al agente con sus metas, tareas,estado mental inicial, (Shoham [152]) , y roles jugados.

Modelo de Interaccin: describe la interaccin entre losAgentes.


Modelo de Metas y Tareas: describe las relaciones entre metasy tareas, estructuras de las metas y estructuras de las tareas.

Modelo Organizacional: describe como se agrupan loscomponentes del sistema, las metas que comparten y lasrestricciones existentes en la interaccin entre agentes.

Modelo de Ambiente: define la percepcin del agente entrminos de los elementos existentes en el sistema.

La metodologa contempla dos etapas: Anlisis y Diseo.En la etapa de Anlisis:

genera los casos de uso y se identifican las acciones de esoscasos de uso con el modelo de interaccin;

se esquematiza la arquitectura del sistema con el ModeloOrganizacional

se genera el Modelo Ambiental.

Durante la etapa de Diseo, se genera un prototipo usando unaherramienta de desarrollo de aplicaciones tales como agentTool deDeLoach [45] o ZEUS de Nwana et al. [122].

INGENIAS proporciona una herramienta para el modelado visual:INGENIAS IDE4 que generar los modelos que conforman la meto-dologa y UML para los diagramas de interaccin que describen elmodelo de Interaccin.

Conclusin.

En el estado interno, INGENIAS modela un agente como unaentidad con un estado mental, con creencias, compromisos, metas yplanes. El agente tiene un estado mental inicial y ste estado mentalpuede variar dependiendo de las creencias del agente y de laspercepciones que el agente tenga de su ambiente. El estado externodel agente, INGENIAS lo describe a travs de roles y caso de uso.Ambas descripciones, a saber estado interno y estado externo delagente, estn descritos de igual manera en el MRA descrito en 2.1.

2.2.7 Tropos.

La metodologa Tropos presentada por Bresciani et al. [18], tomacomo base el trabajo de Yu [168] acerca del modelo i*, que ofrecemodelar actores, metas y dependencia entre actores como conceptosprimitivos. La metodologa Tropos usa los siguientes conceptos:

4 est en http://ingenias.sourceforge.net


Actor: modela una entidad que tiene metas estratgicas e inten-cionalidad dentro de un sistema o valores organizacionales. Unactor representa un agente de software un agente fsico unagente social, as como tambin, un rol una posicin.

Un rol es una caracterizacin abstracta del comportamien-to de un actor social dentro de algn contexto especializa-do o dominio.

Una posicin representa un conjunto de roles jugado porun agente.

Metas: representa intereses estratgicos del actor. Se clasificansegn su relacin o n con los requerimientos funcionales comometas duras y metas blandas.

Plan: es una manera de hacer algo. La ejecucin del plan puedeser un medio para satisfacer una meta.

Recursos: representa una entidad fsica o una entidad informa-cional.

Dependencia: entre dos actores, indica que un actor depende, poralguna razn, de otro para lograr una meta, ejecutar algn plan,o distribuir algn recurso.

Capacidad: representa la habilidad de un actor de definir, escogery ejecutar un plan para cumplir con una meta.

Creencia: representa el conocimiento del actor acerca del mundo.

La metodologia Tropos consiste de cinco fases:

Requerimientos Tempranos: se construye el Modelo de Actor,el Modelo de Dependencia de Metas, el Modelo de Metas y el Modelode Plan.

Requerimientos Finales: extiende los modelos creado enla etapa previa e incluye un nuevo actor, el sistema, y lasdependencias con otros actores del ambiente.

Diseo de la Arquitectura, extiende el Modelo de Actores,identificando las capacidades y agrupandolas para forMRA losAgentes.

Diseo detallado: se especifican los agentes y se construye unModelo de Capacidad.

Implementacin: utiliza una plataforma BDI, como JACKIntelligent Agents de Buseta et al. [20], para la implementacindel sistema multiAgentes.


Para las fases de Requerimientos Tempranos, RequerimientosFinales y Diseo de la Arquitectura, la metodologa Troposproporciona una notacin grfica propia. En la fase de Diseodetallado se usan los los diagramas de actividad de UML y losdiagramas de interaccin de AUML para representar las capacidadesy los planes.

Conclusin.

Tropos propone un agente con un estado interno descrito por metas,intenciones, capacidades y creencias. Los atributos metas, intenciones ycreencias del estado interno del agente Tropos, de igual manera estnincluidos en el MRA descrito en 2.1. El atributo capacidad, Troposlo define como habilidad de un actor de definir, escoger y ejecutarun plan. El atributo capacidad, el MRA lo define como el atributopreferencias del agente, que son un conjunto de metas o de reglasque pueden seleccionarse. El estado externo del agente de Tropos estadescrito por medio de roles al igual que el estado externo del MRA.

2.2.8 MAS-CommonKADS.

La metodologa MAS-CommonKADS propuesto por Iglesias et al. [82]extiende la metodologa Common Knowledge Acquisition DesignSystem (CommonKADS)5 de Schreiber et al. [148], aadiendo aspectosrelacionados con el modelado de SMA. Se definen los SMA mediantelos siguientes modelos:

Modelo de Agentes: Especifica las carcteristicas de losagentes: capacidad de razonamiento, habilidades, servicios,grupos y jerarqua de agentes.

Modelo de Tareas: describe las tareas que un agente puederealizar

Modelo Experto: describe el conocimiento necesario delagente para lograr su tarea.

Modelo de Organizacin: describe la organizacin en la cualel SMA se va a incluir, y la organizacin social de la sociedad deagente

Modelo de Coordinacin: describe la conversacin entreagentes: sus interacciones, protocolos y capacidades requeridas.

Modelo de Comunicacin: detalla la interaccin entre elagente software-humano, y el factor humano para desarrollarestas interfases de usuario

5 est en http://www.commonkads.uva.nl


Modelo de Diseo: consiste de tres submodelos: modelo de red,el diseo del agente y la plataforma de diseo.

La metodologa sigue las siguientes fases para desarrollar losmodelos descritos: Conceptualizacin, Anlisis y Diseo.

Conceptualizacin. Por medio de anlisis de los requerimientos ycasos de usos se obtiene una primera descripcin del problema.

Anlisis. Se especifican los requerimientos, mediante el desarro-llo de los siguientes pasos:

Modelado de Agentes: se identifican y describen los agentesmediante el desarrollo de una instancia inicial del modelode agentes.

Modelado de Tareas: descomposicin de las tareas y determi-nacin de metas y tareas

Modelado de Coordinacin: describe la interaccin y elprotocolo de coordinacin entre agentes.

Modelado del Conocimiento: modela el conocimiento de agen-te (conocimiento para cumplir la tareas y su comporta-miento proactivo) y su ambiente (creencias e inferenciasdel mundo).

Modelado de la Organizacin: se desarrolla el modelo dela organizacin de los agentes que muestra la relacinestructural o esttica entre los agentes.

Diseo. Durante esta fase se desarrolla el modelo especificadoen las etapas anteriores. Esta fase consiste en

Diseo de la red de Agentes: se determinan las facilidades deredes, conocimiento y coordinacin de la infraestructuradel SMA

Diseo del Agente: se determina la arquitectura ms adecua-da para cada agente

Diseo de la plataforma: seleccin del software y hardwarenecesario para el sistema.

El proceso de desarrollo de la metodologa combina la visin demanejo de riesgos con la visin basada en componentes, de maneraque los componentes definidos sean candidatos para el reuso.

La metodologa MAS-CommonKADS inicia la etapa de Conceptualiza-cin del sistema con diagramas UML de Casos de Uso para recolectarlos requerimientos del sistema y luego, se construye Message Sequen-ce Charts (MSC) - Rudolph et al. [145] para formalizar las interaccio-nes.

En la etapa de Anlisis, no hay herramientas grficas para elmodelo de agentes, sino ms bien un conjunto de estrategias para


analizar los requerimientos y determinar los agentes. La metodologano presenta una estructura grfica para el Modelo de Tareas. ElModelo de Coordinacin usa MSC para describir los escenariosentre agentes, y Specification and Description Language (SDL) queaparece en Z100 [169], para modelar cada interaccin.

El modelo de Conocimiento, la metodologa extiende las Tcnicasde Modelado de Objetos, (Object Modelling Technique, OMT) pararepresentar el Dominio del Conocimiento. Y finalmente, para elmodelo de la Organizacin se usa el modelo de Objeto de laTcnicas de Modelado de Objetos, (Object Modelling Technique,OMT).

Conclusin.

MAS-CommonKADS modela el estado interno del agente con losatributos de capacidades de razonamiento, metas e intenciones. Lacapacidad de razonamiento se modela durante la fase de Modelajedel Conocimiento, donde se define tambin el mecanismo deinferencia del dominio y el mecanismo de inferencia del ambiente.Como atributos de la capacidad de razonamiento del agente estn losmtodos de resolucin de problemas, carcter del agente, creencias,conocimiento del mundo y de otros agentes.

El estado externo del agente modelado en MRA descrito en 2.1,establece un estado interno que contempla los atributos de creencias,metas e intenciones. As como un conjunto de mecanismo deinferencia que son parte de la dinmica interna del agente en MRA.

MAS-CommonKADS modela el estado externo del agente por mediode las conversaciones entre los agentes y los protocolos entre agentesoftware-humano, y el factor humano. Adems considera el modeladode creencias e inferencias sobre el mundo. El agente de MRA describeen su estado externo las convesaciones entre agentes y la interrelacinagentes software-humano y el factor humano. Y en la interfaz del agentedel agente MRA se considera el conocimiento del agente acerca de sumedio ambiente.

En consecuencia, el MRA y MAS-CommonKADS coinciden, salvoporque en el MRA no hay previsin explcita del carcter del agente yde su conocimiento sobre otros agentes.

2.2.9 O-MaSE.

La metodologa O-MaSE de Garcia-Ojeda et al. [68], extiende MaSEcon la visin de la Ingeniera de Mtodos presentado en Brinkkemper[19] y visualizan la construccin del SMA a partir de fragmentos demtodos, los cuales estn basados en un metamodelo comn. Paradefinir el armazn de procesos de O-MaSE, toman como referencia al


OPEN Process Framework (OPF)6 de Firesmith and Henderson-Sellers[64] . Definen, de manera similar los niveles del sistema: En el nivelM2 est el metamodelo OPF; y el nivel M1 contiene la definicin deO-MaSE en la forma del Metamodelo O-MaSE, Fragmentos de Mtodos ylas Guas.

Metamodelo O-MaSE: presenta la Organizacin a travs de lasentidades: Metas, Roles, Agentes, Dominio, Modelo y Polticas.

Fragmentos de Mtodos: O-MaSE define las siguientes unidadesde trabajo: Actividad, Tareas, Tcnicas, Productos de Trabajo,Produccin y Lenguaje. Se definen tres tipos de actividades:Ingeniera de Requerimientos, Anlisis y Diseo. Cada actividadtiene asociada tareas, tcnicas para realizar la actividad, productosde trabajo como resultado,mtodo de produccin y lenguaje paradescribir la actividad.

Las actividades constan de:

Ingeniera de Requerimientos:

las tareas asociadas son: (i)la realizacin del modelo de metasy (ii) el Refinamiento de las metas.

el producto de trabajo es un Modelo de Metas paraSistemas dinmicos.

la produccin de esta actividad es el Modelador deMetas.

Anlisis:

las tareas son: (i) Modelado de la Interface Organiza-cional,(ii) Modelado de Roles,(iii) Definicin del Rolesy (iv) el Modelado de Dominio.

la produccin de esta actividad son: Modelador Organi-zacional, el Modelador de Roles, y el Dominio Experto.

el producto de trabajo son: Modelo Organizacional,Modelo de Roles y el Modelo de Dominio

Diseo:

6 OPF est en http://www.opfro.org/En Garcia-Ojeda et al. [68], lo definen as: es una visin de un estandar industrialpara Ingeniera de Mtodos aplicados a la produccin de procesos. OPF ! (OPF !)usaun armazn integrado basado en metamodelos que permite a los diseadoresseleccionar fragmentos de mtodos de un repositorio y construir el proceso usandoconstrucciones identificadas y guias adaptadas. El armazn basado en metamodelosest soportado por un esquema de tres capas. La capa M2 incluye el metamodelo OPF,el cual es un metamodelo de procesos genricos que define los tipos de fragmentosde mtodos que pueden usarse en M1". En el nivel M0 estn las instancias de losprocesos.


Las tareas asociadas son: (i) Modelado de Clases deAgentes,(ii) Modelado de Protocolos, (iii) Modeladode Planes, (iv) Modelado de Polticas, (v) Modeladode Capacidades, (vi) Modelado de Acciones y (vii)Modelado de Servicios.

Los productores son: Modelador de Clases de Agentes,Modelador de Protocolos, Modelador de Planes, Modeladorde Polticas, Modelador de Capacidades, Modelador deAcciones y Modelador de Servicios.

El producto de trabajo son: Modelo de Clases deAgentes, Modelo de Protocolos, Modelo de Planes, Modelode Polticas, Modelo de Capacidades, Modelo de Acciones yModelo de Servicios

Guas: describe como se pueden combinar los fragmentos demtodos para obtener los procesos.

La metodologa O-MaSE proporciona una herramienta para desarrollodel software, AgentToolIII de Garcia-Ojeda et al. [68], que da soportea los pasos de la metodologa y proporciona los diagramas queapoyan cada etapa. Los lenguajes utilizado son:

lenguaje natural

UML y AUML para los diagramas de interaccin, protocolos deinteraccin y modelos especficos

notacin O-MaSE desarrollada en la herramienta AgentToolIII

lenguaje formal, para las especificaciones formales de laspropiedades del sistema.

Conclusin.

La metodologa O-MaSE proporciona un marco de procesos paraconstruir SMA. O-MaSE plantea el estado interno del agente de manerasimilar que el agente de MaSE. Pero en O-MaSE toma en consideracinel ambiente en el cual est inmerso el agente definiendo los objetosque lo conforman y las interacciones entre ellos y le asigna polticas oreglas organizacionales a las organizaciones para modelarlas. Comose explic en la parte 2.2.3, el agente de MRA descrito en 2.1 contemplalos aspectos relacionados al estado interno del agente y su estadoexterno. Sin embargo, los aspectos relacionados con las polticas yreglas organizacionales, no estn consideradas en el MRA.

Hemos revisado un conjunto de metodologas conocidas y sehan comparado con el MRA propuesto en 2.1. Esta comparacin


ha permitido establecer que el MRA es un modelo general de unagente que abarca las distintas visiones de los SMA que ofrecen lasmetodologas revisadas.

En la siguiente seccin exploraremos como el MRA esta inscritodentro de la teora de simulacin multiAgentes propuesta por Dvilaet al. [44].

2.3 teora de simulacin multiagentes .

Una teora de simulacin, Dvila et al. [43] la conceptualizancomo ...una explicacin general de lo que es un sistema, suscomponentes y sus reglas de transicin, establecido todo como unconjunto de proposiciones matemticas formalizadas. El objetivo esel de proporcionar a los desarrolladores de sistemas de simulacincon una especificacin que dice lo que un simulador debe hacer ycmo debe comportarse para simular un sistema.

La teora de simulacin multiAgentes propuesta por Dvila et al.[44] es un mode

modelo de referencia para simulación con agentes y...

Documents