*Departamento de Sistemas Informáticos y Computación, Universidad Politécnica de Valencia, Camino de Vera, Valencia, 46022, jogonba2@inf.upv.es. El autor es estudiante de 3º curso del grado de ingeniería informática -Computación- ** Departamento de Sistemas Informáticos y Computación, Universidad Politécnica de Valencia, Camino de Vera, Valencia, 46022, aldool2@inf.upv.es. El autor es estudiante de 3º curso del grado de ingeniería informática -Computación-

1

Agent Based Simulation

J. Ángel González *, Alberto Donet **

Departamento de Sistemas Informáticos y Computación

Universidad Politécnica de Valencia

Marzo 2015

Resumen

Los modelos basados en agentes nos permiten modelar sistemas sociales compuestos por agentes (ABMS) con características bien definidas: autónomos, proactivos, reactivos, autocontenidos -con tareas bien delimitadas- , sociales, adaptativos y dirigidos por objetivos que interactúan entre sí y se influyen mutuamente, aprendiendo de sus experiencias para poder adaptarse al entorno al que han sido destinados. Véase que una característica imprescindible para modelar este tipo de sistemas es la heterogeneidad, que da lugar a la aparición de la auto-organización y otros fenómenos emergentes entre el conjunto de agentes que componen el sistema, formando sistemas complejos basados en la interacción de componentes autónomos que tienen el objetivo de adaptarse a nivel individual o de población. Nuestro trabajo, por tanto, se centrará en realizar una aproximación a este tipo de sistemas, basándonos en el trabajo de (C.M Macal et al., 2010, « Journal of Simulation», 151-162) y analizar un subconjunto de todas las posibles aplicaciones, que abarcan una amplia gama de áreas y disciplinas tales como la física, biología, redes (propagación de virus en una red -Uri Wilensky-) ,matemática, computación (autómatas celulares -Juego de la vida-), ciencia de la tierra (cambio climático -Uri Wilensky-) , ciencias sociales y sistemas dinámicos entre muchos otros, empleando y analizando la aplicación de modelado basado en agentes NetLogo que ha sido posible gracias a los avances en el desarrollo y diseño de software orientado a agentes.

PALABRAS CLAVE: ABMS, agentes, interacción, sistemas sociales.

Abstract

Agent-based models allow us to model social systems composed by agents (ABMS) with well defined characteristics: autonomous, proactive, reactive, self-contained, with well delimitadas- tasks, social, adaptive and directed by goals interact and influence each other learning from their experiences to suit the environment to which they are destined. See an imperative to model these systems feature is the heterogeneity, leading to the emergence of self-organization and other emergent phenomena among the set of agents that compose the system, forming complex systems based on the interaction of autonomous components which aim to adapt to the individual or population level. Our work, therefore, will focus on an approach to such systems, based on work (CM Macal et al., 2010, "Journal of Simulation", 151-162) and analyze a subset of all possible applications, covering a wide range of areas and disciplines such as physics, biology, networks (spread of virus in a -uri Wilensky- network), mathematics, computing (cellular automata -Game life-), earth science (climate change -uri Wilensky-), social sciences and dynamic systems among many others, using and analyzing the application of NetLogo agent-based modeling has been possible thanks to advances in the development and design of agent-oriented software.

KEYWORDS: ABMS, agents, interaction, social systems

2

Índice

1. Introducción

2. Definición y componentes ABMS

2.1. Características de un Agente

2.2. Interacción entre Agentes

2.3. Entorno

3. Diseño e implementación de un ABMS

4. Análisis de NetLogo

4.1. Vistas

4.1.1. Interfaz

4.1.2. Ajustes del entorno

4.1.3. Ajustes de la simulación

4.1.4. Información

4.2. Agentes y propiedades

4.2.1. Propiedades adicionales

4.2.2. Razas

4.3. Primitivas básicas 4.4. Procedimientos

4.5. Variables 4.6. Listas

4.7. Sentencias condicionales, procedimientos con retorno y bucles 5. Análisis de aplicaciones

5.1. Juego de la vida

5.1.1. Agentes e interacciones

5.1.2. Diferencias con ABMS actuales

5.2 Aplicación a analizar

5.2.1. Agentes e interacciones

5.2.2. Implementación NetLogo

5.2.3. Casuísticas y resultados de experimentos

6. Conclusiones

7. Anexo

8. Bibliografía

3

1. Introducción

El modelado y simulación basado en

agentes- a partir de ahora ABMS - ofrece

una manera de modelar sistemas sociales

compuestos por agentes que interactúan

y se influencian entre ellos , aprendiendo

de sus experiencias y adaptando su

comportamiento para convivir mejor en

el entorno al que han sido destinados,

tanto de forma individual como colectiva.

Dichos agentes poseen ciertas

características como: autonomía,

capacidad social a nivel de cooperación,

negociación y coordinación y capacidad

de adaptación, entre otras. Modelando

estos agentes mediante simples reglas y

de forma individual (primando la

heterogeneidad entre la población de

agentes) se desarrollan una serie de

interacciones que generan patrones,

estructuras, influencias y

comportamientos emergentes que no

han sido explícitamente programados en

los modelos pero surgen entre el

conjunto de agentes de la población.

En el marco citado se desarrolla la

tecnología ABMS, que ha sido utilizada en

una gran variedad de disciplinas y áreas

como el modelado del comportamiento

del mar (Hill et al, 2006), el desarrollo de

guerras biológicas (Carley et al, 2006)

incluso la comprensión de la caída de

civilizaciones antiguas (Kohler et al,

2005). En dichos casos sólo ha sido

necesario implementar los detalles

esenciales de los sistemas, a partir de los

cuales se han dado ciertas interacciones

y comportamientos que han ofrecido

posibles soluciones a los problemas

planteados. Existen incluso sistemas

basados en agentes en los que los

agentes son modelados con un alto nivel

de detalle (con el coste computacional

que ello conlleva) y que han sido posibles

gracias a los avances dados en el

desarrollo de software orientado a

agentes y en la ingeniería del software

orientada a agentes, en los nuevos

enfoques de ABMS y en el incremento del

poder computacional de los dispositivos

actuales.

Por todos los detalles dados y debido a

las posibilidades de los sistemas basados

en agentes, el interés en dicha área se

encuentra en constante crecimiento, que

puede ser comprobado viendo la gran

cantidad de conferencias, artículos de

investigación y jornadas académicas en

los que se emplean ABMS a una amplia

gama de aplicaciones (ABMS Google

Scholar, 603.000 resultados).

En éste trabajo se realizará una síntesis

basándonos en el artículo de (C.M Macal

et al., 2010, « Journal of Simulation», 151-

162) y se comentaráun subconjunto de

todas las posibles aplicaciones

