Agentes e Ambientes de Programação para a Web: Uma Visão da Área

Marcelo Blois Ribeiro

Maurício da Silva Escobar

Pontifícia Universidade Católica do Rio Grande do Sul – PUCRS

Av Ipiranga 6681 – 90619.900 – Porto Alegre - RS

blois@pucrs.br snk_pit@yahoo.com.br

Resumo. O desenvolvimento de sistemas de informação é uma área com

propostas bem evoluídas e que são aplicadas em escala industrial. O

desenvolvimento de sistemas multiagentes, entretanto, está ainda incipiente e

distante de ser aplicado em escala industrial. Isso se deve principalmente a

imaturidade das propostas de desenvolvimento destes tipos de sistemas que

possuem características próprias distintas dos sistemas convencionais. Este

trabalho apresenta uma visão geral da pesquisa na área e detalha algumas

abordagens utilizadas para a especificação e implementação destes sistemas.

Introdução

A área de Inteligência Artificial vem considerando programas de computadores como entidades distintas e que competem com os seres humanos em certas áreas (Ferber, 1999). Muitos foram as iniciativas ao longo do tempo para aproximar o comportamento de um programa de computador do comportamento de um ser humano. A necessidade de um comportamento mais inteligente por parte de programas de computadores surge da necessidade de aumentar o grau de automação das aplicações, fazendo com que os sistemas decidam o que fazer sem intervenção humana direta baseados em um conjunto de objetivos pré-definidos. Estes sistemas podem ser chamados de agentes.

A computação baseada em agentes será a próxima evolução no desenvolvimento de software (Kinny & Georgeff, 1996). Apesar de muitas previsões sobre o futuro da tecnologia de agentes, muitos avanços são necessários para transformar esta tecnologia em um novo paradigma de desenvolvimento de sistemas (Zambonelli et al., 2000). Em especial, faz-se necessária a formalização dos conceitos de agentes e sistemas multiagentes, a criação de metodologias para o desenvolvimento de sistemas inteligentes que utilizem agentes de software como abstração básica e a criação de uma infra-estrutura capaz de abstrair detalhes complexos de implementação destes agentes.

A partir destas necessidades, a computação baseada em agentes, historicamente restrita ao ambiente de pesquisa de Inteligência Artificial, passou a influenciar outras áreas da

computação, especialmente a área de Engenharia de Software (Kendall et al., 1999; Jennings & Wooldridge, 1999).

Este artigo estrutura uma visão geral das pesquisas realizadas em Sistemas Multiagentes do ponto de vista da área de Engenharia de Software na tentativa de gerar metodologias, infra-estrutura e aplicações que utilizem de forma produtiva e objetiva agentes de software como abstração básica.

A próxima seção apresenta o que é um agente de software e quais são so conceitos relacionados a sua existência. A seção 3 apresenta o que é um sistema multiagentes e quais as dificuldades e benefícios relacionados ao desenvolvimento destes sistemas. A seções 4 e 5 trazem respectivamente as questões relacionadas as metodologias de desenvolvimento de sistemas multiagentes e a infraestrutura necessária a este desenvolvimento. A última seção conclui o artigo apresentando as tendências de uso futuro de sistemas multiagentes. O anexo conta traz o manual do programador de um ambiente de desenvolvimento de sistemas multiagentes para a Web Semântica.

Agente de Software

O desenvolvimento de agentes inteligentes de software se confunde com a própria busca de tecnologias inteligentes pelos pesquisadores de Inteligência Artificial. A idéia de se criar um software inteligente capaz de pensar de forma similar a um ser humano sempre atraiu inúmeros pesquisadores (Ferber, 1999), mas os resultados das pesquisas nem sempre foram tão atrativos. A analogia com a capacidade dos seres humanos de pensar, norteou a busca por entidades de software capazes de imitar o comportamento humano (Genesereth, 1995).

O conceito de agente surgiu na área de Inteligência Artificial Distribuída em 1977, quando Carl Hewitt publicou o seu Modelo de Atores Concorrentes. Neste modelo, Hewitt propôs o conceito de um objeto de execução concorrente, autocontido e interativo, denominado ator.

Apesar da importância dos agentes de software, não existe nenhum consenso acerca da sua definição. Muitas definições são usadas na literatura, mas algumas características permanecem entre todas elas. Um agente é uma entidade de software (por exemplo, um programa) que:

- É autônomo – isto significa que uma vez criado, um agente age de forma autônoma com relação as outras entidades de um sistema. Isto não quer dizer que um agente não se comunique ou coopere com outras entidades, mas que o seu fluxo de execução é independente e, mais importante, que o agente tem autonomia de atuação (onde atuação não quer dizer apenas fluxo de execução independente, mas existência de mecanismos de dedução, associação e indução).

- Atua em um ambiente – o conceito de ambiente relaciona-se fortemente a existência de vários agentes, mas é fundamental para o entendimento de que o agente tem uma forma de perceber o que está a sua volta no espaço, ou seja, ele possui a capacidade de perceber o ambiente.

- É inteligente – a inteligência deve ser entendida neste contexto como a capacidade de atuar segundo objetivos e de acordo com o conhecimento que o agente possui do seu ambiente e das suas ações.

- Possui um modelo limitado do mundo – um agente possui uma representação do ambiente em que atua. O seu escopo limitado deve-se a complexidade das entidades que atuam no ambiente e aos objetivos específicos de cada agente. Com isso, um agente só possui o modelo do mundo necessário ao desempenho de suas tarefas e ao alcance de seus objetivos.

Muitas outras características são citadas, mas não definem distintamente um agente. Por exemplo, a capacidade de atuar em benefício de alguém (pessoa ou outro software) é uma característica apresentada por qualquer software programado para o auxílio das atividades de um determinado ator. Esta característica não traz benefícios para a diferenciação de um agente de outros tipos de softwares.

Outra característica associada aos agentes é a capacidade de se reproduzir. Esta característica é interessante na diferenciação de agentes, mas não é uma característica necessária a um agente. Isto quer dizer que mesmo que uma entidade não se reproduza, ela poderá ser considerada um agente. Da mesma forma, a mobilidade pode ser vista como uma capacidade adicional de um agente e não uma condição necessária para a sua existência.

Podemos sintetizar as idéias apresentadas em:

Um agente é uma entidade de software que, a partir de informações sentidas no ambiente, captadas através da interação direta com outros agentes de software ou humanos, ou geradas a partir dos mecanismos dedutivos internos ao agente, atua em um ambiente buscando o alcance de seus objetivos.

A figura 1 apresenta uma visão abstrata de um agente, ou ainda, o comportamento básico do mesmo. Percebe-se a ação de saída gerada pelo agente, visando à interação com o ambiente. Normalmente, o agente não possui o controle total do ambiente em que participa, mas, sim, uma influência. Sendo assim, ações aparentemente idênticas podem apresentar efeitos completamente diferentes. Isto confirma a importância da preparação do agente para possíveis falhas.

