Integração da arquitetura em uma plataforma para o desenvolvimento de

integrada a uma plataforma para o desenvolvimento de sistemas multiagentes. Na literatura, são disponibilizadas diferentes plataformas com esse intuito, como Jason

[Bor07], SemantiCore [Blo07] e Jade [Til11]. Cada uma dessas plataformas define sua própria arquitetura interna de agentes (ainda que com algumas características comuns).

Embora a arquitetura proposta pudesse ser integrada a qualquer uma das plataformas citadas, optou-se por desenvolver uma plataforma simplificada que funciona como um driver de teste [Per00], permitindo a criação de agentes adaptativos ao contexto sem o viés de uma ou outra plataforma. Com isso, espera-se que a aplicação da arquitetura de forma integrada com alguma plataforma ocorra sem maiores problemas no futuro.

A plataforma desenvolvida é, na verdade, uma versão simplificada e executável do metamodelo FAML. Como será visto a seguir, assim como no metamodelo FAML, na plataforma simplificada existem os conceitos agente, objetivo, estado mental, plano, recurso, ação e outros.

A Figura 4.4 apresenta o diagrama de classes em projeto da plataforma desenvolvida. A classe SimpleAgent, que é um processo autônomo (implementação da interface Runnable), representa os agentes desenvolvidos na plataforma simplificada. A classe SimpleAgent é uma especialização da classe ContextAdaptiveAgent, (definida pela arquitetura K2) e, portanto, implementa os métodos para a execução das 13 primitivas genéricas. Além dos métodos para a execução das primitivas, a classe SimpleAgent ainda tem outros dois métodos, que são o receiveMessage e o decide.

Uma das características de agência é a capacidade de interação dos agentes. Para interagirem, os agentes desenvolvidos na plataforma simplificada trocam mensagens (objetos da classe Message). Toda vez que é recebida uma mensagem, são verificados os sensores (classe Sensor) ativos no agente. São os sensores os responsáveis por filtrar as mensagens relevantes dentre as mensagens recebidas pelo agente através do ambiente.

As decisões do agente são tomadas no método abstrato decide. O processo de tomada de decisão tem como base as mensagens recebidas e o estado mental do agente no momento do recebimento de tais mensagens. O método decide é abstrato, porque cada agente tem uma forma diferente de processar as mensagens recebidas e utilizar as informações disponíveis em seu estado mental para tomar decisões.

O estado mental dos agentes desenvolvidos na plataforma (classe MentalState), assim como no metamodelo FAML, é o resultado da agregação de suas crenças e objetivos. Toda crença tem uma especificação, que é do tipo Object. Já os objetivos (classe AgentGoal) possuem três atributos, que são: name, que indica o nome ou identificação do objetivo; committed, cujo valor booleano indica se o agente está tentando alcançar o objetivo ou não; e description, que apresenta uma descrição dos conceitos envolvidos no objetivo - é essa descrição que é utilizada para a procura de adaptadores relevantes.

A classe AgentGoal ainda tem associações com outras duas classes, a classe Sentence e a classe Plan. As sentenças, ou sentenças de verificação, não são definidas no metamodelo FAML original, mas tem um importante objetivo na plataforma desenvolvida. É através das sentenças associadas aos objetivos que é feita a avaliação da satisfação alcançada pelo agente. Para fazer essa avaliação, são utilizados critérios (a Figura 4.3 mostra que a classe ContextAdaptiveAgent está associada a um ou mais objetos da classe Criterion). A classe Criterion, por ser um ponto de flexibilidade, permite que as sentenças sejam avaliadas e comparadas das mais diferentes formas. Cada sentença possui três atributos: (1) subject, que representa o nome de uma variável cujo valor deve ser capturado ao final do alcance do objetivo; (2) operator, que indica o tipo de operador utilizado (pode ser um operador relacional ou de igualdade); e (3) value, que é o valor desejável para a variável.

Cada objetivo possui uma série de planos aplicáveis (vide associação entre AgentGoal e Plan). Um plano possui uma identificação, um indicador de ativado ou não e condições de falha e de sucesso. Cada vez que um objetivo precisa ser alcançado (é invocado o método commit de AgentGoal), um dos planos associados a ele deve ser selecionado para execução. A seleção de um plano para execução é feita no método selectApplicablePlan, cuja implementação é um ponto de flexibilidade da plataforma proposta.

Objetivos e planos podem ser interrompidos ou cancelados antes do término de suas execuções. A diferença entre as duas operações, conforme descrito na Seção 3.2.2 está no armazenamento do estado de execução. De maneira geral, quando um objetivo ou plano é interrompido, é armazenado o estado da execução. Já quando é utilizado o método abort, a execução é completamente cancelada.

Os planos possuem ainda uma série de recursos (vide associação entre Plan e Resource) e são uma agregação de ações. As ações (objetos da classe Action) são abstratas e possuem seus próprios processos de execução (são especializações da classe Thread). Cada ação possui dois atributos: um identificador e um indicador de ativada ou não. Além disso, as ações possuem dois métodos, o abort e o finish. O método abort cancela a execução da ação (observe que as ações não possuem um método para interromper a execução, uma vez que não é possível interromper uma thread guardando seu estado de execução). O método finish é invocado ao final da execução da ação para que sejam coletadas informações para posterior avaliação do desempenho do agente.

Quando um objeto da classe Plan é selecionado para uso no alcance de um objetivo, é invocado o seu método execute. A implementação desse método compreende a execução, de forma seqüencial, de todas as ações contidas no plano, ou seja, a lista de ações é percorrida e as ações são inicializadas. Como as ações são processos distintos, uma vez inicializadas, elas seguem sua execução de forma autônoma. Então, para que se tivesse controle do término das execuções das ações (o que permite deduzir o término da execução do plano e, conseqüentemente, o alcance de um objetivo), foi criada a classe ExecutionEngine.

Cada vez que é iniciada a execução de um plano, é invocado o método addExecutingPlan da classe ExecutionEngine. Depois disto, no método run da classe, são feitas avaliações contínuas do estado das ações do plano (se em execução ou não). Quando todas as ações do plano são finalizadas, é invocado o método finish da classe Plan. Esse método é utilizado para indicar que a execução do plano foi finalizada (a execução do plano só é finalizada quando todas as suas ações foram executadas).

Por fim, há a classe Environment. A classe Environment representa o ambiente habitado pelos agentes. Cada vez que um agente é criado, ele deve ser registrado no ambiente através da invocação do método registerAgent. Há um e apenas um ambiente para cada sistema multiagentes criado na plataforma. Também, é a classe Environment a responsável por distribuir as mensagens aos agentes apropriados. O gerenciamento de contexto é oferecido como um serviço do ambiente. Observe que a classe Environment possui uma associação com a classe ContextManager. Quando o ambiente de um sistema multiagentes é criado, é criado

também um gerente de contexto para aquele ambiente. Através da associação entre o ambiente e o gerente de contexto, os agentes podem solicitar determinados tipos de informações contextuais e receber notificações de atualizações nessas informações.