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

Transcrição

1 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 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

2 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, infraestrutura 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.

3 - É 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. AGENTE sensor de entrada ação de saída AMBIENTE Figura 1 Um agente atuando no ambiente

4 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.

5 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):

6 - 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.

7 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

8 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

9 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

10 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.

11 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 pontoa-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.

12 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-aponto, 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.

13 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

14 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

15 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 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, 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 pp BERNERS-LEE, T.; HENDLER, J.; LASSILA, O. The semantic web. ScientificAmerican, v.1, n.29, p , 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 Anais CASTRO, J., KOLP, M., MYLOPOULOS, J. Towards Requirement-Driven Information Systems Engineering: The Tropos Project. Information Systems, n. 27, p , DELOACH, S.A. Multiagent Systems Engineering. International Journal of Software and Knowledge Engineering, v. 11, n. 3, p , FERBER, J. Multi-agent systems: an introduction to distributed artificial intelligence. Oxford: Addison-Wesley, p. 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 , JADE, Java Agent Development Framework. Desenvolvido por TILAB. Disponível em: < Acesso em: 7 nov 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 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 , p KENDALL, E. A.; MALKOUN, A. T., JIANG, C. H. The Application of Object oriented Analysis to Agent Based Systems. In: EUROPEAN WORKSHOP ON MODELLING

16 AUTONOMOUS AGENTS IN MULTI-AGENT WORLD, 9, 1999, Valência, Espanha. Anais 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, p. MADKIT, The Project. Desenvolvido por The MadKit Team. Disponível em: < Acesso em: 7 nov ODELL, J.; BOCK, C. Suggested UML Extensions for Agents. Desenvolvido por IntelliCorp, Inc. Disponível em: < >. Acesso em: 07 nov OPENCYBELE Agent Infrastructure. Desenvolvido por Intelligent Automation Incorporated. Disponível em: < Acesso em: 7 nov 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 RESOURCE DESCRIPTION FRAMEWORK (RDF). Coordenação de Eric Miller; Ralph Swick; Dan Brickley. Desenvolvido pela World Wide Web Consortium, Disponível em < Acesso em 7 nov WEB ONTOLOGY LANGUAGE (OWL). Coordenação de Eric Miller; Jim Hendler. Desenvolvido pela World Wide Web Consortium, Disponível em < Acesso em 7 nov WEISS, G. Multiagent systems: a modern approach to distributed artificial intelligence. Massachussests: The MIT Press, p. WINIKOFF, M., PADGHAM, L. Prometheus: A Methodology for Developing Intelligent Agents (2002). In: Third International Workshop on Agent-Oriented Software Engineering AAMAS. Anais 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 WOOLDRIDGE, M.; JENNINGS, N. Intelligent agents: theory and practice. Knowledge Engineering Review, v.10, n.2, p , WOOLDRIDGE, M.; JENNINGS, N. R.; KINNY, D. The Gaia methodology for agentoriented analysis and design. Journal of Autonomous Agents and Multi-Agent Systems, v.3, n.3, p , 2000.

17 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

18 Anexo SEMANTICORE MANUAL DO PROGRAMADOR Última atualização: 28 de março de SemantiCore 2006

19 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 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,

20 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.