Figura 1 – Um agente atuando no ambiente

AGENTE

AMBIENTE

sensor de entrada

ação de saída

Dentre as várias classificações de agentes existentes, é interessante mencionar a classificação por natureza de atuação. A classificação por natureza de atuação diz respeito a forma como um agente tende a atuar no ambiente. Os agentes quanto a sua atuação podem ser: reativos ou cognitivos.

Agentes reativos são aqueles que reagem de acordo com as informações sentidas no ambiente ou originadas por mecanismos exteriores ao agente. Como exemplo deste tipo de agente, podem ser citados os agentes de monitoramento de tráfego de rede que sinalizam condições anômalas nas taxas de transferência de dados em um segmento de rede. Estes agentes reagem às alterações de tráfego, realizando tarefas de acordo com as informações sentidas para o alcence de seus objetivos.

Outro tipo de agente é aquele que decide atuar independentemente das informações externas recebidas, quer do ambiente ou da interação com outras entidades externas. Estes agentes são chamados de cognitivos e constituem agentes de mais difícil definição. Os agentes cognitivos, na verdade, baseiam-se em informações geradas por seus mecanismos internos de “pensamento” e em informações relacionadas ao seu histórico de atuação para a realização de ações, sem a necessidade de obter informações imediatamente antes da tomada de decisão.

É interessante notar que o comportamento de um agente cognitivo pode, em determinadas situações, ser igual ao de um agente reativo. Já o contrário não é verdadeiro, ou seja, um agente reativo nunca executa ações de forma independente das informações sentidas.

Para a construção de sistemas complexos é interessante considerar a utilização de vários agentes que desempenham tarefas voltadas à obtenção de seus objetivos e que atuam de acordo com os objetivos globais do sistema. Um sistema que possui vários agentes atuando em um ambiente em busca de seus objetivos é denomidado sistema multiagentes ou SMA.

Sistemas Multiagentes

Assim como a definição de agentes de software, a definição de sistemas multiagentes também é controversa na literatura (Ferner, 1999; Weiss, 1999; Wooldridge & Jennings, 1994). Alguns autores consideram um sistema multiagentes como uma coleção de agentes que se coordenam através de suas interações. Segundo estes autores, um SMA só existe se existe coordenação entre os agentes que o formam. Para outros autores a definição de SMA deve incorporar um conjunto de agentes que interagem entre si e com objetos em um ambiente, mesmo que não haja protocolos de coordenação explícitos entre eles (Wooldridge & Jennings, 1995).

Este trabalho apresenta a seguinte definição de SMA baseada na síntese das definições dos principais autores:

Um SMA é um sistema formado por diversos agentes que mantém alguma relação semântica entre as suas ações e que atuam em um ambiente.

Nesta definição, o conceito de ambiente fica bastante evidente como sendo uma parte de um SMA. O ambiente delimita o escopo de atuação dos agentes de um SMA, servindo como base de informações para os sensores e para o canal de saída das ações dos agentes.

Outra questão que surge desta definição é a relação semântica que deve existir entre as ações dos agentes de um SMA. Esta restrição indica que as ações dos agentes devem estar associadas de alguma forma e que esta associação deve servir aos objetivos individuais dos agentes e ao objetivo de todo o sistema ou sociedade de agentes. Este conceito de SMA muitas vezes é traduzido em termos de organizações de agentes (Klusch, 1999). As organizações de agentes servem para definir papéis que um determinado agente pode desempenhar em uma situação. Assim, o mesmo agente pode desempenhar papéis distintos dependendo da organização de agentes da qual ele faz parte.

Para ilustrar o conceito de SMA, considere a construção de um sistema de alocação de salas de reunião de acordo com os requisitos de cada reunião que será realizada. Inicialmente, podemos pensar em um sistema que controle as salas e saiba todas as características de cada sala. Neste sistema atuaria um agente que, ao receber uma requisição de sala, faria o casamento entre os requisitos solicitados e os recursos oferecidos por cada sala, checando antes os horários disponíveis para cada uma delas. Caso houvesse possibilidade de alocação, o agente reservaria a sala para a reunião. Se a sala necessária estivesse ocupada e todos os horários desejados estivessem tomados, o agente avisaria ao usuário que não há como ele agendar a reunião.

O mesmo problema poderia ser atacado de outras formas, inclusive sem o emprego de sistemas multiagentes. Uma outra maneira de ver a solução do problema seria considerar que não existe só o agente que tentará casar a requisição com a sala, mas um agente que mediará uma cooperação entre agentes que representam as salas para chegarem a melhor opção. Repare que na primeira opção, toda a lógica de encontrar uma solução que esteja de acordo com as restrições de cada reunião estaria no agente de casamento. Já na segunda opção, os agentes das salas poderiam cooperar para melhor se adequar as várias requisições. A segunda opção utiliza uma abordagem onde a lógica decisória está distribuída e em que cada unidade (agente) deve se preocupar com um problema menor a ser resolvido (particionamento).

Embora mais complexa, a segunda opção poderia resolver melhor as solicitações de sala ao longo do tempo, já que cada agente de sala negociaria o seu espaço com os outros agentes, tentando chegar a melhor solução para todo o sistema. Este exemplo de cooperação ilustra como a interação entre agentes pode transformar a busca de objetivos particulares dos agentes na busca do objetivo global do sistema (ou organização). Além disso, as diferentes formas de modelar o mesmo problema indicam que o desenvolvimento de sistemas multiagentes pode ser uma tarefa complexa, sendo difícil decidir que tipo de arquitetura utilizar.

Existem momentos em que os Sistemas Multiagentes não são a melhor solução para um problema. Sendo assim, um domínio em que é aplicada esta tecnologia deve possuir as seguintes características (Jennings et al., 1996):

- Distribuição intrínseca de dados, capacidade de resolução de problemas e responsabilidades;

- Autonomia em suas subpartes, conservando a estrutura organizacional;

- Complexidade nas interações, exigindo negociação e cooperação;

- Diligência, devido à possibilidade de mudanças dinâmicas em tempo real no ambiente.

Com base nestas considerações surge as seguinte questões: Como desenvolver sistemas que utilizem agentes como abstração básica garantindo a convergência das ações de cada agente para o objetivo geral do sistema? Como saber se a melhor solução a ser aplicada na solução de um problema é uma solução multiagente? A busca da solução para estas questões é o principal motivador para o surgimento das abordagens de desenvolvimento de sistemas multiagentes.

Abordagens de Desenvolvimento de Sistemas Multiagentes

Para que os sistemas multiagentes sejam utilizados em escala industrial é necessário que o risco associado a sua produção seja reduzido. (Odell & Bock, 2005) apresenta duas formas de redução do risco na introdução de uma nova tecnologia em escala industrial:

1. Apresentar a nova tecnologia como um incremento ou extensão de métodos confiáveis e bem conhecidos.

2. Prover ferramentas de engenharia que auxiliem a entrega de soluções via métodos já aceitos pela indústria de produção de software.

No sentido de auxiliar a produção em larga escala de sistemas multiagentes, muitos pesquisadores buscaram o desenvolvimento de metodologias para a construção destes sistemas. Algumas iniciativas foram iniciadas e posteriormente abandonadas, tornando-se importante historicamente como exemplos de abordagens de desenvolvimento de sistemas multiagentes, como foi o caso de Gaia (Wooldridge et al., 2000). Outras, estão ainda em desenvolvimento, mas não existe um consenso quanto a melhor metodologia para o desenvolvimento de sistemas multiagentes.

Uma pergunta surge naturalmente quando se propõem novas metodologias de desenvolvimento de software: por que não podemos usar as metodologias já existentes? No caso do desenvolvimento de sistemas multiagentes, as características instrínsecas aos agentes os tornam distintos, por exemplo, dos objetos presentes no desenvolvimento orientado a objetos. Os agentes possuem simultaneamente autonomia dinâmica (a habilidade de iniciar ações sem invocação externa) e autonomia determinística (a capacidade de recusar ou modificar uma requisição externa) que tornam o comportamento dos agentes difícil de ser descrito pelas técnicas atuais de modelagem de software, como UML. Por exemplo, um diagrama de sequência apresenta a invocação de métodos entre os objetos de uma classe. Se estes objetos fossem agentes, um agente poderia recusar uma mensagem enviada por um outro agente com base na sua deliberação interna. Isso faria com que uma mensagem enviada de uma entidade para outra simplesmente não tivesse efeito, o que não é razoável no caso dos sistemas orientados a objetos.

Devido as limitações de UML para modelagem de sistemas multiagentes, (Bauer at al, 2001) apresenta uma proposta para a extensão dos diagramas de UML para a representação de agentes (Agent Unified Modeling Language - AUML). O foco desta extensão está na modelagem no nível da sociedade de agentes, mostrando principalmente o comportamento interativo entre os agentes. Alguns trabalhos estenderam a AUML com outros diagramas, como fez (Parunak & Odell, 2001) para representar as estruturas sociais nas organizações de agentes.

Apesar da AUML trazer importantes contribuições em termos de modelagem de SMA, não houve a repercussão esperada pelos autores em torno da proposta. Uma das características que contribuiram para a não adoção da proposta foi a falta de uma metodologia que utilizasse a proposta de forma organizada, mostrando as atividades e os diagramas relacionados a elas que seriam necessários para a construção de um SMA. Muitas metodologias surgiram ao longo do tempo, cada uma focada em diferentes aspectos do desenvolvimento de SMA (Deloach, 2000) (Castro, et al., 2002) (Winikoff & Padghan, 2002). Um ponto comum entre elas é o fato de que são utilizadas para a modelagem e projeto de SMA desde suas primeiras atividades, ou seja, elas presumem que a solução a ser desenvolvida é uma solução SMA (ou pelo menos usam elementos típicos da área de agentes já na especificação de requisitos).

A seção 3 apresenta, entretanto, que nem todos os problemas são passíveis de uma solução orientada a agentes. Com base neste raciocínio surgiu o MASUP (Bastos & Ribeiro, 2005). No Multi-agent Systems Unified Process não existe a pretensão de se projetar soluções completamente multiagentes. Parte-se do pressuposto que algumas partes de um sistema serão apropriadas para uma abordagem SMA e que outras partes serão desenvolvidas utilizando-se orientação a objetos. Para tal, o MASUP utiliza a estrutura básica do RUP, derivando o seu fluxo a partir do workflow de requisitos na porção do sistema que parece apropriada para um solução multiagentes.

A figura 2 apresenta os modelos presentes no MASUP e os artefatos relacionados a cada modelo. O levantamento de requisitos no MASUP é semelhante ao RUP e gera o modelo de casos de uso, como indicado na figura. A primeira atividade consiste na captura de requisitos por meio de casos de uso. Em seguida, são feitos detalhamentos dos casos de uso, incluindo a elaboração de diagramas de atividades para cada caso de uso. O MASUP encoraja a apresentação dos objetos consumidos e gerados pelas atividades nos diagramas de atividades, já que é com base nestes objetos que é feita a análise de papéis dos agentes caso a solução multiagentes seja apropriada.

Na fase de análise é feita uma revisão dos diagramas de atividades gerados no projeto de forma a descobrir quais atividades utilizam uma tomada de decisão que necessita ser codificada diretamente no sistema e que na modelagem original é realizada por algum ator. A figura 3 mostra os diagramas de atividades utilizados para a especificação do caso de uso Aloca Funcionário em uma sistema de alocação de recursos humanos a atividades de um projeto de desenvolvimento de software de acordo com o perfil dos funcionários e das atividades. As atividades selecionar funcionário e confirmar alocação são substituídas na solução SMA pela atividade ativar alocação. Esta substituição deve-se ao fato de que os critérios de tomada de decisão do ator ao selecionar um funcionário para uma determinada

atividade precisam ser formalizados no software. Desta forma, podemos criar uma solução que automaticamente leve em consideração atributos das atividades e dos funcionários para realizar uma alocação que aproveite de forma satisfatória as características dos recursos presentes em uma determinada empresa.

Terminados os novos diagramas de atividades, é produzida a especificação dos papéis. Esta fase fornece o conhecimento necessário sobre os papéis usados na execução dos casos de uso especificados para o Sistema Multiagentes. Identifica-se a atribuição para cada papel identificado. As tabelas geradas nesta fase apresentam as atribuições derivadas das atividades do caso de uso que solicitam a participação do papel, o caso de uso e a atividade em questão, e as restrições a serem observadas pelo papel para a sua execução.

Figura 2 – Modelos do MASUP e seus Artefatos

Especificados os papéis, são identificados os agentes. O MASUP define um agente como uma agregação de papéis cujas atribuições são complementares. Por atribuição complementar entende-se que o agente deve mudar seu papel quando assumir outra atribuição requisitada por uma atividade do caso de uso. Os agentes são representados por

classes de agentes que especificam as atribuições, comportamento e arquitetura compartilhados por um conjunto deles. As informações necessárias para se definir uma classe de agente são: seu nome, seu número máximo de instâncias na sociedade, seus atributos, as interfaces de interação, seus papéis e suas atribuições. As interfaces de interação fornecem os atos de comunicação que o agente é capaz de reconhecer como válidos para atender a requisição de outro agente. Elas são definidas apenas após a especificação dos cenários de interação nos diagramas de seqüência AUML. A classe de agentes é representada por um retângulo que contém, no mínimo, o nome da classe e o número de instâncias para um determinado tipo de agente no sistema.

