• Aucun résultat trouvé

Bilan et prospective

Dans le document Africapolis (Page 106-125)

MASON10 é um ambiente ABM que vem sendo desenvolvido pelo departamento de computação da George Mason University em conjunto pelo George Mason University Center

for Social Complexity. Foi projetado para atender três requisitos principais (rapidez, flexibilidade, portabilidade) e posteriormente, o requisito de reprodutibilidade foi incorporado (ALLAN, 2010; BALAN et al., 2003; LUKE et al., 2005; RAILSBACK; LYTINEN; JACKSON, 2006).

Ele é um ambiente de modelagem de propósito geral, desenvolvido em linguagem Java (atendendo o requisito de portabilidade garantida por essa linguagem), possui uma biblioteca de visualização e é destinado a pesquisadores (LUKE et al., 2004, 2005). Para atender os requisitos principais, priorizando a velocidade de execução, o MASON não fornece uma linguagem de alto nível ou facilidades de uso para usuários iniciantes. Ele requer grandes conhecimentos de programação, por exemplo, herança, polimorfismo, sobrecarga de métodos e acesso a recursos compartilhados (LUKE, 2011).

O desenvolvimento de modelos ocorre em duas fases. Na primeira, ocorre a construção do modelo e se necessário, posteriormente, é criada a visualização 2D ou 3D. Os modelos são desenvolvidos como qualquer programa escrito em Java e depois de compilado é executado pela Java Virtual Machine (JVM). A camada de visualização é fracamente acoplada ao modelo podendo ser adicionada ou removida da simulação, dependendo da necessidade do usuário (LUKE et al., 2004).

O núcleo de um modelo é a superclasse SimState que representa toda a simulação e mantém

internamente o principal objeto de uma simulação, o escalonador de eventos discretos. O escalonador é uma instância da classe Schedule e representa o tempo da simulação. Ao

descrever um modelo em MASON é necessário especializar a superclasse e redefinir o método start().

No MASON, qualquer classe pode ser considerada um “Agente” e, portanto, escalonada. Luke et al. (2005) caracterizaram e empregaram esse termo no simulador como "um objeto que pode ser escalonado para executar alguma ação e manipular o ambiente". Para tanto, um

agente implementa a interface Steppable que possui apenas o método step() e é invocado

pelo escalonador a cada iteração da simulação.

Figura 2.17 – Interface gráfica padrão do MASON gerada pelo objeto GUIState. A camada de visualização do MASON é criada por meio de especialização da classe

GUIState, que é doravante designada como Console. O Console é a principal interface

gráfica do MASON. Ela visualiza e encapsula o modelo (objeto SimState) passando a

controlar a execução da simulação do modelo. A Figura 2.17 destaca a aba console que contém os parâmetros predefinidos de execução e funciona como um centro de comando da simulação. A barra de ferramentas, destacada em vermelho, possui os botões Play, Pause,

Stop e, ao lado do botão Stop é mostrado o tempo, passo ou taxa da simulação. À direita, temos uma caixa de combinação que permite definir qual período de atualização da simulação e das visualizações será utilizada. As outras abas que compõem essa GUI são: about, display,

inspectors e model. A aba about exibe uma documentação básica sobre o modelo e seus desenvolvedores; a aba display lista e gerencia as janelas criadas durante a simulação e a aba

inspectors permite visualizar e interagir com informações de um agente selecionado. A aba

model, invisível na Figura 2.17, torna-se visível no Console apenas quando o modelo possui

algum parâmetro global e permite que o usuário altere esses parâmetros. Para a criação do

Console, também é necessário sobrecarregar, ao menos, os métodos de inicialização da GUI e

Figura 2.18 – Aba inspectors permite gerar gráficos ou arquivos a partir de dados provenientes do modelo em execução. No exemplo, o objeto sim.app.virus.human@75622c88

do modelo Virus Infection que integra a biblioteca de demonstração da plataforma é inspecionado

A atualização da GUI é feita de forma assíncrona por um escalonador auxiliar vinculado ao escalonador de eventos principal e é executado automaticamente pelo ambiente de modelagem ou por meio de uma especialização de Steppable criada pelo modelador

(LUKE, 2011).

Figura 2.19 – Gráfico de série temporal gerada usando a biblioteca JFreeChart.

O MASON possui várias formas de visualização, por exemplo, gráficos e inspetor de objetos. Estas visualizações são acessadas através da aba inspectors do Console. Usuários mais experientes podem criar novas visualizações a partir da interface Java Portrayal ou alguma

de suas subclasses e redefinir o método draw(). Esse método é invocado pela plataforma

O inspetor de objetos (Figura 2.18) é uma subclasse de objetos Portrayal e pode monitorar

e alterar o valor de alguma propriedade de um objeto do modelo. Por meio dele, é possível apresentar dados de forma textual, em gráficos, salvar em arquivos e transmitir via rede. (LUKE, 2011; LUKE et al., 2005). A Figura 2.19 apresenta um gráfico de série temporal gerado pela biblioteca JFreeChart11. Gilbert (2005) e Luke et al. (2004) afirmam que uma biblioteca de geração de gráficos é vista como um serviço externo ao núcleo do simulador que deve ser mantido conciso e limpo.

Tabela 2.2 – Comparação entre as plataformas de modelagem Plataf. Versão

avaliada Paradigma Tipos de visualizações Definição de GUI’s Novas GUI’s Política de Atualização Sinc. da Atualização Ling. de modelagem Amb. de Execução NetLogo 5.0.3 Multi-

agentes Gráficos, mapas, etc. Primitivas via GUI - Por eventos e sob demanda via GUI

Assíncrona Netlogo Java

Repast Simphony

2.0 Multi-agentes Gráficos, mapas, etc. Assistentes de configuração e primitivas

Herança via

Java Por eventos Assíncrona Relogo, Groovy ou direto em Java

Java

MASON 16 Multi-

agentes Gráficos, mapas, etc. API Java Herança via Java Por eventos Assíncrona Java Java

TerraME 1.2 Multi-

paradigmas

- N/A N/A N/A N/A Lua (ou

direto em C++)

Lua (ou direto em C++)

Dans le document Africapolis (Page 106-125)

Documents relatifs