empleando software orientado a agentes

(NetLogo) : simulación de la propagación

de virus en la red (similar a la

propagación de epidemias (Bagni et al,

2002)) y simulación del cambio

climático, ambos modelados por Uri

Wilensky. Además se analizará el

conocido "Game of Life" desde un

enfoque orientado a agentes y se

comentarán ciertas características de

éste.

Todos los códigos empleados en el

presente trabajo estarán adjuntos como

texto en el apartado Anexo, además

acompañarán al PDF en el .zip del

proyecto en su correspondiente formato,

dando la implementación de las

simulaciones de la propagación de virus

y de la simulación del cambio climático

en código NetLogo y "Game of Life" en

Java, implementado por uno de los

autores de este trabajo.

4

2. Definición y componentes ABMS

Los modelos basados en agentes

también son tratados en las

investigaciones como sistemas

complejos, sistemas adaptativos

complejos, vida artificial, entre otros. Sin

embargo a pesar de que todos los

sistemas mencionados consisten en la

interacción de agentes autónomos,

algunos de ellos tienen características

especiales como los sistemas adaptativos

complejos en los que dichos agentes

tienen la capacidad adicional de

adaptarse a su entorno tanto de forma

individual como colectiva.

Las investigaciones sobre dichos

sistemas han tenido como objetivo

identificar los principios universales que

permiten, a partir de un modelado

mediante sencillas reglas (con los años

los entornos de desarrollo, la potencia

computacional y las nuevas herramientas

orientadas a ABMS han permitido

expandir las capacidades de dichos

agentes y por tanto complicar tales

reglas), generar fenómenos emergentes

tales como la auto-organización, la

adaptación a los entornos y la aparición

de comportamientos emergentes que no

habían sido programados explícitamente.

Siguiendo la convención del artículo

base de este trabajo (C.M Macal et al., 2010,

« Journal of Simulation», 151-162),

emplearemos el término ABMS para

referirnos tanto a simulaciones basadas

en agentes donde se modela un proceso

dinámico dependiente del tiempo como

para otras aplicaciones más generales

que, del mismo modo, están basadas en

agentes.

De la misma forma, sean tales

simulaciones o aplicaciones más

generales, siempre que estén basadas en

modelos de agentes, estarán compuestas

de 3 componentes principales que se

comentarán en el presente trabajo: un

conjunto de agentes con atributos y

comportamientos (explícitamente

programados) que darán lugar a una

serie de interacciones que definirán la

forma y entre que agentes existirán

dichas interacciones y un entorno en el

que convivirán los agentes y se dará

soporte tanto a la interacción agente-

agente como a la interacción agente-

entorno.

2.1 Características de un agente

Los agentes constituyen uno de los 3

componentes necesarios en un ABMS.

Entre sus principales características

destacan la reactividad: siendo capaces

de reaccionar tanto a las acciones que

realicen otros agentes como a cambios en

el entorno al que han sido destinados, la

proactividad: dando a los agentes la

capacidad de tomar decisiones por si

mismos y tomar la iniciativa en las

situaciones que lo requieran y la

capacidad social: que permitirá a los

5

agentes interactuar con los demás

agentes del entorno para acciones tales

como la coordinación, cooperación y

negociación, imprescindibles para la

supervivencia en un entorno. Sin

embargo, la característica principal que

puede ser encontrada en toda la

literatura relacionada es la autonomía,

característica que permite a los agentes

actuar por si mismos de forma autónoma

como respuesta a las situaciones que

pueden darse en el entorno y que

afectarán a dicho agente.

A pesar de lo claro que puede resultar

el término autonomíay las demás

características comentadas (existen

muchas otras que serán analizadas en el

presente apartado), en la literatura no

hay una definición precisa de lo que debe

ser un agente en lo que a características

se refiere, variando dicha definición en

función del artículo, algunos ejemplos

son: Jennings (2000) quien provee una

definición en la que el agente únicamente

debe enfatizar la característica de la

autonomía independientemente de

todas las demás o (Bonabeau, 2001) que

considera como agente a cualquier

componente independiente (pieza de

software, modelo, etc) entre otros que

consideran necesarias características

como la capacidad social para provocar

interacciones entre los agentes.

Debido a las discrepancias existentes

entre los autores, nosotros nos

ceñiremos a la definición empleada en el

artículo base de C.M Macal et al, quienes

consideran que los agentes deben poseer

las siguientes características esenciales:

Auto-contenido/Modular:

Implica que el agente tiene

fronteras, haciendo referencia a

que debe poseer un conjunto de

tareas bien definidas de forma

que sea fácil determinar qué

pertenece al agente y qué no

pertenece a éste. Esta

característica facilita también que

los agentes puedan ser conocidos

y distinguidos unívocamente por

otros agentes.

Autónomo: Actuando

independientemente del entorno

en el que se encuentre y de los

agentes que lo rodeen para dar

respuesta a las situaciones que

puedan afectar a dicho agente.

Dirigido por objetivos: El

agente debe tener metas que

alcanzar mediante sus

comportamientos (que pueden

ser influenciados por la

interacción con otros agentes).

Esto permite a un agente ajustar

sus comportamientos y

respuestas a ciertas situaciones

en futuras interacciones para

alcanzar tales objetivos.

Capacidad social: A pesar de que

pueda parecer imprescindible

debido al marco que estamos

tratando, algunos autores no

consideran la capacidad social

como un elemento esencial en el

desarrollo de los agentes. Esta

capacidad permite a los agentes

tener interacciones dinámicas

entre ellos e influenciarse en sus

comportamientos mediante

protocolos para la interacción

entre agentes (protocolos de

comunicación, lenguajes de

contenido, ontologías, etc), por

ello será necesario que los

agentes tengan la capacidad de

reconocer y distinguir a los

demás agentes, para conocer la

procedencia o el destinatario de

un determinado mensaje, entre

otras acciones.

6

Podemos hablar también de

características supeditadas a la

población de agentes y ya no a un

agente en concreto, como puede

ser la heterogeneidad. De forma

contraria por ejemplo a

simulaciones moleculares

dinámicas en las que se estudian

las interacciones entre partículas

homogéneas, en las simulaciones

basadas en agentes es necesario

considerar una amplia diversidad

de agentes entre una

determinada población.

Es interesante observar como

las características y

comportamientos de los agentes

varían en función del grado de

sofisticación con el que ha sido

desarrollado cada agente, con la

información que se ha tenido en

cuenta a la hora del modelado e

incluso de eventos pasados que

sirven al agente para la toma de

decisiones. Por tanto las

características de un agente

pueden ser: estáticas, que no

cambiarán durante la simulación

o dinámicas, cambiando

conforme vaya avanzando la

simulación.

Una arquitectura típica de

