Processo de Decaimento do Humor

O processo de decaimento do humor refere-se ao movimento do ponto representando o humor atual do agente no espaço PAD3D, voltando ao ponto que representa o humor básico. Esse movimento de retorno é executado quando não há atualizações sendo feitas no estado emocional do agente. Por simplificação da implementação, esse movimento foi idealizado para acontecer sobre a reta que conecta o ponto que representa o humor atual do agente M(t), e o ponto que representa o seu humor básico Mbasic. Usando as

equações paramétricas da reta entre esses dois pontos no espaço tridimensional, a equação do processo de decaimento do humor foi definida como segue:

Figura 4.10: Comportamento da intensidade emocional considerando o processo de eli- citação e decaimento. OCC+ representa a emoção positiva e OCC- representa a emoção negativa. M(t) =     

m1(t) = mbasic1+ tmood(m1(t) − mbasic1)

m2(t) = mbasic2+ tmood(m2(t) − mbasic2)

m3(t) = mbasic3+ tmood(m3(t) − mbasic3)

(4.30)

O parâmetro tmood define o quanto o ponto M(t) se move em direção ao ponto Mbasic

em um passo da simulação. O parâmetro faz parte da descrição do agente, sendo definido por quem modela a aplicação.

Implementação e Validação da

Arquitetura AAFA

A arquitetura proposta foi projetada de forma suficientemente genérica para ser im- plementada na maioria das plataformas de desenvolvimento de sistemas multiagentes. Entretanto, para o processo de teste, a plataforma de desenvolvimento Jason foi a esco- lhida.

Neste capítulo são apresentados os seguintes tópicos:

1. Seção 5.1: A criação da arquitetura proposta para os agentes usando a plataforma Jason;

2. Seção 5.2: A metodologia usada na criação dos cenários de teste (baseados em uma simulação de fuga de um incêndio), e na execução dos experimentos;

3. Seção 5.3: O conjunto de experimentos executados com o objetivo de comprovar a eficiência da arquitetura para Agentes com Foco de Atenção Afetivo (AAFA - Affective Attention Focus Agent).

5.1

Implementando o AAFA usando o Jason

Como já mencionado, a plataforma de desenvolvimento de sistemas multiagentes es- colhida para a construção dos agentes AAFA foi o Jason. Na Seção 2.1.2.3, foi menci- onado que o Jason [Bordini et al. 2007] é um interpretador de uma versão estendida da linguagem AgentSpeak. Essa é uma linguagem de programação em lógica orientada para a construção de agentes com arquitetura BDI (Beliefes, Desires and Intentions) [Rao 1996]. A principal razão para a escolha dessa plataforma foi a intenção inicial de usar a lingua- gem AgentSpeak para implementar o módulo Core dos agentes e seu módulo de plane- jamento. Essa implementação tinha sido programada para ser executada, quando o de- senvolvimento inicial e os testes dos agentes AAFA estivessem concluídos. No próximo capítulo é exposta mais detalhadamente uma mudança nesse planejamento, tendo em vista a decisão de desenvolver uma nova plataforma para a criação de sistemas multiagentes.

A fim de implementar o modelo de agente proposto, o ciclo de raciocínio padrão do Jason (descrito na Seção 2.1.2.3) foi modificado. A Figura 5.1 mostra uma visão esquemática da arquitetura implementada como parte de um novo ciclo de raciocínio.

Figura 5.1: Ciclo de raciocínio do Jason incluindo o Affective Attention Focus A Figura 4.2 pode ser usada como referência para o entendimento da Figura 5.1, pois elas usam a mesma nomenclatura para os blocos formadores. Como a plataforma Jason exige, um agente é especificado através de um arquivo de descrição cuja extensão é ASL. Esse arquivo contém, entre outras coisas:

1. Um conjunto inicial de fatos que define as crenças do agente ao iniciar a simulação;

2. Um conjunto de regras lógicas que trabalha como uma máquina de in- ferência sobre as crenças que o agente possuir;

3. Um conjunto de objetivos (goals) que devem ser alcançados pelo agente durante a simulação;

4. Um conjunto de planos que define o comportamento do agente durante a simulação.

Os dois primeiros itens compõem a base de crenças (belief base) do agente. Nela, está representado o conhecimento que o agente dispõe sobre si próprio e sobre o ambiente no qual está situado. O presente trabalho adota a hipótese de mundo fechado, ou seja, o que não pode ser comprovado com o conhecimento disponível no agente e/ou no ambiente é considerado falso.

Por causa do arquivo de descrição ASL do Jason, os módulos core e behavioral da Figura 4.2 foram condensados em um único bloco chamado “Agent” na Figura 5.1. Nessa figura é possível ver que a base de crenças padrão do Jason foi estendida para conter elementos da arquitetura proposta. Os itens 1 e 2 descritos acima estão contidos no bloco Beliefs.