Especificados os agentes, é definida a sociedade de agentes. Nesta especificação, é necessário definir a relação hierárquica entre os agentes por meio do Diagrama de Classes de Agentes. As relações são identificadas dos Diagramas de Atividades Estendidos AUML, nos pontos em que os papéis são responsáveis por executar conjuntamente uma ou mais atividades, e representam canais de comunicação em que mensagens são trocadas. As relações são representadas por setas que conectam os emissores aos receptores, contendo, opcionalmente, os seus nomes. Elas também contêm, em cada extremidade, a multiplicidade e o papel do agente.

Figura 3 – Caso de Uso Alocar Funcionário: Diagrama de Atividades UML (esq) e Diagrama de Atividades do MASUP com a Indicação de Papéis (dir)

Na Fase de Projeto do MASUP, existem atividades para definir as interações entre os agentes e a interação destes com o ambiente de implementação. As principais atividades do MASUP nesta fase são a especificação dos cenários de interação dos agentes e

complementação da especificação das classes de agentes com os atos de comunicação para a implementação das interações modeladas. Após a fase de projeto, a parte SMA do sistema está apta a ser implementada usando alguma linguagem de programação disponível e/ou uma plataforma de desenvolvimento de sistemas multiagentes, que provê a infraestrutura necessária a implementação da sociedade de agentes.

Infra-estrutura para o Desenvolvimento de Sistemas Multiagentes

O crescente uso de agentes de software para a resolução de problemas distribuídos proporciou um avanço no sentido de oferecer uma infra-estrutura de software que facilite a implementação de sistemas multiagentes. Embora existam iniciativas que procuram oferecer suporte a qualquer tipo de aplicação multiagentes, muitas plataformas criadas concentram-se em tipos específicos de sistemas multiagentes. Além da dimensão de análise das plataformas quanto ao suporte a aplicações genéricas, também pode-se identificar diferenças na forma de implementação dos aspectos mais comuns de agência, como representação de conhecimento, comunicação, capacidade de coordenação, mobilidade, entre outros.

Dentre as plataformas disponíveis, algumas merecem maior atenção por terem sido usadas em uma maior número de casos com resultados satisfatórios. Segundo (OpenCybele, 2005), OpenCybele é uma plataforma Open Source para o desenvolvimento de sistemas baseados em agentes. Foi construída pela IAI (Intelligent Automation Incorporated), sendo desenvolvida sobre a plataforma Java 2.

OpenCybele é composta por um kernel e por diversos serviços. Os mesmos podem ser refinados de acordo com a necessidade, seja ela de ambiente ou de domínio da aplicação de sistemas baseados em agentes. Estes serviços são acessados por meio de interfaces, conhecidas como AOPIs (Activity Oriented Programming Interfaces). Os serviços disponibilizados pela OpenCybele são: o controle de erros, a gerência de concorrência, o controle de eventos, a gerência de threads, a geração de eventos internos, a comunicação e a gerência de eventos de tempo. A figura 4 exibe a arquitetura de serviços em camadas do OpenCybele.

Figura 4 – Arquitetura de Serviços em Camadas do OpenCybele

Segundo (MadKit, 2004), o MadKit é uma plataforma multiagentes escalável e modular, escrita na linguagem Java e construída sob o modelo organizacional AGR (Agente/Grupo/Papel). Neste modelo, os agentes são estabelecidos em grupos e representam papéis. A figura 5 ilustra melhor este conceito. O MadKit permite a alta heterogeneidade em arquiteturas de agentes e em linguagens de comunicação, além de diversas customizações. A comunicação da plataforma é baseada em um mecanismo ponto-a-ponto, tornando possível o rápido desenvolvimento de aplicações distribuídas utilizando os princípios de um Sistema Multiagentes.

Figura 5 – Modelo Agente/Grupo/Papel.

Os agentes no MadKit podem ser programados em Java, Scheme, Jess ou BeanShell. Outras linguagens de script também podem ser facilmente adicionadas. Somado a isto, um conjunto de ferramentas facilita a inicialização, exibição, desenvolvimento e monitoração dos agentes e suas organizações.

Segundo (Jade, 2005), o JADE, Java Agent DEvelopment Framework, é um framework totalmente implementado na linguagem Java, sendo desenvolvido pelo TILAB, um laboratório de pesquisa incorporado pela Telecom Italia Group. Ele simplifica a implementação de Sistemas Multiagentes baseados na arquitetura de comunicação ponto-a-ponto, por meio de um middleware aderente às especificações da FIPA e de um conjunto de ferramentas que auxiliam nas fases de correção de erros e deployment. O middleware JADE contém um ambiente de execução para os agentes, uma biblioteca de classes e um conjunto de ferramentas gráficas. O JADE utiliza os seguintes princípios:

• Interoperabilidade: seguindo as especificações da FIPA, os agentes do JADE podem interoperar com outros agentes;

• Uniformidade e portabilidade: o JADE fornece APIs homogêneas independentes da versão do Java e da rede utilizada;

• Facilidade de uso: a complexidade do middleware é escondida por um conjunto simples e intuitivo de APIs;

• Filosofia do pay-as-you-go: os programadores não precisam utilizar todas as funções fornecidas pelo middleware.

A figura 6 descreve, de maneira simplificada, a arquitetura JADE. Pode-se notar que sua arquitetura permite a adaptação às restrições de ambientes com recursos limitados, bem como a integração em arquiteturas complexas.

Figura 6 – Arquitetura do JADE.

Estas plataformas constituem uma base sobre a qual é possível a construção mais rápida de SMAs utilizando os serviços providos pelas estruturas de cada proposta. Cada uma destas plataformas utiliza seu modelo proprietário de representação dos agentes e dos serviços providos. Além disso, a integração entre elas e as metodologias de desenvolvimento de SMAs é feita de forma ad-hoc. Uma lacuna também presente é a falta de capacidade de modelar os mecanismos de tomada de decisão dos agentes, que são deixados para implementação de acordo com a necessidade do programador. A estrutura interna dos agentes é simplificada ou sisplesmente inexistente na maioria das propostas investigadas.

Buscando reduzir estas lacunas foi proposto o SemantiCore (Blois & Lucena, 2004), que é um framework que visa promover uma camada de abstração sobre plataformas ou serviços de distribuição de computação que facilite a implementação de sistemas multiagentes para execução na Web Semântica. A Web Semântica foi proposta em (Berners-Lee et al., 2001) e visa a extensão da Web convencional com conteúdos que sejam processáveis diretamente por entidades de software. As anotações semânticas associadas ao conteúdo tradicional das páginas Web permitiriam a interpretação da semântica da página por agentes de software que trabalhem com mecanismos de inferência de forma nativa.

