JADECLIPSE - PLUGIN PRA INTEGRAÇÃO ENTRE JADE E ECLIPSE

UNIVERSIDADE FEDERAL DO MARANHÃO CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA

CURSO DE CIÊNCIA DA COMPUTAÇÃO

DANIEL LOPES SOARES LIMA

JADECLIPSE – PLUG-IN PARA INTEGRAÇÃO ENTRE JADE E ECLIPSE: Desenvolvimento e Implementação

São Luís 2004



Monografia apresentada ao Curso de Ciência da Computação da UFMA, como parte dos requisitos para a obtenção do título de Bacharel em Ciência da Computação. Orientador: Prof. MSc. João Carlos Pinheiro

São Luís 2004



Monografia apresentada ao Curso de Ciência da Computação da UFMA, como parte dos requisitos para a obtenção do título de Bacharel em Ciência da Computação.

Aprovada em / /

BANCA EXAMINADORA

_________________________________________ João Carlos Pinheiro (Orientador)

Mestre em Ciência da Computação CEFET

_________________________________________ Mário Antônio Meireles Teixeira

Doutor em Ciência da Computação UFMA

_________________________________________ Maria Auxiliadora Freire

Mestre em Ciência de Engenharia UFMA

São Luís 2004

Ao meu amado irmão Oscar Filho (in memoriam).

AGRADECIMENTOS

Aos meus pais, Oscar e Teresinha, e aos meus irmãos, Ivaldo, Adriana,

Rui e Luciana, pelo apoio e incentivo em todos os sentidos e que, mesmo com a

distância, sempre estiveram ao meu lado oferecendo todas as condições possíveis

para que eu conseguisse meus objetivos.

A Lélia, uma dessas pessoas que de repente surgem em nossas vidas e,

sem a menor cerimônia, tornam-se parte daquilo que mais amamos, um grande

beijo.

A João Carlos, pela confiança e ajuda para a realização desse trabalho.

Ao professor Sofiane Labidi, pelas oportunidades e conhecimentos

adquiridos.

Aos companheiros de birita, André, Carlos Eduardo, David, Robertson e

Valdeci, pelos momentos de descontração e alegria, principalmente em noites de

jogo e calouradas.

Aos amigos do Laboratório de Sistemas Inteligentes, Antônio Luna,

Bysmarck e Delano, pelas inúmeras conversas produtivas, e pelas improdutivas

também.

Aos demais colegas de turma, Rafael, Ricardo, Stanley, Osvaldo,

Raimundo e Francislene, e a todos os colegas com quem tive a oportunidade de

estudar, pelos bons momentos que desfrutamos juntos, pela amizade e

companheirismo.

A todas as pessoas que me ajudaram direta ou indiretamente para a

realização deste trabalho.

“A principal ocupação de minha vida consiste em vivê-la o melhor possível.”

Michel de Montaigne

RESUMO

Sistemas multiagentes com seus conceitos de agentes inteligentes e autônomos

interagindo juntos com um objetivo comum têm despertado grande interesse tanto

na área acadêmica quanto industrial. Os avanços recentes nessa área de pesquisa

têm levado ao surgimento de muitas arquiteturas multiagentes e, com isso, uma

necessidade de simplificação e padronização desses novos conceitos visando

facilitar o desenvolvimento de sistemas inteligentes baseados em agentes. O

objetivo deste trabalho é mostrar a implementação do Jadeclipse Plug-in, módulo

responsável por integrar JADE com o Eclipse, formando um poderoso ambiente para

o desenvolvimento de aplicações orientadas a agentes.

Palavras-chave: Inteligência Artificial, Agentes Inteligentes, Sistemas Multiagentes,

JADE, Eclipse, Plug-in, Jadeclipse.

ABSTRACT

The concept of intelligent, autonomous and independent agents interacting each

other, called Multi-agent System (MAS) has gradually received great attention of the

academic and industrial area. The recent advances in this research area has

emerged divers MAS architectures aimed at facilitating the development of agent-

based intelligent systems. The objective of this work is to show the implementation of

the Jadeclipse Plug-in, responsible module for integrating JADE with the Eclipse,

forming a powerful environment for the development of agent applications.

Keywords: Artificial Intelligence, Intelligent Agents, Multiagent Systems, JADE,

Eclipse, Plug-in, Jadeclipse.

LISTA DE ILUSTRAÇÕES

Figura 2.1 – Visão parcial da tipologia de agentes....................................................26

Figura 2.2 – Comunicação direta entre agentes........................................................29

Figura 2.3 – Comunicação por sistema federado......................................................30

Figura 2.4 – Modelo de referência de gerenciamento de agentes ............................33

Figura 3.1 – Diagrama de estados do agente na Plataforma JADE. .........................50

Figura 3.2 – Estrutura básica de uma classe de agente em JADE ...........................52

Figura 3.3 – Estrutura básica de um agente que envia uma mensagem ..................53

Figura 3.4 – Estrutura básica de um comportamento................................................53

Figura 4.1 – Arquitetura do Eclipse ...........................................................................58

Figura 4.2 – Cenário típico de interconexões entre plug-ins. ....................................59

Figura 4.3 – Integração entre JFace, SWT e Workbench. ........................................64

Figura 5.1 – Trecho de código do arquivo de manifesto. ..........................................72

Figura 5.2 – Página de preferências do Jadeclipse...................................................76

Figura 5.3 – Menu do Eclipse contendo os wizards do Jadeclipse. ..........................78

Figura 5.4 – Criação de um novo projeto Jade..........................................................79

Figura 5.5 – Criação de um novo agente Jade..........................................................81

Figura 5.6 – Estrutura de um arquivo de modelo utilizado pelos templates. .............82

Figura 5.7 – ActionSets do Jadeclipse (barra de ferramentas e menu).....................83

LISTA DE ABREVIATURAS E SIGLAS

ACC – Agent Communication Channel

ACL – Agent Communication Language

AID – Agent Identifiers

AMS – Agent Management System

API – Application Program Interface

AWT – Abstract Window Toolkit

CORBA – Common Object Request Broker Architecture

CPL – Common Plublic Licence

CVS – Concurrent Versioning System

DF – Directory Facilitor

DPS – Distributed Problem Solving

FIPA – Foundation for Intelligent Physical Agents

GUI – Grafic User Interface

GUID – Globally Unique Identifier

HTTP – Hypertext Transfer Protocol

IA – Inteligência Artificial

IAD – Inteligência Artificial Distribuída

IDE – Integrated Development Environment

IIOP – Internet Inter-ORB Protocol

IPMT – Internal Platform Message Transport

JADE – Java Agent Development framework

JAR – Java Archive

JDT – Java Development Tool

JNI – Java Native Interface

JRE – Java Runtime Environment

JSP – Java Server Pages

JVM – Java Virtual Machine

LGPL – Lesser General Public License

MAS – Multi-Agent System

MaSE – Multi-Agent Systems Engineering

MTP – Message Transport Protocol

PAI – Parallel Artificial Inteligence

PDE – Plug-in Development Environment

RMA – Remote Monitoring Agent

RMI – Remote Method Invocation

RPC – Remote Procedure Call

SDK – Software Development Kit

SMA – Sistemas Multiagentes

SMTP – Simple Mail Transfer Protocol

SWT – Standard Widget Toolkit

UML – Unified Modeling Language

WWW – World Wide Web

XML – Extensible Markup Language

SUMÁRIO

1 INTRODUÇÃO .......................................................................................................14

1.1 Contexto.............................................................................................................14

1.2 Motivação...........................................................................................................14

1.3 Objetivos ............................................................................................................15

1.4 Estrutura ............................................................................................................16

2 SISTEMAS MULTIAGENTES................................................................................18

2.1 Agentes ..............................................................................................................19

2.1.1 Características dos Agentes.............................................................................21

2.1.2 Categorias de Agentes .....................................................................................23

2.1.3 Arquiteturas de Agentes ...................................................................................24

2.1.4 Tipos de Agentes .............................................................................................25

2.2 Sistemas Multiagentes......................................................................................27

2.2.1 Comunicação entre Agentes ............................................................................28

2.2.2 Coordenação entre Agentes.............................................................................31

2.3 FIPA ....................................................................................................................32

2.3.1 Gerenciamento de Agentes..............................................................................32

2.3.2 Linguagem de Comunicação de Agentes.........................................................35

2.4 Ferramentas para Desenvolvimento de Sistemas Multiagentes ...................36

2.4.1 AgentTool .........................................................................................................37

2.4.2 ZEUS................................................................................................................37

2.4.3 JADE ................................................................................................................38

2.5 Considerações Finais .......................................................................................39

3 JADE......................................................................................................................40

3.1 Características de JADE ...................................................................................42

3.2 A Plataforma de Agentes ..................................................................................44

3.3 Ferramentas de Gerenciamento e Depuração ................................................45

3.3.1 Remote Monitoring Agent.................................................................................45

3.3.2 DummyAgent....................................................................................................46

3.3.3 Introspector Agent ............................................................................................46

3.3.4 Sniffer Agent.....................................................................................................46

3.3.5 DF GUI .............................................................................................................47

3.4 O Agente na Plataforma JADE .........................................................................47

3.5 Comunicação entre Agentes em JADE ...........................................................50

3.6 Estrutura de um programa em JADE...............................................................51

3.6.1 Agente ..............................................................................................................51

3.6.2 Mensagens.......................................................................................................52

3.6.3 Comportamentos..............................................................................................53


4 ECLIPSE ................................................................................................................54

4.1 Arquitetura do Eclipse ......................................................................................57

4.1.1 O Ambiente de Execução e Arquitetura dos Plug-ins.......................................58

4.1.2 Workspace .......................................................................................................59

4.1.3 Workbench e Bibliotecas de Interface ..............................................................60

4.1.3.1 Standard Widget Toolkit – SWT ....................................................................61

4.1.3.2 JFace.............................................................................................................63

4.1.4 Team ................................................................................................................64

4.1.5 Help ..................................................................................................................66

4.2 Eclipse SDK .......................................................................................................66

4.2.1 JDT...................................................................................................................67

4.2.2 PDE..................................................................................................................67

4.2.3 Debugger..........................................................................................................68

4.2.4 JUnit .................................................................................................................68

4.2.5 Outros Plug-ins.................................................................................................69


5 JADECLIPSE PLUG-IN .........................................................................................69

5.1 Conceitos de programação para plug-ins.......................................................71

5.1.1 Anatomia de um plug-in....................................................................................71

5.1.2 Pontos de Extensão .........................................................................................73

5.2 Arquitetura do Jadeclipse ................................................................................75

5.2.1 PreferencePage ...............................................................................................75

5.2.2 Nature...............................................................................................................77

5.2.3 Wizards ............................................................................................................77

5.2.3.1 Jade Project ..................................................................................................78

5.2.3.2 Jade Agent ....................................................................................................80

5.2.4 ActionSets ........................................................................................................82


6 CONCLUSÃO ........................................................................................................84

REFERÊNCIAS.........................................................................................................86

1 INTRODUÇÃO

1.1 Contexto

A tecnologia de agentes tem adquirido nos últimos anos uma importância

cada vez maior em muitos aspectos da computação, principalmente na área de

Inteligência Artificial Distribuída. O conceito de autonomia e de aplicações capazes

de executar tarefas de forma inteligente e independente tem despertado grandes

interesses da comunidade científica. Interações entre agentes, que trabalham juntos

para um objetivo único e maior vem reforçando e amadurecendo o conceito de

sistemas multiagentes.

Estudos e pesquisas sobre sistemas multiagentes dentro do campo da

Inteligência Artificial Distribuída começaram a cerca de 20 anos atrás. Atualmente

esses sistemas não são mais apenas tópicos de pesquisa, mas já estão se tornando

um importante assunto na área de ensino acadêmico e em aplicações comerciais e

industriais. Como conseqüência disso, várias metodologias, arquiteturas e

ferramentas já foram desenvolvidas para facilitar o desenvolvimento de sistemas

multiagentes.

1.2 Motivação

Com o crescente uso de ferramentas de desenvolvimento de sistemas

multiagentes é extremamente necessário que estas ferramentas possuam

mecanismos para que os sistemas escritos através delas possam se comunicar com

15

outras comunidades de agentes, possibilitando que as sociedades evoluam através

da troca de informações. JADE vem de encontro a esse objetivo, pois atende

completamente às especificações propostas por FIPA1. Entretanto possui algumas

limitações em referência ao desenvolvimento do código do agente, pois não possui

um ambiente apropriado para a edição de código fonte. Nesse ponto é que entra o

Eclipse como um ambiente poderoso para edição de código fonte e que através de

sua característica de adaptar-se a novas ferramentas através de plug-ins, resolve o

problema de JADE através do Jadeclipse Plug-in, tema proposto neste trabalho.

1.3 Objetivos

O principal objetivo deste trabalho é mostrar a implementação do

Jadeclipse Plug-in e as facilidades que ele oferece ao usuário final. Porém, podem-

se identificar diversos outros pontos de grande importância ao longo deste trabalho,

tais como:

• Apresentar toda a teoria sobre agentes e sistemas multiagentes, em

especial sua conceituação e caracterização, bem como também os

padrões que garantem a interoperabilidade entre sociedades de

agentes.

• Apresentar os conceitos propostos por FIPA e uma ferramenta que se

adapte perfeitamente a esses conceitos, acrescentando algumas

funcionalidades a mais ao desenvolvedor, que é o que JADE

proporciona.

1 Foundation for Intelligent Physical Agents: órgão responsável por definir os padrões para interoperabilidade de agentes heterogêneos em sistemas multiagentes.

16

• Apresentar ao usuário o Eclipse, que é um ambiente de

desenvolvimento bastante robusto e adaptável, em especial as

tecnologias que o compõem e os conceitos de adaptabilidade que a

plataforma oferece.

1.4 Estrutura

A estrutura deste trabalho encontra-se dividida de forma que podem ser

distinguidos dois módulos principais. O primeiro módulo compreende os capítulos