agente es la siguiente:

2.2 Interacción entre agentes

La simulación basada en agentes está

constituida en base a las relaciones e

interacciones entre los distintos agentes

que forman parte del entorno. De modo

que, mediante esas interacciones, se

consigue un objetivo común que no sería

alcanzable de manera individual. Esta

capacidad de interacción entre agentes

es lo que se llama sociabilidad (también

recibe el nombre de capacidad social).

Cada agente solo posee información

local, a la que solo él tiene acceso, por lo

7

quecada agente necesita comunicarse

con el resto de agentes del entorno para

informarse, cooperar, coordinarse e

incluso realizar negociaciones para un fin

común.

Los Sistemas Basados en Agentes

(ABS) son sistemas descentralizados. No

hay una autoridad central que informe a

todos los agentes y que controle su

comportamiento en el esfuerzo de

mejorar el rendimiento. Es cada agente el

que interactúa con los demás agentes.

Aunque no es completamente cierto que

todos interactúen entre ellos, puesto que

normalmente se comunican con un

subconjunto de esos agentes, lo que

generalmente se conoce como el

vecindario. El conjunto de agentes que

forman parte de ese vecindario va

cambiando en el tiempo conforme se va

ejecutando la simulación y los agentes se

van desplazando por el entorno. Por

ejemplo, los agentes vecinos de otro

agente pueden ser aquellos que se

encuentren localizados físicamente cerca,

o aquellos que cumplen una relación

respecto del agente (esta relación debe

fijarse con anterioridad).

Lo más importante a la hora de

modelar las interacciones entre los

agentes son las especificaciones de quién

es el agente que interactúa, o a quién va

dirigido, y los mecanismos de

interacción. Estos mecanismos, que

explican cómo los agentes están

conectados, se conocen como topología o

conectividad. Dos ejemplos de topología

son “Knowledge Query Management

Language (KQML)”, basado en

performativas; y “Foundation for

Intelligent Physical Agents (FIPA)”,

basado en actos de habla con protocolos

de interacción de alto nivel

(conversaciones).

Originalmente, los modelos espaciales

basados en agentes eran implementados

mediante autómatas celulares (AC), que

representa la interacción entre agentes

utilizando la información local de una

celda (un agente por celda) y la

información que proporciona el

vecindario (celdas vecinas), donde

existen dos tipos muy conocidos:

vecindario de Moore y vecindario de von

Neumann. Un ejemplo de AC con agentes

inmóviles es “El juego de la vida” de John

Conway, del cual hablaremos en futuros

apartados. En cuanto a ejemplos de AC

con agentes móviles, tenemos topologías

en red, euclidiana y sistemas de

información geográfica (GIS), entre otras.

2.3 Entorno

Se ha podido comprobar a lo largo del

trabajo que los agentes interactúan entre

ellos y/o con su entorno.

Dicho entorno puede ser utilizado de

diversas formas para realizar

interacciones, bien sean simples, como

por ejemplo para proveer información

espacial de un agente con respecto a los

demás agentes (véase el ejemplo en

clases de teoría de los robots y las

8

piedras dejando partículas radioactivas),

usando esta alternativa normalmente

para que los agentes sigan el

movimiento de los demás agentes que

avanzan de una forma correcta a través

de un determinado entorno. O de formas

más complejas (que conllevan un

modelado más complejo) como por

ejemplo los entornos empleados en

modelos de simulación hidrológica y

atmosférica, en los cuales es común

encontrarse con limitaciones de las

acciones de los agentes por parte del

entorno.

Estas interacciones entre los agentes y el

entorno también dependen de las

características del entorno, normalmente

los entornos son complejos y los agentes

no suelen tener control total sobre éste,

pudiendo fallar las acciones que realice el

agente sobre dicho entorno, en

conclusión, los entornos son no

deterministas y los agentes deben estar

preparados ante posibles fallos. Entre las

propiedades de los entornos podemos

destacar: accesibilidad, dependiendo de

si el agente puede obtener información

completa, exacta y actualizada del

entorno (entornos complejos suelen ser

inaccesibles), determinismo, si

cualquier acción por parte de un agente

tiene un efecto garantizado, el entorno

será determinista (el mundo físico es

indeterminista), dinamicidad, si en el

entorno se producen cambios no

únicamente provocados por los agentes

el entorno será dinámico, en otro caso

será estático y continuidad, si hay un

número fijo de acciones y percepciones

en el entorno, éste será discreto, en otro

caso será un entorno continuo.

3 Diseño e implementación

de un ABMS

Para realizar el diseño de un ABMS, es

necesario contestar a una serie de

preguntas que nos ayudaran a

prepararlo:

¿Qué problema debemos

resolver? Y, ¿qué cuestiones debe

ser capaz de solucionar el

modelo?

¿Qué función desarrollarán los

agentes? ¿Qué atributos de los

agentes serán solamente

descriptivos? ¿Cuáles serán

calculados y actualizados

dinámicamente?

¿En qué entorno se van a mover

los agentes? ¿Cómo van a

interactuar con él?

¿Qué decisiones podrán tomar los

agentes? ¿Qué acciones

realizarán? ¿Cómo deberán

comportarse?

¿Cómo van a interactuar entre sí

los agentes?

¿Cómo validar el modelo?

Encontrar la respuesta a estas

preguntas será fundamental para

plantear el diseño. En general, las

metodologías de diseño altamente

iterativas parecen ser las más eficaces

para el desarrollo del modelo.

La comunicación de un modelo, la

hipótesis de proyecto, así como los

elementos detallados son esenciales si el

modelo va a ser posteriormente

comprendido y/o reutilizado. Para ello,

Grimm et al (2006) presenta un

protocolo estándar para describir los

modelos basados en agentes, con la

esperanza de que sea un primer paso

para establecer un formato común.

En cuanto a la implementación, el

modelado basado en agentes puede

implementarse empleando diseño

software y herramientas especializados,

que se ocupan de los requisitos del

modelo, o utilizando lenguajes de

programación. Como ejemplo más

9

sencillo tenemos las Hojas de cálculo de

Microsoft Excel, aunque los modelos

resultantes generalmente ofrecen una

diversidad entre agentes bastante

limitada, además de restringir los

comportamientos y de tener una

escalabilidad muy reducida. Un ejemplo

de software especializado es la

herramienta JASON (utilizada en las

prácticas de Agentes Inteligentes,

Ingeniería Informática – Rama

Computación - ), que permite realizar

proyectos de modelado de agentes, como

el robot recogedor de basura

desplazándose en un entorno

unidimensional y bidimensional.

4 Análisis de Netlogo

