Repast

O simulador Repast7 foi criado no laboratório de pesquisa computacional em Ciências Sociais da Universidade de Chicago. Atualmente, o projeto é gerenciado pela organização Repast

Organisation for Architecture and Development (ROAD) (CROOKS, 2007). Ele é uma

plataforma ABM desenvolvida em Java, de código livre e atualmente está na versão Simphony 2.0 (versão avaliada neste trabalho). É destinada ao estudo de Ciências Sociais e o nome é um acrônimo para Recursive Porous Agent Simulator Toolkit.

O Repast foi concebido como uma biblioteca Java para trabalhar em conjunto com o simulador Swarm8 facilitando seu uso. No entanto, devido ao potencial vislumbrado pelos pesquisadores tornou-se um projeto independente (COLLIER, 2002). Para disseminar sua utilização nas diversas áreas de pesquisa e buscando atender pesquisadores com diferentes níveis de conhecimentos de programação, o simulador provê três formas de construção de modelos (COLLIER, 2009):

 Linguagem Java: Destinada a usuários com grandes conhecimentos de programação e modelagem;

 Linguagem ReLogo ou Groovy: Indicadas a usuários iniciantes ou com pouco conhecimento de modelagem e programação;

 Diagrama de fluxos: Recomendado à usuários que desejam construir modelos visualmente. A lógica do modelo é descrita usando a linguagem ReLogo ou diretamente na linguagem Groovy9.

ReLogo é uma linguagem de domínio específico para ABM, baseada na linguagem Logo projetada por Papert (1980) e escrita na linguagem Groovy.

1 - (...)

2 - import repast.simphony.context.Context; 3 -

4 - public class Drenagem implements ContextBuilder<Object> { 5 - (...)

6 -

7 - // Método de construção do contexto da simulação

8 - public Context<Object> build(Context<Object> context){ 9 - context.setId("drenagem");

10 - return context; 11 - }

12 - }

Figura 2.10 – Modelo “Drenagem” escrito em Java que implementa a interface

ContextBuilder

A estrutura padrão de um modelo no Repast é baseada em dois objetos Context e Projection. Context é um container de objetos e representa uma população abstrata de

agentes. Internamente, ele mantém informações sobre o ambiente em que os agentes estão imersos, contudo, sem determinar qualquer estrutura espacial para este ambiente (ALLAN, 2010; HOWE et al., 2006). Projections são estruturas que definem algum tipo de relação entre os agentes pertencentes a um Context, permitindo a interação entre eles (ALLAN, 2010). A relação entre objetos Context e Projections é 1:n e entre Projections e Context é

1:1.

9 _{Groovy é uma linguagem de programação de propósito geral dinâmica para a plataforma Java é} largamente utilizada em substituição à linguagem de programação Java. Disponível em:

Figura 2.11 – Visão geral do ambiente de execução Repast Simphony durante a simulação do modelo Game of Life.

(a) (b)

Figura 2.12 – Diferentes formas de modelagem disponível. Em (a) diagrama de fluxos e (b) lógica do modelo escrita na linguagem Groovy (Fonte: Modelo FlowZombies disponível junto

com o simulador)

A criação de uma simulação é feita pela implementação da interface Java ContexBuilder

responsável por manter o estado da simulação (Figura 2.10). A execução do modelo é feita dentro do ambiente de execução Repast Simphony apresentado na Figura 2.11. Se o modelador optar pela linguagem ReLogo ou por diagramas de fluxos para o desenvolvimento do modelo, o compilador Groovy gerará o código final diretamente em Java bytecodes (Figura 2.12). Assim, independente da forma escolhida pelo usuário, o código do modelo é compilado e executado como uma aplicação Java.

1 - @ScheduledMethod(start = 1, interval = 1, priority = 2) 2 – public void step(){

3 - (...) 4 - }

Figura 2.13 – Escalonamento estático

1 - @Watch(watcheeClassName = "jzombies.Zombie", watcheeFieldNames = "moved", query = "within_vn 1", whenToTrigger = WatcherTriggerSchedule.IMMEDIATE) 2 – public void run(){

3 - (...) 4 - }

Figura 2.14 – Escalonamento dinâmico

Classificado como um simulador de eventos discretos, ele organiza a execução dos eventos por meio de um escalonador que determina a dinâmica da simulação. O tempo pode ser usado de forma síncrona, no qual supõe que todos os agentes da simulação mudam simultaneamente, e de forma assíncrona, padrão utilizado pela plataforma, em que os agentes mudam considerando a realidade deixada pelo agente anterior (CROOKS, 2007).

1 - (...)

2 - //Specify that the action should start at tick 1 and execute every other tick

3 - ScheduleParameters params = ScheduleParameters.createRepeating(1, 2);

4 - //Schedule my agent to execute the move method given the specified schedule parameters.

5 - schedule.schedule(params, myAgent, "move", "Forward", 4); 6 - (...)

7 -

8 - public class MyAgent { 9 (...)

10 - public void move(String direction, int distance){ 11 - (...)

12 - } 13 - (...) 14 - }

Figura 2.15 – Escalonamento direto

O escalonamento de alguma ação pode ser feito de três formas: annotations, watchers ou escalonamento direto. Annotations são comentários especiais inseridos imediatamente antes da descrição de métodos (Figura 2.13) e usados para escalonar estaticamente, em períodos pré-estabelecidos, algum evento. Watchers são anotações especiais similares aos annotations, porém, usadas para escalonar dinamicamente algum evento (Figura 2.14). Esse escalonamento requer profundos conhecimentos sobre o domínio do problema em estudo, pois não ocorre em períodos pré-estabelecidos. No escalomento direto, o usuário utiliza o objeto Schedule e por

uso desse objeto. Na linha 3 são definidos os parâmetros da ação e na linha 5, a ação é escalonada e os parâmetros necessários para a execução dela também são passados.

A GUI é definida por meio de um assistente de configuração que é invocado dentro do ambiente de execução Repast Simphony. Nesse assistente, o usuário seleciona os projections, as classes de agentes e os estilos que serão usados para desenhá-los, além de definir os parâmetros de atualização da interface gráfica. No Repast, qualquer objeto é considerado um agente. Um estilo estabelece as características visuais, por exemplo, cor, tamanho e rotação, que serão usadas pela ferramenta para desenhar um agente. A plataforma dispõe de estilos predefinidos e também possibilita a criação de novos, por meio de novas implementação da interface Java StyleOGL2D ou de alguma de suas subclasses. As configurações estabelecidas

através do assistente são armazenadas em arquivos Extensible Markup Language (XML) e utilizadas para a geração de interfaces gráficas e de outros componentes em tempo de execução. A atualização de GUI’s é feita de forma contínua e assíncrona diretamente pelo escalonador.

(a) (b) (c)

Figura 2.16 – Exemplos de visualizações fornecidas pelo ambiente: (a) probe, (b) mapa 2D e (c) gráfico de série temporal.

O simulador fornece diversas formas de visualização, por exemplo, gráficos de séries temporais e histogramas, mapas 2D dinâmicos e probes (Figura 2.16). Mapas 2D representam espacialmente o comportamento de um agente ou um relacionamento entre agentes. Probes são GUI’s que permitem definir, monitorar ou alterar algum parâmetro do modelo durante a simulação. É possível criar novas visualizações através da especialização da classe