Os elementos do Semanticore são estruturados em dois grandes modelos: modelo do domínio e modelo do agente. No modelo do domínio encontram-se as estruturas básicas para o funcionamento da sociedade de agentes. Entre estas estruturas, temos o agente de controle do domínio, o agente de controle de serviços e o agente de controle de recursos. O agente de controle de domínio é responsável pela autenticação de agentes nas sociedades existentes e pela descoberta de agentes dentro de uma sociedade. O agente de controle de serviços armazena quais os serviços oferecidos por cada agente da sociedade e pela sociedade como um todo. Quando é necessário descobrir que agente oferece determinado serviço, o agente que demanda o serviço realiza uma requisição ao agente de controle de serviços para que este verifique os candidatos ao atendimento daquela demanda. O agente de controle de recursos é resposável pela oferta de informações (recursos) para os agentes de um determinado domínio. Este agente oferece uma interface uniforme entre recursos presentes nos domínios Web convencionais e recursos presentes nos domínios semânticos estruturados pelo SemantiCore. Um último agente de controle faz a comunicação entre os diferentes domínios semânticos, sendo denominado gerente de comunicação.

O modelo do agente estrutura internamente a arquitetura de um agente no SemantiCore. A estrutura interna do agente é organizada em componentes com funções especializadas que implementam o ciclo de vida de execução de um agente. O Componente Sensorial é responsável pela gestão dos sensores cadastrados para um agente e pela ativação destes sensores de acordo com os recursos recebidos no ambiente. Estes recursos são então passados ao Componentes Decisório que possui regras e fatos relacionados ao histórico de recursos recebidos e a programação feita no agente para tomada de decisão. Os recursos recebidos geram novos fatos que podem disparar as regras do mecanismo decisório. Com base nas derivações das regras, algumas ações podem ser disparadas, sendo então transmitidas ao Componente Executor. Este componente possui os planos de ação do agente na forma de uma sequência de tarefas a serem realizadas para o alcance de seus

objetivos. Algumas ações do plano podem gerar novos recursos a serem transmitidos no ambiente. Para isso, este componente aciona o Componente Efetuador que é o responsável pela publicação dos recursos gerados no processamento do agente.

Os recursos recebidos e transmitidos ficam armazenados na memória do agente que é controlada pelo Componente Gerenciador de Memória. Com isso, novos processamentos poderão buscar informações relacionadas a processamentos anteriores do mesmo agente. Os elementos básicos do agente, como sensores, regras, fatos, efetuadores, planos de ação e recursos podem ser encapsulados em um objeto denominado Objeto de Conhecimento. Este objeto é gerenciado pelo Componente de Gerência do Conhecimento. Este componente viabiliza a catalogação do conhecimento de cada agente, permitindo o controle de versões e a troca de conhecimento entre agentes de acordo com os objetivos que podem ser atingidos com aquele conhecimento.

O SemantiCore possui hotspots associados a diversas características do framework para que seja possível instanciá-lo sobre diversas plataformas. Foram feitas instanciações sobre o FIPAOS e sobre o JADE. Existem hotspots para flexibilizar o mecanismo de envio e recepção de mensagens dos agentes, a codificação dos recursos, a máquina de inferência utilizada para a tomada de decisão, o mecanismo de execução de ações do componente executor, a especificação das ações a serem executadas (podem ser definidas em tempo de execução) e a linguagem de representação dos objetos de conhecimento. Cada instanciação deverá implementar estes hotspots ou utilizar a implementação base provida focada no uso de padrões de Web Semântica nativamente nos agentes, como OWL (Web Ontology Language, 2004), RDF (RDF, 1997), etc. O anexo deste artigo apresenta o manual do programador para o SemantiCore que auxilia na compreensão do uso do ambiente para o desenvolvimento de aplicações baseadas em agentes na Web.

Conclusão

A utilização em escala industrial de sistemas multiagentes pode revolucionar a maneira como as aplicações são desenvolvidas atualmente. A incorporação de mecanismos de representação de conhecimento no processo de desenvolvimento de software pode facilitar a geração de sistemas multiagentes robustos, onde existe uma garantia em nível de projeto que o sistema atingirá os objetivos para o qual foi proposto.

Este cenário somente será possível se as metodologias de desenvolvimento de software incorporarem mecanismos que consigam capturar todas as características destes sistemas e que possuam rastreabilidade entre os artefatos gerados na modelagem e a implementação das estruturas sociais e internas dos agentes.

Outra necessidade fundamental é a criação de uma infra-estrutura para implementação destes sistemas que facilite a criação dos elementos básicos de um SMA, provendo abstrações que escondam os detalhes de implementação. Este ferramental permitirá que os programadores concentrem-se em atividades de mais alto nível e que possam atingir novos patamares de codificação de sistemas complexos, abertos e heterogêneos.

Este trabalho proporcionou uma visão geral das necessidades da área de Engenharia de Software aplicada a Sistemas Multiagentes contribuindo para um posicionamento crítico

com relação as pesquisas realizadas. Espera-se que as novas metodologias possam se tornar estáveis o suficiente para a geração de aplicações mais inteligentes, levando o desenvolvimento de software a novos horizontes em termos de redução de complexidade e possibilidade computacional. Para maiores informações acesse o site http://semanticore.pucrs.br.

Referências

BASTOS, R. M.; RIBEIRO, M. B. MASUP: An Agent-Oriented Modeling Process for Information Systems. In: Software Engineering for Multi-Agent Systems III: Research Issues and Practical Applications. Berlin: Springer-Verlag, 2005.

Bauer, B., Müller, J.P., Odell, J. Agent UML: A Formalism for Specifying Multiagent Interaction. In: Agent-Oriented Software Engineering, Lecture Notes in Computer Science. Berlin: Springer-Verlag. 2001. pp 91-103.

BERNERS-LEE, T.; HENDLER, J.; LASSILA, O. The semantic web. ScientificAmerican, v.1, n.29, p. 35-43, 2001.

BLOIS, M., LUCENA, C. Multi-agent Systems and The Semantic Web-The SemantiCore Agent-based Abstraction Layer. In: ICEIS-International Conference on Enterprise Information Systems. Porto, Portugal, v.4, pp.263-270. Anais…2004.

CASTRO, J., KOLP, M., MYLOPOULOS, J. Towards Requirement-Driven Information Systems Engineering: The Tropos Project. Information Systems, n. 27, p. 365-389, 2002.

DELOACH, S.A. Multiagent Systems Engineering. International Journal of Software and Knowledge Engineering, v. 11, n. 3, p. 231-258, 2000.

FERBER, J. Multi-agent systems: an introduction to distributed artificial intelligence. Oxford: Addison-Wesley, 1999. 528p.

GENESERETH, M. R.; SINGH, N.; SYED, M. A distributed and anonymous knowledge sharing approach to software interoperation. International Journal of Cooperative Information Systems, v.4., n.4, p. 339-367, 1995.

JADE, Java Agent Development Framework. Desenvolvido por TILAB. Disponível em: <http://jade.tilab.com>. Acesso em: 7 nov. 2005.