En los siguientes apartados vamos a proceder a describir, analizar y explicar el origen, el funcionamiento, las características y la apariencia de la herramienta NetLogo en su versión 5.2, que es la más reciente del software hasta la fecha. Fue el matemático, informático y profesor, Uri Wilensky, quien creó en el año 1999 esta herramienta. Es la generación de una serie de modelados multi-agente que empezó con StarLogo, pero añadiendo funcionalidades, características nuevas y un lenguaje rediseñado y con interfaz de usuario.

NetLogo es una herramienta que sirve

para modelar sistemas complejos que

evolucionan en el tiempo, como pueden

ser fenómenos naturales o sociales, entre

otros. Permite la creación, modificación y

ejecución de modelos de una forma fácil

y sencilla; de hecho, NetLogo incluye tras

su instalación y ejecución (ejecutable

sólo si se tiene instalada una Máquina

Virtual de Java -JVM) una colección de

modelos que pueden ser alterados y que

pertenecen a ámbitos muy diversos,

tanto de las ciencias sociales (incluye

matemáticas, física y química, biología,

medicina, computación, economía y

psicología social) como de la naturaleza.

4.1 Vistas

Comentaremos en este apartado las

características básicas de NetLogo en

los temas relativos a la interfaz de la

aplicación, como pueden ser los

paneles de control, los ajustes tanto de

la simulación como de los aspectos del

modelo (entorno, agentes, etc) y la

propia interfaz.

4.1.1 Interfaz

Una vez arrancada la aplicación, se nos presentará la siguiente ventana:

Nos fijamos en la aparición de 3 pestañas principales en la parte superior de la aplicación: Ejecutar, Información y Código.

En el apartado Ejecutar veremos una representación gráfica de nuestro modelo (la evolución de la simulación será visible también) junto con una serie botones que nos permitirán interactuar para configurar su comportamiento.

En el 2º apartado, Información, obtendremos información de nuestro modelo (previamente establecida por el programador) para informar a los usuarios como pueden ser: qué

10

significa el modelo, cómo funciona, cómo usarlo, etc.

Finalmente, en la última pestaña, Código, serán visibles los procedimientos (código fuente) que permitirán la ejecución de nuestro modelo en el apartado Ejecutar.

Dentro del apartado Ejecutar, podemos distinguir los diversos widgets de los que se compone, entre los que se encuentran:

Que nos permitirán añadir, editar y borrar elementos para el control de la simulación, tales como botones, sliders, gráficos, etc.

Que es el panel de control de la simulación, donde podremos cambiar la velocidad de simulación e incluso indicar cuándo se actualizará el mundo, pudiendo incluso indicar manualmente el número de ticks para el refresco.

En la parte derecha podemos encontrar el botón de configuración que permitirá cambiar las propiedades del “mundo” (entendiendo mundo en el ámbito de NetLogo como el entorno ya comentado).

El entorno de nuestro modelo, donde se visualizará el comportamiento de los agentes de nuestro modelo. Dicho

entorno está formado por celdas (de forma similar al robot recogedor de basura de las prácticas) cuyo tamaño y número puede ser modificado en el apartado configuración. Dicho entorno estará poblado por agentes que serán comentados en apartados posteriores.

Otro elemento importante es la ventana de comandos que nos permitirá llevar a cabo la simulación en caso de que no hayamos definido un código formado por procedimientos, en caso de que se emplee la ventana de comandos (terminal de instrucciones), el propio agente observador (se comentará después el papel de éste en la arquitectura de NetLogo) será el “programador” del modelo. En ella podremos realizar acciones que tengan un efecto sobre el mundo, como pueden ser crear tortugas (también se comentará después el papel de éstas) y ordenarles la realización de acciones.

4.1.2 Ajustes del modelo

En éste apartado, alcanzable al clickear en el apartado Configuración presentado antes, se puede modificar la configuración de nuestro modelo, desde las características del entorno como pueden ser la anchura y la altura dadas por las variables de Netlogo world-width y world-height (por defecto 33 y 33, que dan un total de 1089 patches en total), que almacenan la anchura y la altura del "mundo", cumpliendo que el tamaño del mundo es el producto entre estas 2 variables. Además el tamaño del mundo queda definido también por las variables max-pxcor y max-pycor, que representan la coordenadas centrales de las celdas más alejadas del origen.

11

También es posible configurar el tamaño de las celdas por las que está compuesto el mundo que será el tamaño que tendrá el mundo en la representación, dicho tamaño dependerá tanto del tamaño de las celdas como de max-pxcor y max-pycor, ya que cuanto mayor sean estas 2 variables más celdas cabrán en la representación.

La frontera del mundo también se puede modificar con 2 parámetros, límite horizontal y límite vertical, indicando si los agentes se podrán desplazar más allá de los límites tanto horizontalmente como verticalmente, pudiéndose generar errores en el modelo si los agentes avanzan superan dichos límites.

La etiqueta para indicar un incremento en la iteración de la simulación, por tanto, si escribimos ticks en nuestro código (tal como está en la imagen), se avanzará la simulación.

4.1.3. Ajustes de la simulación

En cuanto a los ajustes de simulación una vez se va a ejecutar el modelo, podemos modificar el parámetro de la velocidad de simulación, la cual se encuentra por defecto en la posición “normal”, mediante un slider en la parte superior central de la ventana principal. Este slider nos ofrece la

posibilidad de cambiar la velocidad de forma que la simulación sea más lenta o más rápida. Sin embargo, no se modifica la velocidad de la obtención de los datos como podría pensarse, sino la velocidad con la que esos datos se mostrarán.

Además de la velocidad, cuando activamos el checkbox “Actualizar de la Vista…” (view updates), y dependiendo de la opción que seleccionemos en el combobox inmediatamente por debajo del checkbox (continuamente o por sticks), podremos observar los cambios en el modelo paso a paso o por cada iteración. Mientras que si no activamos esta opción tan sólo se actualizará el mundo-entorno al finalizar la simulación.

Por último, para la modificación de cualquier variable global modificable, su representación o para mostrar información referente al modelo podremos incorporar los siguientes elementos:

Button. Al pulsarlo se ejecutan comandos.

Slider. Permite modificar el valor de una variable dentro de un rango.

Switch. Controla el valor de una variable global booleana.

Chooser. Similar al slider, pero los valores que podrá tomar la variable serán discretos.

Input. El usuario teclea el valor de una variable.

Monitor. Muestra el valor que toma una variable durante su ejecución.

Plot. Permite realizar una representación gráfica.

12

Output. Una pantalla en la que podemos mostrar información (mensajes a lo largo de la ejecución).

Note. Texto.

4.1.4. Información

Como se ha comentado en 4.1.1, en este apartado de la aplicación obtendremos información de nuestro modelo para informar a los usuarios. Con más detalle, observamos categorías ya definidas semejantes a cualquier documentación de software convencional, como:

Una explicación de sobre qué trata nuestro modelo.

Sobre cómo funciona las reglas rigen el comportamiento de los agentes del modelo.

Incluso sobre casuísticas de prueba que podrían resultar interesantes para el usuario de la aplicación y de nuestro modelo.

Es posible editar la información del

modelo mediante el botón Editar,

escribiendo la documentación con un

lenguaje de marcado similar a

Markdown.

4.2 Agentes y propiedades

Como ya se ha comentado en el apartado de introducción a NetLogo, éste es un lenguaje de programación que sigue la filosofía del modelado basado en agentes.

Entre los agentes disponibles en NetLogo encontramos 3 tipos

principales que nos permitirán desarrollar nuestro modelos:

· Turtles: Son los agentes principales visibles por el observador (considerado otro agente en el ámbito de NetLogo), que se desplazan sobre el entorno e interactúan entre sí y con el entorno (con los patches que conforman mundo, considerados otro agente como ahora veremos) de forma sencilla o compleja según unas reglas específicas que regulan su comportamiento, pudiendo dar lugar a comportamientos emergentes que no han sido explícitamente programados. Cada tortuga es identificada por un id que la hace única.

· Patches: El mundo (entorno) de NetLogo es el terreno donde se desplazan las tortugas. Este mundo está formado por porciones más pequeñas denominadas patches o celdas. Del mismo modo que las tortugas vienen identificadas por un id único, estos patches están identificados por las coordenadas de su punto central.

· Link: Pueden existir turtles que estén relacionados entre sí (sin tener por ello que ser necesaria una interacción), para modelar estos enlaces o relaciones se emplean los links, considerados otro agente dentro del ámbito de NetLogo. Los links también están identificados unívocamente, en este caso por una tupla n-dimensional que relaciona turtles, e.g. (turtleN,turtleM).

· Observador: El último agente considerado por NetLogo es el observador o usuario de la aplicación. Aunque éste no está representado en el mundo como el resto de los agentes, es capaz de modificar el comportamiento de la simulación y del mundo (creando y destruyendo agentes, propiedades, …), razón por la cual éste es considerado como un agente más.

13

Cada agente tiene una serie de propiedades que lo describen (no lo identifican), por ejemplo, las tortugas cuentan con las siguientes características:

who ;; identificador (no se puede modificar)

color ;; color

heading ;; orientación

xcor ;; coordenada x

ycor ;; coordenada y

shape ;; forma

label ;; etiqueta

label-color ;; color de la etiqueta

breed ;;raza

hidden? ;; ¿visible o no visible?

size ;; tamaño

pen-size ;; tamaño del trazo al desplazarse (cuando pen-mode=down)

pen-mode ;; ¿dejar trazo al desplazarse o no?

Es posible ver dichas propiedades mientras la simulación está en ejecución haciendo click con el botón derecho del ratón sobre la tortuga y seleccionando la tortuga de la que queremos conocer la información.

Los patchs que conforman el entorno también tiene propiedades asociadas entre las que se encuentran las siguientes:

pxcor ;; coordenada x del patch

pycor ;; coordenada y del patch

pcolor ;; color del patch

plabel ;; etiqueta del patch

plabel-color ;; color de la etiqueta del patch

Podemos conocer las propiedades de los agentes también desde el código de nuestro modelo mediante: [propiedad] of id_agent. También se pueden identificar los agentes mediante la primitiva básica ask. Tales instrucciones junto con las primitivas

básicas serán explicadas en el correspondiente apartado.

4.2.1 Propiedades adicionales

En el apartado anterior se han comentado las propiedades básicas de todo agente y que se poseen desde el momento de su creación, sin embargo es posible definir propiedades adicionales sobre los agentes que nos interese. Por ejemplo, añadir la propiedad edad a los agentes turtle que simulen un humano en nuestro modelo.

Para definir dichas propiedades se utilizará también una primitiva básica, own o se podrán establecer desde el momento de creación del agente con la primitiva set. Las dos formas posibles son las siguientes:

1. crt 1 [set edad 20] ;; Se crearía una tortuga con la propiedad edad desde su inicio.

2. turtles-own [edad] ;; Se añade la propiedad edad sobre el conjunto turtles.

Es importante observar que mediante el segundo método es necesario dar un valor a la propiedad una vez establecida, por ejemplo de la siguiente forma: ask turtle 1 [set edad 20]

4.2.2 Razas

Hemos supuesto hasta ahora que todos los turtles empleados son del mismo tipo y poseen las mismas propiedades (a pesar de que hayamos definido propiedades adicionales), pero no es necesario que ésto sea así.

Cuando sea necesario que en nuestro modelo coexistan diferentes tipos de agentes - con propiedades diferenciadas - emplearemos lo que NetLogo denomina razas o breeds.

14

Para la creación de una nueva raza emplearemos la primitiva breed seguida de corchetes entre los que indicaremos, primero el nombre del conjunto de agentes de la raza (en plural) seguido del nombre en singular de cada agente de la nueva raza (en singular), e.g.

breed [alumnos alumno].

Una vez definida la nueva raza podemos emplear el nombre de la raza (el plural que identifica al conjunto de agentes) para realizar las mismas acciones que realizaríamos sobre las tortugas “normales”. Entre éstas, destacan la asignación de una nueva forma a la hora de su creación para diferenciar la nueva raza de las demás tortugas con set-default-shape , la petición de realización de alguna acción por parte de los agentes de la raza con ask raza [acción parámetros] y la creación de nuevos agentes pertenecientes a la raza con create-nombreraza nºagentes .

4.3 Primitivas básicas

Ya comentado el enfoque de los sistemas basados en agentes que propone NetLogo, tenemos que ser capaces de emplear comandos que nos permitan llevar a cabo la simulación, pudiendo crear/destruir/modificar agentes, ordenar la realización de acciones por parte de éstos entre muchas otras posibilidades ofrecidas por dicho software. Todas los comandos, a partir de ahora primitivas, serán lanzados en este apartado a través de la ventana de comandos ofrecida por NetLogo, comentando en apartados siguientes la posibilidad de crear nuestros propios procedimientos empleando también tales primitivas, además, nos ceñiremos a comentar únicamente las primitivas básicas más utilizadas.

En primer lugar, es necesario introducir la primitiva create-turtles cuya abreviatura es crt. Tal primitiva es empleada para la creación de tortugas, indicando tras la orden de creación el número de tortugas que el observador (al trabajar con la ventana de comandos, consideraremos que el agente observador será también el programador del modelo) desea crear, e.g. create turtles 2 o crt 2 , crearían 2 tortugas en nuestro mundo, situadas en las coordenadas centrales de éste.