onde são apresentadas as teorias sobre sistemas multiagentes e ferramentas

utilizadas para a geração do sistema. O segundo módulo compreende os capítulos

onde são apresentados os conceitos para o desenvolvimento de plug-ins do Eclipse

e a própria implementação da ferramenta em si.

No Capítulo 2 serão apresentados conceitos e características de agentes

e sistemas multiagentes, bem como mecanismos de comunicação e coordenação.

Serão apresentados também os conceitos propostos por FIPA para a padronização

de sistemas multiagentes.

No Capítulo 3 será apresentada uma visão geral sobre a ferramenta de

desenvolvimento de sistemas multiagentes JADE, mostrando suas características,

ferramentas de suporte, assim como o seu modelo de implementação da plataforma,

atendendo aos padrões FIPA.

No Capítulo 4 será apresentada a ferramenta Eclipse. Em especial sua

arquitetura e principais características, bem como uma breve introdução ao

desenvolvimento de plug-ins.

17

No Capítulo 5 refere-se à implementação do Jadeclipse, mostrando sua

estrutura, assim como suas principais funcionalidades, classes e contribuições à

plataforma Eclipse.

No Capítulo 6 são apresentadas as considerações finais, e algumas

sugestões de trabalhos futuros de melhoria ao Jadeclipse.

18

2 SISTEMAS MULTIAGENTES

O ideal buscado pela Inteligência Artificial (IA), no início dos anos 50, foi o

desenvolvimento de um sistema que se adaptasse às necessidades de seus

usuários, trazendo comodidade e parecendo tão igual, quanto possível, ao seu

pensamento e as suas atitudes. A idéia era de que máquinas realizassem tarefas

que antes eram executadas somente por pessoas. Com o passar do tempo, surgiu a

necessidade de distribuir os sistemas de IA, para que os mesmos pudessem utilizar

as facilidades de sistemas distribuídos. Com a união das idéias de IA e sistemas

distribuídos, no início da década de 70, surgiu a Inteligência Artificial Distribuída

(IAD), que procura resolver os problemas de modo cooperativo e onde o foco está

na integração de agentes, os quais cooperam entre si a fim de alcançar um objetivo

comum.

Um dos ramos da IAD são os Sistemas Multiagentes (SMA), que tem

como foco os agentes, tendo como objeto de estudo agentes autônomos em um

universo multiagente, ou seja, cada agente possui sua própria existência,

independente dos outros. O projeto de um agente deve resultar numa entidade

capaz de realizar um determinado processamento e não numa entidade capaz de

realizar este processamento exclusivamente no contexto de uma aplicação

particular. Os agentes devem cooperar quando for proposto um problema específico

ao sistema (ALVARES, 1997).

19

2.1 Agentes

O termo agente de software, ou simplesmente agente, é utilizado em

muitos contextos com significados nem sempre idênticos. Ainda não há entre os

pesquisadores um consenso formal sobre a definição de agentes, mas as diferentes

conceituações possuem traços em comum que serão discutidos adiante. Assim,

torna-se mais produtivo estudar agentes analisando as diferentes conceituações,

para delas extrair o conhecimento essencial para a assimilação de alguns de seus

conceitos aplicáveis a este trabalho. Seguem-se algumas delas.

A FIPA (2001) define agente como uma entidade que reside em um

ambiente onde interpreta dados através de sensores que refletem eventos no

ambiente e executam ações que produzem efeitos no ambiente. Um agente pode

ser software ou hardware puro.

Alguns pesquisadores, como Wooldridge e Jennings (1995), adotaram

duas definições gerais: noção fraca e noção forte de agentes. Na definição ou noção

fraca de agentes, eles conceituam como sistemas computacionais, sendo hardware

ou software, com certas propriedades tais como autonomia, habilidade social,

reatividade e pró-atividade. Na noção forte de agentes, mais adotada pelos

pesquisadores ligados a área de Inteligência Artificial, possui, além das propriedades

acima citadas, noções relacionadas ao comportamento humano tais como o

conhecimento, a crença, a intenção e a obrigação.

Para Ferber (1999), um agente pode ser uma entidade física ou virtual.

Física seria alguma coisa concreta e que atue no mundo real, virtual seriam

justamente entidades abstratas tais como componentes de softwares.

20

Segundo Russel e Norvig (1995), um agente é tudo aquilo que percebe

seu ambiente através de sensores (sensors) que por sua vez alimentam

mecanismos internos reagindo por intermédio de seus atuadores (effectors) de forma

autônoma.

Russel e Norvig (1995) também definem o conceito de um agente ideal:

“Para cada seqüência possível de percepção, um agente racional ideal deverá fazer

toda ação esperada para maximizar sua medida de desempenho com base nas

evidências providas pela percepção e toda a base de conhecimentos construída e

adquirida pelo próprio agente”.

Algumas comparações entre objetos e agentes são inevitáveis, porém,

apesar de existir semelhanças, as diferenças são muito mais evidentes. Diferenças,

segundo Weiss (1999), são o fato de agentes terem uma noção mais forte de

autonomia em relação aos objetos, serem capazes de um comportamento flexível e

pela característica de um sistema multiagente ser inerentemente multithread2.

Segundo Santos (2002), um agente é uma entidade cognitiva, ativa e

autônoma, ou seja, que possui um sistema interno de tomada de decisões, agindo

sobre o mundo e os demais agentes que o rodeiam, e, por fim, que é capaz de

funcionar sem necessitar de algo ou de alguém para guiar.

Para Barreto (2001), agentes autônomos de software são programas

dotados de inteligência e que agem como um parceiro melhorando a eficiência do

trabalho do ser humano.

Diante das diferentes visões acerca do apresentado, é útil reunir e inferir

alguns conceitos que serão aplicados neste trabalho:

2 Múltiplas linhas de execução executando concorrentemente em um processo.

21

• Agentes são entidades autônomas, que possuem mecanismos próprios

para seu acionamento e funcionamento, agindo e reagindo com o

ambiente ao qual está inserido.

• Os agentes possuem uma base de conhecimentos e capacidade de

inferência para que possam atuar dado determinado(s) objetivo(s).

• Os agentes executam uma ou mais ações para as quais define o

motivo de sua própria existência.

• O agente possui um comportamento inteligente pela sua capacidade

de aprendizado e auto-aprendizado por conseqüência da interação

com o ambiente e também refinando sua base de conhecimentos

quando da descoberta de novas informações.

2.1.1 Características dos Agentes

Basicamente, o que diferencia uma definição da outra são as propriedades

que caracterizam cada agente. As propriedades e sua intensidade caracterizam o

comportamento do agente dentro de uma sociedade. Como qualidades

consideradas desejáveis em um agente de software, podem-se citar:

• Autonomia: um agente é capaz de tomar iniciativa e exercer um grau

de controle sobre suas próprias ações;

• Flexibilidade: as ações de um agente não seguem um roteiro, estes

são capazes de realizar escolhas dinâmicas de quais ações realizar e

em qual seqüência, em resposta a uma mudança do ambiente externo.

(NWANA, 1996);

22

• Inicialização própria: um agente pode perceber modificações em seu

ambiente e decidir quando atuar, o que o difere dos programas

padrões que são diretamente disparados pelos usuários;

• Comunicação: um agente é capaz de comunicar-se com outros

agentes, incluindo pessoas, com o intuito de obter informações ou

conseguir ajuda para cumprir seus objetivos;

• Inferência social: um agente deve ser capaz de inferir sobre as

atividades de outros agentes. (NWANA, 1996);

• Inteligência: um agente é capaz de raciocinar e aprender a partir das

interações com outros agentes, com seus usuários e com o ambiente,

podendo ser dotado de diferentes níveis de inteligência;

• Mobilidade: um agente móvel é aquele que é capaz de se transportar

de uma máquina para outra durante sua execução. (NWANA, 1996);

• Continuidade temporal: um agente é um processo que está em

execução continuamente, não como um instante computacional que

mapeia uma única entrada para uma única saída e termina.

(WOOLDRIDGE; JENNINGS, 1995);

• Pró-atividade: um agente não apenas reage a um estímulo, mas pode

tomar iniciativas que visem a alcançar seu objetivo;

• Benevolência: em um sistema que apresente vários agentes

interagindo para realizar as tarefas para as quais foram projetados,

estes podem apresentar objetivos coletivos ou individuais, que podem

variar de acordo com o agente. Porém, um agente não pode realizar

serviços que o coloquem em conflito com seus próprios objetivos.

(NWANA, 1996).

23

2.1.2 Categorias de Agentes

Segundo Álvares e Sichman (1997), os agentes de software podem ser

divididos em duas categorias: agentes cognitivos e reativos.

Agentes cognitivos são baseados em modelos organizacionais humanos.

Esse tipo de agente mantém a representação explícita de seu ambiente e dos outros

agentes, e um histórico das interações e ações passadas. A comunicação feita entre

agentes é realizada através do envio e recebimento de mensagens. Seu

comportamento é pró-ativo e seu modelo organizacional é parecido com o dos

humanos. Sua sociedade não possui muitos agentes.

Na abordagem reativa os agentes não necessitam ser inteligentes para

executarem suas tarefas. O objetivo é que cada agente execute uma tarefa simples,

mas a cooperação desses agentes fará com que possam executar tarefas

complexas. Exemplo clássico dessa abordagem é a colônia de formigas. O trabalho

de uma formiga não é inteligente, mas o da colônia de formigas é bem complexo.

Esses agentes não mantêm representação explícita de seu ambiente ou de seu

conhecimento. As informações referentes ao seu comportamento estão no ambiente

e suas reações dependem da percepção deste ambiente. Cada agente tem seu

objetivo e não há memória das suas ações. O modelo organizacional desse tipo de

agente é parecido com a dos animais e sua sociedade possui muitos agentes. O

trabalho em grupo é imprescindível para esse tipo de agente, pois isoladamente não

seriam capazes de realizar tarefas de tamanha complexidade.

24

2.1.3 Arquiteturas de Agentes

Russel e Norvig (1995) apresentam uma classificação para as arquiteturas

de agentes: agente reativo simples, agente reativo com estado, agente baseado em

objetivos e agentes baseado em utilidades. Estas arquiteturas definem a forma com

a qual o agente irá interagir com o seu ambiente, tendo cada uma particularidades

que influenciarão diretamente na maneira da implementação do mesmo.

Agente reativo simples: este tipo de arquitetura contempla o modo mais

simplificado para o funcionamento de um agente: encontrar uma regra que

corresponda à situação atual e executar uma ação a ela associada, também

conhecida como condição-ação que trata por realizar uma conexão entre a

percepção e a ação.

Agente reativo com estado: em determinados casos, a ação não pode

ser definida exclusivamente pelas percepções recebidas pelo fato de que nem

sempre os sensores podem prover acesso completo aos estados do mundo. Nestas

situações um agente baseado em estados pode ser aplicado. Esta arquitetura

redefine os agentes reativos incluindo agora um estado interno que é utilizado no

processo de tomada de decisão e pode ser atualizado a partir das percepções e

reações.

Agente baseado em objetivos: quando uma seqüência de passos é

necessária para se atingir a solução de um problema, os agentes reativos e de

estado não são suficientes. Desta maneira a implementação de agentes baseados

em objetivos permite que sejam especificadas quais as ações a serem tomadas em

função dos objetivos propostos, em outras palavras, representam o conhecimento na

forma como o mundo pode ser transformado pela execução de suas ações.

25

Agente baseado em utilidades: a definição das ações em função de

objetivos nem sempre pode resultar em sucesso. A definição então do grau de

certeza de sucesso frente aos objetivos pode então ser modelado através deste tipo

de arquitetura. Agentes baseados em utilidades provêem um grau de distinção entre

estados “felizes” e “infelizes”. Podem existir problemas onde os objetivos sejam

conflitantes (e.g: velocidade x segurança) ou ainda a possibilidade de existirem

muitos objetivos que o agente pretende atingir, mas nenhum que se possa alcançar

com certeza. Nestes casos uma definição de utilidade fornece um caminho no qual a

probabilidade de sucesso possa ser pesada em relação à importância dos objetivos.

2.1.4 Tipos de Agentes

Para Nwana (1996), os agentes podem ser categorizados em função da

ênfase dada a alguns de seus atributos primários (cooperação, aprendizado e

autonomia). De forma geral, Nwana (1996) propõe a seguinte classificação para

agentes:

• Agentes colaborativos: dão ênfase para a autonomia e cooperação

com outros agentes a fim de executarem tarefas a eles delegadas.

Algumas características que os denotam são habilidade social,

autonomia, pró-atividade, benevolência ou até mesmo a combinação

entre elas.

• Agentes de interface: enfatizam a autonomia e o aprendizado para

executarem as tarefas de seus “donos”. Neste caso distingue-se de

agente colaborativo, pois aqui a colaboração se dá com o usuário e

26

não com outros agentes. Este tipo de agente interage com o usuário

recebendo especificações e devolvendo resultados.

• Agentes móveis: possuem a capacidade de se movimentar por uma

rede de computadores, como a World Wide Web (WWW), interagindo

com outros servidores e agentes, coletando e reunindo informações

que são retornadas, tendo executado as tarefas configuradas pelo(s)

seu(s) usuário(s).

• Agentes de informação: executam a tarefa de gerenciar, manipular e

reunir informações de diversas fontes distribuídas.

• Agentes reativos: não possuem um modelo simbólico interno de seu

ambiente, mas sim atuam através de estímulos e respostas dadas em

função do estado presente do seu ambiente, normalmente solicitadas

pelo usuário.

• Agentes híbridos: é a combinação de duas ou mais filosofias de

agentes (mobilidade, interface, colaboração, etc.)

O que, portanto, define a tipologia de agentes, é o grau de inter-relação

entre as características de cooperação, aprendizagem e autonomia, conforme

representado na figura a seguir:

Figura 2.1 – Visão parcial da tipologia de agentes

27

2.2 Sistemas Multiagentes

Dentro do contexto da Inteligência Artificial Distribuída, Torsun (1995)