JENNINGS, N. et al., Using intelligent agents to manage business processes. In: Practical Applications of Intelligent Agents and Multi-Agent Technology – PAAM’96, Lon-don, UK. Anais… 1996.

JENNINGS, N.; WOOLDRIDGE, M. Agent-oriented software engineering. In: EUROPEAN WORKSHOP ON MOMDELLING AUTONOMOUS AGENTS IN A MULTI-AGENT WORLD, 9, 1999, Valência, Espanha. Anais ... 1999, p. 1-7.

KENDALL, E. A.; MALKOUN, A. T., JIANG, C. H. The Application of Object oriented Analysis to Agent Based Systems. In: EUROPEAN WORKSHOP ON MODELLING

AUTONOMOUS AGENTS IN MULTI-AGENT WORLD, 9, 1999, Valência, Espanha. Anais … 1999.

KINNY, D., GEORGEFF, M. Modelling and design of multi-agent systems. In: INTERNATIONAL WORKSHOP ON AGENT THEORIES, ARCHOTECTURES, AND LANGUAGES (ATAL-96), 3, 1993, Budapest, Hungria. Anais do Intelligent Agents III, 1996, 401p.

KLUSCH, M. Intelligent Information Agents: agent based information discovery and management on the Internet. New York: Springer, 1999. 498p.

MADKIT, The Project. Desenvolvido por The MadKit Team. Disponível em: <http://www.madkit.org>. Acesso em: 7 nov. 2005.

ODELL, J.; BOCK, C. Suggested UML Extensions for Agents. Desenvolvido por IntelliCorp, Inc. Disponível em: < http://www.agent.ai/doc/upload/200302/odel99_4.pdf >. Acesso em: 07 nov. 2005.

OPENCYBELE Agent Infrastructure. Desenvolvido por Intelligent Automation Incorporated. Disponível em: <http://www.opencybele.org>. Acesso em: 7 nov. 2005.

PARUNAK, H. V. D.; ODELL, J. Representing social structures in UML. In: INTERNATIONAL CONFERENCE ON AUTONOMOUS AGENTS, 5, 2001, Montreal, Canadá. Anais do International Workshop on Agent-Oriented Software Engineering, 2001, p. 1-16.

RESOURCE DESCRIPTION FRAMEWORK (RDF). Coordenação de Eric Miller; Ralph Swick; Dan Brickley. Desenvolvido pela World Wide Web Consortium, 1997-2002. Disponível em <http://www.w3.org/RDF/>. Acesso em 7 nov. 2005.

WEB ONTOLOGY LANGUAGE (OWL). Coordenação de Eric Miller; Jim Hendler. Desenvolvido pela World Wide Web Consortium, 2004. Disponível em < http://www.w3.org/2004/OWL/>. Acesso em 7 nov. 2005.

WEISS, G. Multiagent systems: a modern approach to distributed artificial intelligence. Massachussests: The MIT Press, 1999. 619p.

WINIKOFF, M., PADGHAM, L. Prometheus: A Methodology for Developing Intelligent Agents (2002). In: Third International Workshop on Agent-Oriented Software Engineering – AAMAS. Anais…2002.

WOOLDRIDGE, M.; JENNINGS, N. Agent theories, architectures and languages: a survey. In: EUROPEAN CONFERENCE ON ARTIFICIAL INTELLIGENCE, 11, 1994, Amsterdã, Holanda. Anais do Workshop on Agent Theories, Architectures, and Languages, 1994, p. 1-39.

WOOLDRIDGE, M.; JENNINGS, N. Intelligent agents: theory and practice. Knowledge Engineering Review, v.10, n.2, p. 115-152, 1995.

WOOLDRIDGE, M.; JENNINGS, N. R.; KINNY, D. The Gaia methodology for agent-oriented analysis and design. Journal of Autonomous Agents and Multi-Agent Systems, v.3, n.3, p. 285-312, 2000.

ZAMBONELLI, F. et al. Agent-oriented software engineering for internet applications. In: OMICINI, A. et al. (Ed.) Coordination of internet agents: models, technologies, and applications. Heidelberg, Alemanha: Springer-Verlag, 2000 p. 326-346.

Anexo

SEMANTICORE MANUAL DO PROGRAMADOR

Última atualização: 28 de março de 2007. SemantiCore 2006

1. Introdução

O SemantiCore é um framework para desenvolvimento de aplicações para a Web

Semântica desenvolvido na linguagem Java que provê uma camada de abstração sobre os serviços de distribuição oferecendo aos desenvolvedores uma abstração de alto nível.

O framework SemantiCore é divido em dois modelos: o modelo de agente e o modelo de domínio. Ambos os modelos dispõem de pontos de flexibilidade (hotspots) permitindo ao desenvolver associar diferentes padrões, protocolos e tecnologias.

2. Usando o SemantiCore

Este capítulo descreve os passos necessários para a criação de aplicações que estendem o framework SemantiCore.

2.1. Plataforma

O SemantiCore define o domínio (Semantic Domain) onde os agentes atuam. Cada domínio pode ser pensado como um Sistema Multiagentes já que nesta versão o SemantiCore não possui o conceito de sociedade. Cada domínio é conectado a outro através da infra-estrutura da Internet. Um domínio pode ser distribuído através de diferentes plataformas de hardware ou em um mesmo computador. A figura 1 mostra um exemplo da distribuição de um domínio.

Figura 1: Distribuição de um domínio

Entre os dois domínios representados na figura 1 existe um canal de comunicação. Este canal é gerenciado pelo agente da plataforma chamado CommunicationManager.

Todas as informações que são trocadas entre diferentes domínios passam por este agente,

que tem a responsabilidade de receber e enviar a informação até o seu destino. Esta informação deve ser uma mensagem padrão da plataforma (Semantic Message).

O framework SemantiCore trabalha com dois arquivos de inicialização. Estes arquivos necessitam ser configurados de acordo com as definições do desenvolvedor da aplicação. O primeiro arquivo é o arquivo XML chamado semanticoreconfig.xml. Este arquivo contém a descrição dos Agentes que serão inicializados junto com a plataforma. A figura 2 contém um exemplo de configuração deste arquivo:

Figura 2: Exemplo de configuração (a)

Cada tag “agent” indica a inicialização de um agente na plataforma. Esta tag contêm os atributos name, class e um atributo opcional chamado param. O atributo name é o nome que será atribuído ao agente dentro do domínio, e ele deve ser único; o atributo class é a URL da classe Java que implementa o agente; e o atributo param é um conteúdo do tipo String que será passado no construtor do agente, podendo assim ser manipulado pelo usuário na inicialização do agente. Por exemplo, ele pode ser usado para diferenciar o modo de inicialização do agente de acordo com o seu conteúdo.