O módulo do foco de atenção (Attention Focus) foi implementado como uma custo- mização da função de atualização da base de crenças do agente, a BUF (Belief Update

Function). Nesse caso, está sendo considerado o processo de organização da percepção do ambiente descrito na Seção 4.2. O foco qualitativo e o foco quantitativo, ou seja, os parâmetros definidos pelos conjuntos A e LoI, são implementados como fatos armazena- dos na base de crença do agente. A parte customizada da BUF é responsável por realizar o processamento das informações provenientes do ambiente como descrito na Seção 4.2.1 e, ao finalizar esse processo, invoca a função BUF padrão do Jason para realizar a atuali- zação da BB (Base de Crenças - Belief Base) do agente, como descrito na Seção 2.1.2.3.

O estado afetivo do agente é também implementado como um conjunto de fatos na base de crenças e, como foi discutido na Seção 4.1.3, o módulo afetivo funciona como se estivesse “sobre” os outros módulos, desde que ele não processa informação, mas fun- ciona como uma base de dados que define o modo pelo qual os outros componentes da arquitetura executam suas tarefas. A Figura 4.4 mostra esse relacionamento de um modo esquemático.

O módulo meta_info operators (MIO) e o módulo de raciocínio do comportamento são implementados como ações internas dos agentes, definidas pelo Jason como ações que o agente realiza internamente, ou seja, dentro do seu próprio código. Essas ações são implementadas como uma customização da classe Java internal_Action disponível na plataforma Jason. Somente um bloco de comportamento é mostrado na Figura 5.1, pois, como o objetivo desse trabalho é testar e validar o processo de foco de atenção proposto, somente um comportamento foi implementado. Por causa disso, o módulo planner, presente na Figura 4.2 não foi implementado.

Finalmente, o sub-módulo action é implementado como uma ação externa do agente Jason. Para a plataforma, essas ações são ações que o agente executa no ambiente em ele está situado. Essas ações são implementadas como customização da classe Java exter- nal_Actiondisponibilizada pela plataforma.

Esta seção assume que o leitor tenha conhecimento sobre os conceitos envolvidos nos agentes BDI, na linguagem AgentSpeak e nos processos de customização da plataforma Jason. Para maiores informações, as referências básicas para esses assuntos são [Bratman 1965], [Rao 1996] and [Bordini et al. 2007] respectivamente.

Seguindo o projeto da arquitetura proposta (Seção 4.4), o sistema implementado pode trabalhar de diferentes maneiras, dependendo da configuração dinâmica ou fixa definida para o foco qualitativo e foco quantitativo. O sistema desenvolvido sobre a plataforma Jason pode ser configurado para operar das seguintes maneiras:

1. Foco Qualitativo Fixo e Foco Quantitativo Fixo: os focos qualitativo e quantitativo usam valores definidos no início da simulação e estes se mantém fixos durante toda a execução;

2. Foco Qualitativo Dinâmico e Foco Quantitativo Fixo: o foco qualitativo utiliza um valor inicial que é atualizado durante a execução da simula- ção e o foco quantitativo usa um valor fixo que não sofre alterações; 3. Foco Qualitativo Dinâmico e Foco Quantitativo Dinâmico: os foco qua-

litativo e quantitativo usam um valor inicial que é atualizado dinamica- mente durante a simulação;

4. Foco Qualitativo Fixo e Foco Quantitativo Dinâmico: o foco qualitativo adota um valor inicial que se mantém fixo ao longo da simulação e o

foco quantitativo adota um valor inicial que é dinamicamente atualizado durante a simulação;

5. Sem Arquitetura: a arquitetura proposta é desabilitada criando agentes oniscientes para permitir comparações nos testes de validação.

O processo de customização das classes Java da plataforma Jason consumiu uma grande quantidade de horas e foi bastante trabalhosa. O processo de implementação da arquitetura proposta nessa plataforma consiste de mais de seis mil linha de código. Isso não é só uma grande quantidade de código, mas também uma codificação sem uma estru- tura, pois a customização é feita em vários locais diferentes da plataforma original. Esse “espalhamento” do código resultou em problemas sérios para a correção e manutenção. Um ponto importante que é necessário enfatizar é a dificuldade para avaliar e corrigir o comportamento de um grupo de agentes, com as ferramentas oferecidas pela plataforma. Essas ferramentas são focadas no correção e avaliação do que foi feito em AgentSpeak e não das customizações em linguagem Java. A plataforma também não disponibiliza nenhum agent profiler para facilitar a avaliação de como as threads que implementam os agentes estão operando.