classifica-a em Distributed Problem Solving (DPS), Multi-Agent Systems (MAS) e

Parallel Artificial Inteligence (PAI). DPS ou Resolução Distribuída de Problemas

decompõe o problema em módulos através de uma abordagem descendente (top-

down) desenhado especificamente para um problema em particular, onde grande

parte do raciocínio sobre a solução é inserida pelo próprio projetista. PAI ou

Inteligência Artificial Paralela interessa-se mais por desempenho do que por avanços

conceituais, preocupando-se principalmente em desenvolver linguagens e algoritmos

de computação paralela. Por último, MAS ou Sistemas Multiagentes, caracteriza-se

pela existência de agentes que interajam de forma autônoma que trabalhem juntos

para resolver um determinado problema ou objetivo.

Em suma, pode-se dizer que Sistemas Multiagentes são sistemas

constituídos de múltiplos agentes que interagem ou trabalham em conjunto de forma

a realizar um determinado conjunto de tarefas ou objetivos. Esses objetivos podem

ser comuns a todos os agentes ou não. Os agentes dentro de um sistema

multiagente podem ser heterogêneos ou homogêneos, colaborativos ou

competitivos, etc. Ou seja, a definição dos tipos de agentes depende da finalidade

da aplicação que o sistema multiagente está inserido.

Os sistemas multiagentes com agentes reativos são constituídos por um

grande número de agentes. A inteligência surge da interação entre o grande número

de agentes e o ambiente, ou seja, os agentes não são inteligentes individualmente,

mas o comportamento global é.

28

Já os sistemas multiagentes constituídos por agentes cognitivos são

geralmente compostos por uma quantidade bem menor de agentes se comparado

aos sistemas multiagentes reativos. Estes, conforme a definição de agentes

cognitivos, são inteligentes e contêm uma representação parcial de seu ambiente e

dos outros agentes. Podem, portanto, comunicar-se entre si, negociar uma

informação ou um serviço e planejar uma ação futura.

Esse planejamento de ações é possível, pois em geral os agentes

cognitivos são dotados de conhecimentos, competências, intenções e crenças, o

que lhes permite coordenar suas ações visando à resolução de um problema ou a

execução de um objetivo.

2.2.1 Comunicação entre Agentes

A comunicação é fundamental para permitir que haja colaboração,

negociação, cooperação e etc. entre entidades independentes. Em sistemas

multiagentes, é necessário que a comunicação seja disciplinada para que os

objetivos sejam alcançados efetiva e eficientemente, necessitando assim uma

linguagem que possa ser entendida pelos outros agentes presentes no ambiente.

Essa comunicação tem como principal objetivo à partilha do conhecimento com os

outros agentes e a coordenação de atividades entre agentes. Ou seja, ela deve

permitir que agentes troquem informações entre si e coordenem suas próprias

atividades resultando sempre em um sistema coerente.

Existem diversas maneiras para agentes trocarem informações uns com

os outros em sistemas multiagentes. Segundo Baker (1997), agentes podem trocar

mensagens diretamente, chamada também por alguns autores como comunicação

29

direta, podem comunicar-se através de um agente “facilitador” especial em sistema

“federado” (comunicação assistida), podem também utilizar uma comunicação por

difusão de mensagens (broadcast) e até utilizar o modelo de comunicação através

de blackboard ou quadro-negro.

Na comunicação direta, ou comunicação via troca de mensagens direta,

cada agente comunica-se diretamente com qualquer outro agente sem qualquer

intermediário. Na Figura 2.2 há um estabelecimento de uma ligação direta (ponto-a-

ponto) entres os agentes através de um conjunto de protocolos que garante a

chegada de mensagens com segurança. Nesse tipo de comunicação faz-se

necessário que cada agente envolvido tenha conhecimento da existência dos outros

agentes e da forma de como endereçar mensagens para eles. A principal vantagem

deste tipo de comunicação entre agentes é o fato de não existir um agente

coordenador da comunicação. Isso porque esses agentes coordenadores podem

levar a um “gargalo” ou até ao bloqueio do sistema caso haja, por exemplo, um

grande número de troca de mensagens. As principais desvantagens são o custo da

comunicação que se torna grande, principalmente quando há um grande número de

agentes no sistema, pois os agentes têm que se conhecer uns aos outros, e a

própria implementação que se torna muito complexa em comparação às outras

formas de comunicação.

Figura 2.2 – Comunicação direta entre agentes

30

Na comunicação por sistemas federados ou comunicação assistida, os

agentes utilizam algum sistema ou agente especial para coordenar suas atividades

(BAKER, 1997). Ou seja, uma estrutura hierárquica de agentes é definida e a troca

de mensagens dá-se através agentes especiais designados “facilitadores” ou

mediadores (Veja a Figura 2.3).

Essa é uma alternativa bem popular à comunicação direta, pois diminui

muito o custo e a complexidade necessária aos agentes individuais na realização da

comunicação. Geralmente é utilizado quando o número de agentes dentro do

sistema é muito grande.

Figura 2.3 – Comunicação por sistema federado

A comunicação por difusão de mensagens ou broadcast geralmente é

utilizada em situações onde a mensagem deve ser enviada para todos os agentes

do ambiente ou quando o agente remetente não conhece o agente destinatário ou

seu endereço. Em suma, todos os agentes recebem a mensagem enviada.

Comunicação por quadro-negro ou blackboard, segundo Baker (1997), é

bastante usada na Inteligência Artificial como modelo de memória compartilhada. Ou

seja, nada mais é que um repositório onde os agentes escrevem mensagens a

outros agentes e obtêm informações sobre o ambiente.

31

2.2.2 Coordenação entre Agentes

Weiss (1999) afirma que coordenação é uma característica fundamental

para um sistema de agentes que executam alguma atividade em um ambiente

compartilhado.

A coordenação está muito relacionada com o compartilhamento de

conhecimento entre os agentes, sendo, seu principal objetivo, tornar as ações

individuais de cada agente coordenadas para se atingir o objetivo final do sistema

multiagente. Além disso, há uma preocupação com a coerência de modo a se

discutir como o sistema multiagente por completo se comporta enquanto está

resolvendo o problema. O principal motivo para uma preocupação maior com a

coordenação entre agentes é o fato de que um só agente, dentro de um sistema

multiagente, não terá informação ou capacidade suficiente para resolver muitos dos

problemas - muitos dos objetivos não podem ser atingidos por agentes agindo

isoladamente.

Assim, coordenação seria a capacidade desses agentes trabalharem em

conjunto e combinar seus objetivos de forma a concluírem o objetivo final do

sistema. Geralmente para uma cooperação ser bem sucedida, cada agente deve

manter um “modelo” dos outros agentes e também desenvolver um modelo de

interações futuras ou possíveis. Ela pode ser dividida em cooperação e negociação.

Segundo Weiss (1999): “Negociação é a coordenação entre agentes

antagônicos ou simplesmente egoístas (self-interested)”. Ou seja, a negociação está

relacionada à coordenação de agentes competitivos. Geralmente são usados

protocolos de negociação para determinar as regras de negociação e são definidos

os conjuntos de atributos sobre os quais se pretende chegar a um acordo.

32

Cooperação, como afirma Weiss (1999), é a coordenação entre agentes

não antagônicos. Ou seja, uma coordenação com agentes que não possuem

objetivos conflitantes geralmente é chamada de cooperação. Neste caso, agentes

cooperativos auxiliam-se mutuamente nem que para isso provoquem custos

individuais. O papel da coordenação é agir de forma que o conjunto de agentes

realize suas tarefas como um “trabalho de equipe” visando sempre o objetivo final do

sistema.

2.3 FIPA

Foundation for Intelligent Physical Agents ou simplesmente FIPA, é uma

fundação sem fins lucrativos direcionada à produção de padrões para a

interoperabilidade de agentes heterogêneos e interativos e sistemas baseados em

agentes. Foi fundada em 1996 em Genebra. Sua missão básica é facilitar a

interligação de agentes e sistemas multiagentes entre múltiplos fornecedores de

ambientes, ou seja, permitir a interoperabilidade entre agentes autônomos.

As especificações apresentadas a seguir são a base para a utilização da

tecnologia de agentes determinada por FIPA e que são fortemente usadas por

JADE, como será visto no capítulo seguinte.

2.3.1 Gerenciamento de Agentes

As especificações do gerenciamento de agentes definem como registrar,

passar mensagens, o ciclo de vida e a plataforma para agentes. É necessário definir

33

uma ontologia3 de gerenciamento de agentes para facilitar a interoperabilidade entre

agentes que utilizam a plataforma FIPA.

Estas especificações mostram o conjunto lógico para o desenvolvimento

da plataforma de agentes, e não implicam na configuração física da plataforma de

agentes. Assim, uma mesma plataforma pode estar residente em vários

computadores. Desta maneira, a FIPA faz com que a distribuição da plataforma de

agentes permita a construção de ambientes abertos e heterogêneos de

implementação.

O modelo de referência para a plataforma de agentes pode ser visto

abaixo:

Figura 2.4 – Modelo de referência de gerenciamento de agentes (FIPA,2000)

Os componentes que formam o modelo de referência da plataforma de

agentes são (FIPA, 2000):

• Agente: é o principal elemento para uma plataforma de agentes. Ele

combina um ou mais serviços e integra o modelo de execução para

acesso de software externo, usuários e facilidades de comunicação.

3 Ontologia é uma definição de conceitos e relacionamentos entre objetos de vários domínios.

34

Ele suporta um enorme número de notações para identificação, a partir

de um GUID (Globally Unique Identifier), que é conhecido por todo o

domínio da FIPA e não possui ambigüidades para distingui-lo no

universo de agentes.

• Facilitador de Diretórios (Directory Facilitor – DF): oferece um serviço

de "páginas amarelas" para outros agentes, ou seja, através do DF

podem ser obtidas várias informações a respeito dos agentes que

compõem a plataforma de agentes, tais como que serviços

determinados agentes executam, que ontologias eles possuem, a

descrição dos agentes, etc. O DF é um agente normativo que serve de

intermediário para um diretório de agentes. A partir do DF pode-se

restringir informações sobre algum diretório desejado e verificar

permissões de acesso para agentes que queiram utilizar os serviços.

Um mesmo agente pode fazer parte de vários DFs.

• Sistema de Gerenciamento de Agentes (Agent Management System –

AMS): é um componente muito importante para uma plataforma de

agentes , pois ele supervisiona o controle e o acesso para o ACC

(Agent Communication Channel), que será explicado a seguir. O AMS

é responsável pelo gerenciamento de atividades na plataforma de

agentes.

• Canal de Comunicação de Agentes (Agent Communication Channel –

ACC): todos os agentes possuem acesso ao ACC, pois ele provê

acesso básico entre agentes, incluindo ao DF e ao AMS. Ele roteia

mensagens entre agentes que estejam na mesma ou em outras

plataformas. Apenas mensagens endereçadas pelo agente podem ser

35

mandadas via ACC. A FIPA possui o mínimo necessário de

especificações para interoperabilidade tendo como base o protocolo

IIOP (Internet Inter-ORB Protocol), que é o protocolo utilizado para

conexões TCP/IP nos domínios da Internet dentro do padrão CORBA4.

• Transporte de Mensagens no Interior da Plataforma (Internal Platform

Message Transport – IPMT): canal para troca de mensagens entre

agentes na plataforma.

• Software: todos os softwares são definidos como não agentes,

executando coleções de instruções de acesso para um domínio através

de um agente. Os acessos a agentes podem ser usados por softwares

de forma temporária ou permanente.

2.3.2 Linguagem de Comunicação de Agentes

Para que dois agentes se comuniquem utilizando troca de mensagens,

eles devem possuir o mesmo tipo de mecanismo de transporte. A linguagem de

comunicação de agentes, ou ACL (Agent Communication Language), foi

desenvolvida para que sistemas complexos de tecnologia de agentes possam

realizar a comunicação da melhor forma possível, em um alto nível de interação.

Estes mecanismos de comunicação não podem ser comparados com protocolos de

redes, como TCP/IP, pois estes realizam uma interação em baixo nível. Eles

4 CORBA é um middleware, uma camada de software intermediária, que permite a comunicação entre aplicações cliente e servidor heterogêneas. (SILBERSCHATZ, 2001)

36

também não representam uma alternativa para mecanismos como CORBA, Java

RMI5 ou RPC6.

O principal papel da linguagem ACL é tornar possível a interação entre

sistemas abertos de agentes. Outros mecanismos, principalmente CORBA, se

desvencilham um pouco deste objetivo, pois impõem certas restrições nas interfaces

propostas para os objetos. Normalmente, agentes e sistemas de agentes são

implementados para interagir com o maior número possível de mecanismos de

interface. Pode-se encontrar vários exemplos de agentes que utilizam sockets

TCP/IP, HTTP ou SMTP. Desta forma, ACL foi desenvolvida para respeitar esta

diversidade e busca padronizar o mínimo requerido para que as mensagens possam

ser compreendidas pelos agentes.

2.4 Ferramentas para Desenvolvimento de Sistemas Multiagentes

Os Sistemas Multiagentes têm evoluído e mostrado sinais claros de que

possuem um enorme potencial computacional. A aplicabilidade da tecnologia de

agentes vem crescendo rapidamente o que deixa margem para o surgimento de

ambientes multiagentes variados. Com o apoio de grandes corporações,

universidades e da comunidade de código livre, o surgimento de ferramentas para o

desenvolvimento de sistemas multiagentes vem crescendo. A seguir será

apresentada uma breve explanação sobre algumas ferramentas de sistemas

multiagentes. É importante salientar que todas as ferramentas citadas têm por

5 Java RMI: um recurso Java que permite que um thread invoque um método em um objeto remoto. 6 Remote Procedure Call: recurso semelhante ao Java RMI, que permite que um thread chame um procedimento ou função em um outro processo. (SILBERSCHATZ, 2001)

37

características básicas serem totalmente desenvolvidas em Java e terem código

aberto.

2.4.1 AgentTool

AgentTool é um ambiente de desenvolvimento gráfico para auxiliar o

