Post on 10-Feb-2017
transcript
*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