O segundo arquivo de inicialização é o arquivo XML chamado semanticoreinstantiation.xml. Este deve conter a descrição dos hotspots que serão inicializados e usados como mecanismos default dos agentes na plataforma. A figura 3 mostra um exemplo de configuração deste arquivo:

Figura 3: Exemplo de configuração (b)

A tag decisionengine referencia o mecanismo decisório do agente, e a classe semanticore.agent.decision.hotspots.GenericDecisionEngine indica a classe Java que implementa este mecanismo. Para configurar um mecanismo diferente, deve ser especificado na tag class uma nova classe que implementa este mecanismo. Esta regra também se aplica para o mecanismo do componente executor, utilizando a tag executionengine.

2.2. O Modelo de Agente

Um agente é essencialmente um contexto autônomo de execução populado com processamento lógico e decisório realizando tarefas e capturando eventos e mensagens do ambiente. Estes agentes são organizados em domínios semânticos.

O modelo de agente define todos os elementos necessários para construir um agente no SemantiCore (SemanticAgent). Este agente é composto por quatro componentes básicos. Cada componente e responsável por uma tarefa especializada. A estrutura orientada a componentes de um SemanticAgent auxilia o desenvolvedor a estruturar o agente em partes. Esta modularização oferece benefícios em termos de manutenção, organização do código e extensão funcional dos agentes.

2.2.1. Componentes O componente sensorial centraliza os elementos que são capazes de receber objetos do ambiente. Este componente armazena os sensores definidos pelo desenvolvedor e verifica se um destes sensores será ativado pela recepção de um objeto do ambiente. Um sensor é uma classe Java que estende a classe Sensor (semanticore.agent.sensorial.Sensor)

presente no framework SemantiCore. A figura 4 ilustra um exemplo de implementação de um Sensor.

Figura 4: Exemplo de implementação de um Sensor

O método evaluate deve conter o código que trata os objetos recebidos do ambiente, e o retorno deste método deve conter os dados que serão transmitidos para o componente decisório do agente. O sensor deve retornar um conteúdo válido, caso ele consiga identificar que o conteúdo recebido é compatível com o padrão de reconhecimento de

recursos estabelecido. Caso ele não identificar a similaridade, o retorno deve ser nulo (sentença null em Java). No exemplo da figura 4, temos a implementação de um sensor que verifica se o conteúdo de uma mensagem recebida do ambiente é do tipo String. Se o teste resultar em verdadeiro, então ele retorna a mensagem recebida para ser transmitida ao componente decisório. Em agentes da Web Semântica a verificação dos padrões de recurso é tipicamente feita pela comparação da estrutura de uma ontologia com um padrão ontológico esperado. O pacote do SemantiCore conta com a classe OWLSensor que implementa sensores capazes de realizar esta verificação. O componente decisório recebe os objetos vindos do componente sensorial e processa esses dados baseando-se em regras e fatos em uma dada linguagem de representação. O componente decisório possui um mecanismo responsável pelo processamento dos objetos recebidos. Este mecanismo é chamado DecisionEngine, e ele é um ponto de flexibilidade da plataforma. Nesta componente podem ser inseridas máquinas de inferência capazes de processar código OWL como é o caso da máquina de inferência do Jena.

O componente executor é responsável por armazenar os planos de ação do agente e gerenciar as suas execuções. Estas ações são criadas pelo desenvolvedor estendendo a classe Action. Com isso, quando houver a necessidade de disparo de uma ação pelo resultado do processamento decisório, a ação definida pelo usuário é instanciada e gerenciada pelo executor.

Para um agente publicar um conteúdo no ambiente, é necessário que ele possua um efetuador capaz de publicar no ambiente o formato no qual este conteúdo está estruturado. Os efetuadores de um agente são controlados pelo componente efetuador. Este componente recebe dados dos outros componentes e verifica em qual efetuador este objeto deve ser processado. Assim como os sensores, os efetuadores são pontos de flexibilidade, permitindo aos desenvolvedores a utilização de diferentes tecnologias para a transmissão de dados, como por exemplo, SOAP1.

2.2.2 Ciclo de vida do Agente Um agente do SemantiCore possui um ciclo de vida (figura 5). O agente inicia a sua execução pela chamada do método setup. O setup tem todo código necessário para o agente ser estruturado. No setup o desenvolvedor pode criar sensores, fatos, regras, efetuadores, ações, planos de ação e objetivos para os agentes. Todas essas estruturas são criadas usando classes do SemantiCore e formam o modelo de referência de um SemanticAgent. Após a estruturação o agente permanece em um loop conceitual de execução que corresponde a tentativa de sentir novos conteúdos que chegaram no ambiente, a tomada de decisão sobre o que fazer a seguir com base nos conteúdos recebidos e no histórico de execução, a execução das ações necessárias e, finalmente, a publicação de novas 1 Simple Object Access Protocol. Disponível em http://www.w3.org/TR/soap

mensagens e recursos no ambiente. Este ciclo é teórico, já que cada componente do SemantiCore é uma thread autônoma de execução que realiza as suas atividades independentemente das demais.

Figura 5: Ciclo de vida de um Semantic Agent

2.3 O Modelo de Domínio

Um agente deve atuar em um ambiente. O SemantiCore define o lugar onde estes agentes executam como um domínio semântico. O conceito de domínio do SemantiCore fornece ao desenvolvedor um mecanismo de transição da noção tradicional de domínio Web para a noção de um domínio composto de agentes e objetos. Os domínios requerem o domínio Web para operarem. Este domínio semântico pode ser visto como uma região na Web em que os agentes vivem.

Cada domínio é composto pode algumas entidades administrativas, como Domain

Controller e o Communication Manager (nesta versão). O Domain Controller é um agente da plataforma responsável pelo registro de agentes no ambiente, recepção de agentes móveis de outros domínios e características de segurança do domínio. O Communication

Manager é o agente da plataforma responsável pelo gerenciamento da comunicação com outros domínios. A figura 6 ilustra a representação de um domínio semântico como uma parte do domínio Web.

Figura 6: Modelo de domínio

Além da comunicação entre diferentes domínios, o SemantiCore permite que um

domínio seja particionado e distribuído através de diferentes plataformas de hardware, e

cada parte de um domínio é chamada de Domain Part. A distribuição é transparente para o desenvolvedor e para o usuário da aplicação. As demais entidades administrativas do SemantiCore foram simplificadas nesta versão e desenvolvidas como infra-estrutura diretamente codificada na plataforma ao invés de serem consideradas agentes (isto será feito nas próximas versões).

2.4. Troca de Mensagens entre Agentes

As mensagens que são trocadas entre os agentes são chamadas de Semantic

Messages. A definição de uma Semantic Message está presente na classe Java SemanticMessage (pacote semanticore.domain.model). Ela possui um conjunto de atributos para auxiliar o desenvolvedor na construção de uma mensagem.

O SemantiCore permite três tipos de endereçamento de mensagens:

1. Unicast a. Mensagem é endereçada diretamente a um agente

i. O campo from deve conter o nome do agente destino da mensagem ii. Exemplo:

new SemanticMessage("Origem", "Agente_b", "Hello");

2. Multicast a. Mensagem é endereçada a um grupo de agentes

i. O campo from deve conter um array com os nomes dos agentes destino da mensagem

ii. Exemplo: String [] destinos = { "Agente_a", "Agente_b" };

new SemanticMessage("Origem", destinos, "Hello");

3. Broadcast a. Mensagem é enviada para todos os agentes do domínio

i. Campo from contém o caractere “*” sinalizando broadcast ii. Exemplo

new SemanticMessage ( "Origem", "*", "Hello" );

3. Exemplo Geral de Uso de Agentes no SemantiCore

3.1. Criando e Configurando um Agente Para criar um agente é necessário desenvolver uma classe que estende a classe SemanticAgent (pacote semanticore.domain.model).

Exemplo:

public class MyAgent extends SemanticAgent

{

public MyAgent(Environment env, String agentName, String arg) {

super(env, agentName, arg);

}

@Override

protected void setup()

{

}

}

O construtor default e o método setup são necessários para uma correta compilação

do código. O método setup deve conter todo o código de inicialização para um certo agente. Este método será invocado automaticamente após a plataforma inicializar o agente. Por definição, um agente contêm os componentes básicos e os mecanismos default

especificados no arquivo de instanciação (semanticoreinstantiation.xml). Abaixo segue um exemplo de implementação do método setup: …

protected void setup ( )

{

// add a set of sensors to the Sensorial Component

addSensor ( new OwlSensor ( "OwlSensor" ) );

addSensor ( new StringSensor ( "StringSensor" ) );

addSensor ( new RDFSensor ( "RDFSensor" ) );

}

… Neste exemplo, é possível verificar que três tipos de sensores foram adicionados ao

agente: um sensor capaz de identificar padrões em OWL, um sensor que busca padrões em strings e um último sensor que compara estruturas em RDF para captação no ambiente.

3.2. Implementando o mecanismo do Componente Decisório A classe que implementa o mecanismo deve estender a classe GenericDecisionEngine, que implementa o mecanismo padrão do componente decisório, e deve sobrescrever o método compare. Esse método deve conter a implementação do mecanismo de tomada de decisão do agente, e seu retorno deve ser uma ação no formato da plataforma (classe Action) ou um objeto nulo indicando que nenhuma operação será realizada.

A figura 7 contém um exemplo da implementação de um mecanismo decisório:

Figura 7: Exemplo de implementação (mecanismo decisório).

Neste caso, a tomada de decisão está sendo feita usando-se um simples comando IF para decidir qual mensagem jogar na tela. Nenhuma ação está sendo indicada para execução. Neste ponto é possível instanciar máquinas de inferências para serem usadas como base para a tomada de decisão. Isso pode ser feito colocando-se a invocação da máquina de inferência no método compare e passando-se o objeto information como fatos básicos sobre os quais a inferência deve ser realizada.

3.3. Criando Planos de Ação e Ações Um plano de ação está associado ao alcance de um certo objetivo do agente e suas ações contêm o código que será executado em busca deste objetivo. Como exemplo de implementação de uma ação, tem-se:

public class SayHi extends Action

{

public SayHi(){

super("ActionSayHi", null, null);

}

@Override

public void exec() {

System.out.println("Hi you all!");

}

}

Uma ação no SemantiCore possui duas formas de inicialização. A primeira possui em seu construtor dois parâmetros, sendo respectivamente o nome da ação e o seu descritor. O descritor indica o modo como a ação será interpretada pelo componente executor.

Os dois principais tipos de descritor são o “EXEC_PLAN” e o “EXEC_ACTION”. Uma ação que contém o tipo “EXEC_PLAN” em seu descritor sinaliza ao componente

executor que ele deve executar um determinado plano que está instalado em sua base de planos. Este plano é referenciado pelo seu nome, e esse nome é armazenado no atributo parameter da ação. O SemantiCore já possui uma ação da plataforma que abstrai esse primeiro tipo de operação, chamada ExecuteProcessAction. Esta ação recebe como parâmetro o nome do plano de ação que deve ser executado.

O segundo tipo de inicialização da ação possui três atributos de entrada, sendo respectivamente: nome da ação, um fato pré-condição e um fato como pós-condição. Um fato segue o modelo de fatos do SemantiCore, definido na classe Fact. A classe Fact

representa os recursos (qualquer entidade especificada em uma ontologia). A classe Fact possui três especializações: SimpleFact, FunctionBasedFact e

ComposedFact. Nos fatos simples, há três datatype properties2 (propriedades do tipo de

dados) denominadas subject, predicate e object. Essas propriedades representam a tripla (sujeito, predicado, objeto), que é o elemento básico de um modelo RDF3. Os fatos baseados em função representam os fatos que dependem de uma avaliação de outros fatos para serem gerados. Esses fatos são usados, principalmente, nas regras de inferência. Com eles, pode-se verificar, por exemplo, se A e B, ambos recursos RDF e literais do tipo inteiro, são diferentes (“notEqual (A, B)”) ou se B é menor que A (“lessThan (B, A)”). Fatos baseados em função possuem nome (name) e argumentos (args). Já os fatos compostos são formados por fatos simples, compostos ou baseados em função ligados por um operador lógico.

Exemplos de definição de ações em diferentes formatos:

• Ações com pré e pós-condições: ...

public SayHi ( String actionName, Fact preCondition, Fact postCondition )

{

super ( actionName, preCondition, postCondition );

}

...

new SayHi ( "SayHi", new SimpleFact ( "subject", "predicate", "object"), null );

new SayHi ( "SayHi", null, null );

....

• Ações com descritores: public SayHi(String name, String descriptor)

{

super(name, descriptor);

} … new SayHi ( "SayHi", SCOnt.EXE_ACTION );

new SayHi ( "SayHi", SCOnt.EXE_PLAN ); ...

2 Datatype properties ou propriedades de tipo de dados relacionam um indivíduo com um valor

XML Schema Datatype (string, integer, entre outros) ou com um literal RDF. 3 W3C (2006b) “RDF - Resource Description Framework”. Capturado em:

<http://www.w3.org/RDF/>. Junho de 2006.

Associando o plano de ação ao agente: … protected void setup ( )

{

ActionPlan plan = addActionPlan ( "PlanHi" );

plan.addAction ( new SayHi ( ) );

}

…

O método addActionPlan gera uma instância de um ActionPlan e instala esse plano no componente executor. Já o método addAction adiciona uma ação no plano de ação. Dúvidas sobre como desenvolver aplicações com o SemantiCore podem ser esclarecidas através da sua lista de desenvolvimento acessível em http://semanticore.pucrs.br.