desenvolvedor na análise, projeto e implementação de SMA. No AgentTool, o

desenvolvedor define graficamente o comportamento do sistema em alto nível

utilizando a metodologia MaSE7. Pode-se definir o tipo dos agentes do sistema bem

como as possíveis comunicações que os agentes podem desempenhar. Esta

especificação de alto nível é então refinada para cada tipo de agente. Para isso, o

desenvolvedor seleciona ou cria uma arquitetura para o agente e fornece a

especificação detalhada do comportamento para cada componente da arquitetura do

agente.

2.4.2 ZEUS

ZEUS é uma ferramenta para construção de aplicações multiagentes

colaborativos. ZEUS define o desenvolvimento e suporte de sistemas multiagentes

com um ambiente visual para capturar as especificações do usuário, que são usadas

para gerar código fonte em Java.

7 Multi-Agent Systems Engineering: Metodologia pra projeto e desenvolvimento de Sistemas Multiagentes.

38

Na modelagem ZEUS, o principal objetivo é facilitar o rápido

desenvolvimento de sistemas multiagentes pela abstração proporcionada pela

ferramenta através de princípios comuns e suporte proporcionado por alguns


2.4.3 JADE

JADE (Java Agent Development framework) é um ambiente para

desenvolvimento de aplicações baseada em agentes conforme as especificações da

FIPA para interoperabilidade entre sistemas multiagentes totalmente implementado

em Java. Possui um abrangente conjunto de agentes de serviços de sistema, os

quais tanto facilitam como possibilitam a comunicação entre agentes, de acordo com

as especificações da FIPA: serviço de nomes (naming service) e páginas amarelas

(yellow-page service), transporte de mensagens, serviços de codificação e

decodificação de mensagens.

As principais razões para a escolha de JADE como ferramenta de

desenvolvimento de agentes escolhida deste trabalho é que JADE abstrai ao

desenvolvedor a necessidade de preocupar-se com a implementação de uma

plataforma eficiente de agentes, bem como a comunicação, troca de mensagens e

muitos outros atributos que um sistema multiagente necessita. Além disso, oferece

uma gama de ferramentas de monitoração, gerenciamento e depuração que ajudam

tanto no desenvolvimento quanto na manutenção e suporte de sistemas

multiagentes. Vale ressaltar a grande preocupação que JADE tem de manter os

padrões especificados pela FIPA. Fato que aumenta o grau de interoperabilidade do

ambiente em relação às outros sistemas multiagentes.

39

2.5 Considerações Finais

Neste capítulo foi apresentada toda a teoria sobre agentes e sistemas

multiagentes. Em especial, a conceituação e caracterização de agentes e sistemas

multiagentes, bem como sua comunicação e coordenação. Foram abordados

também os conceitos da FIPA para a interoperabilidade de sistemas multiagentes e

apresentado um comparativos entre as principais ferramentas de desenvolvimento

de agentes.

No próximo capitulo será apresentada a ferramenta JADE, que é um

framework para o desenvolvimento de sistemas multiagentes.

40

3 JADE

JADE (Java Agent Development framework) é um ambiente para

desenvolvimento de aplicações baseado em agentes, totalmente implementado em

Java, que está em conformidade com as especificações da FIPA para

interoperabilidade entre sistemas multiagentes. É open source sob a licença LGPL8

(Lesser General Public License) e foi desenvolvido e suportado pelo CSELT da

Universidade de Parma na Itália. JADE é um middle-ware9 de agentes que

implementa uma plataforma de agentes e um software de desenvolvimento, ou seja,

não apenas facilita o desenvolvimento como também é utilizado para o

gerenciamento de agentes.

Segundo Bellifemine e outros (2003a), o principal objetivo do JADE é

simplificar e facilitar o desenvolvimento de sistemas multiagentes garantindo um

padrão de interoperabilidade entre sistemas multiagentes através de um abrangente

conjunto de agentes de serviços de sistema, os quais tanto facilitam como

possibilitam a comunicação entre agentes, de acordo com as especificações da

FIPA, tais como: serviço de nomes (naming service) e páginas amarelas (yellow- 8 A licença LGPL permite a redistribuição do código fonte e modificações sem restrições desde que as modificações sejam também enquadradas sob licença LGPL. 9 Por middle-ware entenda-se o conjunto de classes e pacotes que JADE disponibiliza que permitem um desenvolvimento de aplicações mais fácil e eficiente, provendo serviços de uso genérico, tais como comunicação, acesso a dados, codificação e controle de recursos, não apenas para uma simples aplicação, mas preferencialmente para uma variedade de aplicações.

41

page service), transporte de mensagens, serviços de codificação e decodificação de

mensagens e uma biblioteca de protocolos de interação (padrão FIPA) pronta para

ser usada.

Toda a comunicação entre agentes é feita via troca de mensagens. Além

disso, lida com todos os aspectos que não fazem parte do agente em si e que são

independentes das aplicações tais como transporte de mensagens, codificação e

interpretação de mensagens e ciclo de vida dos agentes. Uma analogia seria

comparar JADE ao kernel de um sistema operacional e os agentes às aplicações.

JADE é completamente codificada em Java devido às características

peculiares da linguagem que facilitam o desenvolvimento de sistemas multiagentes,

particularmente a orientação a objetos em ambientes distribuídos heterogêneos. Em

relação ao desenvolvimento de sistemas multiagentes, Bigus (2001) relaciona

algumas características importantes de Java:

Autonomia – Aplicações Java são processos separados e como tais

podem executar por um longo período de tempo. Além disso, é possível também

implementar um agente como uma thread separada. A comunicação pode ser feita

através de sockets ou invocação de métodos remotos (Remote Method Invocation -

RMI). Outro problema relacionado à autonomia é como um agente sabe que alguma

coisa mudou. A forma mais natural é através da notificação por eventos. Java

disponibiliza um sistema de tratamento de eventos, utilizado nos sistemas de janelas

AWT (Abstract Window Toolkit) e Swing.

Inteligência – A inteligência em agentes abrange tanto código lógico

procedural ou orientado a objetos quanto capacidades sofisticadas de raciocínio e

aprendizagem. Embora Lisp e Prolog sejam linguagens consagradas para este tipo

de aplicação, vários trabalhos vêm sendo feitos em C e C++, e, portanto, podem ser

42

implementados também em Java. Representações de conhecimento padrões em

Inteligência Artificial como frames, redes semânticas e regras if-then podem ser

facilmente e naturalmente implementadas usando Java.

Mobilidade – A mobilidade é facilitada em Java pela portabilidade do

bytecode10 e dos arquivos JAR (várias classes agrupadas em um único arquivo para

facilitar a distribuição dos programas). Em Java é possível enviar os códigos pela

rede e executar em outra máquina, como por exemplos applets. Um dos requisitos

para programas com mobilidade é a habilidade de salvar o estado do processo em

execução, despachá-lo e então restaurar o processo onde quer que ele tenha sido

entregue, mesmo que agora esteja executando em um sistema diferente. Uma vez

que a JVM11 provê um ambiente de computação padrão para processos executando

Java, irá prover também uma máquina virtual homogênea que permite que agentes

Java se movam entre sistemas de hardware heterogêneos.

3.1 Características de JADE

Seguem abaixo algumas características que JADE fornece para o

desenvolvimento de sistemas multiagentes, de acordo com Bellifemine e outros

(2003a):

• Plataforma distribuída de agentes: A plataforma de agentes pode ser

dividida em vários “hosts” ou máquinas (desde que eles possam ser

conectados via RMI). Apenas uma aplicação Java e uma JVM é

executada em cada host. Os agentes são implementados como

10 Código fonte Java compilado. 11 Ambiente de execução onde os bytecodes são interpretados.

43

threads Java e inseridos dentro de repositórios de agentes chamados

de containers (Agent Containers) que provêem todo o suporte para a

execução do agente.

• GUI – Grafic User Interface: interface gráfica que gerencia vários

agentes e containers de agentes, inclusive remotamente.

• Ferramentas de debugging para ajudar no desenvolvimento e

depuração de sistemas multiagentes baseados em JADE.

• Mobilidade de agentes intraplataforma, incluindo a transferência do

estado e do código do agente.

• Suporte a execução de concorrentes atividades de agentes através dos

modelos de comportamentos (behaviours).

• Plataforma de agentes aderente ao padrão FIPA, no qual incluem o

sistema gerenciador de agentes (AMS - Agent Management System), o

diretório facilitador (DF - Directory Facilitator) e o canal de comunicação

de agentes (ACC - Agent Communication Channel). Todos esses três

componentes são automaticamente carregados quando o ambiente é

iniciado.

• Eficiente transporte de mensagens no padrão FIPA-ACL dentro da

mesma plataforma de agentes.

• Biblioteca de protocolos FIPA prontos para serem usados para a

interação entre agentes.

• Registro e cancelamento automático de agentes no AMS.

• Serviços de nomes (Naming Service) em conformidade aos padrões

FIPA: na inicialização dos agentes, estes obtêm seus GUID (Globally

44

Unique Identifier) da plataforma que são identificadores únicos em todo

o ambiente.

3.2 A Plataforma de Agentes

JADE cumpre totalmente com a arquitetura especificada por FIPA. Sendo

que, no carregamento da plataforma JADE, o AMS e o DF são criados e o ACC é

configurado para permitir a comunicação através de mensagens.

Logo, em relação à FIPA, JADE abstrai ao programador muitas de suas

especificações, tais como:

• Não há a necessidade de se implementar a plataforma de agentes: o

sistema gerenciador de agentes (AMS), o diretório facilitador (DF) e o

canal de comunicação dos agentes (ACC) são carregados na

inicialização do ambiente.

• Não há a necessidade de se implementar um gerenciamento de

agentes: um agente é registrado na plataforma no seu próprio

construtor, recebendo nome e endereço, sem falar na classe Agent que

oferece acessos simplificados a serviços no DF.

• Não há necessidade de implementar transporte de mensagens e

parsing12, isto é automaticamente feito pelo ambiente na troca de

mensagens.

A plataforma de agentes pode ser divida em vários hosts. Apenas uma

aplicação Java, e por isso apenas uma JVM é executada em cada host. Cada JVM é 12 Validação de sintaxe e semântica.

45

um Container básico de agentes que fornece um completo ambiente de execução

para agentes e permite que vários agentes executem concorrentemente no mesmo

host. O conjunto de containers ativos é chamado Platform. Um container especial

chamado de Main container deve sempre estar ativo na plataforma e todos os

outros containeres registram-se com ele assim que são criados. Neste container é

que são carregados o AMS, o DF e o ACC.

3.3 Ferramentas de Gerenciamento e Depuração

Como mencionado anteriormente, JADE possui ferramentas que auxiliam

na depuração e no gerenciamento de agentes. Cada ferramenta é um agente JADE,

obedecendo às mesmas regras, às mesmas capacidades de comunicação e ao

mesmo ciclo de vida como uma aplicação de agentes qualquer.

3.3.1 Remote Monitoring Agent

O Remote Monitoring Agent (RMA) é um console gráfico para o controle e

gerenciamento de agentes na plataforma JADE. Permite o controle dos estados do

ciclo de vida de todos os agentes em execução, inclusive os distribuídos. O RMA é a

interface principal da plataforma, centralizando as principais funcionalidades, tais

como comandos de gerenciamento dos agentes (criar agente, excluir agente, clonar

agente, migrar agente), gerenciamento de plataformas distribuídas e comandos para

chamar as outras ferramentas.

46

3.3.2 DummyAgent

Permite criar e enviar mensagens ACL para outros agentes bem como

listar todas as mensagens ACL enviadas e recebidas. Essa lista de mensagens, que

pode ser salva no disco e depois recuperada, pode ser visualizada pelo usuário e

cada mensagem pode ser vista em detalhes e também editada. Como se trata de um

agente, muitas instâncias do DummyAgent podem ser criadas.

3.3.3 Introspector Agent

Esta ferramenta permite o monitoramento e o controle do ciclo de vida dos

agentes em execução, bem como suas trocas de mensagens e seus

comportamentos que estão sendo executados. Permite também o controle de

execução do agente, no caso uma execução passo a passo.

3.3.4 Sniffer Agent

É uma ferramenta que mostra a troca de mensagens graficamente em

notação similar a diagramas de seqüências UML entre determinados agentes.

Quando um usuário decide fazer um “sniff” em um agente ou grupo de agentes, toda

mensagem direcionada a este agente / grupo de agentes ou vinda destes, é

rastreada e disponibilizada na GUI. O usuário poderá ver todas as mensagens e

salvá-las em disco para uso posterior.

47

Em sua inicialização, o Sniffer Agent registra-se no DF para ele poder ser

informado quando cada agente é criado ou excluído, e também quando um container

é criado ou apagado.

3.3.5 DF GUI

DF GUI é uma ferramenta para interação com DF do JADE, mas que pode

ser utilizada com outros DF’s caso o usuário deseje. Com ela é possível criar uma

complexa rede de domínios e subdomínios de páginas amarelas com uma simples

maneira de controlá-las. Ela permite registrar/cancelar registros, modificar/procurar

agentes e serviços e até mesmo integrar DF’s.

Com essa GUI, o usuário pode interagir com o DF de diversas maneiras

tais como visualizar e editar as descrições dos agentes registrados e fazer buscas,

ações que se tornam muito úteis em sistemas multiagentes com grande quantidade

de agentes.

3.4 O Agente na Plataforma JADE

Ao iniciar a plataforma, os agentes recebem seus identificadores únicos

globais (GUID - Globally Unique Identifier), sendo que o AMS registra

automaticamente os agentes criados. O nome do agente é composto por um

apelido@nome_do_host.domínio:porta/JADE. Por exemplo: ag@myhost:1099/JADE.

Um agente é visto pela plataforma como um objeto ativo que carrega

consigo uma thread de controle. Ele é completamente autônomo (controla sua

48

execução, decide quando ler as mensagens e quais mensagens ler), pode iniciar

diversas conversações simultâneas e executar varias tarefas concorrentemente.