La segunda primitiva que comentaremos será ask, que permitirá la petición de realización de acciones por parte de las tortugas. Dicha primitiva se emplea indicando junto a ella el nombre del agente o conjunto de agentes que deben realizar la acción, seguido a su vez de, entre corchetes, otra primitiva o conjunto de primitivas que indiquen la acciones a realizar entre las que destacan (se indican las primitivas seguidas de su abreviatura y su semántica):

forward ;; (fd) avanzar

back ;; (bk) retroceder

left ;; (lt) giro a la izquierda

right ;; (rt) giro a la derecha

repeat ;; repetir un conjunto de primitivas

pen-up ;;(pu) subir el lápiz (los agentes no dejan huella al moverse)

pen-down ;;(pd) bajar el lápiz (los agentes dejan trazos al moverse)

clear-all;;(ca) se resetean variables, se limpia “el mundo”, se borran gráficas, etc.

Un ejemplo de construcción empleando la primitiva ask , sería, e.g. ask turtles [fd 5] que indicaría a todos los agentes

15

tortuga a realizar un movimiento de avance 5 posiciones hacia el ángulo al que estén orientados. Para ilustrar un ejemplo más detallado, consigamos que todas las tortugas creadas realicen un movimiento de forma que dibujen un cuadrado de 5 unidades, introduciríamos lo siguiente:

clear-all ;; Resetearemos el entorno

crt 4 ;; Creamos 4 tortugas

ask turtles [fd 5 rt 90 fd 5 rt 90 fd 5 rt 90 fd 5]

Mediante la última primitiva indicamos al conjunto de las tortugas que se desplacen 5 posiciones en su orientación, giren 90º, se desplacen 5 posiciones en su orientación, giren 90º y así sucesivamente hasta haber alcanzado la posición inicial, formando un cuadrado que empieza y acaba en las coordenadas origen. Sin embargo, si se realiza el experimento no se observa movimiento aparente, el problema es la velocidad de simulación, al ser un modelo tan sencillo el tiempo de proceso de tal primitiva es muy reducido y no se observan cambios significativos respecto del estado inicial, dicho problema se soluciona reduciendo la velocidad de simulación en el slider de la pestaña Ejecutar. Si hacemos esto último observamos que las tortugas no realizan las acciones en paralelo por lo que en principio no existe paralelismo si se pide la realización de una acción por parte de un conjunto de tortugas del mismo tipo.

Podemos también hacer que dibujen explícitamente los movimientos que realizan mediante el uso de las primitivas pen-down/pd y pen-up/pu , que permiten a los agentes la “utilización de un lápiz” para marcar sus movimientos, si el lápiz se encuentra en uso (bajado, pen-down), o dejar de marcarlos si el lápiz está en desuso (subido, pen-up). En el ejemplo

anterior solo tendríamos que modificar la última primitiva ask , indicando junto a los movimientos que el lápiz debe bajarse al inicio del desplazamiento y subirse al final.

clear-all ;; Resetearemos el entorno

crt 4 ;; Creamos 4 tortugas

ask turtles [pd fd 5 rt 90 fd 5 rt 90 fd 5 rt 90 fd 5 pu] ;; Ahora indicando el uso del lápiz

Observamos otro problema en la primitiva anterior. ¿Qué pasaría si tuviésemos que realizar un número elevado de desplazamientos para formar un polígono complejo como un miriágono?. Nos llevaría un tiempo considerable indicar a mano junto con la primitiva ask los movimientos a realizar, para ello podemos emplear otra primitiva muy empleada como es repeat. Dicha primitiva nos permite repetir una determinada acción o conjunto de acciones un número de veces que se indica explícitamente junto a la primitiva, nuestro ejemplo dibujando el cuadrado quedaría:

clear-all ;; Resetearemos el entorno

crt 4 ;; Creamos 4 tortugas

;; Empleando la primitiva repeat

ask turtles [pd repeat 4 [fd 5 rt 90] pu]

4.4 Procedimientos

Podemos entender los procedimientos en NetLogo como las funciones o procedimientos en cualquier otro

16

lenguaje no orientado al modelado basado en agentes, una función definida por el programador que engloba un conjunto de primitivas ya definidas por el lenguaje para conseguir una acción que requiere de la ejecución conjunta de tales primitivas.

Es necesario comprender que NetLogo es un ambiente ejecutado sobre una máquina virtual Java que interpreta un lenguaje denominado Quasi-Pearl, por tanto, interpretará línea a línea los comandos introducidos por ello los procedimientos se describen como sigue. Para inicializar un procedimiento emplearemos la palabra reservada to seguida del nombre del procedimiento y a partir de este punto de entrada se ejecutarán una a una las primitivas introducidas en las siguientes líneas hasta alcanzar otra palabra reservada para la finalización de los procedimientos, end. Para comprobar el funcionamiento de los procedimientos vamos a ponerlos en práctica. Primero definiremos un procedimiento llamado cuadrado que realice las acciones del apartado anterior, pero ahora englobadas en dicho procedimiento, para ello nos desplazamos a la pestaña Código y escribimos nuestro procedimiento:

to cuadrado ;; Inicio del procedimiento

clear-all ;; Resetearemos el entorno

crt 4 ;; Creamos 4 tortugas

ask turtles [pd repeat 4 [fd 5 rt 90] pu] ;; Empleando la primitiva repeat

end ;; Fin del procedimiento

Y una vez escrito pulsamos sobre Comprobar. Si no obtenemos ningún error (mostrados en una barra en la parte superior, de color amarillo indicando el tipo de error obtenido), podemos lanzar nuestro procedimiento desde la ventana de comandos

simplemente llamándolo por su nombre, cuadrado en nuestro caso.

Es importante observar que el

procedimiento, tal como está definido,

no es determinista, por lo que no se

obtendrá la misma salida exactamente

cada vez que se lance debido a que

durante la creación de las tortugas,

éstas son orientadas hacia un ángulo

aleatorio y al realizar el

desplazamiento describirán

trayectorias diferentes.

4.5 Variables Distinguiremos entre 2 tipos de variables presentes en el ámbito de NetLogo, las variables locales y las variables globales. Dicho ámbito de las variables es análogo al mismo en otros lenguajes de programación.

Una variable global es accesible por todos los procedimientos de un programa NetLogo.

Un caso particular de este tipo de variables son las variables de entrada, introducidas por el usuario a través de la interfaz de NetLogo mediante los posibles widgets (botones, sliders, choosers). Para comprobar su funcionamiento emplearemos el procedimiento desarrollado en apartados anteriores para formar un cuadrado, pero en esta ocasión su funcionamiento estará condicionado a la introducción de variables de entrada: el ángulo ,el

17

desplazamiento de las tortugas y las repeticiones, de forma que se podrán generar distintos tipos de polígonos.

