Framework PIABA

Como mencionado no capítulo 5, os agentes AAFA foram implementados na pla- taforma Jason. Nesse mesmo capítulo foi igualmente mencionada a grande quantidade de linhas de código necessárias na implementação da arquitetura para fins de teste, bem como a dificuldade de harmonizar todo o código, devido ao fato do mesmo estar inse- rido em diferentes níveis da plataforma utilizada: ações internas, ações externas, mundo, visualização do mundo e a parte implementada em AgentSpeak.

A plataforma Jason se mostrou altamente customizável, para permitir uma ampla gama de aplicações com agentes dentro da arquitetura BDI. Para isso, o raciocínio e o pla- nejamento do agente precisa ser pensado no contexto da arquitetura BDI e ser expresso na linguagem AgentSpeak. Isso traduz uma obrigatoriedade de contexto da aplicação, como também pressupõe a necessidade de trabalhar com o agente desenvolvido em dois ambientes:

1. Linguagem Java

• Implementação das ações externas do agente, ou seja, as ações que são executadas sobre o ambiente (mundo) em que o agente está e que, portanto, definem o seu comportamento aparente;

• Implementação de algumas ações internas, que requerem mais po- der computacional em relação ao oferecido pela linguagem AgentS- peak.

• Definição do comportamento do agente baseado no raciocínio meio- fins [Newell & Simon 1972] criado a partir de planos e regras; • Construção e manipulação da base de crenças do agente.

No início do capítulo 5, são discutidas as razões que levaram à escolha dessa pla- taforma para implementação do dispositivo de teste da arquitetura. Porém, analisando o processo de desenvolvimento do aplicativo de teste na plataforma Jason, notou-se a necessidade de algumas funcionalidades que facilitariam o trabalho de avaliação da ar- quitetura proposta. A partir das necessidades encontradas na aplicação de teste da arqui- tetura, foi concebido um framework que também facilitasse o uso da arquitetura proposta neste trabalho. Além disso, procurou-se generalizar para o desenvolvimento de aplica- ções baseadas em simulação multiagente em geral. De forma resumida, as principais funcionalidades visualizadas foram:

1. Ambiente de desenvolvimento concentrado em um único paradigma de linguagem de programação;

2. Customização da plataforma configurável via arquivos XML; 3. Customização do modo de operação síncrono dos agentes em:

• DefaultList: uma lista configurável da ordem de execução é defi- nida pelo desenvolvedor da aplicação e ela se mantém inalterada durante toda a simulação;

• FixRandomList: uma lista inicial é gerada por um escalonador de processos e determina a ordem de execução dos agentes, que é man- tida fixa durante toda a simulação;

• RandomList: a lista de execução dos agentes é gerada randômica- mente pelo escalonador de processos a cada ciclo de simulação; • FixedTimeList: similar ao modo DefaultList, porém os agentes pos-

suem um tempo (configurável pelo usuário) para executar as suas deliberações;

4. Possibilidade de implementação de um ambiente dinâmico, onde o “mundo” do agente varia durante o ciclo de raciocínio dos agentes;

5. Possibilidade de definir o comportamento de um agente como um con- junto de Actions, onde cada Action possui:

• Um conjunto de pré-condições que habilitam a ação para execução; • Uma tupla de atributos hcusto,benefício,pós-condições,prioridadei para ser usada pelo escalonador de ações, para definir qual a melhor ação a ser executada em determinada situação;

• Um foco de atenção para filtrar o conjunto de percepções recebido, de forma a utilizar somente as informações mais adequadas ao com- portamento em questão.

6. Disponibilidade de um processo de armazenagem das simulações, para posterior visualização e análise, incluindo um agent profiler.

Um dos requisitos não funcionais do framework é o de ser pequeno e portável, que possa ser executado com o mínimo de modificações tanto em ambientes Desktop (Win-

dows e Linux), quanto no sistema operacional para dispositivos móveis Android. O fra- mework foi então denominado de “Piaba”. Este é o nome de um peixe brasileiro de porte pequeno, que raramente ultrapassa 20cm de comprimento. No Nordeste brasileiro, em especial em terras potiguares, “piaba” serve como substituto ao adjetivo “pequeno”. Dessa forma, nasceu a denominação do framework para simulação multiagente, simples e contendo somente as características mínimas necessárias, para ser executado também em dispositivos embarcados (em específico em ambientes Android).

Uma aplicação desenvolvida com o framework PIABA consiste basicamente de três arquivos XML, que configuram o mundo da simulação (MASWorld.xml), os agentes (MA- SAgent.xml), e as meta_info operators (MASAmio.xml).

O arquivo MASWorld.xml configura o mundo da simulação. A implementação real desse mundo é feita por meio de uma classe Java, que é instânciada durante a execução do processo da simulação. A identificação de qual classe deve ser usada para a criação do mundo é indicada no arquivo de configuração. Algumas das propriedades que são configuráveis para o mundo são mostradas a seguir:

• Simulation Running Mode (SRM):

– thread mode: os agentes são instanciados como threads, o que sig- nifica que o controle do pseudo-paralelismo das ações é deixado por conta da máquina virtual do Java. Esta é a implementação tra- dicional do modo de operação assíncrono.

– nothread mode: o usuário define como será a operação síncrona dos agentes instanciados, podendo ser escolhidas umas dentre as quatro possibilidades descritas anteriormente.

• Agent Class (AC): define as classes que devem ser instanciadas para a implementação dos agentes.

O arquivo MASAgent.xml configura os agentes que serão usados na simulação, depen- dendo do seu tipo e denominação. As classes instanciadas pelo parâmetro Agent Class (AC) são as responsáveis por obter os dados para a configuração dos agentes. Algu- mas das propriedades desse arquivo são descritas a seguir. Basicamente, são descritas as propriedades que definem a arquitetura AAFA, que pode ou não ser usada pelo desenvol- vedor.

• Update L (UL): Limite a ser utilizado no filtro do foco.

• Update Focus (UF): estabelece que o foco espacial seja atualizado dina- micamente, através do uso dos meta_info operators.

• Update Emotion (UE): o módulo emocional da arquitetura é ativado. • Mood Relation (MR): define a relação entre as emoções e o perfil de

humor do agente. – Emoções Positivas – Emoções Negativas

• Agent Personality Profile (APP): define o perfil de personalidade do agente baseado no modelo OCEAN.

• Personality Relation (PR): define a relação entre o perfil de personali- dade e o perfil de humor do agente.

– Pleasure: 0_{, 21 ∗ E + 0,59 ∗ A + 0,19 ∗ N} – Arousal: 0_{, 15 ∗ O + 0,30 ∗ A − 0,57 ∗ N}

– Dominance: 0_{, 25 ∗ O + 0,17 ∗C + 0,60 ∗ E − 0,32 ∗ A}

O arquivo MASAmio.xml configura os meta_info operators, que serão usados por cada agente, para avaliar as informações recebidas pela percepção. Esse arquivo simplesmente indica quais são as classes Java que devem ser instanciadas, para que esses agentes tenham acesso aos métodos de avaliação.

A funcionalidade que armazena as simulações para posterior exibição gráfica (visua- lização), incluindo um agent profiler, está sendo desenvolvida como um pacote adicional, não fazendo parte do framework PIABA em si. Esse pacote permitirá avaliar várias si- mulações simultaneamente. As simulações poderão ser apresentadas de forma contínua, como um filme, ou com o controle passo a passo, de acordo com a preferência e neces- sidade do usuário. Além disso, as informações relativas a cada agente e à situação do mundo em cada passo estarão disponíveis para verificação.