O programador usa os behaviours (comportamento do agente) para

modelar as ações que o agente é capaz de executar (usa-se uma thread por agente

e não por behaviour, o que mantém razoável o número de threads necessárias

executando na plataforma). Os behaviours trabalham em modo de agendamento

cooperativo. Cada behaviour deve ceder o controle para permitir que os outros

possam ser executados.

O JADE suporta mobilidade intraplataforma e clonagem: os agentes

podem migrar entre os containers, podem ser clonados entre os containers, podem

ser iniciados pelo próprio agente (doMove, doClone) ou solicitados pela plataforma

via AMS.

Do ponto de vista do programador, um agente JADE é simplesmente uma

instância da classe Agent (pacote jade.core), no qual os programadores ou

desenvolvedores deverão escrever seus próprios agentes como subclasses de

Agent, adicionando comportamentos específicos de acordo com a necessidade e

objetivo da aplicação, através de um conjunto básico de métodos, e utilizando as

capacidades herdadas que a classe Agent dispõe tais como mecanismos básicos de

interação com a plataforma de agentes (registro, configuração, gerenciamento

remoto, etc.).

Não há a necessidade de implementar uma plataforma uma vez que o

JADE inclui o AMS, o DF e o ACC que são iniciados automaticamente com a

plataforma. O AMS controla o ciclo de vida dos agentes (criação remota, migração,

clonagem entre outros) dentro da plataforma JADE, ativa e/ou desativa os

protocolos de transporte de mensagem (MTP – Message Transport Protocol) nos

49

containers, realiza pesquisas nas "white-pages" da plataforma, controla e

supervisiona o acesso a plataforma e ainda mantém um diretório com os

identificadores dos agentes (AID – Agent Identifiers) e o estado de cada agente.

Cada agente ao registrar-se com AMS recebe um AID válido.

Os agentes da plataforma JADE podem estar em diversos estados de

acordo com o ciclo de vida especificado pela FIPA. De acordo com Bellifemine e

outros (2003a), os estados são:

• AP_INTIATED: o agente está construído, contudo ainda não se

registrou com o AMS, não tem nem um nome nem um endereço e não

pode se comunicar com outros agentes.

• AP_ACTIVE: o agente está registrado com o AMS, portanto já possui

seu AID e pode ter acesso às várias características do JADE.

• AP_SUSPENDED: o agente está atualmente parado, sua thread

interna está suspensa e nenhum behaviour esta sendo executado.

• AP_WAITING: o agente está bloqueado, esperando por algo. Sua

thread está dormindo temporariamente.

• AP_DELETED: o agente definitivamente está concluído. Sua thread

interna foi terminada e o agente não está mais registrado com o AMS.

• AP_TRANSIT: um agente móvel entra neste estado enquanto está

migrando. O sistema continua armazenando as mensagens que serão

enviadas a nova localidade.

• AP_COPY: esse estado é usado internamente pelo JADE para estados

que estão começando a serem clonados.

50

• AP_GONE: esse estado é usado internamente pelo JADE quando o

agente móvel migrou para uma nova localidade e possui um estado

estável.

A relação entre esses estados pode ser melhor entendida analisando o

diagrama de estados da figura 3.1:

Figura 3.1 – Diagrama de estados do agente na Plataforma JADE.

3.5 Comunicação entre Agentes em JADE

Toda a comunicação entre agentes na plataforma é feita através de troca

de mensagens no padrão FIPA-ACL. Os agentes se comunicam enviando

mensagens individuais uns para os outros. A mensagem é entendida pelos agentes

como atos falados e não chamadas. Os agentes enviam e recebem objetos Java,

que representam mensagens ACL, dentro do escopo dos protocolos de interação. O

JADE codifica transparentemente todas as mensagens.

O padrão FIPA define que somente mensagens ACL são transportadas na

plataforma, porém não define nenhum padrão para o conteúdo das mensagens.

51

Cada agente possui uma fila privada de mensagens ACL a qual ele processa da

forma que o mesmo achar mais interessante (BELLIFEMINE et al., 2003a).

O JADE utiliza o mecanismo de transporte adaptável, ou seja, o protocolo

de transporte de mensagem é escolhido de acordo com a situação. Tentando

sempre obter menor custo possível de transmissão de mensagem.

A arquitetura do software se baseia na coexistência de várias JVMs que

podem estar espalhadas por vários hosts, sendo que cada JVM é um container de

agentes que provê um ambiente de runtime completo para execução de agentes e

permite que vários agentes sejam executados concorrentemente no mesmo host.

As mensagens intra-container são transportadas por meio de eventos Java

(Java Events), já a comunicação inter-containers é feita utilizando Java RMI. A

comunicação inter-plataforma é realizada utilizando o ACC em conjunto com um

tradutor e o protocolo IIOP.

3.6 Estrutura de um programa em JADE

Na programação de agentes em JADE, têm-se basicamente três

estruturas que são fundamentais:

• Classes de Agentes

• Classes de Mensagens

• Classes de Comportamentos

3.6.1 Agente

52

Na é o mais importante.

É nele que de icial do agente, tais

como constru no DF, etc. Segue

abaixo, na Fi ue deriva da classe

Agent.