Para ello, partiendo del código anterior:

to cuadrado ;; Inicio del procedimiento

clear-all ;; Resetearemos el entorno

crt 4 ;; Creamos 4 tortugas

ask turtles [pd repeat 4 [fd 5 rt 90] pu] ;; Empleando la primitiva repeat

end ;; Fin del procedimiento

introduciremos 4 sliders, uno para el número de tortugas a generar:

(variable global turt), otro para las repeticiones:

(variable global rep), otro para el número de desplazamientos:

(variable global desp) y un último para indicar el ángulo de giro:

(variable global ang).

Con los sliders para configurar los parámetros de la simulación ya definidos, debemos establecer un botón para iniciar

dicha simulación: , que llamará al punto de entrada de nuestro programa, en nuestro caso el procedimiento cuadrado.

Y únicamente resta modificar el código anterior para ajustarlo a la utilización de las variables de entrada, quedando como sigue:

to cuadrado ;; Inicio del procedimiento

clear-all ;; Resetearemos el entorno

crt turt ;; Creamos [turt] tortugas

ask turtles [pd repeat rep [fd desp rt ang] pu] ;; Empleando la primitiva repeat

end ;; Fin del procedimiento

Un ejemplo con {turt=5}, {rep=83}, {desp=10} y {ang=92} es el siguiente:

Las variables globales que no son variables de entrada y por tanto no son introducidas mediante los widgets de la pestaña Ejecutar las declararemos al inicio del programa mediante la primitiva globals y, entre corchetes, el nombre de las variables globales que vamos a emplear en nuestro programa e.g.

globals [

variable_global_1

variable_global_2

variable_global_n ]

Este tipo de declaración no era necesario en las variables de entrada porque internamente NetLogo se encarga de su definición. Posteriormente, es posible asignarle valores a las variables globales mediante la primitiva set , la misma que empleábamos para definir propiedades adicionales en los agentes tortuga.

Por otro lado, se encuentran las variables locales, que sólo son válidas dentro del procedimiento donde son declaradas, por tanto, ya no son declaradas al inicio del programa, sino que se crean dentro de un procedimiento y se les asigna un valor según se va necesitando a lo largo del programa. Una variable local se crea mediante la primitiva let, dándole un valor inicial en durante su creación e.g. let variable_local 5. Si posteriormente necesitamos asignarle otro valor diferente a la variable local se empleará la primitiva set e.g. let variable_local 7.

18

4.6 Listas

Las listas son estructuras de datos equivalentes al concepto de vector/array en otros lenguajes de programación. Al ser un lenguaje con tipado dinámico, las listas pueden ser heterogéneas, pudiendo estar compuestas de elementos de diferentes tipos. Dada una lista L representada como un conjunto de valores entre corchetes, sus elementos son numerados desde el índice 0 hasta |L|-1 .

Existen dos formas de construir una lista, en función de si estará compuesta por datos conocidos a priori o no.

Si los datos son conocidos, construiremos la lista como una variable normal (asumiremos la definición como una variable local, pero es fácilmente extrapolable a variable global) de la siguiente manera: let lista-1 [el0 el1 elN]

Si los datos no son conocidos a priori (situación más común) es necesario emplear la primitiva list , que recibe una serie de argumentos y devuelve una lista compuesta con los argumentos pasados. Se pueden dar dos casos en el uso de dicha primitiva:

Si se le pasan 2 argumentos a la primitiva, se escribirá de la forma: list a b , siendo a y b variables definidas previamente en el programa (también pueden ser valores constantes válidos).

Si se le pasan más de 2

argumentos, se escribirá la

primitiva list seguida de

todos los argumentos

necesarios, todo ello entre

paréntesis e.g. (list a b c d) ,

siendo a,b,c y d variables

definidas previamente en el

programa (también pueden

ser valores constantes

válidos).

Una vez han sido introducidas las listas es necesario comentar las operaciones que tienen asociadas, que nos permiten manipularlas de una forma sencilla, contando como cualquier estructura de datos con al menos operaciones de consulta, inserción, borrado y modificación de elementos. Entre estas operaciones encontramos, las siguientes primitivas (a,b,..., son constantes válidas de NetLogo o variables) :

1. Para realizar operaciones de

consulta sobre una lista.

first: nos permite consultar el

primer elemento de la lista e.g. first [a b c] ;; a

last: para obtener el último elemento de la lista e.g. last [a b c] ;; c

but-first: obtiene una lista con todos los elementos de la lista menos el primero e.g. but-first [a b c] ;; [b c]

but-last: obtiene una lista con todos los elementos de la lista menos el último e.g. but-last [a b c] ;; [a b]

item: obtiene el elemento n-ésimo de la lista e.g. item 2 [a b c] ;; b

n-of: toma una lista de n elementos al azar de la lista e.g. n-of 2 [a b c] ;; [n1 n2]

2. Para realizar operaciones de modificación sobre una lista.

fput: introduce un elemento al

inicio de la lista e.g. fput d [a b c];;[d a b c]

19

lput: introduce un elemento al final de la lista e.g. lplut d [a b c];;[a b c d]

remove: elimina el elemento indicado de la lista e.g. remove b [a b c];;[a c]

remove-item: elimina el elemento indicado por posición de la lista e.g. remove-item 2 [a b c] ;; [a b]

remove-duplicates: elimina los elementos duplicados de la lista e.g. remove-duplicates [a b b c] ;; [a b c]

replace-item: reemplaza el elemento indicado por otro elemento indicado por el programador e.g. replace-item b [a b c] d ;; [a d c]

3. Otras primitivas útiles para operar con listas.

length: permite conocer la

longitud de una lista e.g. length [a b c] ;; 3

modes: permite conocer la moda de una lista e.g. modes [a b b c] ;; b

position: para conocer la posición de un elemento en la lista e.g. position b [a b c] ;; b

shuffle: desordena aleatoriamente los elementos de la lista e.g. shuffle [a b c]

reverse: obtiene el reverso de la lista e.g. reverse [a b c] ;; [c b a]

sort: ordena los elementos por valor creciente, otra versión de sort, es sort-by que permite indicar el criterio de ordenación e.g. sort [4 2 5] ;; [2 4 5]

sentence: permite la concatenación de listas, sin

realizar aplanamiento de listas. Si se van a concatenar 3 o más listas es necesario incluir la sentencia entre paréntesis e.g. sentence [a b c] [b c a] ;; [a b c b c a]

sort-by: realiza la misma función que la primitiva sort, pero siendo ahora posible especificar el criterio de ordenación. Dicho criterio se indica entre corchetes, asignando nombres auxiliares (que comenzarán siempre por ?) y que se emplearán durante las iteraciones necesarias para referenciar los valores actuales en el proceso de ordenación e.g. sort-by [?1 > ?2] [2 3 1 5] ;; [5 3 2 1], obsérvese que ordenamos en orden decreciente en este caso, a diferencia de la primitiva sort

