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
DANIEL LOPES SOARES LIMA
JADECLIPSE – PLUG-IN PARA INTEGRAÇÃO ENTRE JADE E ECLIPSE: Desenvolvimento e Implementação
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
DANIEL LOPES SOARES LIMA
JADECLIPSE – PLUG-IN PARA INTEGRAÇÃO ENTRE JADE E ECLIPSE: Desenvolvimento e Implementação
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
3.7 Considerações Finais .......................................................................................54
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
4.3 Considerações Finais .......................................................................................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
5.3 Considerações Finais .......................................................................................84
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
sistemas multiagentes.
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
3.7 Considerações Finais
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.
4.3 Considerações Finais
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.
5.3 Considerações Finais
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
sistemas multiagentes.
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.
Top Related