public class MyAgent extends Agent { public MyAgent { } public void setup() { // Código de inicialização do agente // Registrar agente no DF // Adicionar comportamentos } }

Figura 3.2 – Estrutura básica de uma classe de agente em JADE

3.6.2 Mensagens

Na estrutura de mensagens, dois importantes aspectos são a classe

ACLMessage e a classe AID. Essas classes são fundamentais para a criação de

u r é um

a amente

tê em e a

p trutura

e

13

ma mensagem. Na mensagem o remetente é sempre um agente, o recepto

gente ou um conjunto de agentes, sendo que todos os agentes obrigatori

m que ter um AID. Além disso, deve-se informar o conteúdo da mensag

erformativa13 (INFORM, AGREE, QUERY, etc.). Na Figura 3.3 temos a es

xemplificada na Figura 3.2 com a funcionalidade de enviar mensagem.

Modo como de

estrutura de uma classe Agent, o método setup

ve ser implementado o código de configuração in

ir e adicionar comportamentos, registrar o agente

gura 3.2, uma estrutura básica de uma classe q

ve ser interpretado o conteúdo da mensagem.

53

public class MyAgent extends Agent { public MyAgent { } public void setup() { // Código de inicialização do agente // Registrar agente no DF // Adicionar comportamentos (addBehaviour) // Etc. ACLMessage msg = new ACLMessage(ACLMessage.INFORM); msg.setSender(getAID()); // getAID <- Retorna o AID do Agente msg.addReceiver(new AID(“AgenteReceptor”, AID.ISLOCALNAME)); msg.setContent(“Minha Mensagem”); send(msg); } }

Figura 3.3 – Estrutura básica de um agente que envia uma mensagem

3.6.3 Comportamentos

Definir comportamentos de um agente é praticamente definir que ações

ele deve tomar em determinadas situações. Ou seja, é uma das funções mais

importantes no desenvolvimento de sistemas multiagentes, pois é nelas que vão ser

definidos os comportamentos que esses agentes terão no ambiente. Como cada

comportamento em JADE é uma classe Behaviour ou derivada de Behaviour,

definir estes comportamentos em JADE significa implementar essas classes Java.

Na Figura 3.4 temos uma estrutura básica de um comportamento do tipo

SimpleBehaviour.

public class MyBehaviour extends SimpleBehaviour { public MyBehaviour { } public void action() { // Método onde localiza-se o comportamento de agente System.out.println("Comportamento simples"); } }

Figura 3.4 – Estrutura básica de um comportamento

54


Neste capítulo apresentou-se a ferramenta de desenvolvimento de

sistemas multiagentes JADE. Em especial, suas características, ferramentas de

suporte, seu modelo de implementação da plataforma proposta pela FIPA e como o

agente deve ser implementado em JADE. No capítulo a seguir será apresentada a

ferramenta Eclipse, sua organização interna e principais componentes, bem como

também uma breve introdução a SWT e JFace.

4 ECLIPSE

O Eclipse é uma plataforma para integração de ferramentas de

desenvolvimento. Inicialmente desenvolvido pela IBM e depois doado à comunidade

de software livre, é distribuído sob a forma de um framework open source sob

licença CPL (Common Plublic Licence). Sobre o framework são instalados plug-ins

que fornecem recursos como integração a compiladores e depuradores, editores

com realce de sintaxe, desenho de diagramas UML, acesso a bancos de dados e o

que mais for útil para um desenvolvedor de software.

Seus principais objetivos são prover uma plataforma aberta para

ferramentas de desenvolvimento de aplicações, independente de sistema

operacional, pois é todo escrito em Java; e facilitar a integração de ferramentas,

através de sua arquitetura extensível pelo mecanismo de plug-ins, tornando possível

adicionar novas ferramentas e características a produtos já instalados de uma forma

bastante fácil. Devido a essa arquitetura de plug-ins é possível conseguir também

55

uma neutralidade de linguagens, pois são os plug-ins que adicionam suporte a

determinadas linguagens de programação no Eclipse.

Apesar de ser um projeto recente14, o Eclipse já faz sentir o seu impacto

no mercado, em especial no desenvolvimento em Java. Alguns dos IDEs15 mais

populares nesta área, como o WebSphere Studio da IBM ou XDE da Rational, têm

como base o Eclipse.

O Eclipse em si fornece apenas o ambiente integrado para a execução

dos plug-ins e uns poucos plug-ins básicos, como editor de textos ASCII, sistema de

ajuda e integração ao CVS16. Para iniciar o desenvolvimento, em qualquer

linguagem que seja, devem ser instalados plug-ins adicionais. Assim sendo, o

Eclipse tem dois públicos-alvos distintos:

1. Desenvolvedores de software, que agregam plug-ins ao Eclipse para

construir o ambiente de trabalho mais poderoso, integrado e simples

possível;

2. Fornecedores de ferramentas de desenvolvimento, que escrevem os

plug-ins e competem entre si para fornecer as melhores ferramentas ao

mercado.

Para o primeiro grupo é fornecido o Eclipse Platform, que fornece o IDE

pronto para receber plug-ins de terceiros, constituídos apenas dos componentes

básicos do framework. Para o segundo é fornecido o Eclipse SDK, que fornece o

código fonte do Eclipse em si e uma série de ferramentas voltadas para o seu

próprio desenvolvimento ou de plug-ins, tais como o JDT e o PDE, que serão

explicados mais adiante. Por convenção, adotaremos nesse trabalho o nome

14 O projeto Eclipse teve início em 2001. 15 Ambiente de Desenvolvimento Integrado: é um ambiente de desenvolvimento onde encontram-se todas as ferramentas necessárias para o desenvolvimento de aplicações. 16 Concurrent Versioning System : sistema de controle de versão, que permite que grupos de pessosas trabalhem simultaneamente em grupos de arquivos.

56

plataforma Eclipse quando nos referirmos ao framework básico Eclipse Platform, e

adotaremos o nome Eclipse quando estivermos nos referindo à ferramenta completa

para edição de código fonte Java e desenvolvimento de plug-ins que é o Eclipse

SDK.

O ambiente do Eclipse, de modo similar a outros IDEs, é baseado nos

conceitos de Projeto, Perspectiva e Visão:

• Um projeto agrupa arquivos-fonte e define os plug-ins responsáveis

pelas atividades de compilação, depuração, etc, assim como

configurações personalizadas;

• Uma perspectiva fornece layouts diferenciados para o IDE,

customizados para atividades como gerenciamento de versões,

codificação ou testes pela ativação das visualizações apropriadas;

• Uma visão é o componente básico de uma perspectiva, fornecendo,

por exemplo, navegação pela estrutura de classes, uma lista de tarefas

a realizar ou o histórico de modificações de um arquivo-fonte no CVS.

Internamente, estes componentes se comunicam entre si e com os

componentes que realizam as tarefas reais de desenvolvimento de software, os

quais são:

• Editores especializados na edição de tipos específicos de arquivo,

normalmente fontes em uma linguagem de programação, fornecendo

realce de sintaxe e recursos, como o code completion17, mas que

também podem ser voltados para a edição de ícones, desenho visual

de formulários ou desenho de modelos de Engenharia de Software;

17 Recurso de auto-complementar o código, sugerindo nomes de classes e métodos.

57

• Lançadores (launchers), que fornecem ambientes para a execução do

projeto ou partes dele dentro de um depurador, servidor web ou outros

tipos de containeres;

• Construtores (builders), responsáveis por traduzir diversos tipos de

arquivos-fonte nos arquivos-objetos correspondentes ou por pré-

processar arquivos-fonte, gerando outros arquivos-fonte, que serão por

sua vez processados por outros construtores.

4.1 Arquitetura do Eclipse

Exceto por um pequeno kernel de execução, tudo no Eclipse consiste em

um plug-in ou em um conjunto de plug-ins relacionados. Em adição a esse pequeno

kernel, a plataforma Eclipse é composta por alguns componentes, que são o

Workbench, Workspace, Help e Team. Outros componentes podem ser adicionados

à plataforma para criarem uma aplicação usual.

58

Figura 4.1 – Arquitetura do Eclipse

4.1.1 O Ambiente de Execução e Arquitetura dos Plug-ins

Um plug-in é a menor unidade funcional da Plataforma Eclipse. Todas as

funcionalidades do Eclipse estão diretamente relacionadas aos plug-ins. Os plug-ins

são compostos por uma ou mais classes Java agrupadas em um arquivo JAR, um

arquivo de manifesto codificado em XML e alguns outros recursos como imagens,

arquivos de texto, etc.

O componente mínimo para um plug-in funcionar é o arquivo de manifesto

(plugin.xml), que é onde são declaradas todas as suas interconexões com a

plataforma e com outros plug-ins. O modelo de interconexão baseia-se em dois

mecanismos, que são os pontos de extensão (extension points) e as extensões para

os referidos pontos de extensão.

Segundo Gallardo e outros (2003), pontos de extensão são entidades

definidas para o agrupamento de contribuições, ou seja, são os pontos onde a

59

funcionalidade do plug-in pode ser estendida. Já extensões são as contribuições

propriamente ditas, são as funcionalidades adicionadas ao plug-in. Por exemplo, o

plug-in Workbench, que será descrito mais adiante, declara um ponto de extensão

para as preferências de interface do usuário, com isso qualquer plug-in pode

contribuir com suas próprias preferências apenas definindo extensões para este

ponto de extensão. Na figura 4.2 temos um exemplo de um cenário típico desse

mecanismo de interconexões entre plug-ins.

Figura 4.2 – Cenário típico de interconexões entre plug-ins.

Na inicialização da plataforma Eclipse, todos os plug-ins contidos no

diretório plugins são detectados. Baseado nos arquivos de manifesto dos plug-ins, o

ambiente de execução constrói na memória um registro com todos os plug-ins

disponíveis e seus pontos de extensão, mas não os carrega até que sejam

realmente necessários. Isto ocorre para que sejam economizados recursos da

máquina e para diminuir o tempo de inicialização da plataforma. (GALLARDO et. al.,

2003).

4.1.2 Workspace

60

O Workspace é o responsável por gerenciar os projetos, através de

ferramentas que criam, lêem, modificam e excluem os recursos18 do usuário. Cada

projeto corresponde a um diretório no sistema de arquivos especificado pelo usuário.

Os vários projetos contidos no Workspace podem direcionar para diferentes

diretórios ou unidades no sistema de arquivos, embora, por padrão, todos os

projetos direcionem para subdiretórios do diretório workspace da distribuição do

Eclipse.

Para minimizar o risco de acidentalmente perder ou danificar recursos, o

Workspace mantém um histórico de todas as mudanças ocorridas nos recursos do

usuário. Isto torna possível reverter mudanças imediatamente, tão bem quanto

reverter a um estado salvo previamente.

É fornecido também um mecanismo de natures. Com esse mecanismo é

possível associar determinados projetos a temas comuns, como, por exemplo,

associar projetos a uma linguagem de programação qualquer, onde todos os

projetos terão as mesmas características. Com isto permite-se trabalhar com vários

projetos abertos ao mesmo tempo e organizá-los de uma forma clara e concisa.

4.1.3 Workbench e Bibliotecas de Interface

O Workbench é a interface gráfica do Eclipse, que fornece uma estrutura

para a interação das ferramentas de desenvolvimento com o usuário. Uma de suas

características mais notáveis é que, diferentemente da maioria das aplicações Java,

18 Por recursos entenda-se o termo usado para relacionar o conjunto de projetos, arquivos e pastas da área de trabalho.

61

sua aparência e seu comportamento são similares a aplicações nativas. Isto ocorre

porque ele é construída utilizando-se SWT e JFace, que serão explicados a seguir.

4.1.3.1 Standard Widget Toolkit – SWT

Segundo o Eclipse Platform Technical Overview19 , SWT é um conjunto de

widgets20 e uma biblioteca gráfica integrada com o sistema de janelas nativo, mas

independente da API21 do sistema operacional. Antes de analisarmos por completo

este conceito, vamos falar das outras bibliotecas gráficas disponíveis em Java, que

são o AWT e o Swing.

O AWT fornece uma API para a construção de componentes gráficos tais

como rótulos, botões, caixas de texto, listas e menus, e delegam ao sistema

operacional a tarefa de fornecer a implementação específica do componente.

Quando se constrói uma caixa de texto AWT, o sistema operacional constrói a caixa

de texto e a exibi em uma janela de aplicação. Uma caixa de texto AWT no Windows

assemelha-se a uma caixa de texto Windows, e uma caixa de texto AWT no MacOS

assemelha-se a uma caixa de texto MacOS.

O problema com o AWT é que a Sun só implementou componentes que

eram comuns em todas as plataformas onde Java era suportada. Para resolver este

problema a Sun trabalhou junto com a Netscape e desenvolveram o Swing, que era

uma tentativa de fazer um abrangente conjunto de widgets que funcionassem em

qualquer plataforma. Para alcançar esse objetivo, eles escreveram tudo em Java, e

19 Disponível http://www.eclipse.org/whitepapers/eclipse-overview.pdf 20 Símbolo gráfico que permite a interação entre o usuário e a aplicação, por exemplo, botões, caixas de rolagem, listas, etc. 21 Application Program Interface: conjunto de regras ou funções que habilitam a comunicação entre duas aplicações distintas.

62

tudo seria interpretado pela JVM, não mais delegando a construção do widget ao

sistema operacional. Esta política ajudou Java a se tornar mais útil em termos de

interface gráfica, mas isso teve um custo:

• A aparência dos componentes não era mais semelhante à dos

componentes nativos da plataforma onde estavam executando.

• O desempenho tornou-se muito pior comparada às implementações

nativas.

Então a Sun tentou resolver o primeiro problema com o desenvolvimento

do chamado look and feel22 adaptável, que significa que os widgets teriam a

aparência semelhante aos widgets nativos do sistema operacional. Entretanto,

embora essa política tenha resolvido parte do problema, a Sun não foi capaz de

acompanhar o desenvolvimento dos sistemas operacionais. Por exemplo, o look and

feel de componentes Swing é o mesmo em todas as versões do Windows (Windows

95, Windows 98, Windows Me, Windows 2000 e Windows XP), embora as

aplicações nativas pareçam diferentes dependendo da versão do sistema em que

estão executando. (GALLARDO et. al., 2003).

Em termos de desempenho, com o desenvolvimento de novas versões do

JDK a Sun conseguiu melhorar bastante, entretanto, um componente emulado

jamais terá um desempenho melhor do que um componente nativo similar. Mesmo

com o advento do Java JIT23, uma fase de tradução sempre ocorre na JVM, a qual

converte componentes emulados em um conjunto de instruções nativas.

Durante o desenvolvimento do Eclipse, a IBM desenvolveu um novo

método para tentar resolver o problema, que basicamente consiste em uma

abordagem hibrida das duas tomadas anteriormente. SWT é um conjunto de widgets 22 Refere-se à aparência e ao comportamento dos componentes gráficos. 23 Java Just in Time, ou seja, os bytecodes são compilados para código nativo depois de terem sido executados uma vez.

63

que acessam controles nativos do sistema através da JNI (Java Native Interface).

Apenas alguns controles que não estão presentes em um sistema operacional

qualquer é que são emulados. O lado negativo desta abordagem é que bibliotecas

nativas são requeridas para cada plataforma onde o Eclipse será utilizado, isto não

chega a ser um problema, pois o Eclipse é suportado nos mais diversos sistemas

operacionais encontrados hoje. Entretanto, o lado positivo é que as aplicações têm

aparência e desempenho semelhantes às aplicações nativas.

4.1.3.2 JFace

JFace é um framework independente de plataforma para construção de

interfaces gráficas construído sobre o SWT. Ele fornece classes adequadas para a

manipulação das características de aplicações mais típicas e simplifica um

significativo número de tarefas comuns de interface de usuário. JFace simplifica o

uso do SWT sem escondê-lo do desenvolvedor. O principal objetivo do JFace é

portanto, libertar o desenvolvedor de implementações específicas de tarefas comuns

em aplicações com interface gráfica.

A figura 4.3 mostra o relacionamento entre SWT, JFace e o Workbench.

Como se pode ver, JFace é completamente dependente do SWT, mas o SWT não é

dependente de nada. O Workbench é construído sobre ambas as camadas do SWT

e JFace e usa-os quando necessário.

64

Figura 4.3 – Integração entre JFace, SWT e Workbench.

Segundo Gallardo e outros (2003), JFace fornece as seguintes

funcionalidades:

• Fornece classes de visões que manipulam as tediosas tarefas de

preenchimento, classificação, filtragem e atualização de componentes.

• Fornece ações que permitem aos usuários desenvolver seus próprios

comportamentos e determiná-los a componentes específicos, como

itens de menu, barra de ferramentas, botões, etc. As ações são

designadas para serem compartilhadas entre diferentes widgets. Para

não haver duplicação de código, a mesma ação pode ser usada para

um item de menu e um item em uma barra de ferramentas.

• Define janelas de diálogos e wirzards24 padrões e define um framework

que pode ser usado na construção de interações com o usuário.

• Fornece registros que organizam imagens e fontes. Estes registros são

usados para fornecer mecanismos que parecem o mais simples

possível quando os recursos do sistema forem limitados.

4.1.4 Team

24 Por wizard entenda-se assistentes que guiam o usuário a desenvolver determinadas ações.

65

Team é um plug-in que oferece o suporte ao trabalho em equipe, através

do uso do sistema de controle de versão que gerencia os recursos nos projetos dos

usuários e define um fluxo de trabalho necessário para salvar e retomar arquivos em

um repositório. A plataforma Eclipse inclui um cliente para o uso do CVS (Concurrent

Versioning System).

O CVS é um sistema que permite que grupos de pessoas trabalhem

simultaneamente em grupos de arquivos como, por exemplo, manuais, apostilas e

códigos de programas. É utilizado um repositório central com as versões mais

recentes dos arquivos. Sendo possível, a qualquer momento, criar uma cópia

pessoal desses arquivos e, caso no futuro esses arquivos sejam atualizados, o CVS

se encarregará de atualizar a cópia do usuário quando este desejar fazê-lo. O

usuário pode alterar os seus arquivos à vontade. Se novas versões destes arquivos

forem colocadas no CVS nesse período de modificação, a atualização tentará o

máximo possível combinar as alterações do repositório com as feitas localmente

pelo usuário.

Caso haja coincidência nas alterações e algum conflito seja criado pelas

suas mudanças e as já em efeito no repositório, o CVS avisará ao usuário e este

deverá resolver este problema na sua cópia. Depois de resolvido o problema pode-

se, então, enviar os arquivos para o repositório. Quando o usuário tentar enviar um

arquivo para o repositório, o CVS verificará se a versão que o usuário possui é a

mais recente. Caso não seja, ele receberá uma notificação do CVS, devendo então

atualizar a sua cópia, resolver quaisquer conflitos que venham a surgir e, só então,

enviar os arquivos para o repositório.

Com o CVS cada desenvolvedor trabalha em seu próprio diretório, com

suas próprias versões dos arquivos e o sistema se encarrega de juntar as versões

66

espalhadas numa só, contemplando todas as mudanças feitas pelos diversos

desenvolvedores.

4.1.5 Help

Como a própria plataforma Eclipse, o componente Help é um sistema de

documentação extensível. Ferramentas adicionais podem adicionar documentação

em formato HTML, e usando XML, definir uma estrutura de navegação. Espelhando-

se no modo como os plug-ins conectam-se a outros plug-ins, as documentações das

ferramentas podem inserir tópicos em árvores de tópicos preexistentes.

Recursos avançados do sistema de ajuda incluem auxílio contextual com

links de referência (conhecidos como infopops) e a capacidade de chamar código da

plataforma a partir da documentação. Um navegador de ajuda permite exibir,

imprimir e pesquisar sua documentação.

4.2 Eclipse SDK

O Eclipse SDK é um pacote completo para desenvolvimento de aplicações

Java e para o desenvolvimento de plug-ins Eclipse. Diferentemente da plataforma

Eclipse que possui somente uma estrutura básica para a adição de novas

funcionalidades, o Eclipse SDK possui o JDT (Java Development Tool), que é o

ambiente de desenvolvimento Java, e o PDE (Plug-in Development Environment),

que é o ambiente para desenvolvimento de plug-ins. O Eclipse SDK também inclui o

suporte a depuração de programas (Debugger) e o suporte a testes unitários (JUnit).

67

4.2.1 JDT

JDT é um ambiente completo para desenvolvimento de aplicações Java

no Eclipse. É formado por vários plug-ins, que adicionam à plataforma novos

editores, perspectivas e visões, que dão um completo suporte à linguagem,

fornecendo complementação de código, coloração de sintaxe, formatação de código,

dicas e correções de código, visualização de classes e métodos, entre outras coisas.

Um dos pontos fracos do JDT em relação a produtos comerciais da

mesma qualidade é que ele não fornece suporte à construção visual de

formulários25. Outra deficiência é o suporte ao desenvolvimento de aplicações

voltadas para a web, tais como JSP. Mas como a principal vantagem do Eclipse é

adaptá-lo a qualquer usuário, existem vários plug-ins no mercado que acrescentam

estas capacidades sem que seja necessário adquirir produtos caros baseados no

Eclipse como o Websphere Studio da IBM.

4.2.2 PDE

PDE é o ambiente de desenvolvimento de plug-ins do Eclipse. Tal como o

JDT, também é formado por uma série de plug-ins que adicionam editores, visões e

perspectivas à plataforma, adicionando características tais como construção,

compilação, depuração, teste e empacotamento de plug-ins para o Eclipse.

25 Está em desenvolvimento um plug-in para a construção visual de formulários em AWT, Swing e SWT. Mais informações em http://www.eclipse.org/vep/

68

O objetivo do PDE é garantir que os plug-ins sejam desenvolvidos de

forma correta, seguindo as regras de extensão e ponto de extensão, garantindo que

estes incorporem-se perfeitamente à plataforma.

O PDE gerencia plug-ins dentro dos projetos. Cada projeto representa um

plug-in e mantém as pastas e os arquivos que o definem e a maneira com a qual irá

interagir com a plataforma.

4.2.3 Debugger

O Debugger permite detectar e diagnosticar erros em programas sendo

executados localmente ou remotamente. Torna-se fácil controlar a execução dos

programas, através da adição de breakpoints, os quais suspendem a inicialização,

possibilitando analisar o código por "dentro" e examinar o conteúdo das variáveis.

A utilização dessa perspectiva é através de um design cliente/servidor,

sendo assim os programas podem rodar remotamente em outros sistemas

operacionais na rede, como rodariam localmente na estação de trabalho do

desenvolvedor. O servidor de depuração roda no mesmo sistema operacional que o

programa a ser analisado, o qual pode estar na maquina do desenvolvedor (local

debugging) ou em um sistema operacional que esteja acessível através da rede

(remote debugging).

4.2.4 JUnit

69

JUnit é um framework open-source para o desenvolvimento de testes

automatizados. Usando JUnit o usuário pode facilmente construir uma suíte de

testes que o ajudará a medir o seu progresso, localizar efeitos colaterais

indesejáveis e focalizar o empenho no desenvolvimento.

4.2.5 Outros Plug-ins

Como o principal objetivo do Eclipse é ser altamente configurável através

de plug-ins, é possível encontrar uma variedade enorme de plug-ins em sites

especializados na internet. A Eclipse Foundation26 também fornece outros plug-ins

provendo suporte a outras linguagens de programação bastante utilizadas no

mercado, tais como C/C++ e COBOL.


Neste capítulo foi apresentada uma visão completa sobre a ferramenta

Eclipse, mostrando sua arquitetura e principais componentes, bem como também

uma breve introdução sobre a estrutura básica de um plug-in no Eclipse.

No próximo capítulo será apresentado o Jadeclipse Plug-in, que é um

plug-in para integrar as funcionalidades para desenvolvimento de sistemas

multiagentes do JADE com o Eclipse.

5 JADECLIPSE PLUG-IN

26 Eclipse Foundation é uma organização sem fins lucrativos responsável pelo desenvolvimento e gerenciamento do projeto Eclipse.

70

Jadeclipse é um plug-in do Eclipse para integração com JADE, que tem

por principal objetivo facilitar o desenvolvimento de sistemas multiagentes, unindo as

principais características dessas duas plataformas, ou seja, combina um poderoso

ambiente para edição de código fonte em Java com um conjunto de bibliotecas para

o desenvolvimento de agentes. Dessa forma, Jadeclipse resolve um dos problemas

de JADE que é não possuir um ambiente para edição e manipulação do código fonte

do agente. Deficiência essa que termina dificultando o desenvolvimento de sistemas

multiagentes em JADE, pois o usuário terá que usar outro ambiente para escrever o

código do agente, onde ele terá que configurar as bibliotecas de JADE, para poder

compilar o código. Para executar o agente o usuário terá que copiar a classe do

código do agente para o diretório do JADE e carregá-lo através de seu menu

principal ou então configurar o classpath do JADE para apontar também para onde o

código do agente foi compilado. Realizar esse trabalho para escrever uma

comunidade grande de agentes é um desperdício de tempo enorme, resultando

assim em perda de produtividade, ao passo que utilizar um plug-in onde

praticamente tudo já vem configurado, o usuário teria um ganho de produtividade

muito maior.

Tendo como prerrogativa tornar o desenvolvimento de agentes mais fácil,

o Jadeclipse oferece ao usuário algumas comodidades. Uma dessas comodidades é

o uso de templates27, onde o código do agente é pré-gerado com os

comportamentos mais comuns. Através do Jadeclipse é possível também compilar e

executar os agentes de dentro do Eclipse, bastando que para isso a plataforma

JADE tenha sido previamente carregada, o que também é possível através do plug-

27 Modelos previamente configurados para serem usados na geração de novas classes.

71

in. Portanto o Jadeclipse fornece ao usuário as principais tarefas que ele teria que

fazer usando outras ferramentas e métodos do sistema operacional.

Antes de analisarmos a arquitetura interna do Jadeclipse vamos introduzir

alguns conceitos referentes ao desenvolvimento de plug-ins para o Eclipse.

5.1 Conceitos de programação para plug-ins

Conforme exposto no capítulo anterior, o módulo utilizado para o

desenvolvimento de plug-ins no Eclipse é o PDE, que ajusta de forma clara e

concisa, todas as visões e editores para a edição do código necessário ao

desenvolvimento de plug-ins. O PDE fornece ao usuário um editor para o arquivo de

manifesto (plugin.xml), onde são declarados todos os pontos de extensão do plug-in,

e um ambiente para a edição de arquivos Java, que são responsáveis por

implementar a funcionalidade das contribuições28 do plug-in.

5.1.1 Anatomia de um plug-in

Um plug-in basicamente é composto de um arquivo de manifesto, uma ou

mais classes Java, e alguns arquivos de configuração e ícones. No arquivo de

manifesto são declaradas diversas informações, tais como:

• Informações gerais, tais como identificador, nome, versão, etc.

• Classe principal que o implementa e nome do arquivo JAR que será

gerado. 28 Terminologia usada para indicar as extensões do plug-in aos pontos de extensão da plataforma Eclipse.

72

• Plug-ins requeridos para o seu funcionamento. Por questões de

segurança, um plug-in não pode usar bibliotecas externas no seu

desenvolvimento, apenas bibliotecas de outros plug-ins.

• Declaração dos pontos de extensão que ele estende da plataforma,

indicando IDs e classes que implementam essas contribuições.

Na figura 5.1 podemos encontrar algumas dessas configurações.

<?xml version="1.0" encoding="UTF-8"?> <plugin id="br.ufma.jadeclipse" name="Jadeclipse Plug-in" version="1.0.0" provider-name="Daniel Lima" class="br.ufma.jadeclipse.JadeclipsePlugin"> <runtime> <library name="jadeclipse.jar"/> </runtime> <requires> <import plugin="org.eclipse.core.resources"/> <import plugin="org.eclipse.ui"/> <import plugin="org.eclipse.jdt.core"/> <import plugin="org.eclipse.jdt.ui"/> <import plugin="org.eclipse.debug.core"/> <import plugin="org.eclipse.debug.ui"/> <import plugin="org.eclipse.jdt.debug.ui"/> <import plugin="org.eclipse.jdt.launching"/> </requires> <extension point="org.eclipse.ui.preferencePages"> <page name="Jade" class="br.ufma.jadeclipse.preferences.JadePreferencePage" id="br.ufma.jadeclipse.preferences.JadePreferencePage"> </page> </extension>

Figura 5.1 – Trecho de código do arquivo de manifesto.

Todas as classes que implementam os pontos de extensão da plataforma

Eclipse herdam métodos e atributos de classes específicas. Dessa forma garante-se

que o plug-in integra-se à plataforma de forma correta e permite ao desenvolvedor

preocupar-se apenas com a funcionalidade específica do plug-in. Por exemplo, um

plug-in que utiliza o ponto de extensão org.eclipse.ui.preferencePages

73

declara no arquivo de manifesto um identificador da extensão, que é como o eclipse

localiza as extensões do plug-in; o nome da página que será exibida na árvore de

preferências na janela do sistema; e a classe que implementa esse ponto de

extensão. A classe que implementa a página de preferência herda métodos e

atributos da classe PreferencePage, de forma que automaticamente ela será

ajustada na janela de preferências do sistema. Assim o desenvolvedor preocupa-se

apenas com os componentes que aparecerão na janela, e sua funcionalidade, pois

sabe que a janela será exibida de forma correta e com um layout semelhante a todas

as outras janelas que implementam esse ponto de extensão.

5.1.2 Pontos de Extensão

A plataforma Eclipse fornece uma série de pontos de extensão, que vão

desde simples janelas para exibição de informações até builders e launchers, que

são pontos de extensão utilizados para construção de compiladores de linguagens

de programação específicas e lançadores de aplicações escritas nessas linguagens.

Os principais pontos de extensão da plataforma são:

• org.eclipse.ui.views: Visões são pontos de extensão do Workbench

onde é exibida uma janela com informações diversas sobre um

determinado objeto ou recurso. Por exemplo, a visão outline exibe a

estrutura do arquivo Java em edição no momento, ou seja, mostra as

classes, métodos a atributos que pertencem a esse arquivo. Outra

visão bastante utilizada é a properties, que exibe as propriedades do

objeto selecionado.

74

• org.eclipse.ui.editors: Editores são pontos de extensão onde são

criados mecanismos para a manipulação do conteúdo de arquivos. O

Eclipse SDK vem com três editores padrões: um editor para arquivos

de texto simples, um para arquivos Java e um para edição de arquivo

de manifesto. Através dos editores é possível criar diversas

funcionalidades, tais como: formatação e identação de código, code

completion, coloração de sintaxe e uma série de outras características

onde o objetivo é facilitar a edição do arquivo pelo usuário.

• org.eclipse.ui.actionSets: ActionSets são pontos de extensão do

Workbench onde o plug-in pode adicionar novos menus, itens de menu

e botões na barra de ferramentas. Para reduzir a desordem que seria

causada por ter todas as contribuições de menu do plug-in exibidas ao

mesmo tempo, elas são agrupadas em conjuntos de ações, cuja

visualização pode ser obtida de acordo com a preferência do usuário.

• org.eclipse.ui.newWizard: Wizards são assistentes gráficos que

auxiliam o usuário na execução de diversas tarefas, tais como a

criação de novos projetos, pacotes, classes, interfaces, etc. Este ponto

de extensão é utilizado para registrar as extensões do recurso do

assistente de criação. Os assistentes localizam-se dentro do menu

“New” e estão organizados em categorias que normalmente refletem o

domínio de um determinado problema. Por exemplo, um plug-in Java

pode definir uma categoria chamada "Java", que é adequada para os

assistentes de criação "Classe" ou "Pacote". As categorias definidas

por um plug-in podem ser referenciadas por outros plug-ins utilizando o

atributo category. Assistentes sem categoria definida, bem como

75

assistentes com caminhos de categoria inválidos terminarão na

categoria "Outros".

• org.eclipse.ui.preferencePages: Páginas de preferência são paginas

onde são listadas preferências e configurações que o usuário pode

ajustar. Quando a caixa de diálogo de preferências for aberta

(inicializada a partir do menu principal), as páginas contribuídas nesse

modo serão incluídas na caixa de diálogo. A caixa de diálogo de

preferências serve para o agrupamento hierárquico das páginas.

5.2 Arquitetura do Jadeclipse

Como já mencionado, o Jadeclipse oferece algumas facilidades ao

usuário. Para melhor entender-mos sua arquitetura, será associada a cada extensão

uma funcionalidade relacionada, cobrindo assim toda a sua estrutura e

características.

5.2.1 PreferencePage

A classe JadePreferencePage implementa a funcionalidade do ponto

de extensão da plataforma de página de preferência. Essa classe tem por objetivo

identificar onde o JADE encontra-se instalado na máquina do usuário. É

apresentada ao usuário uma janela com dois campos de edição. No primeiro campo

ele indica o diretório raiz do JADE e automaticamente o plug-in configura o outro

campo para o diretório padrão de bibliotecas do JADE. Se o diretório de bibliotecas

76

configurado no computador do usuário for outro, ele pode apontar o diretório correto

tal como ele fez com o diretório raiz. Com isso o Jadeclipse obtêm a informação da

localização correta das bibliotecas do JADE e pode configurar o classpath para o

projeto do usuário poder carregar a plataforma e os agentes.

Figura 5.2 – Página de preferências do Jadeclipse

Toda página de preferência tem associada a ela uma estrutura de dados

chamada preferenceStore onde são guardadas suas respectivas configurações.

Através dos métodos setPreferenceStore e getPreferenceStore essas

informações são gravadas e restauradas. O método setPreferenceStore cria

automaticamente um arquivo de texto onde são guardadas as informações passadas

ao preferenceStore. Por sua vez, quando a página de preferência é carregada é

77

chamado o método getPreferenceStore que lê do arquivo de configuração e

configura o preferenceStore adequadamente.

5.2.2 Nature

Natures são mecanismos usados pelo Eclipse para associar conjuntos de

projetos a determinados grupos. Por exemplo, projetos de aplicações em Java têm

uma nature comum, que é a Java Nature. No Jadeclipse esse mecanismo foi usado

para agrupar conjuntos de projetos que têm a mesma característica, que é o

desenvolvimento de sistemas multiagentes através do JADE. Com isso é possível

configurar os classpaths de todos os projetos para apontarem para as bibliotecas do

JADE configuradas na página de preferência.

A classe que implementa esse ponto de extensão no Jadeclipse é a

JadeProject. Essa classe configura o classpath do projeto com as bibliotecas do

JADE e associa o construtor padrão de código Java ao projeto. Com isso cria-se um

projeto JADE com as características de um projeto Java, mas que possui em seu

classpath as bibliotecas necessárias ao desenvolvimento de agentes.

5.2.3 Wizards

O Jadeclipse apresenta dois assistentes que auxiliam o usuário nas

tarefas de criar projetos e agentes JADE. Esses assistentes ajudam o usuário na

criação da pasta de trabalho no Workspace e na criação de arquivos Java contendo

o código dos agentes. No arquivo de manifesto foi declarada também a criação de

78

uma nova categoria para agrupar esses wizards. Assim no menu “File → New →

Other” do Eclipse aparecerá uma nova categoria chamada Jade, como pode ser

visto na figura 5.3, contendo os wizards “Jade Project” e “Jade Agent”.

Para a criação de um wizard são necessárias pelo menos duas classes.

Uma classe principal, associada à extensão declarada no arquivo de manifesto do

plug-in, e uma ou mais classes para cada página de configuração que o wizard

disponibiliza. Na classe principal são declaradas as páginas que serão carregadas e

a ordem em que elas serão apresentadas. Nesta classe também é configurado o

comportamento que o wizard terá quando este for encerrado, ou seja, quando todas

as páginas foram exibidas e o usuário tiver clicado em finish, ou então se o usuário

cancelar o wizard.

Figura 5.3 – Menu do Eclipse contendo os wizards do Jadeclipse.

5.2.3.1 Jade Project

79

O primeiro wizard que deve ser usado pelo usuário é o Jade Project, que

cria um novo projeto JADE. Através dele o usuário escolhe o nome do projeto e o

nome da pasta a ser criada no sistema de arquivos (o próprio Eclipse sugere um

nome de pasta e localização no sistema de arquivos). Com isso cria-se um projeto

JADE com o classpath configurado de forma correta, garantindo que seja possível

executar a plataforma JADE e carregar os agentes.

Figura 5.4 – Criação de um novo projeto Jade.

A classe principal utilizada na implementação de um novo projeto JADE é

a JadeProjectCreationWizard. Esta é a classe responsável por gerenciar todo

o funcionamento do wizard. Nela são declaradas duas páginas. Uma para o usuário

configurar o nome do projeto e a sua localização no sistema de arquivos, e outra

onde são configuradas demais opções de um projeto Java qualquer. As classes que

80

implementam as páginas desse wizard pertencem à plataforma e foram apenas

instanciados objetos delas, dessa forma foi preciso apenas ater-se ao

comportamento executado ao término das páginas, que é configurar a nature do

projeto, e tratar quaisquer erros que possam acontecer.

5.2.3.2 Jade Agent

O outro wizard disponível pelo Jadeclipse é o que fornece ao usuário a

característica de criar agentes utilizando-se templates com diversos comportamentos

já pré-configurados. Isso facilita o trabalho do usuário, pois este não tem que ater-se

aos comandos básicos e repetitivos de configuração do agente para registrar-se na

plataforma JADE. Dessa forma o usuário escolhe o template com o respectivo

comportamento desejado e o Jadeclipse cria o código com as configurações

previamente obtidas, permitindo ao usuário concentrar-se apenas no comportamento

do agente.

A classe principal utilizada na implementação de um novo agente JADE é

a NewJadeAgentWizard. Esta é a classe principal do wizard que controla a

quantidade e a ordem de páginas usadas, no caso apenas uma, e também o

comportamento executado ao término do wizard, que é gerar um arquivo Java

baseado no template selecionado a abri-lo no editor Java padrão da plataforma.

NewJadeAgentWizard herda métodos de NewCreationWizard, classe esta

criada para centralizar operações de controle dos templates e geração do arquivo

baseado no template.

A única página deste wizard é implementada pela classe

NewJadeAgentWizardPage. Esta classe é responsável por gerar a interface que

81

será apresentada ao usuário na configuração do agente. Através da janela

apresentada ao usuário é possível configurar diversos parâmetros, tais como:

• Pasta de origem, ou seja, onde será criado o arquivo;

• Pacote;

• Superclasse, configurada por padrão em jade.core.Agent;

• Nome do agente;

• Opções de configuração no DF, tais como tipo e dono;

• Comportamento, obtido através dos templates disponíveis.

Figura 5.5 – Criação de um novo agente Jade.

Os templates são gerados utilizando como base arquivos Java presentes

no subdiretório templates do Jadeclipse. Estes arquivos são escritos com marcação

especial para diferenciar as diversas partes que o compõem, tais como marcação

82

para métodos, construtores, atributos, pacotes importados, etc. Na figura 5.6 é

possível entender melhor a marcação usada na estrutura dos arquivos de modelo.

No diretório principal do Jadeclipse há um arquivo de configuração dos templates,

chamado templates.properties, que relaciona o nome arquivo Java que o template

se baseia, com uma descrição de seu propósito. Este arquivo é utilizado pela classe

NewCreationWizard para a geração da lista de templates disponíveis na tela

apresentada ao usuário, e para a geração dos mesmos, utilizando os arquivos

associados.

<jc:import>jade.core.Agent</jc:import> <jc:import>jade.domain.DFService</jc:import> <jc:parentClass>jade.core.Agent</jc:parentClass> <jc:constructor name="c1"> public <jc:className/>() { super(); } </jc:constructor> <jc:method name="setup">

public void setup() { DFAgentDescription dfd = new DFAgentDescription(); ServiceDescription sd = new ServiceDescription(); sd.setType("<jc:type/>"); sd.setName(getName()); sd.setOwnership("<jc:ownership/>"); dfd.setName(getAID()); dfd.addServices(sd); try { DFService.register(this,dfd); } catch (FIPAException e) {

System.err.println(getLocalName()+" registration with DF unsucceeded. Reason: "+e.getMessage());

doDelete(); } MyBehaviour myBehaviour = new MyBehaviour(this); addBehaviour(myBehaviour); } </jc:method>

Figura 5.6 – Estrutura de um arquivo de modelo utilizado pelos templates.

5.2.4 ActionSets

83

Os ActionSets são usados no Jadeclipse para criar atalhos no menu e na

barra de ferramentas da plataforma Eclipse, atalhos estes que servem para carregar

a interface gráfica da plataforma JADE e agentes na plataforma em execução. Estes

ActionSets são implementados através das classes

StarPlattformActionDelegate e StartAgentActionDelegate, que são

bem parecidas, mudando apenas o método chamado para carregar a plataforma e

um agente respectivamente.

Figura 5.7 – ActionSets do Jadeclipse (barra de ferramentas e menu).

Como já colocado um plug-in não pode acessar métodos de bibliotecas

externas em seu código, com isso não é possível utilizar métodos da API de JADE

para carregar a plataforma e agentes de dentro de qualquer aplicação Java. Para

contornar essa limitação foram criadas duas classes que têm por função configurar

os parâmetros e carregar uma nova JVM como se fosse através da linha de

comando no sistema operacional. A primeira delas é a JadeBoot, cujas principais

funções são configurar o classpath para localizar o código do agente e configurar os

84

parâmetros de inicialização do JADE de acordo com a classe que a chama, ou seja,

se é para carregar a plataforma ou um agente. A outra classe criada é a

VMLauncherUtility, que é responsável por localizar a JRE29 instalada no sistema

e criar uma nova JVM com os parâmetros recebidos de JadeBoot. Portanto através

dessas duas classes consegue-se invocar tanto a plataforma quanto agentes de

forma a suprir a limitação do uso de métodos de bibliotecas externas.


Neste capítulo foi apresentado o Jadeclipse Plug-in, tema central deste

trabalho, mostrando sua arquitetura, bem como suas principais funcionalidades,

classes e contribuições à plataforma Eclipse.

Foram apresentados também conceitos de desenvolvimento de plug-ins

para o Eclipse, detalhando a estrutura do arquivo de manifesto e principais pontos

de extensão da plataforma.

6 CONCLUSÃO

29 Java Runtime Environment: ambiente de execução de aplicativos Java.

85

Neste trabalho foi apresentado o desenvolvimento do Jadeclipse Plug-in,

módulo responsável por integrar duas ferramentas de código aberto bastante

utilizadas, construindo assim um ambiente poderoso para o desenvolvimento de


Inicialmente foi apresentada toda a teoria a respeito de sistemas

multiagentes, tais como características principais e mecanismos de comunicação e

coordenação. Foram apresentados também os padrões definidos por FIPA para

interoperabilidade de sistemas multiagentes. Padrões estes que são seguidos

rigorosamente por JADE.

Em seguida apresentou-se a ferramenta JADE, suas funcionalidades e,

principalmente, toda a arquitetura que JADE fornece ao usuário, de modo que este

não precisa preocupar-se com a implementação de uma plataforma eficiente de

agentes, bem como a comunicação, troca de mensagens e muitos outros atributos

que um sistema multiagente necessita.

Por fim apresentou-se a plataforma Eclipse e introduziram-se os conceitos

de plug-ins para adaptar a plataforma aos mais diversos usos, culminando com a

implementação do Jadeclipse e apresentação de suas contribuições à plataforma

Eclipse.

As contribuições mais importantes deste trabalho referem-se às

funcionalidades que o Jadeclipse proporciona ao desenvolvedor, que são:

• Ambiente robusto para edição de código fonte, onde são

disponibilizadas ao usuário diversas facilidades, tais como

complementação de código, depuração e trabalho em equipe.

• Uso de wizards que guiam o usuário para a configuração correta dos

parâmetros de inicialização da plataforma e dos agentes;

86

• Utilização de templates para a geração de código pré-configurado,

onde são gerados os comandos básicos para o registro do agente na

plataforma JADE e configuração de seu comportamento;

• Atalhos que proporcionam ao desenvolvedor as tarefas de compilação

e execução dos agentes e da plataforma de agentes diretamente no

ambiente de edição, sem a necessidade de alternar entre ferramentas

para a execução dessas tarefas.

Apesar das dificuldades iniciais, os objetivos do trabalho foram obtidos

com êxito. Dificuldades como o difícil acesso a material referente ao Eclipse, pois

trata-se de um ambiente relativamente novo e com poucos livros a respeito,

atrasaram um pouco o andamento do trabalho, mas ao final saiu como planejado.

Como propostas para trabalhos futuros destacam-se:

• Novos templates para auxilio na criação de classes de mensagens,

comportamentos e agentes genéricos, tais como agentes móveis;

• A criação de visões para exibição de todos os agentes em execução na

plataforma;

• Novos actionSets para os controles de criar, migrar, clonar e excluir

agente, e para atalhos às ferramentas de gerenciamento e depuração

presentes no JADE;

• Criar um plug-in com as bibliotecas do JADE e utilizá-lo no Jadeclipse

que maneira que este possa tornar-se totalmente funcional sem

necessitar de qualquer instalação do JADE.

REFERÊNCIAS

87

AgentTool. Disponível em: <http://www.cis.ksu.edu/~sdeloach/ai/>. Acesso em: 05

mai. 2004.

ALVARES, Luís Otávio; SICHMAN, Jaime Simão. Introdução aos Sistemas Multiagentes. Jornada de Atualização em Informática. XVII Congresso da

Sociedade Brasileira de Computação. Brasília, 1997.

BAKER, Albert. JAFMAS – A java-based agent framework for multiagent systems: Development and Implementation. Department of Electrical & Computer

Engineering and Computer Science University of Cincinnati, 1997. Doctoral thesis.

Disponível em: <http://www.ececs.uc.edu/~abaker/JAFMAS/>. Acesso em: 23 jul.

2004.

BARRETO, J. M. A Inteligência Artificial no limiar do século XXI. 3 ed.

Florianópolis. PPP Edições, 2001.

BELLIFEMINE, Fabio; CAIRE, Giovanni; TRUCCO, Tiziana; RIMASSA, Giovanni.

JADE Programmer’s Guide. 2003a. Disponível em: <http://sharon.cselt.it/projects/

jade/doc/programmersguide.pdf>. Acesso em: 05 mai. 2004.

BELLIFEMINE, Fabio; CAIRE, Giovanni; TRUCCO, Tiziana; RIMASSA, Giovanni.

JADE Administrator’s Guide. 2003b. Disponível em: <http://sharon.cselt.it/projects/

jade/doc/administratorsguide.pdf>. Acesso em: 05 mai. 2004.

BIGUS, Joseph P.; BIGUS Jennifer. Constructing Intelligent Agents Using Java. 2nd Edition. Wiley Computer Publishing, 2001.

CAIRE, Giovanni. JADE Programing For Beginners . 2003. Disponível em:

<http://sharon.cselt.it/projects/jade/doc/JADEProgramming-Tutorial-for-

beginners.pdf>. Acesso em: 05 mai. 2004.

88

DEITEL, H. M. & DEITEL, P. J. Java: Como Programar. 3a. Edição. Porto Alegre.

Bookman, 2000.

Eclipse. Disponível em: <http://www.eclipse.org>. Acesso em: 11 mai. 2004.

Eclipse Platform Technical Overview. 2003. Disponível em:

<http://www.eclipse.org/whitepapers/technical-overview.pdf>. Acesso em: 15 jun.

2004.

FERBER, Jacques. Multi-Agent Systems: An Introduction to Distributed Artificial

Intelligence. 1st Edition. Addison-Wesley Pub Co, 1999.

FIPA Specification. 2000. Disponível em: <http://www.fipa.org/repository/

fipa2000.html>. Acesso em: 15 jun. 2004.

GALLARDO, David; BURNETTE, Ed; MCGOVERN, Robert. Eclipse in Action: A

Guide for Web Developers. 1st Edition. Manning Publications, 2003.

GUDWIN, Ricardo R. Introdução à Teoria de Agentes. DCA-FEEC-UNICAMP.

Disponível em <http://www.dca.fee.unicamp.br/~gudwin/courses/IA009/>. Acesso

em: 10 mai. 2004.

JADE – Java Agent Development Framework. Disponível em:

<http://jade.tilab.com/>. Acesso em: 15 jun. 2004.

WOOLDRIDGE, M.; JENNINGS, N. Intelligent Agents: Theory and Practice.

Knowledge Engineering Review. V. 10. Cambridge University Press, 1995.

Disponível em: < http://www.csc.liv.ac.uk/~mjw/pubs/ker95/ker95-html.html>. Acesso

em: 21 jul. 2004.

MENESES, Eudenia Xavier. Jornada de Atualização em Inteligência Artificial – Integração de Agentes de Informação. 2001. Disponível em:

<http://www.ime.usp.br/~eudenia/jaia/>. Acesso em: 15 mai. 2004.

89

NWANA, S. H. Software agents: an Overview. Knowledge Engineering Review. Vol.

11, No 3. Cambridge University Press, 1996. Disponível em:

<http://agents.umbc.edu/introduction/ao/>. Acesso em: 25 jul. 2004.

RUSSEL, S. J.; NORVIG, P. Artificial Intelligence – A modern approach. New

Jersey: Ed. Prentice Hall, 1995.

SANTOS. N. M dos. Agentes autônomos inteligentes. Disponível em:

<http://www.din.uem.br/ia/vida/agentes/apresentacao.htm>. Acesso em: 05 mai.

2004.

SILBERSCHATZ, Abraham & GALVIN, Peter & GAGNE, Greg. Sistemas Operacionais – Conceitos e Aplicações. 1a. Edição. Rio de Janeiro. Editora

Campus, 2001.

TORSUN, I.S. Foundations of Intelligent Knowledge-based systems. London.

Academic Press, 1995.

WEISS, Gerhard. Multi-Agent Systems. A Modern Approach to Distributed Artificial Intelligence. MIT Press, 1999.

Zeus. Disponível em: <http://more.btexact.com/projects/agents/zeus/>. Acesso em:

21 jul. 2004.

JADECLIPSE - PLUGIN PRA INTEGRAÇÃO ENTRE JADE E ECLIPSE

Documents

Transcript of JADECLIPSE - PLUGIN PRA INTEGRAÇÃO ENTRE JADE E ECLIPSE