Es necesario aclarar que tales operaciones se han considerado en sus casos más básicos, existiendo situaciones de mayor complejidad como por ejemplo, cuando hay varios niveles de anidación de listas. Del mismo modo, se ha mostrado directamente el uso de las primitivas, pero es posible emplearlas en otras condiciones, como en la creación de una variable local e.g. let a (sentence [a b c] [c b a] [d c d])

También encontramos primitivas que nos permiten iterar de una forma sencilla sobre los elementos de las listas sin necesidad de emplear repeat, while (se comentará en la siguiente sección) , ni procedimientos recursivos. Estas primitivas especiales son:

foreach: permite realizar un

conjunto de operaciones sobre una lista, utilizando, del mismo modo que en la primitiva sort-by, nombres auxiliares para referenciar los valores actuales. Para comprobar su funcionamiento vamos a escribir un procedimiento en el que un agente tortuga describa la trayectoria de la secuencia de

20

fibonacci hasta cierto elemento n de la serie (en nuestro caso [1 1 2 3 5 8 13 21]).

También es posible aplicar la primitiva foreach para operar sobre más de una lista a la vez, empleando varias variables auxiliares, una para cada lista.

map: dicha primitiva toma como

entrada una lista y da como resultado otra lista resultado de aplicar una función a cada elemento de la lista, siendo análoga la primitiva map al concepto de la función map en el paradigma de programación funcional. Del mismo modo que en la primitiva foreach se empleará una variable auxiliar para hacer referencia al valor actual. Su sintaxis es la siguiente: map [“operacion”] lista. Un ejemplo muy sencillo en el que se incrementa en una unidad cada elemento de la lista, mostrándolo por la terminal, es el siguiente:

to fibonacci ca let lista [1 1 1 1 1 1] show map [? + 1] lista end

4.7. Sentencias condicionales,

procedimientos con retorno y

bucles

En cuanto a sentencias condicionales se refiere podremos emplear la sentencia if de la siguiente forma:

if condición

[

;; comandos

]

De modo que si la condición se cumple se ejecutarán los comandos que se escriban a continuación de la condición y entre corchetes. En el caso que la condición no se cumpla, los comandos que se encuentren dentro de los corchetes no se ejecutarán.

En el caso de que se requiera diversas acciones (ejecutar varios comandos) cuando la condición no se cumple deberemos emplear la sentencia condicional ifelse, cuya sintaxis es la siguiente:

ifelse condición

[

;; comandos que se ejecutan si se cumple la condición

]

[

;; comandos que se ejecutan si no se cumple la condición

]

En esta ocasión, si la condición se cumple se ejecutarán los comandos que se encuentren dentro del primer par de corchetes.. En caso contrario, se

to fibonacci ca

let lista [1 1 2 3 5 8 13 21]

crt 1

ask turtles [pd]

foreach lista [ ask turtles [fd ? rt 90] ]

ask turtles [pu]

end

21

ejecutarán aquellos comandos que se encuentren dentro del segundo par de corchetes.

Los procedimientos con retorno son aquellos que devuelven un valor al procedimiento que les ha llamado. Para construir un procedimiento con retorno comenzaremos el procedimiento con la palabra to-report, seguido del nombre que le queramos asignar al procedimiento y de los parámetros que va a recibir el procedimiento, entre corchetes. A continuación escribiremos los comandos que vaya a ejecutar el procedimiento de retorno, como último comando emplearemos la palabra report seguido de la variable o valor que queramos devolver y por último la palabra end. De esta manera, la sintaxis para los procedimiento de retorno queda de la siguiente forma:

to-report nombre_del_procedimiento [valor_recibido]

;; comandos

report valor_resultante

end

Por último, para la ejecución de bucles podremos emplear tanto la primitiva while como la primitiva repeat. La primitiva while sirve para repetir un conjunto de comandos mientras se cumpla determinada condición. Emplea la siguiente sintaxis:

while condición

[ ;; comandos

]

Sin embargo, la primitiva repeat repite una serie de comandos un número finito de veces, no necesita ninguna condición. Su sintaxis es la siguiente:

repeat n [

;; comandos

]

La variable n que sigue a la primitiva

repeat indica el número de veces que se

van a ejecutar los comandos que se

encuentren dentro de los corchetes.

5 Análisis de aplicaciones

El modelado basado en agentes ha sido

usado en una gran variedad de áreas

como la física, la biología, las ciencias

sociales e incluso las ciencias de la

computación ofreciendo una estructura

elegante y minimalista para modelar

sistemas complejos que nos ayuden a

responder y comprender cuestiones del

mundo real relacionadas con dichas

áreas.

Diversos autores han realizado ya sus

aproximaciones mediante modelado

basado en agentes a cuestiones que

requerían comprensión, siendo necesario

simular el comportamiento del sistema

para observar su evolución. Entre éstos

podemos destacar aquellos que han

realizado trabajos similares al que

realizaremos en el presente documento

como son: (Alber et al, 2003) empleando

autómatas celulares para modelar sistemas

celulares (nosotros analizaremos desde un

enfoque basado en agentes un autómata

celular bidimensional muy conocido como

es "Game of Life") y (Carley et al, 2006;

Epstein et al, 2007) quienes realizaron

modelos basados en agentes para modelar

la propagación de epidemias y pandemias

modelando la actividad real de las

personas y sus patrones de contacto

mediante topologías de redes (del mismo

modo, si consideramos las personas como

nodos en una red, seremos capaces de

simular la propagación de virus por la red).

Una vez realizada la aproximación a los

ABMS y comentadas sus características,

22

componentes y algunas de sus

aplicaciones interesantes, estamos en

condiciones de poder analizar un

subconjunto de las posibles aplicaciones

de dichos sistemas, entre las que se

encontrarán: el autómata celular

bidimensional con las reglas de Cornway

"Game of Life" , la propagación de virus

en la red, y el cambio climático.

Realizando un análisis más profundo de

la primera aplicación (aplicación

principal del presente trabajo) y dando

una posible implementación en Java a

ésta, realizada por los autores. También

analizaremos las dos últimas y

comentaremos una implementación en el

software ABMS NetLogo realizada por

Uri Wilensky.

5.1. Juego de la vida

5.1.1. Agentes e interacciones

5.1.2. Diferencias con ABMS

actuales

5.2 Aplicación a analizar

5.2.1. Agentes e interacciones

5.2.2. Implementación NetLogo

5.2.3. Casuísticas y resultados de

experimentos

6. Conclusiones

7. Anexo

8. Bibliografía