Agent based simulation

*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.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.
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:
;; 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
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:
ask turtles [pd repeat 4 [fd 5 rt 90] pu] ;;
Empleando la primitiva repeat
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:
crt turt ;; Creamos [turt] tortugas
ask turtles [pd repeat rep [fd desp rt ang]
pu] ;; Empleando la primitiva repeat
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.2. Diferencias con ABMS
actuales
5.2 Aplicación a analizar
5.2.2. Implementación NetLogo
5.2.3. Casuísticas y resultados de
experimentos
6. Conclusiones
7. Anexo
8. Bibliografía

Agent based simulation

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (12)

Ähnlich wie Agent based simulation

Ähnlich wie Agent based simulation (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Agent based simulation