universidade do vale do itajaÍ centro de ciÊncias tecnolÓgicas da terra e...
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
GILGAMESH – FERRAMENTA DE E-COMMERCE PARA LEILÕES E PESQUISA DE PREÇOS
Área de Inteligência Artificial
por
Rafael de Santiago
Rudimar Luís Scaranto Dazzi, M.Sc. Orientador
Márcia Cristina Schiavi Dazzi, M.Sc. Co-orientadora
Itajaí (SC), novembro de 2006
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
GILGAMESH – FERRAMENTA DE E-COMMERCE PARA LEILÕES E PESQUISA DE PREÇOS
Área de Inteligência Artificial
por
Rafael de Santiago Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Rudimar Luís Scaranto Dazzi, M.Sc.
Itajaí (SC), novembro de 2006
ii
DEDICATÓRIA
Dedico todos os meus esforços, minha incansável vontade, bem como todo este trabalho, aos
meus verdadeiros heróis: Mario César de Santiago e Evanir Bechtold de Santiago.
iii
AGRADECIMENTOS
Agradeço inicialmente a minha família. A meu pai e minha mãe, pelo apoio dado em toda
minha vida, ao meu irmão pelos momentos de exclusividade no computador, e ótimo
relacionamento fraterno. A meus avós pelas palavras doces e o grande exemplo de vivência.
Agradeço também a Carolina Zukoski Pedro, que como companheira, me ajudou a manter a
calma e a sanidade, quando as trevas encobriam meus pensamentos.
Meus orientadores, o casal Rudimar e Márcia Dazzi foram imprescindíveis. Foi através dos
conselhos e da fé deles em minhas idéias que a conclusão desse trabalho foi possível. São tutores
por vocação e amigos para a vida inteira.
Aos mestres que ajudaram a trilhar meu caminho. Agradecimentos especiais a professora
Anita Maria da Rocha Fernandes, que sempre esteve ao meu lado, a Elisangela Maschio de Miranda
que sempre me ajudou quando mais precisei, ao professor Rafael Luiz Cancian, pelo pulso firme e
os conhecimentos fantásticos, ao professor Ovidio Felippe Pereira da Silva Júnior e ao professor
Antônio Carlos de Novaes e Silva, pelas noções fundamentais no despertar da consciência
empreendedora.
Ao querido coordenador Luís Carlos Martins, que sempre nos deu atenção devida, bem
como o crédito cedido ao nosso esforço nessa caminhada.
Agradecimentos ao grupo de RPG Lamia, por estarem sempre me fornecendo o suporte que
só os amigos conseguem dispor.
Agradeço também ao grupo de pesquisa do LIA (Laboratório de Inteligência Aplicada) da
UNIVALI, onde encontrei amigos, conhecimentos e muito trabalho.
Aos companheiros de trabalho da empresa, Ivan Correia Filagrana, José Vanderlei de
Menezes e Artur Sonnenhohl, que sempre prestaram idéias e apoio ao meu trabalho, além da
confiança, fundamental ao dia a dia na empresa.
Obrigado companheiros, amigos e irmãos.
iv
SUMÁRIO
Dedicatória .................................................................................................ii AGRADECIMENTOS.............................................................................iii LISTA DE ABREVIATURAS.................................................................vi LISTA DE FIGURAS .............................................................................vii LISTA DE TABELAS..............................................................................ix
RESUMO ..................................................................................................xi ABSTRACT .............................................................................................xii 1 INTRODUÇÃO.....................................................................................1 1.1 PROBLEMATIZAÇÃO ..................................................................................... 3 1.1.1 Formulação do Problema ................................................................................. 3 1.1.2 Solução Proposta ............................................................................................... 3 1.2 OBJETIVOS ........................................................................................................ 3 1.2.1 Objetivo Geral ................................................................................................... 3 1.2.2 Objetivos Específicos ........................................................................................ 4 1.3 METODOLOGIA................................................................................................ 4 1.4 ESTRUTURA DO TRABALHO ....................................................................... 5
2 FUNDAMENTAÇÃO TEÓRICA .......................................................6 2.1 COMÉRCIO ELETRÔNICO ............................................................................ 6 2.1.1 Comércio Eletrônico e Agentes Inteligentes................................................... 7 2.2 SISTEMAS DE COMÉRCIO ELETRÔNICO PARA BUSCA DE PRODUTOS................................................................................................................. 8 2.2.1 Mecanismos de Busca na Web......................................................................... 8 2.2.2 Exemplo de Ferramenta de Busca na Web: Google .................................... 11 2.2.3 Exemplo de Sistemas de Pesquisa de Produtos............................................ 13 2.3 LEILÕES............................................................................................................ 18 2.3.1 Tipos de Leilões ............................................................................................... 19 2.3.2 Mecanismos de Encerramento....................................................................... 20 2.3.3 Leilões Virtuais................................................................................................ 21 2.4 INTELIGÊNCIA ARTIFICIAL ...................................................................... 27 2.4.1 Agentes Inteligentes ........................................................................................ 28 2.4.2 Sistemas Especialistas..................................................................................... 38
3 Desenvolvimento .................................................................................40 3.1 MODELAGEM.................................................................................................. 41 3.1.1 Levantamento de Requisitos .......................................................................... 41 3.1.2 Características dos Agentes ........................................................................... 43 3.1.3 Modelo de Casos de Uso ................................................................................. 45
v
3.1.4 Modelos de Interação...................................................................................... 61 3.1.5 Diagramas de Classes ..................................................................................... 70 3.1.6 Diagrama Entidade Relacionamento ............................................................ 79 3.1.7 Árvores de Decisão.......................................................................................... 90 3.2 IMPLEMENTAÇÃO ........................................................................................ 93 3.2.1 Utilização do RMI ........................................................................................... 93 3.2.2 Base de Dados .................................................................................................. 95 3.2.3 IDE NetBeans .................................................................................................. 95 3.2.4 Implementação dos Agentes........................................................................... 95 3.2.5 Implementação do Sistema Especialista ....................................................... 96 3.2.6 Implementação dos Web crawlers................................................................. 99 3.2.7 Implementação dos Agentes de Busca de Preços ......................................... 99 3.3 TESTES ............................................................................................................ 103 3.3.1 Guia de Avaliação da Qualidade de Produto de Software........................ 103 3.3.2 Teste Baseado nas Funcionalidades do Sistema......................................... 104 3.4 A FERRAMENTA........................................................................................... 106 3.4.1 Funções Gerais da Ferramenta ................................................................... 106 3.4.2 Módulo de Leilões ......................................................................................... 110 3.4.3 Módulo de Busca de Preços de Produtos .................................................... 116
4 CONCLUSÃO...................................................................................118
REFERÊNCIAS BIBLIOGRÁFICAS ................................................121
A QUESTIONÁRIO DE TESTES ......................................................125 A.1 QUESTIONÁRIO DE AVALIAÇÃO DE QUALIDADE DE PRODUTO DE SOFTWARE ............................................................................................................ 125 A.1.1 Quesito Documentação ................................................................................. 125 A.1.2 Quesito Interface ........................................................................................... 129 A.1.3 Quesito Funcionalidade ................................................................................ 133
vi
LISTA DE ABREVIATURAS
ACL Agent Communication Language B2C Business to Consumers C2B Consumers to Business C2C Consumer to Consumer CD Compact Disc CENPRA Centro de Pesquisas Renato Archer CLIPS C Language Integrated Production System EDI Electronic Data Interchange ER Entidade Relacioamento FIPA Fipa Foundation for Intelligent Physical Agents FIPA-OS Fipa Foundation for Intelligent Physical Agents – Open Source G2C Government to Consumer HTML HyperText Markup Language IA Inteligência Artificial IAD Inteligência Artificial Distribuída IDE Integrated Development Environment IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol JADE Java Agent Development Framework KQML Knowledge Query Manipulation Language NASA National Aeronautics and Space Admistration PC Personal Computer RMI Remote Method Invocation RN Regras de Negócio RF Requisitos Funcionais RNF Requisitos Não Funcionais SACI Simple Agent Communication Infrastructure SBC Sistema Baseado Conhecimento SGBD Sistema Gerenciador de Banco de Dados SMA Sistema Multiagente SMTP Simple Mail Transfer Protocol SQL Structured Query Language URL Uniform Resource Locator TCC Trabalho de Conclusão de Curso TCP Transmission Control Protocol WWW World Wide Web UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí XML Extensible Markup Language
vii
LISTA DE FIGURAS
Figura 1. Arquitetura de um Web crawler .........................................................................................10 Figura 2. Arquitetura do mecanismo de busca do Google .................................................................12 Figura 3. Resultados da busca em Jango............................................................................................15 Figura 4. Pesquisa no BuscaPé...........................................................................................................16 Figura 5. Resultado da pesquisa no Buscapé .....................................................................................16 Figura 6. Resultado da pesquisa Bondfaro.........................................................................................17 Figura 7. Resultado de busca por produto..........................................................................................22 Figura 8. Detalhamento de oferta no Mercado Livre .........................................................................22 Figura 9. Tipos de leilões do AuctionBot ..........................................................................................24 Figura 10. Arquitetura do AuctionBot ...............................................................................................26 Figura 11. Mensagem em KQML ......................................................................................................34 Figura 12. Mensagem em FIPA-ACL................................................................................................35 Figura 13. Criando um agente utilizando o JADE .............................................................................37 Figura 14. Implementação de Comportamento ..................................................................................38 Figura 15. Arquitetura do sistema Gilgamesh....................................................................................40 Figura 16. Casos de uso da ferramenta Gilgamesh ............................................................................46 Figura 17. Casos de uso do módulo de leilões ...................................................................................50 Figura 18. Caso de uso do módulo de busca de produto....................................................................54 Figura 19. Casos de uso dos agentes do módulo de leilões................................................................55 Figura 20. Casos de uso dos agente do módulo de busca de produtos...............................................58 Figura 21. Diagrama de seqüência de cadastro de usuário ................................................................62 Figura 22. Diagrama de seqüência de criação de leilões....................................................................64 Figura 23. Diagrama de seqüência de sumissão de lances.................................................................65 Figura 24. Diagrama de seqüência de busca de produtos ..................................................................66 Figura 25. Diagrama de seqüência dos agentes do processo de busca de produtos na Web.............68 Figura 26.Diagrama de seqüência dos agentes envolvidos no processo de leilão ............................70 Figura 27. Diagrama de classes da ferramenta...................................................................................71 Figura 28. Diagrama de classes dos agentes do Gilgamesh...............................................................75 Figura 29. Diagrama ER do módulo de leilões ..................................................................................80 Figura 30. Diagrama ER do módulo de busca de produtos................................................................88 Figura 31. Árvore de decisão do agente Arrematante........................................................................92 Figura 32. Árvore de decisão do agente Ofertante.............................................................................93 Figura 33. Uso do RMI e distribuição das aplicações........................................................................94 Figura 34. Resolução dos problemas do JClips..................................................................................98 Figura 35. Funcionamento da solução aos problemas com JClips.....................................................99 Figura 36. Código quebrado em busca de conteúdos.......................................................................101 Figura 37. Busca por preço de produto ............................................................................................102 Figura 38. Busca por nome de produto ............................................................................................102 Figura 39. Cadastro de usuário.........................................................................................................107 Figura 40. Autenticação no sistema .................................................................................................108 Figura 41. Interface principal do sistema .........................................................................................109 Figura 42. Interface do cadastro de leilões.......................................................................................111 Figura 43. Interface do seleção de produtos.....................................................................................112 Figura 44. Cadastro de lances ..........................................................................................................114 Figura 45. Tipo automático de lances ..............................................................................................115 Figura 46. Tipo de lances únicos......................................................................................................116
viii
Figura 47. Interface de busca por preços de produtos......................................................................116
ix
LISTA DE TABELAS
Tabela 1. Comparativo entre as ferramentas de pesquisa de preços ..................................................18 Tabela 2. Comparativo entre as ferramentas de leilão .......................................................................27 Tabela 3. Propriedades dos agentes do Gilgamesh ............................................................................44 Tabela 4. Classificação e caracterização dos agentes do Gilgamesh .................................................45 Tabela 5. Atributos da classe GLance................................................................................................71 Tabela 6. Operações da classe GLance ..............................................................................................72 Tabela 7. Atributos da classe GLeilao ...............................................................................................72 Tabela 8. Operações da classe GLeilao..............................................................................................72 Tabela 9. Atributos da classe GUsuario .............................................................................................73 Tabela 10. Operações da classe GUsuario .........................................................................................73 Tabela 11. Atributos da classe GProduto ...........................................................................................73 Tabela 12. Operações da classe GProduto .........................................................................................74 Tabela 13. Atributos da classe GOferta .............................................................................................74 Tabela 14. Operações da classe GOferta............................................................................................74 Tabela 15. Atributos da classe GAgOfertante....................................................................................76 Tabela 16. Operações da classe GAgOfertante..................................................................................76 Tabela 17. Atributos da classe GAgArrematante...............................................................................76 Tabela 18. Operações da classe GAgArrematante .............................................................................77 Tabela 19. Atributos da classe GAgBuscaLeilao...............................................................................77 Tabela 20. Operações da classe GAgBuscaLeilao .............................................................................77 Tabela 21. Atributos da classe GAgWebCrawler ..............................................................................78 Tabela 22. Operações da classe GAgWebCrawler.............................................................................78 Tabela 23. Atributos da classe GAgBuscaProduto ............................................................................78 Tabela 24. Operações da classe GAgBuscaProduto...........................................................................78 Tabela 25. Dicionário de dados da entidade GMSH_USUARIO ......................................................81 Tabela 26. Dicionário de dados da entidade GMSH_PRODUTO .....................................................81 Tabela 27. Dicionário de dados da entidade GMSH_GRUPO ..........................................................82 Tabela 28. Dicionário de dados da entidade GMSH_SUBGRUPO...................................................82 Tabela 29. Dicionário de dados da entidade GMSH_PRODCARAC ...............................................82 Tabela 30. Dicionário de dados da entidade GMSH_CARACS........................................................83 Tabela 31. Dicionário de dados da entidade GMSH_OFERTA ........................................................83 Tabela 32. Dicionário de dados da entidade GMSH_LANCE...........................................................84 Tabela 33. Dicionário de dados da entidade GMSH_TPARREMAT................................................84 Tabela 34. Dicionário de dados da entidade GMSH_TPAGENT......................................................84 Tabela 35. Dicionário de dados da entidade GMSH_LEIAGENT ....................................................85 Tabela 36. Dicionário de dados da entidade GMSH_TRANS...........................................................85 Tabela 37. Dicionário de dados da entidade GMSH_LANCFECHADO ..........................................85 Tabela 38. Dicionário de dados da entidade GMSH_TRANSAGENT .............................................86 Tabela 39. Dicionário de dados da entidade GMSH_LEILAO .........................................................86 Tabela 40. Dicionário de dados da entidade GMSH_DETLANCE...................................................87 Tabela 41. Dicionário de dados da entidade GMSH_SITE ...............................................................88 Tabela 42. Dicionário de dados da entidade GMSH_PRODRECUP ................................................89 Tabela 43. Dicionário de dados da entidade GMSH_LINK ..............................................................89 Tabela 44. Dicionário de dados da entidade GMSH_PAGINA.........................................................90 Tabela 45. Dicionário de dados da entidade GMSH_CRITERIO .....................................................90 Tabela 46. Dicionário de dados da entidade GMSH_TEMPLATE ...................................................90
x
Tabela 47. Trocas de mensagens entre agentes do módulo de leilões ...............................................96 Tabela 48. Testes sobre as funcionalidades do Gilgamesh ..............................................................105
xi
RESUMO
SANTIAGO, Rafael de. Gilgamesh – Ferramenta de E-Commerce para Leilões e Pesquisa de Preços. Itajaí, 2006. 148 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2006. A disseminação das tecnologias de informação, principalmente da Internet, está intensificando a utilização de ferramentas virtuais, como o comércio eletrônico. Dois exemplos disso são os leilões virtuais e a pesquisa de preços de produtos em lojas virtuais. No entanto, essas ferramentas costumam estar dissociadas, não convergindo em um software que possua estas características, principalmente na versão livre. A fim de disponibilizar uma ferramenta que agregue, inicialmente, essas funcionalidades, foi realizado o projeto e implementação do sistema Gilgamesh. A ferramenta Gilgamesh possibilita que pessoas utilizem um sistema de comércio eletrônico com mais de uma aplicação, pois o mesmo possui a busca de preços de produtos e leilões virtuais. Esse software tem como base um apelo pela automação das tarefas de leilão e de busca de preços, com a tecnologia de multiagentes que foi empregada por meio do framework JADE (Java Agent Development Framework). Esses agentes foram projetados com o intuito de possuir o conhecimento necessário para executarem suas tarefas por meio do Sistema Especialista JClips. No Gilgamesh, os agentes assumem papéis diferentes em módulos que convergem a uma ferramenta de comércio eletrônico. No módulo de leilões, os agentes trabalham, principalmente, como entidades de leilão (arrematante e ofertante), enquanto no módulo de busca de preços, os agentes estão envolvidos com a busca (Web crawling) e reconhecimento de produtos em sites de lojas virtuais. Outra característica importante do Gilgamesh é sua portabilidade, pois esse software foi desenvolvido na linguagem Java, da empresa Sun, necessitando apenas da máquina virtual para sua execução. Para facilitar o estudo e o uso da ferramenta, todas as tecnologias utilizadas no projeto não possuem licenças que requerem recursos financeiros dos usuários. Ao final da implementação, os testes realizados com a ferramenta revelaram que apesar da necessidade de mecanismos mais didáticos para auxiliar usuários inexperientes, o Gilgamesh possui uma interface de uso simplificada e organizada, com funcionalidades executando de forma prevista. Com a idealização do Gilgamesh, espera-se que o projeto contribua para que novas ferramentas possam usufruir das tecnologias de Inteligência Artificial em aplicações de comércio eletrônico. Palavras-chave: Inteligência Artificial. Agentes. E-Commerce.
xii
ABSTRACT
The spread of information tecnologies, mainly on Internet, is intensifing the use of virtual tools, like the electronic commerce. Two examples for that are the virtual auctions and the price research of products on virtual stores. Though, these tools are generally unassociated, not converging on a software with such characteristics, mainly in a free version. In ought to provide a tool that binds, inicially, these functionalities, it was made the project and implementation of Gilgamesh system. The Gilgamesh tool makes possible that people use a electronic system commerce with more than one application, because the software have the product price research and the virtual auctions tool. This software have as a base for automation of auction tasks and price research, with the multiagent technology that was applied thru the JADE (Java Agent Development Framework) framework. These agents were projected in the intention od having the knowledge needed to execute its tasks thru the Specialist System JClips. On Gilgamesh, the agents take different parts on modules that converge to an electronic commerce tool. On the auction module, the agents work, mainly, as auction entities (bidder and auctioneer), while on the price research module, the agents are involved with the search (Web crawling) and acknowledgement of products on web sites of virtual stores. Another important characteristic of Gilgamesh is its portability, as it is a software developed on Java language, from Sun, needed only a virtual machine for its execution. To make easier the study and use of the tool, all the used technologies on the project don't have licenses that requires financial resources from its users. At the end of the implementation, the tests made with the tool revealed that although the need of mode didatics mechanisms to help inexperienced users, the Gilgamesh has a use interface simplified and organized, with functionalities executing as expected. With the idealization of Gilgamesh, it is expected that the project may contribute that the new tools may to usufruct of the Artificial Intelligence technologies in electronic commerce applications. Keywords: Artificial Intelligence. Agents. E-Commerce.
1 INTRODUÇÃO
No início da história das civilizações, o homem verificou que seus semelhantes
necessitavam de produtos que ele possuía em quantidade maior do que ele poderia consumir. Essa
necessidade de consumo de outras pessoas determinou que o homem pudesse fazer trocas de seus
produtos. Foi a partir dessa percepção do homem primitivo em fazer trocas obtendo vantagens que
iniciou-se a prática do comércio (MEIRELLES, 1983).
No decorrer das eras, o homem estabeleceu rotas de comércio, grandes navegações, fundiu
culturas em busca do comércio. Foi graças as grandes rotas marítimas que as Américas foram
descobertas. Desde os caminhos desbravados pelas caravelas até a formação de superpotências
mundiais, o comércio deixou marcas profundas na história da humanidade, sempre impulsionando o
homem a novas descobertas (MEIRELLES, 1983).
Com o advento da era dos computadores, e com a necessidade crescente em disponibilizar
informações de maneira confiável e rápida, as organizações e as pessoas careciam de trocas
comerciais mais inovadoras. Desde o surgimento das primeiras conexões de redes entre
computadores, que resultaram no surgimento da Internet, as empresas observaram que poderiam
ganhar vantagens utilizando a mais alta tecnologia empregada ao comércio. A alta disponibilidade
que um sistema computacional, totalmente conectado, poderia fornecer aos negócios se tornou um
dos principais motivos para sua aplicação nas trocas comerciais. Com isso, surgiu um conceito
revolucionário, que modificou o significado dos negócios, denominado de e-Commerce (O’BRIEN,
2004).
O comércio eletrônico (ou e-Commerce) teve seu princípio na década de 70, com a
transferência eletrônica de fundos. Em seus primeiros passos, as aplicações se resumiam a grandes
transações. Depois, o intercâmbio eletrônico de dados permitiu que outros tipos de transações
ocorressem, possibilitando a participação de todos os setores do comércio. (TURBAN; POTTER e
RAINER, 2003)
O conceito de e-Commerce está mudando a forma de concorrência entre vendedores e
compradores, a velocidade entre as trocas comerciais e a natureza de liderança nas empresas.
Simplificando, esta revolução atua de maneira a melhorar as interações de comércio, facilitar a
2
demonstração do produto, fornecer pagamentos dos clientes às empresas, e da mesma a seus
fornecedores (O’BRIEN, 2004).
O comércio eletrônico pode ser dividido, atualmente, em algumas categorias. A categoria de
comércio C2C (Consumer-to-Consumer – consumidor-a-consumidor) engloba negócios onde
consumidores negociariam entre si a compra e venda de mercadorias como, por exemplo, um leilão
eletrônico. A categoria B2C (Business-to-Consumers, significa empresa-a-consumidor) é
caracterizada pelo mercado eletrônico onde empresas disponibilizam vendas de produtos e serviços,
um exemplo são os sites de compras. B2B (Business-to-Business, significa empresa-a-empresa) é a
categoria que envolve mercados eletrônicos e ligações de mercado entre as empresas como, por
exemplo, o intercâmbio eletrônico de dados (EDI) via Internet (O’BRIEN, 2004).
Ferramentas de comércio virtual são facilmente encontradas nos diversos sites da Internet.
Contudo, é difícil encontrar ferramentas que contemplem mais do que uma categoria de e-
commerce. Se um comprador deseja verificar se há algum leilão de um determinado produto, e ao
mesmo tempo, verificar se há alguma oferta do mesmo produto em alguma loja virtual, ele pode não
dispor de ferramentas para auxiliá-lo nesta tarefa.
Este projeto implementa uma ferramenta de e-commerce, que contempla aplicações de
categorias de comércio C2C e B2C. Esta ferramenta foi dividida em duas funções básicas: leilão e
busca de produtos mais baratos. Outra divisão está de acordo com o modelo Cliente / Servidor. No
lado Cliente, o usuário poderá visualizar uma interface em modelo Cliente / Servidor. Ainda na
aplicação Cliente, o usuário pode acessar uma lista de opções e configurações para poder realizar
sua busca por leilões e ofertas de um produto determinado. No lado Servidor, existe uma aplicação
dedicada, na qual, diversos clientes se conectam a fim de criar ou participar de leilões, ou ainda,
buscar ofertas de produtos.
A ferramenta do projeto foi denominada de Gilgamesh. A origem do nome provém de um
rei sumério que governou depois do dilúvio histórico. A mitologia conta que esse rei era dois terços
deus e um terço homem. Na obra “Epopéia de Gilgamesh”, é descrita a vida do rei Gilgamesh, e
também uma das mais antigas referências sobre comércio (WIKIPEDIA, 2005).
3
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
Há diversas ferramentas de comércio eletrônico disponíveis no mercado, mas não é comum
encontrar sistemas que contemplem mais de uma modalidade em uma única aplicação. Além disso,
ferramentas desse tipo que utilizem recursos computacionais para auxiliar o usuário a executar
tarefas exaustivas de maneira mais simples são necessárias.
Leilões eletrônicos geralmente não possuem aplicações de lances automáticos, ou mesmo
ferramentas que contemplem outras modalidades de comércio eletrônico. O mesmo ocorre com as
ferramentas de busca de preços na Web. Uma ferramenta que agregue as duas funcionalidades
supracitadas, utilizando a comodidade da automação de lances com o acesso a preços de ofertas
tanto de leilões quanto de lojas virtuais, poderá trazer mais conforto e comodidade a um usuário
interessado em comprar ou vender produtos.
1.1.2 Solução Proposta
Para solucionar o problema identificado, criou-se um sistema que possui características
encontradas em ferramentas de leilões e de busca de preços em lojas virtuais. Desse modo, usuários
podem utilizar o módulo de leilões para criar leilões ou submeter lances, e um módulo de busca de
produtos, onde estão disponíveis informações previamente mapeadas de produtos em lojas virtuais.
Esta ferramenta utiliza o modelo Cliente/Servidor, possibilitando que os processamentos que
consomem mais desempenho da máquina fiquem em uma máquina dedicada a aplicação, enquanto
as máquinas Clientes possam usufruir do sistema sem sobrecarga.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo desse projeto é desenvolver uma ferramenta de e-Commerce, com um módulo de
leilão e um módulo de busca de preços de produtos na Internet, ambas para comércio em geral.
4
1.2.2 Objetivos Específicos • Analisar o funcionamento de leilões;
• Selecionar técnicas de buscas de preços em sites da Internet;
• Identificar e analisar ferramentas eletrônicas de leilões;
• Pesquisar e analisar ferramentas eletrônicas de busca de preços de produtos;
• Pesquisar e analisar o funcionamento de agentes em ambientes de e-Commerce;
• Pesquisar bibliotecas e/ou ferramentas para implementação de agentes que poderá ser
utilizada no projeto;
• Definir heurística utilizada para os diferentes agentes do software;
• Modelar o sistema Gilgamesh;
• Implementar o sistema Gilgamesh; e
• Testar o sistema Gilgamesh.
1.3 METODOLOGIA
Na primeira etapa, foi realizada uma pesquisa bibliográfica sobre comércio eletrônico com a
intenção de se obter um embasamento fundamental a sistemas do tipo. Nas duas etapas seguintes,
foram realizadas a pesquisa e a análise sobre o funcionamento de leilões e ferramentas de busca de
preços de produtos na Web, respectivamente, adquirindo assim conhecimentos necessários para
projetar as principais funcionalidades do Gilgamesh. A quarta etapa verificou e equiparou as
diferentes ferramentas de leilões e buscas de preços com o intuito de traçar um perfil de
funcionalidades entre as mesmas. Na quinta etapa, foi realizado um estudo sobre técnicas de
inteligência artificial, no qual pôde-se analisar as opções disponíveis para a inteligência dos agentes
do Gilgamesh. Na etapa seguinte, foram pesquisadas bibliotecas e ferramentas com o intuito de
encontrar meios de desenvolvimento de agentes para o sistema. Nas sétima, oitava e nova etapas
foram desenvolvidas as modelagens de projeto pertinentes às funcionalidades gerais da ferramenta,
dos agentes e da interface. Depois da realização dessas etapas, foram desenvolvidas,
respectivamente, as funcionalidades primordiais ao Gilgamesh (base da ferramenta), o módulo de
leilões eletrônicos e o módulo de busca de preços, onde os esforços foram centrados na
implementação da ferramenta Gilgamesh. Na seqüência a implementação, os testes foram
5
realizados através de questionário e análise da execução das funcionalidades do sistema. Durante
todo o decorrer do projeto ocorreu na redação da documentação desse Trabalho de Conclusão de
Curso.
1.4 ESTRUTURA DO TRABALHO
Esse trabalho de conclusão está estruturado em quatro capítulos: Introdução, Fundamentação
Teórica, Desenvolvimento e Conclusão.
O Capítulo 1, Introdução, apresentou uma visão geral do projeto. Neste visualiza-se o
problema proposto, os objetivos do projeto e a metodologia utilizada.
No Capítulo 2, Fundamentação Teórica, é apresentada uma revisão bibliográfica sobre os
assuntos envolvidos no projeto: leilões, buscas gerais e de preços na Web, comparações entre
ferramentas com propósito semelhante ao Gilgamesh e estudos sobre agentes.
O Capítulo 3, Desenvolvimento, explicita o projeto da ferramenta Gilgamesh, utilizando
diagramas UML (Unified Modeling Language), são descritos casos de uso, cenários do sistema,
requisitos, seqüência das funções e estruturas de dados do Gilgamesh. Além disso, são englobadas
informações sobre tecnologias utilizas, descrição de implementações e funcionamento do sistema
desenvolvido
O Capítulo 4, Conclusão, conclui o trabalho apresentando as considerações finais sobre os
objetivos, bem como os futuros passos para projetos posteriores.
2 FUNDAMENTAÇÃO TEÓRICA
Para levantar as informações necessárias ao desenvolvimento do projeto Gilgamesh, foram
realizados buscas e estudos, em livros, periódicos e artigos, focando os objetivos do projeto. Dentre
as informações levantadas, destacam-se: conceitos gerais de comércio eletrônico, conhecimentos
sobre leilões e busca de preços em lojas virtuais, e estudo de ferramentas virtuais com módulos
semelhantes aos implementados para a ferramenta. Os dados, informações e estudos realizados
podem ser vistos nesta sessão.
2.1 COMÉRCIO ELETRÔNICO
O comércio eletrônico abrange o processo on-line de desenvolvimento, marketing, venda,
entrega, atendimento e pagamento de produtos e serviços, negociados com consumidores no
mercado, interconectados através de uma rede de computadores. As aplicações de comércio
eletrônico dependem dos recursos tecnológicos disponíveis na Internet, Intranet, extranets, entre
outros (O’BRIEN, 2004).
No início da década 70, o comércio eletrônico surgiu através de aplicações entre grandes
empresas, como a transferência eletrônica de fundos. Essas aplicações se limitavam a um
intercâmbio de informações. Pouco tempo depois, outros tipos de transações foram acrescentando a
participação de outros setores. Atualmente, o comércio eletrônico possui uma ampla gama de
aplicações: lojas virtuais, busca de empregos, leilões, banco virtual (home banking) e colaboração
eletrônica entre parceiros de negócio (TURBAN; POTTER e RAINER, 2003).
De acordo com Turban, Potter e Rainer (2003), existem diversas modalidades de comércio
eletrônico:
• Comécio colaborativo (c-commerce): parceiros de negócios colaboram eletronicamente,
uns com os outros;
• Business-to-Consumers (B2C): organizações são os vendedores e pessoas físicas são os
compradores;
• Consumers-to-Business (C2B): os clientes possuem necessidade de adquirir produtos ou
contratar serviços. As organizações fornecem o que os clientes necessitam, através de
uma concorrência;
7
• Consumer-to-Consumer (C2C): uma pessoa vende produtos a outras pessoas
interessadas;
• Business-to-Business (B2B): organizações utilizam aplicações de comércio eletrônico
para aperfeiçoar suas operações;
• Governo para cidadãos e para outros (G2C): os governos prestam serviços a cidadãos,
outros governos e empresas, por intermédio de uma aplicação de comércio eletrônico; e
• Comércio móvel (m-commerce): comércio eletrônico se utiliza de ambiente de
comunicação sem conexão física.
O comércio eletrônico causou mudança no mundo dos negócios, pois seu surgimento
transformou significativamente as organizações, afetando-as como um todo. Desde uma simples
aquisição de material ou uma grande colaboração comercial, de publicidade a pagamento de contas,
muitas empresas passaram a usar o conceito de comércio eletrônico (TURBAN; POTTER e
RAINER, 2003).
Devido a essa demanda, foram empregadas diversas tecnologias nas ferramentas de
comércio eletrônico. Como exemplo disso, a utilização de técnicas de Inteligência Artificial está
presente em diversas ferramentas desse tipo, para auxiliar na tomada de decisão nas empresas.
Técnicas como redes neurais, agentes e sistemas especialistas possuem amplo campo de utilização
na área de comércio eletrônico (TURBAN; POTTER e RAINER, 2003).
2.1.1 Comércio Eletrônico e Agentes Inteligentes
Uma tecnologia que pode ser empregada para dar suporte às diversas tarefas de uma
ferramenta de comércio eletrônico são os agentes. A função dos agentes é monitorar o ambiente e
reagir de acordo com determinadas “decisões”, facilitando o trabalho dos usuários. Agentes
inteligentes utilizam-se de recursos especializados ou baseados em conhecimento, tomando
decisões autônomas quando necessário (TURBAN; POTTER e RAINER, 2003).
A aplicabilidade desses agentes pode ser vista em leilões virtuais, sistemas de busca de
preços, sistemas de recomendação, e diversos outros sistemas de comércio eletrônico. A seguir têm-
se algumas das aplicações de agentes em mecanismos de comércio eletrônico (ibidem):
8
• Agentes de busca e filtragem: agentes auxiliam consumidores a selecionar itens de suas
compras. As avaliações das ofertas são feitas de maneira criteriosa;
• Agentes de pesquisa de produtos e fornecedores: com consumidores que possuem
decisão sobre o que vão adquirir em suas compras, esses agentes, geralmente, fazem
uma varredura de preços e diferentes fornecedores; e
• Perfis de consumidores utilizando agentes: os agentes, através de técnicas de filtragem
colaborativa, coletam informações dos consumidores, para depois, elaborar um perfil de
consumidor. Esse perfil é utilizado para fornecer ofertas mais desejáveis ao consumidor.
Considerando as informações supracitadas, constata-se que os agentes possuem
aplicabilidade válida em sistemas de comércio eletrônico, principalmente com a objetividade de
diminuir o trabalho do usuário e criar maior dinamismo desses sistemas.
2.2 SISTEMAS DE COMÉRCIO ELETRÔNICO PARA BUSCA DE PRODUTOS
Há sistemas de comércio eletrônico que auxiliam o consumidor a selecionar o que e onde se
deve comprar. O que a ferramenta faz são diversas buscas a sistemas on-line de vendas de produtos
ou serviços, estabelecendo diferenças entre cada oferta e retornando ao consumidor, as melhores
opções de compra encontradas. Sistemas como esse, são geralmente implementados utilizando
agentes de comparação. Esses agentes, normalmente utilizam-se de comparações baseadas no valor
dos produtos (TURBAN; POTTER e RAINER, 2003). Para demonstrar o funcionamento destes
agentes, a seguir há explicações sobre mecanismos de buscas, utilizando-se de exemplos de
ferramentas de busca textual e de produtos.
2.2.1 Mecanismos de Busca na Web
De acordo com Crovella, Lindemann e Reiser (2000), os sistemas de busca na Internet
cresceram consideravelmente nos últimos anos. Esses sistemas operam geralmente através de
agentes. A maior parte destas ferramentas de procura e indexação de informações são chamadas de
Web crawlers. Entre estas ferramentas pode-se citar o Google.
Segundo Brin e Page (1998), os criadores do Google, desenvolver ferramentas de pesquisa
na Web é um grande desafio. Há uma necessidade de possuir algoritmos de busca rápidos, pois os
9
dados devem estar atualizados para as pesquisas dos usuários. Outro desafio é a variedade de
tecnologias distintas que podem ser encontradas nos sites da Internet.
Para prover uma busca de qualidade é necessário: encontrar quase qualquer informação na
Web e procurar algo de real interesse do usuário (retornando resultados ordenados por interesse).
Devido a esta última característica, o algoritmo de busca deve ser o mais preciso possível, pois o
volume de dados na ferramenta de busca tende a crescer consecutivamente (BRIN e PAGE, 1998;
PESHAVE e DEZHGOSHA, 2005).
Há várias diferenças entre como os mecanismos de busca Web trabalham, mas todos eles
devem executar três tarefas básicas (CASTILLO e BAEZA-YATES, 2002; PESHAVE e
DEZHGOSHA, 2005):
1. Procurar pela Internet (ou em partes dela, baseados em palavras importantes): uma das
maneiras mais comuns para disponibilizar estas informações de procura é utilizando
Web crawlers;
2. Manter um índice de palavras que o mecanismo encontrou, e onde ele as encontrou:
através de repositórios de dados, as páginas encontradas e armazenadas pelos Web
crawlers, são classificadas e indexadas; e
3. Disponibilizar interface do mecanismo: disponibilizar interface que permita aos usuários
formularem pesquisas através de palavras ou combinações de palavras.
Um mecanismo de busca acessa as informações de seus bancos de dados, que são
constituídos de informações disponibilizadas pelas lojas virtuais ou podem retirar informação
através de Web crawlers (PESHAVE e DEZHGOSHA, 2005).
2.2.1.1 Como Trabalham os Web Crawlers
Um Web crawler é um programa que faz o download e armazena páginas Web
freqüentemente, para os mecanismos de busca. Seu desempenho está intimamente ligado com a
velocidade de acesso as páginas que estão sendo mapeadas (CASTILLO e BAEZA-YATES, 2002).
A arquitetura de um Web crawler pode ser visualizada na Figura 1. Os Web crawlers
geralmente são iniciados através de um agendador que inserem um conjunto inicial de URLs
(Uniform Resource Locator) em uma fila, de onde todas elas devem ser recuperadas, mantidas e
10
priorizadas. A partir desta fila, o crawler recupera a URL, faz o download da página que esta
referencia, extrai qualquer URL da página que foi baixada e coloca as novas URLs na fila. Esse
processo ocorre repetidas vezes até que o programa crawler decide parar. As páginas coletadas são
armazenadas em um repositório de textos (Base de Textos) e logo depois, ficam disponibilizadas
pelos mecanismos de busca. (PESHAVE e DEZHGOSHA, 2005).
Figura 1. Arquitetura de um Web crawler
Fonte: Adaptado de Castillo e Baeza-Yates (2002).
2.2.1.2 Técnicas para Web Crawlers
De acordo com Peschave e Dezhgosha (2005), os Web crawlers podem adotar duas técnicas
para facilitar seu processamento:
• Técnica focada: nessa técnica os Web crawlers buscam as informações em um grupo
particular de endereços na Web. O principal objetivo desta técnica é garantir maior
relevância na busca de assuntos específicos e pré-definidos; e
• Técnica distribuída: técnica que visa distribuir os Web crawlers em diversos processos,
aproveitando escalabilidade, facilidade de configuração do sistema e tolerância a falhas.
Esta técnica utiliza o modelo de sistemas distribuídos.
WWW
Web Crawler
URLs Base
de Textos
Agendador
11
2.2.2 Exemplo de Ferramenta de Busca na Web: Google
Para exemplificar como funciona uma ferramenta de busca na Web, será utilizada a
descrição de Brin e Page (1998) sobre o Google, um sistema de busca de informações contidas na
Web.
O Google utiliza-se de duas importantes configurações que provêem alta precisão em seus
resultados. A primeira, chamada de PageRank, refere-se a usar da estrutura de links da Web para
calcular a qualidade de cada página. A segunda é utilizar links para melhorar os resultados da busca.
Para que seja possível uma melhor compreensão sobre a configuração de PageRank, Brin e
Page (1998) explicam que é utilizado um mapa de hyperlinks com intuito de prever a qualidade e o
interesse das pessoas pela página. Esses mapas possibilitam uma rápida avaliação sobre qual é o
melhor resultado.
A Equação 1 demonstra o funcionamento do PageRank. A equação assume que a página
denominada de “A” possui “T1” a “Tn” (“T” representa uma citação) realizando citações a página
“A”. O parâmetro “d” determina um fator de ajuste que corresponde a um valor entre zero e um.
Esse valor estabelece a probabilidade de um usuário ficar insatisfeito com a página e procurar por
outras. A função “C” determina o número de links externos da página recebida como parâmetro
(PAGE, 1998 apud BRIN e PAGE, 1998).
PR(A) = (1-d) + d (PR(T1)/C(T1) + ... + PR(Tn)/C(Tn)) Equação 1
Além da técnica PageRank, Brin e Page (1998) explicam uma segunda técnica para
melhorar os resultados da busca. No Google, os links de texto são tratados de maneira diferente aos
demais sistemas de busca. Ao invés do algoritmo de busca somente associar o texto do link com a
página que o link está, o Google ainda associa o texto com as páginas que os links apontam. A
utilização desta técnica se justifica, pois as âncoras (textos que identificam os links) fornecem
descrições mais específicas das páginas para onde apontam. Outra vantagem está em referenciar
texto que não podem ser indexados em uma pesquisa, como: imagens, programas e banco de dados.
Para que o mecanismo de busca do Google possa funcionar com as técnicas de recuperação
de resultados, é necessário que o sistema possua uma arquitetura que suporte a rápida pesquisa aos
12
repositórios de informações. A proposta de Brin e Page (1998) demonstra como foi possível criar
uma arquitetura desse tipo.
2.2.2.1 Arquitetura do Google
Para entender melhor como o sistema de busca Google funciona, além de constatar quais as
características principais dele, é necessário verificar como é a arquitetura do sistema. A maior parte
do Google foi implementada nas linguagens C e C++ devido a eficiência e a portabilidade destas
linguagens para ambientes com os sistemas operacionais Linux e Solaris (BRIN e PAGE, 1998). A
arquitetura do sistema pode ser visualizada na Figura 2.
Figura 2. Arquitetura do mecanismo de busca do Google
Fonte: Adaptado de Brin e Page (1998).
No Google, o processo de armazenar as páginas Web (Web crawling) é realizado por muitos
crawlers distribuídos. Há um servidor de URL que envia as listas de URLs para serem buscadas
13
pelos crawlers. As páginas Web que são buscadas são enviadas a um servidor de armazenamento.
Esse servidor, por sua vez, comprime e armazena as páginas Web em um repositório. Cada página
possui um identificador chamado de “docID” que é atribuído sempre que uma nova URL é
analisada gramaticalmente. A função de indexação é executada por um indexador e um
classificador. O indexador é responsável por ler documentos (páginas) descomprimidos, a partir do
repositório, e analisá-los gramaticalmente. Cada documento é convertido em uma série de palavras
encontradas, chamadas de “hits”. Os “hits” armazenam as palavras, a posição no documento, o
tamanho da fonte e a capitalização da palavra. O indexador distribui os “hits” nos repositórios
chamados de “barris”, criando uma classificação através do índice. Outra importante função do
indexador é analisar gramaticalmente todos os links de cada página Web e armazenar informações
sobre eles em um arquivo de âncora. Esse arquivo contém informações necessárias para determinar
o texto do link, para onde cada link aponta e de onde o mesmo é apontado (BRIN e PAGE, 1998;
PESHAVE e DEZHGOSHA, 2005).
O chamado “URL resolver” lê os arquivos de âncora e converte as URLs relativas em
absolutas e, logo em seguida, identifica seu “docID”. O “URL resolver” coloca o texto da âncora
em um índice, associado ao “docID” que a âncora aponta, gerando assim um banco de dados de
links. Esses links são utilizados para processar a técnica de PageRank (ibidem).
O classificador verifica os “barris” que estão organizados por “docIDs” e reclassifica-os
pelos chamados “wordIDs” (índices de palavras nos documentos) para gerar um índice invertido.
Além disso, o classificador também gera uma lista de “docIDs” de índice invertidos. Um programa
chamado de DumpLexicon, seleciona as listas geradas pelo indexador e gera uma lista léxica para
ser utilizada na busca da informação, que será feita na Web (BRIN e PAGE, 1998 apud PESHAVE
e DEZHGOSHA, 2005).
Analisando a arquitetura de um sistema de buscas como o Google, é possível verificar como
se deve proceder na implementação de um módulo de pesquisa de preços na Web. Tendo em vista
que não há muita diferença entre os dois tipos de sistema, a arquitetura do Google contribuiu para o
projeto do módulo de pesquisa de preços do Gilgamesh.
2.2.3 Exemplo de Sistemas de Pesquisa de Produtos
Há diversos sistemas de pesquisa de informações de vendas de produtos. A seguir se
encontra uma discussão acerca de algumas destas ferramentas, para traçar um perfil mais exato das
14
funcionalidades destas aplicações. As ferramentas estudadas são: Bargainfinder, Jango, Kasbah,
Buscapé e Bondfaro.
2.2.3.1 Bargainfinder
Bargainfinder, desenvolvido pela Andersen Consulting, foi o primeiro agente para
comparações de preços on-line (GUTTMAN; MOUKAS e MAES, 1998). Seu objetivo era fazer
busca on-line de CDs em vários revendedores e produzir listas com informações sobre localização e
preço (TURBAN; POTTER e RAINER, 2003).
De acordo com Wilder (1995), o Bargainfinder pesquisava títulos em CDs, solicitados por
seus usuários, em oito bancos de dados de lojas virtuais em busca de disponibilidade e preço.
Depois de realizada a busca, um relatório era disponibilizado contendo os preços dos títulos
requisitados pelo usuário e os links de localização da oferta para cada item.
O agente Bagainfinder causou diversos problemas de concorrência entre as lojas virtuais,
que, em grande maioria, bloquearam as requisições provenientes do Bargainfinder (GUTTMAN;
MOUKAS e MAES, 1998).
2.2.3.2 Jango
De acordo com Guttman, Moukas e Maes (1998), Jango1 é um Bargainfinder otimizado. Sua
versão original resolve o problema de bloqueio, devido a requisições dos produtos originarem de
cada consumidor em um navegador de Internet, ao invés de um site central como no Bargainfinder,
fazendo as requisições parecerem de consumidores reais. Nesta forma "agressiva" de
interoperabilidade, torna as pesquisas dos consumidores mais convenientes, não deixando muitas
opções de bloqueio dos agentes ao site (GUTTMAN; MOUKAS e MAES, 1998).
Quando um consumidor submete uma determinada pesquisa de um determinado produto a
interface da aplicação, o sistema retorna uma série de lojas virtuais, onde se localizam itens com a
determinada palavra chave. Um exemplo disto pode ser visualizado em uma busca com as palavras-
chave “iron maiden”. A Figura 3 demonstra o resultado da pesquisa exemplo.
1 A ferramenta Jango pode ser visualizada no endereço http://www.jango.com.
15
Figura 3. Resultados da busca em Jango
2.2.3.3 Kasbah
Desenvolvido pelo MIT Media Lab, o Kasbah, é um sistema que utiliza a tecnologia multi-
agente. Um usuário que deseja vender ou comprar algo, cria um agente, configurando estratégias de
direção e envia as informações para um agente central de mercado. O sistema procura potenciais
compradores e vendedores e negocia com eles ou seus manipuladores. O objetivo de cada agente é
completar seu ideal, que pode ser: encontrar o maior preço, o menor preço, o preço aceitável e a
data para completar as transações (GUTTMAN; MOUKAS e MAES, 1998).
2.2.3.4 Buscapé
A ferramenta brasileira Buscapé é utilizada para localização de ofertas de produtos em geral.
O serviço é gratuito, podendo ser acessado em seu site (http://www.buscape.com.br) na Internet. O
Buscapé compara preços de trinta e duas diferentes categorias de produtos e serviços. Entre elas
podem se destacar: combustíveis, tarifas bancárias, alimentos, aparelhos eletrônicos, livros e
revistas (BUSCAPÉ, 2006).
O sistema Buscapé possui os preços atualizados através de um software chamado de Spider.
Esse software rastreia as lojas e outras empresas (que possuem parceria comercial com o Buscapé) e
então as informações dos produtos são inseridas em um banco de dados. Essa atualização ocorre
diariamente de seis em seis horas (BUSCAPÉ, 2006).
Na Figura 4, pode ser visualizada uma pesquisa no sistema Buscapé (2006). O item
procurado foi descrito através das palavras-chave “iron maiden fear of the dark”. Todas as
16
categorias onde foram localizados itens que possuem semelhança com a descrição das palavras-
chave, foram listadas para que se possa especificar melhor a consulta.
Figura 4. Pesquisa no BuscaPé
Na Figura 5, pode-se observar o resultado final da busca. Logo após uma categoria ser
especificada, o Buscapé (2006) faz a listagem dos preços encontrados, além das informações da loja
e do produto. As lojas possuem uma qualificação de garantia em sua descrição, auxiliando o usuário
a fazer a escolha mais agradável.
Figura 5. Resultado da pesquisa no Buscapé
17
2.2.3.5 Bondfaro
Bondfaro (2006) é uma ferramenta brasileira disponibilizada na Internet, para pesquisa de
preços de produtos. Estas informações são coletadas constantemente de lojas virtuais que possuam
um convênio com os mantenedores da ferramenta (BONDFARO, 2006).
Como no sistema BuscaPé, o Bondfaro possui uma ferramenta para fazer a coleta das
informações dos produtos, disponibilizando assim, os preços dos produtos para uma possível
comparação dos usuários. Esta ferramenta utiliza agentes inteligentes para executar sua tarefa
(BONDFARO, 2006).
Na consulta pelas palavras-chave “iron maiden fear of the dark”, foram obtidos os
resultados visualizados na Figura 6.
Figura 6. Resultado da pesquisa Bondfaro
2.2.3.6 Comparativo entre as Ferramentas
Considerando as ferramentas estudadas, podem ser observadas algumas semelhanças e
diferenças. O BargainFinder, como foi o primeiro sistema desse tipo a ser desenvolvido, possuía as
funcionalidades comuns a todos os sistemas: a busca de informações de produtos. O sistema Jango
se difere aos demais sistemas estudados, pois sua busca não visa essencialmente o preço, mas sim
qualquer informação sobre o produto a ser pesquisado, ou seja, não foca um critério de busca.
Kasbah é uma ferramenta que utiliza arquitetura baseada fortemente em agentes. O maior
diferencial da ferramenta é o foco de suas pesquisas que podem ser baseadas em maior preço,
menor preço, preço médio e data de validade das transações. As ferramentas BuscaPé e Bondfaro
possuem praticamente as mesmas funcionalidades e suas interfaces são muito parecidas. Ambos os
sistemas possuem uma ferramenta que faz a coleta das informações de preços de produtos em
18
intervalos de tempo pré-determinados. Na Tabela 1 é possível visualizar uma síntese dos
comparativos realizados.
Tabela 1. Comparativo entre as ferramentas de pesquisa de preços
Ferramentas Possui Web crawler
Foca-se em busca por preço
Sistema de reputação
Utiliza agentes
Bargainfinder - SIM NÃO SIM Jango NÃO MAIS CRITÉRIOS NÃO - Kasbah - MAIS CRITÉRIOS NÃO SIM Buscapé SIM SIM SIM - Bondfaro SIM SIM SIM SIM
2.3 LEILÕES
Os leilões são um dos mecanismos de comércio mais favorecidos pelo emprego do comércio
eletrônico, pois o baixo custo e o aumento do número de participantes que a tecnologia proporciona
são imprescindíveis para o sucesso do leilão (TURBAN; POTTER e RAINER, 2003).
Leilões são mecanismos de mercado caracterizados por uma natureza competitiva na qual se
alcança o preço final. Possuindo métodos estabelecidos há séculos, os leilões são muito eficazes
para lidar com negociações onde os canais convencionais de marketing são ineficazes ou mesmo
ineficientes (TURBAN; POTTER e RAINER, 2003).
Segundo Klemperer (1999), um grande volume de transações são realizadas em leilões
atualmente. Governos utilizam leilões para vender contas do Tesouro, direito sobre exploração de
recursos (incluindo petróleo) e privatização de companhias estatais. A concorrência através dos
leilões seleciona os fornecedores para contratos com administrações públicas. Produtos agrícolas,
peças de arte, casas, carros, peças de antiguidade são vendidos comumente através de leilões.
Os leilões possuem uma série de denominações específicas. Castro (2003) demonstra uma
série de conceitos básicos necessários para o melhor entendimento da teoria de leilões:
• Leiloeiro: indivíduo que possui a responsabilidade do andamento do leilão. Esse
geralmente permanece neutro às negociações, trabalhando apenas como mediador do
leilão;
19
• Ofertante: indivíduo que oferece algum produto ou serviço, para ser leiloado; e
• Arrematante: chamado em referências de língua inglesa como bidder, um arrematante é
o indivíduo que submete os lances.
2.3.1 Tipos de Leilões
Segundo Turban, Potter e Rainer (2003), os leilões são divididos em duas modalidades: os
diretos e os reversos.
Os leilões diretos são caracterizados pela venda de um ou mais itens para possíveis
compradores. Nesta modalidade de leilão, existem diversos mecanismos, os quais, segundo Turban,
Potter e Rainer (2003), são:
• Leilões ingleses: os lances são feitos pelos arrematantes em um item por vez. Os preços
dos lances aumentam, até que seja decretado o fim do leilão, geralmente quando nenhum
comprador deseja dar um lance maior. Se o preço for o critério único, o melhor lance
garante ao comprador o item. De acordo com Klemperer (1999), esses leilões também
são denominados de aberto, oral ou leilão de lances ascendentes;
• Leilões yankees ou americanos: análogos aos leilões ingleses com a diferença de que são
leiloados vários itens idênticos. Os compradores podem fazer lances a qualquer
quantidade de itens;
• Leilões holandeses: na maioria das vezes leiloam itens iguais. Funcionando de modo
inverso ao leilão inglês, os leilões holandeses começam com lances altos, que vão
decrescendo de preço até que o valor específico seja apresentado. O comprador que der
o lance desejado primeiro ganha. Klemperer (1999) denomina esse tipo de leilão como
leilão de lances declinantes;
• Leilões duplos: a teoria padrão de leilões assume que um vendedor controla a
negociação e muitos consumidores submetem lances. Em leilões duplos, compradores e
vendedores são tratados simetricamente como compradores submetendo lances e
vendedores submetendo pedidos. O leilão duplo é proveniente da ligação com literatura
de barganha (KLEMPERER, 1999);
20
• Primeiro preço: nesse leilão cada arrematante submete um único lance. Os lances são
feitos de maneira secreta. O arrematante que oferecer o maior valor, vence a
concorrência (KLEMPERER, 1999); e
• Segundo preço: cada arrematante submete apenas um lance, sem que os outros saibam o
valor. O indivíduo que ofereceu o maior lance vence, pagando o valor equivalente ao
segundo maior preço do leilão. Esse tipo também é conhecido como leilão de Vickrey
(KLEMPERER, 1999).
Na modalidade de leilão reverso, um comprador deseja comprar algum item ou contratar
algum serviço. Fornecedores do material ou do serviço são convidados a apresentar ofertas (lances).
Caso as ofertas venham a não contemplar o esperado pelo comprador, o leilão poderá ter várias
rodadas (TURBAN; POTTER e RAINER, 2003).
2.3.2 Mecanismos de Encerramento
O encerramento de um leilão está fortemente conectado ao tipo de estratégia que será
utilizada em um leilão. Os leilões devem ser divididos, quanto a mecanismos de encerramento, da
seguinte forma (CASTRO, 2003):
• Fechamento temporal: o leilão acaba em um momento pré-determinado pelo leiloeiro.
Esse momento (data e hora) é geralmente conhecido por todos os arrematantes que
participarão do leilão. Utilizado comumente em leilões do tipo: inglês, americano e de
Vickrey; e
• Fechamento por evento: o encerramento do leilão ocorre pelo acontecimento de um
evento pré-determinado pelo leiloeiro. Os eventos mais comuns geralmente são:
apresentação de um lance (leilão do tipo holandês), ordem do leiloeiro para fechar um
leilão (americano, inglês e Vickrey) e fim de um período de tempo sem a apresentação
de um novo lance (americano, inglês e Vickrey).
Tanto o mecanismo de fechamento por evento, quanto o mecanismo de fechamento temporal
são características muito importantes a serem incorporadas ao sistema Gilgamesh, pois estabelecem
o momento que um leilão deve encerrar sua atividade.
21
2.3.3 Leilões Virtuais
Segundo Turban, Potter e Rainer (2003), a Internet fornece um ambiente ideal para que
leilões de qualquer tipo possam fluir de maneira muito produtiva. A rede mundial de computadores
possibilita mecanismos de leilões de baixo custo e com uma elevada quantidade de compradores e
vendedores.
Turban, Potter e Rainer (2003) esclarecem uma série de benefícios provenientes de leilões
on-line. Alguns benefícios aos vendedores que podem ser destacados são a determinação do preço
pelo mercado é ótima e a relação e a lealdade com o cliente são aperfeiçoadas.
Há diversos benefícios também para os compradores, como: oportunidades de encontrar
itens exclusivos e a possibilidade de participar do leilão de qualquer local que possua conexão com
a aplicação de leilão.
Os leilões eletrônicos também possibilitam aos leiloeiros o benefício de expansão do
negócio.
2.3.3.1 Comparativos entre Ferramentas de Leilões Eletrônicos
Para desenvolver o módulo de leilões do sistema Gilgamesh foi necessário um estudo das
ferramentas com funcionalidade de leilão virtual, a fim de verificar quais as características são
comuns e o que poderia ser agregado ao Gilgamesh. As ferramentas pesquisadas foram: Mercado
Livre, eMediator e Auctionbot.
Mercado Livre
O Mercado Livre trata-se de uma ferramenta virtual, que possibilita que pessoas façam
comércio virtual com outras pessoas ou com empresas. Esta ferramenta é associada ao grupo de
sites de comércio eletrônico eBay, que possuem o mesmo propósito. O Mercado Livre pode ser
facilmente acessada por um site2 na Internet (MERCADOLIVRE, 2006).
A ferramenta não possui custos adicionais àqueles que utilizam a mesma para efetuar
compras. Durante as consultas de preços, os consumidores poderão dispor de uma gama de detalhes
que facilitam a localização da melhor oferta (MERCADOLIVRE, 2006): 2 A ferramenta Mercado Livre pode ser acessada no endereço: http://www.mercadolivre.com.br.
22
• Visualizar o produto através de fotos ou vídeos: o que possibilita aos consumidores
maior segurança na determinação exata do que está sendo comprado;
• Os produtos são diferenciados por grupos, um exemplo desta funcionalidade pode ser
demonstrado da seguinte forma: ao procurar o item “Rei Arthur”, seria solicitado que
tipo de produto esta sendo pesquisado, livros ou filmes (Figura 7);
• Anúncios feitos como grandes catálogos, possibilitando aos consumidores poderem
selecionar as melhores ofertas (os preços mais atraentes, ou mais coesos), de maneira
mais rápida; e
• Detalhamento do produto através da seleção do mesmo, visualizando, desta forma,
detalhes como: qualificações do vendedor, estado do produto, localização da estocagem
da mercadoria, quantidade de visitas na oferta, preço da mercadoria (Figura 8).
Figura 7. Resultado de busca por produto
Figura 8. Detalhamento de oferta no Mercado Livre
23
A ferramenta de Mercado Livre possibilita que vendedores se cadastrem e possam ofertar
suas mercadorias (MERCADOLIVRE, 2006). Os vendedores devem selecionar uma modalidade
para estabelecer o preço dos produtos:
• Preço fixo: a oferta do produto possui um único valor, que permanece congelado até que
o vendedor aumente o preço da mercadoria; e
• Venda pelo melhor preço: o maior valor, até certo momento, compra a mercadoria.
A opção de “venda por melhor preço” é a característica que torna o Mercado Livre uma
aplicação que contempla a modalidade de leilão direto. Consumidores vão submetendo lances a
partir de um preço mínimo, sendo que o maior valor ofertado até o fechamento do leilão, leva a
mercadoria (MERCADOLIVRE, 2006).
Há um espaço reservado para perguntas e respostas, no detalhamento do produto. Um
comprador pode fazer perguntas ao vendedor sobre o item que o mesmo está vendendo. Esta opção
permite um feedback ao comprador, possibilitando a obtenção de maiores detalhes sobre a
negociação.
Cada membro (tanto vendedor, quanto comprador) possui uma reputação que é fornecida
para avaliar as negociações passadas do indivíduo. Durante ou depois de uma negociação, um dos
agentes (comprador e vendedor) da transação podem inserir comentários e ponto de reputação para
a outra pessoa com a qual está negociando. Desta forma, é possível verificar o histórico de um
comprador ou vendedor antes de fechar o negócio.
eMediator
O eMediator é uma ferramenta de comércio eletrônico que utiliza técnicas de inteligência
artificial com o intuito de aperfeiçoar o emprego de suas funcionalidades. Além de dois outros
módulos (ferramenta de comprometimento de contratos e de trocas comerciais), o eMediator
contempla a modalidade de leilão eletrônico, denominado de eAuctionHouse (SANDHOLM, 2000).
O eAuctionHouse é uma aplicação servidor para leilões virtuais. De acordo com Sandholm
(2000), seu projeto foi desenvolvido com o intuito de implementar uma ferramenta que fornecesse
ao usuário a praticidade e o conforto de um computador associado ao poder de negociação dos
leilões. Desenvolvida, principalmente, na linguagem Java, o eAuctionHouse utiliza uma base de
dados relacional para armazenar as informações provenientes dos leilões.
24
Utiliza diversas modalidades de leilões, Sandholm (2000) destaca leilões ingleses
(denominado na ferramenta como leilões seqüencial) e leilões yankees (chamados de leilões
paralelos).
O eAuctionHouse fornece uma escolha de esquema de abordagem de preços. Esses
esquemas estão divididos em: primeiro preço, segundo preço ou Vickrey e Vickrey para múltiplas
unidades (SANDHOLM, 2000).
Auctionbot
Wurman, Wellman e Walsh (1998) destacam a ferramenta The Michigan Internet
Auctionbot como sendo um servidor de leilões que suporta agentes humanos ou de software. Esses
agentes de software, que são configurados por usuários, comunicam-se com o sistema com intuito
de participar de leilões. Usuários humanos podem inspecionar suas contas através da Web, verificar
seus lances, seus leilões, e transações passadas. Para participar de leilões na ferramenta é necessário
ser cadastrado previamente.
A ferramenta contempla os vários tipos de leilões. Na Figura 9, pode-se observar os tipos de
leilões que existem no Auctionbot e suas divisões. Os leilões são primeiramente classificados como
de um lado (um ofertante com vários arrematantes) ou dois lados (leilão duplo) e posteriormente
como lances secretos ou públicos. E assim chega-se aos tipos específicos de leilões que a
ferramenta utiliza: Holandês, Inglês, Vickrey e dois tipos de leilões duplos.
Figura 9. Tipos de leilões do AuctionBot
Fonte: Adaptado de Wurman, Wellman e Walsh (1998).
dois lados (duplos) um lado
Vickrey Inglês CDA Call Market Holandês descendente ascendente
público
secreto público
secreto
25
Wurman, Wellman e Walsh (1998) definiram três regras de negócio para o funcionamento
do sistema Auctionbot:
• Quando um lance é realizado, o leiloeiro deve verificar se esse está de acordo com as
regras do leilão;
• Leilões devem fornecem agentes com alguma forma de intermediar resultados; e
• O propósito central da ferramenta é determinar trocas e pagamentos entre consumidores
e vendedores.
Para suportar estas regras de negócio, foram criados os seguintes tipos de mensagens para a
comunicação entre os agentes e o sistema:
• Lance: mensagem enviada por um agente para o leilão, oferecendo uma oferta para
comprar ou vender mercadorias;
• Retirada de lance: mensagem enviada por um agente para cancelar um lance. Nem todos
os leilões permitem esta ação;
• Admissão de lance: mensagem enviada do leilão para o agente, informando que o lance
está dentro das regras do leilão;
• Rejeição de lance: mensagem enviada do leilão para o agente, informando que o lance
não está de acordo com as regras do leilão;
• Cota de preço: mensagem enviada do leilão para o agente. O conteúdo da mensagem
varia de leilão para leilão, mas sempre é informado o preço que o agente deve
contemplar para que seus lances sejam aceitos pelas regras e que os lances não
ultrapassem o tempo do leilão; e
• Notificação de transação: mensagem enviada do leilão para o agente, informando dados
gerais da transação, como termos de troca, preço, quantidades.
Dentro do protocolo de interação, as percepções dos agentes somente observam a cota de
preço. Se um agente der um lance maior que a cota de preços (e no caso de vendedores um preço
menor), ele é quem está liderando a negociação.
Na Figura 10, pode-se visualizar a arquitetura do sistema Auctionbot, onde há uma divisão
de duas interfaces diferentes, a Web para que humanos possam acessar o sistema e a interface
26
TCP/IP (Transmission Control Protocol / Internet Protocol) do agente, para que os agentes possam
se comunicar com o sistema. O agendador monitora o banco de dados para verificar eventos do
processo, ou lances submetidos. Quando um leilão deve ser realizado, o agendador invoca o
programa leiloeiro. O leiloeiro possui a função de carregar as funções do leilão e agrupar os lances
no banco de dados (WURMAN; WELLMAN e WALSH, 1998).
Figura 10. Arquitetura do AuctionBot
Fonte: Adaptado de Wurman, Wellman e Walsh (1998).
Comparativo entre as ferramentas
As ferramentas de leilões virtuais estudadas apresentam a funcionalidade de lances
efetuados por usuários humanos. Destas, a ferramenta Auctionbot é a única que explícita a
utilização de agentes para seu funcionamento, além de permitir que agentes de outras ferramentas
utilizem o sistema de leilões. A ferramenta Mercado Livre possui um diferencial quanto as demais,
pois o nível de comunicação entre os vendedores e compradores de seus leilões permite um bom
feedback, graças às funcionalidades de reputação de usuários e a sessão de questionamentos aos
ofertantes da mercadoria. A ferramenta eMediator, em seu módulo de leilões, apresenta as mesmas
funcionalidades básicas das ferramentas estudadas, mas ela possui outros módulos de comércio
eletrônico. Além de possuir um módulo de leilões, Sandholm (2000) destaca que o eMediator
possui ferramentas de gerenciamento de compromisso com contratos e trocas comerciais. Um
comparativo pode ser visualizado na Tabela 2.
27
Tabela 2. Comparativo entre as ferramentas de leilão
Ferramentas Utiliza agentes Comunicação entre negociantes
Sistema de reputação
Somente Leilão
Auctionbot Sim Baixa Não Não. Possui mais funcionalidades.
Mercado Livre Não explícito Alta Sim Sim EMediator Não explícito Baixa Não Sim
2.4 INTELIGÊNCIA ARTIFICIAL
De acordo com Nascimento Jr. e Yoneyama (2000), a Inteligência Artificial (IA) busca
capacitar máquinas que possuem algum recurso computacional a realizar atividades mentais do ser
humano. Contudo, a essa tecnologia também procura motivar o ser humano a conhecer as próprias
atividades mentais humanas.
Russel e Norvig (2004), dividem a Inteligência Artificial em quatro categorias para explicar
o que é essa tecnologia:
• Sistemas que pensam como seres humanos: motivação de fabricar máquinas com mentes
(HAUGELAND, 1985 apud RUSSEL e NORVIG, 2004). IA é automação do
pensamento humano, atividades de tomada de decisão, a resolução de problemas
(BELLMAN, 1978 apud RUSSEL e NORVIG, 2004);
• Sistemas que pensam racionalmente: estudo das computações que permitem perceber,
raciocinar e tomar ações (WINSTON, 1992 apud RUSSEL e NORVIG, 2004);
• Sistemas que atuam como seres humanos: arte de criar máquinas com capacidade de
executar tarefas inteligentes (KURZWEIL, 1990 apud RUSSEL e NORVIG, 2004); e
• Sistemas que atuam racionalmente: inteligência computacional é contemplada através de
agentes inteligentes (POOLE et al., 1998 apud RUSSEL e NORVIG, 2004).
Dentre as aplicabilidades da Inteligência Artificial, destacam-se: sistemas especialistas,
raciocínios baseados em casos, redes neurais e agentes inteligentes (Inteligência Artificial
Distribuída) (REZENDE, 2003). Dessas técnicas, para o projeto Gilgamesh utilizou-se agentes
inteligentes e sistemas especialistas (representando a inteligência dos agentes).
28
2.4.1 Agentes Inteligentes
Agentes inteligentes são visualizados em sociedades de sistemas computacionais, como uma
metáfora de comportamento social, pela Inteligência Artificial Distribuída (IAD), uma sub-área da
IA (SICHMAN, 1992 apud HÜBNER, 2003).
Segundo Russel e Norvig (2004), um agente é algo capaz de perceber seu ambiente através
de suas percepções (sensores) e tomar uma ação com seus atuadores. Para Briot e Demazeau (2002,
apud HÜBNER, 2003) agentes são entidades lógicas ou físicas que são capazes de atuar de forma
autônoma, muitas vezes em conjunto com outros agentes, para realizar um determinado propósito.
De acordo com Souza (1996), agentes são softwares que operam sobre ambientes dinâmicos
e complexos, os quais atuam autonomamente e de acordo com a percepção obtida. Esta ação
executada deve realizar um conjunto de tarefas e objetivo do agente.
A percepção de um agente é utilizada para representar entradas sensoriais ao agente. A
seqüência de percepções é um histórico contendo todas as entradas sensoriais de um determinado
agente. Esse histórico irá influenciar o agente na tomada de ações. A chamada função do agente
mapeia qualquer seqüência de percepções para que uma determinada ação seja tomada, definindo
um comportamento (RUSSEL e NORVIG, 2004).
De acordo com Russel e Norvig (2004), para modelar a função do agente, descrevem-se as
seqüências de percepções (entrada da tabela) relacionando ações que o agente deve tomar quando
esses pré-requisitos sensoriais forem satisfeitos (reflexo das percepções).
Tendo em vista os conceitos básicos sobre agentes, deve-se conhecer as informações
necessárias para desenvolver agentes inteligentes. Para isso, deve ser considerado: racionalidade,
ambiente de tarefas, estrutura, cooperatividade com demais agentes (multiagentes), padrões de
comunicação e verificar se a implementação do agente ocorrerá com auxílio de algum framework.
2.4.1.1 Racionalidade de Agentes
Um agente racional possui, para toda entrada na tabela de função do agente, os resultados
preenchidos de maneira correta. A ação correta é descrita como aquela que permite o agente obter o
maior sucesso ao executá-la. (RUSSEL e NORVIG, 2004).
29
A racionalidade não especifica que um agente sempre irá executar as suas tarefas com um
resultado absolutamente perfeito, mas garante que ele fará o possível para que suas ações tenham
coerência com a solução do problema (RUSSEL e NORVIG, 2004).
Para medir o sucesso de um agente, submete-se o mesmo a um teste. Um agente modifica o
estado do ambiente através de suas ações. Se esse estado do ambiente for desejável, é porque o
agente executa de maneira correta (RUSSEL e NORVIG, 2004).
2.4.1.2 Ambientes de Tarefas
Ambientes de tarefas são os problemas nos quais os agentes racionais fornecem soluções. A
medida de desempenho, o ambiente, os atuadores e os sensores, agrupados formam o ambiente de
tarefas. Os ambientes de tarefas podem ser classificados de acordo com as seguintes características
(RUSSEL e NORVIG, 2004):
• Observável (completamente ou parcialmente): um ambiente de tarefa é completamente
observável, se seus sensores detectarem todas as informações de relevância. Para ser
parcialmente observável, seus sensores devem estar sofrendo alguma interferência, ou
qualquer outra ação que prejudique a leitura de informações;
• Determinístico ou estocástico: se o próximo estado do ambiente é detectado
completamente pelo estado atual, caracteriza-se o ambiente de tarefa como
determinístico. O oposto caracteriza o estado estocástico;
• Episódico ou seqüencial: um ambiente de tarefa é caracterizado como episódico quando
a experiência do agente é dividida em episódios atômicos, ou seja, cada episódio
consiste na percepção do agente, e, posteriormente, na execução de uma ação. Os
episódios seguintes não dependem dos anteriores. Ao contrário de episódicos, ambientes
seqüenciais possuem episódios muito conectados, e uma decisão atual poderia afetar
decisões futuras;
• Estático ou dinâmico: se um ambiente possui a possibilidade de se alterar, enquanto um
agente está deliberando, esse ambiente de tarefa é caracterizado como dinâmico, caso
contrário, é caracterizado como estático. Se um ambiente não puder se alterar, mas o
nível de desempenho do agente se altera, considera-se o ambiente de tarefa como
semidinâmico;
30
• Discreto ou contínuo: um ambiente é considerado discreto caso tiver um número finito
de estados distintos, além de um conjunto discreto de percepções e ações. Ambientes
contínuos possuem estado contínuo, tempo contínuo e ações contínuas; e
• Agente único ou multiagente: ambientes de agente único necessitam de apenas um
agente para resolver o problema, enquanto que em ambientes multiagente o ambiente
com dois ou mais agentes que possuem uma certa relação. Esta relação pode ser
competitiva ou cooperativa.
2.4.1.3 Estrutura de Agentes
A estrutura de um agente pode ser dividida em arquitetura e programa de agente. Os
dispositivos de computação que executam o programa com atuadores e sensores são chamados de
arquitetura. O programa agente implementa a função do agente que mapeia percepções em ações.
(RUSSEL e NORVIG, 2004).
O programa deve estar apropriado a arquitetura. Um exemplo prático desta necessidade é
exposto por Russel e Norvig (2004): se o programa recomendar ações de caminhar, é necessário que
a arquitetura tenha pernas. A arquitetura pode variar muito: pode ser um PC (Personal Computer)
ou um carro robótico com computadores e câmeras.
Programas de agente
Os programas agentes possuem sempre a mesma função básica: recebem a percepção atual
do ambiente como entrada dos sensores e retornam uma ação para os atuadores. Somente a
percepção atual pode ser dada como entrada. Se as ações do agente dependem da seqüência de
percepções inteira, o agente deve memorizar as mesmas (RUSSEL e NORVIG, 2004).
De acordo com Russel e Norvig (2004), levando em consideração os programas agentes, há
quatro tipos básicos de agentes:
• Agentes reativos simples: tipo de agentes que selecionam ações utilizando como base a
percepção atual. Nesse tipo, o agente toma ações de acordo com uma regra, na qual
condição corresponde ao estado atual definido pela percepção;
• Agentes reativos baseados em modelo: o agente mantém algum tipo de estado interno,
no qual o histórico das percepções afeta. Sendo assim, este agente reflete alguns detalhes
não observáveis pela análise da percepção atual;
31
• Agentes baseados em objetos: da mesma forma que o agente necessita de uma descrição
do estado atual, os objetos que o agente pretende atingir devem possuir estados, para que
uma ação resulte do processamento baseados nos objetos; e
• Agentes baseados na utilidade: usa modelo do ambiente como uma função de utilidade
que regula suas preferências entre os estados do mesmo. Logo depois, é selecionada uma
ação que leva a melhor utilidade esperada, onde a utilidade esperada é calculada pela
média entre todos os estados resultantes possíveis.
Arquitetura de agente
De acordo com Maes (1991, apud WOOLDRIDGE e JENNINGS, 1995), arquitetura é uma
metodologia para a construção dos agentes. Esta especifica como o agente pode ser dividido em um
conjunto de componentes e como esses são feitos para interagir. O conjunto total de componentes e
suas interações provêem uma solução para o problema, utilizando-se dos dados provenientes dos
sensores e o estado interno do agente.
2.4.1.4 Multiagentes
Segundo Jomi F. Hübner (2003), o que caracteriza principalmente os sistemas multi-agentes
(SMA) é o seu objetivo de estudo, pois se deve levar em consideração a coletividade, focando-se
principalmente na interação entre as entidades do sistema.
As principais vantagens da utilização de SMA são (HÜBNER, 2003):
• Possuir a capacidade de adaptar o modelo a novas situações, eliminando ou incluindo
novos agentes ou ainda mudando a organização do sistema;
• Servir de alternativa utilizada para a abordagem de sistemas complexos e distribuídos,
pois a modelagem, a análise do problema e a atribuição de problemas menores aos
agentes, permitem um alto nível de abstração e independência entre os diversos pedaços
do sistema (JENNINGS e WOOLDRIDGE, 1998 apud HÜBNER, 2003);
• Possibilitar agentes em arquiteturas e plataformas distintas, presentes na mesma rede,
podem cooperar entre si; e
• Possibilitar mudança de sociedades, mesmo que projetados de maneira distinta.
32
2.4.1.5 Comunicações entre Agentes
Para estabelecer como os agentes do Gilgamesh devem trocar mensagens, foram levantadas
através de pesquisa algumas linguagens de comunicação específicas para este tipo de comunicação:
ACL, KQML e FIPA-ACL.
Padrão ACL
ACL (Agent Communication Language) é um padrão para linguagens de comunicação entre
agentes que provê a troca de informações e de conhecimentos. Esse padrão partiu da iniciativa de
um grupo de pesquisa do Departamento de Defesa dos Estados Unidos da América, chamada de
Knowledge Sharing Effort. Esse grupo estabeleceu o padrão de três camadas para problemas
identificados na comunicação entre agentes (LABROU; FININ e PENG, 1999):
• Primeira camada: tradução sintática de uma linguagem para outra de sua família;
• Segunda camada: o mesmo conceito não deve perder seu significado através das
aplicações por onde passa; e
• Terceira camada: endereçamento de comunicação entre agentes, pois agentes necessitam
comunicar-se através de atitudes complexas.
A partir destas premissas, o padrão ACL foi constituído. O que distingue o padrão das
linguagens de comunicação antecessoras são os objetos de discurso e sua complexidade semântica
na comunicação. As mensagens ACL são baseadas em ações que descrevem crenças, desejos,
intenções, ou algo similar (LABROU; FININ e PENG, 1999).
De acordo com Labrou, Finin e Peng (1999), a ACL possui as seguintes vantagens sobre as
tecnologias de comunicação entre sistemas distribuídos:
• Manipular proposições, regras e ações no lugar de objetos com nenhuma semântica
associada a eles; e
• Descrever um estágio esperado na linguagem declarativa ao invés de invocar métodos ou
procedimentos.
33
Linguagem KQML
KQML (Knowledge Query Manipulation Language) é uma linguagem desenvolvida para
trocar informações e conhecimentos entre agentes, caracterizada pela formatação da mensagem e
pelo protocolo de manipulação das mesmas (FININ et al., 1997 apud FARACO, 1998).
De acordo com Labrou, Finin e Peng (1999), KQML é uma mensagem de comunicação e
um protocolo para troca de informações. O KQML é independente do mecanismo de transporte
(TCP/IP, SMTP, ou qualquer outro), independente de conteúdo de linguagem (SQL, Prolog, ou
qualquer outra) e independente da antologia3 assumida pelo conteúdo. Uma mensagem KQML se
divide em três camadas (LABROU; FININ e PENG, 1999):
• Conteúdo: camada que carrega o conteúdo atual da mensagem. Esta camada pode
carregar qualquer linguagem representativa;
• Comunicação: camada que codifica configurações da mensagem, descrevendo
parâmetros de comunicação em baixo nível, assim como a identidade do remetente e
recipiente, e um identificador único relacionado à comunicação; e
• Mensagem: camada que codifica uma mensagem que a aplicação deseja transmitir para
outra.
Na Figura 11, observa-se um exemplo de mensagem KQML demonstrado por Labrou, Finin
e Peng (1999). Acima de “(a)” pode-se verificar uma mensagem enviada pelo agente “joe” que
solicita o preço ao servidor estoque “IBM”. A mensagem imediatamente acima de “(b)” contêm a
resposta do “estoque-server” solicitada, previamente, por “joe”.
3 Ontologia: conjunto de especificações aplicáveis a algum domínio determinado que estão explícitas de significados, conceitos e relacionamentos. Utilizar ontologia permite a definição de um contexto único, livre de ambiguidade (COSTA, 1999).
34
(ask-one :sender joe :content (PREÇO IBM ?price) :receiver estoque-server :reply-with ibm-estoque :language LPROLOG :ontology NYSE-TICKS) (a) (tell :sender estoque-server :content (PREÇO IBM 14) :receiver joe :in-reply-to ibm-estoque :language LPROLOG :ontology NYSE-TICKS) (b)
Figura 11. Mensagem em KQML
Fonte: Adaptado de Labrou, Finin e Peng (1999).
Linguagem FIPA-ACL
De acordo com Hübner e Sichman (2000), a linguagem de comunicação ACL da FIPA
baseia-se nos mesmos princípios presentes no KQML, além de utilizar a mesma sintaxe na
composição das mensagens. O aspecto que distingue a FIPA-ACL do KQML está presente na
descrição formal dos efeitos da mensagem na mente do receptor e emissor, pois a semântica dos
tipos de mensagens são diferentes.
Segundo Leonardo Ayres de Morais e Silva (2003), FIPA-ACL é baseada em ações de fala.
Essa linguagem consiste em um conjunto de mensagens e a definição dos efeitos dos agentes
remetentes e destinatários. Labrou, Finin e Peng (1999) destacam que FIPA-ACL possui a mesma
sintaxe da KQML, embora suas primitivas possuam nomes diferentes.
Na Figura 12, pode ser visualizado a estrutura de uma mensagem FIPA-ACL. O
“communicative act” é uma primitiva da linguagem.
35
(communicative act :sender <valor> :receive <valor> :content <valor> :language <valor> :ontology <valor> :conversation-id <valor> )
Figura 12. Mensagem em FIPA-ACL
Fonte: Silva (2003).
2.4.1.6 Padrões e Ferramentas para o Desenvolvimento de Agentes
Os padrões de desenvolvimento de agentes têm o propósito de facilitar a implementação de
sistemas que utilizam as características de agentes, sendo os mesmos inteligentes ou não. Nessa
sessão encontra-se um estudo realizado sobre os padrões de desenvolvimento.
Padrão FIPA
FIPA (Fipa Foundation for Intelligent Physical Agents) é um padrão estabelecido pelo IEEE
(Institute of Electrical and Electronics Engineers) que provê especificações e estruturas para o
desenvolvimento de sistemas computacionais que utilizem agentes (ODELL, 2006).
FIPA-OS (Fipa Foundation for Intelligent Physical Agents – Open Source) é um pacote com
ferramentas de implementação, de código aberto e orientadas a componente, de agentes no padrão
FIPA. Há componentes que são obrigatórios para o funcionamento das ferramentas como a shell de
agentes padrão. Tecnologias que são opcionais agregam ao pacote maior flexibilidade. O
componente de agente JESS pode ser acoplado para que se disponha da tecnologia de sistema
especialista no pacote. (FIPA-OS, 2001).
Padrão SACI
SACI (Simple Agent Communication Infrastructure) é uma ferramenta construída a partir
dos objetivos de simplicidade e bom desempenho na utilização de agente, tornando detalhes da
programação distribuída transparentes ao desenvolvedor (HÜBNER e SICHMAN, 2000).
Desenvolvido na linguagem de programação Java, o SACI utiliza-se de KQML para
comunicação entre agentes. Entre as demais características desta ferramenta, destacam-se
(HÜBNER e SICHMAN, 2000):
36
• Possuem métodos para utilizar mensagens KQML (compor, enviar, receber);
• A localização do agente na rede é transparente, pois a identificação do mesmo é feita
através do nome do agente, facilitando assim a comunicação;
• Agentes podem conhecer os demais através do serviço de paginas amarelas;
• Possibilita a implementação de agentes em applets, o que possibilita disponibilizar a
interface do mesmo em uma página Web;
• Agentes podem ser iniciados remotamente; e
• Possui ferramenta de monitoração de agentes, permitindo assim a visualização e
armazenamento das comunicações.
Segundo Hübner e Sichman (2000), na ferramenta SACI os agentes são agrupados em
sociedades, que possuem um agente especial chamado de facilitador. A função deste agente é
identificar e localizar agentes da sociedade, além de verificar os serviços que os agentes fornecem.
Padrão JADE
JADE (Java Agent Development Framework) é um framework para desenvolvimento de
aplicações que utilizam o conceito de agentes que seguem as especificações da FIPA. O objetivo
principal do framework é garantir a interoperabiliade entre sistemas multi-agentes, utilizando vários
agentes de serviços, que possibilitam a comunicação entre agentes (BELLIFEMINE et al., 2006).
O JADE utiliza troca de mensagens para estabelecer a comunicação entre agentes. Para isto,
o framework disponibiliza os serviços de nomes, páginas amarelas, transporte de mensagens,
serviço de codificação e decodificação de mensagens, além de uma biblioteca de interação
(BELLIFEMINE et al., 2006).
Silva (2003) cita diversas características do framework:
• Plataforma distribuída de agentes: os agentes podem estar presentes em computadores
diferentes, bastando apenas que seja executada uma aplicação Java e a máquina virtual
dessa linguagem;
• Execução concorrente: possibilita a execução paralela entre os agentes;
37
• Compatibilidade com a especificação da FIPA: o framework foi construído baseado nas
especificações da FIPA;
• Transporte de mensagens: transporte de mensagens na linguagem de comunicação FIPA-
ACL;
• Serviço de nomes padronizados de acordo com a FIPA: os nomes que identificam os
agentes em sua inicialização são estabelecidos em conformidade com o padrão da FIPA;
• Integração: permite que outros mecanismos carreguem os agentes autônomos
construídos a partir do framework; e
• Implementação Java: os agentes desenvolvidos com o JADE, são implementados na
linguagem JAVA.
No framework, a implementação de um agente deve ser realizada em uma classe que herde
características da "Agent", classe padrão do JADE. Na Figura 13, pode ser visualizado a
implementação de um agente utilizando o JADE. O método “setup” é responsável por iniciar as
funções do agente.
public class Ofertante extends Agent { public Ofertante () { } protected void setup() { DFAgentDescription dfd = new DFAgentDescription(); ServiceDescription sd = new ServiceDescription(); dfd.setName(getAID()); sd.setType( "ofertante" ); sd.setName( getLocalName() ); dfd.addServices(sd); DFService.register(this, dfd); addBehaviour(new Comportamento(this, novoLance, lances)); } }
Figura 13. Criando um agente utilizando o JADE
Fonte: Adaptado de Silva (2003).
Para definir ações que o agente deve retornar, é necessário criar uma tarefa, denominada de
comportamento do agente. Na Figura 14, é demonstrado uma implementação de comportamento de
agentes no JADE. As ações de comportamento são inseridas dentro do bloco do método “action”.
38
Este comportamento é vinculado ao agente utilizando o método “addBehaviour”, presente no
método “setup” na Figura 13 (demonstrada anteriormente).
public class Comportamento extends OneShotBehaviour { public Comportamento (Agent a, String novoLance, String[] lances) { super(a); this.lances = lances; this.novoLance = novoLance; } public void action() { verificaValidadeLance(novoLance); gravaLance(novoLance, lances); } }
Figura 14. Implementação de Comportamento
Fonte: Adaptado de Silva (2003).
Segundo Silva (2003), o framework JADE oferece um ambiente robusto e conciso que
abstrai ao desenvolvedor de agentes a preocupação de implementar uma plataforma que se adapte a
aplicação.
O Gilgamesh foi implementado utilizando o padrão de desenvolvimento de agentes
(framework) JADE (Java Agent Development Framework), devido, principalmente, o emprego dos
padrões da FIPA e ter sido desenvolvido para a linguagem Java.
2.4.2 Sistemas Especialistas
De acordo com Nascimento Jr. e Yoneyama (2000), a técnica de Sistemas Especialistas é
utilizada para atuar como consultores altamente qualificados em uma determinada área do
conhecimento. A partir desse conhecimento, o sistema especialista busca fornecer diagnósticos,
sugestões ou outras informações que possuam utilidade ao problema proposto. Luger (2004)
conceitua sistemas especialistas como um software que usa o conhecimento de um especialista, para
obter o domínio de um problema específico.
Segundo Rezende (2003), um sistema especialista é classificado como um sistema baseado
em conhecimento (SBC), ou seja, sistemas que resolvem um determinado problema usando um
conhecimento específico sobre o domínio de aplicação. Esses podem ser divididos quanto a sua
estrutura: núcleo do sistema baseado em conhecimento, base do conhecimento, memória de trabalho
e base de dados.
39
O núcleo de um SBC, também conhecido como Shell, é a estrutura responsável por controlar
a interação com o usuário ou equipamento, processamento do conhecimento (usando linhas de
raciocínio) e conclusões obtidas através do raciocínio. Um núcleo é composto por três módulos
interdependentes (REZENDE, 2003):
• Módulo Coletor de Dados: responsável pela interação do sistema com o usuário, obtendo
os parâmetros para o problema, através de questionamentos. O módulo também valida as
respostas enviadas pelo usuário;
• Motor de Inferência: responsável pelo desenvolvimento do raciocínio através das
informações obtidas pelo módulo coletor de dados. O motor de inferência processa a
linguagem de representação que se encontra na base do conhecimento do SBC; e
• Módulo de Explicações: módulo que se encarrega de explicitar justificativas e
conclusões obtidas através da execução do motor de inferência.
De acordo com Luger (2004), a base do conhecimento contém informações de um domínio
particular de uma aplicação. Em um sistema especialista baseado em regras, este conhecimento é
representado por condições (se... então...). Essa base possui o conhecimento necessário baseado em
informações de especialistas em uma determinada área de aplicação.
A memória de trabalho é a responsável por armazenar as conclusões intermediárias de um
processo de raciocínio, enquanto a base de dados é o repositório de dados e informações utilizadas
ou geradas a partir de um sistema especialista (REZENDE, 2003).
Para concluir, visualizou-se o funcionamento de um sistema especialista e suas camadas.
Pôde-se entender como ocorre o fluxo de raciocínio e quais as peças necessárias para se criar um
sistema especialista.
O sistema Gilgamesh utilizou sistemas especialistas para implementação das heurísticas dos
agentes inteligentes responsáveis pelos leilões, pois o raciocínio dos ofertantes e arrematantes
podem ser expressos facilmente por regras
40
3 DESENVOLVIMENTO
Nesta sessão serão abordados o projeto, desenvolvimento e funcionamento da ferramenta
Gilgamesh. A arquitetura do sistema pode ser visualizada na Figura 15, onde é demonstrada a
divisão do Gilgamesh em três aplicações:
• Aplicação Servidor: responsável pela maior parte do processamento do sistema. O
software que executará como servidor deverá gerenciar os agentes e o repositório de
dados da aplicação;
• Aplicação Sistema Especialista: responsável por manter e executar as regras do Sistema
Especialista; e
• Aplicação Cliente: responsável pelo fornecimento de uma interface para que o usuário
utilize o sistema Gilgamesh.
Gilgames h
Servidor Gilgamesh
Cliente Gilgamesh
RMI
InterfacesAplicação SE
RMI
Agentes
BD
SE(JCLIPS)
Figura 15. Arquitetura do sistema Gilgamesh
Os modelos desenvolvidos para o projeto Gilgamesh, utilizaram a ferramenta Enterprise
Archtect 6. Entre os itens que podem ser encontrados a seguir, destacam-se: a descrição dos
requisitos do sistema, o modelo de casos de uso, o modelo de interação (diagramas de seqüência), o
41
modelo de classes e o modelo ER (entidade-relacionamento). Além dos modelos de projeto, podem
ser visualizados a seguir, informações sobre a idealização da implementação do Gilgamesh.
As tecnologias envolvidas na implementação do sistema, que se relacionam principalmente
com as aplicações de leilões e busca de preços de produtos, são apresentadas a seguir na descrição
do desenvolvimento do projeto.
3.1 MODELAGEM
Para modelar o sistema Gilgamesh foram levantados os requisitos e informações sobre os
agentes, e foram produzidos casos de uso, diagramas de seqüência, diagrama de classe e diagrama
ER. Também foram construídos os protótipos das principais telas do sistema e as árvores de decisão
do sistema especialista. A seguir se encontra o projeto realizado para modelar o sistema Gilgamesh.
3.1.1 Levantamento de Requisitos
Os requisitos foram levantados para estabelecer as funções indispensáveis à ferramenta
proposta. Estes requisitos especificam o que a ferramenta deve ou não fazer, e não como os
procedimentos devem ser realizados.
3.1.1.1 Regras de Negócio (RN)
Regras de negócio especificam como o negócio funciona. As regras de negócio não são
funcionalidades do sistema, mas sim características a serem consideradas no projeto e
implementação. As regras de negócio do sistema Gilgamesh são:
• RN01: O sistema não deve possibilitar lances feitos pelos próprios ofertantes;
• RN02: Deve-se limitar a busca de preços em algumas lojas virtuais, para manter um
escopo na busca de produtos e no tipo de lojas que devem ser observadas; e
• RN03: Nenhum usuário pode interromper (descartar) um leilão.
3.1.1.2 Requisitos Funcionais (RF)
Requisitos funcionais especificam funções que o sistema proposto deverá contemplar, como
o sistema deve reagir a determinadas situações. Os requisitos funcionais do Gilgamesh são:
• RF01: O sistema deve dispor de uma interface para solicitação de cadastro de usuários;
42
• RF02: O sistema deve acessar somente a usuários cadastrados e identificados;
• RF03: O usuário deve poder criar leilões;
• RF04: O usuário deve poder participar de leilões criados;
• RF05: O usuário deve poder pesquisar os leilões, que estão em andamento;
• RF06: O módulo de leilões deve permitir que os usuários possam participar em mais de
um leilão por vez;
• RF07: O sistema deve permitir que o usuário que criou o leilão possa encerrá-lo,
proclamando um vencedor, no momento em que desejar, finalizando assim, a
negociação;
• RF08: O sistema deve permitir ao usuário criador de um leilão, a visualização do
mesmo;
• RF09: O sistema deve permitir buscas a produtos;
• RF10: O sistema deve permitir que as buscas de produtos retornem as melhores ofertas
de produtos, baseando-se no preço;
• RF11: O módulo de buscas de produtos deve retornar a uma pesquisa o nome do
fornecedor, o nome do produto, o preço do produto e link para a página encontrada;
• RF12: O sistema deve permitir que o usuário altere as informações de seu cadastro
(menos campos de identificação pessoal); e
• RF13: O sistema deve procurar leilões novos para os arrematantes, possibilitando a
aceitação ou não da sugestão.
3.1.1.3 Requisitos Não Funcionais (RNF)
Requisitos não funcionais definem propriedades e restrições do sistema, e não suas funções.
Os requisitos não funcionais do projeto estão listados a seguir:
• RNF01: O sistema deve ser desenvolvido para o modelo Cliente/Servidor;
• RNF02: As senhas devem ser criptografadas;
• RNF03: O sistema deve utilizar base de dados livre de cobrança de licenças;
• RNF04: Para desenvolvimento da ferramenta será utilizado o ambiente JADE; e
43
• RNF05: A implementação deve ser realizada utilizando a linguagem Java.
3.1.2 Características dos Agentes
Os agentes podem ser caracterizados de acordo com suas propriedades e classificação. Com
a finalidade de atribuir essas definições aos agentes do sistema Gilgamesh, a seguir encontram-se
caracterizações dadas a cada um deles.
3.1.2.1 Propriedades dos Agentes
Fernandéz e Valente (1998, apud BARONE, 2003) identificam atributos e propriedades que
definem os agentes:
• Autonomia: a operação do agente ocorre sem intervenção humana ou com outros
agentes;
• Reatividade: os agentes são capazes de se comunicar entre si, através de uma linguagem
de comunicação. Os agentes são guiados por estímulos;
• Iniciativa: os agentes podem atuar guiados por objetivos;
• Continuidade Temporal: os agentes executam continuamente (executam em segundo
plano);
• Orientação por Objetivos: os agentes executam tarefas complexas, podendo dividi-las
com outros agentes a fim de alcançar seus objetivos;
• Mobilidade: capacidade dos agentes se locomoverem em uma rede de computadores;
• Veracidade: agentes que não comunicam informações de falso propósito;
• Benevolência: agentes que estão dispostos a ajudar outros agentes, se isso não resultar
em nenhum conflito com os seus objetivos;
• Racionalidade: agentes que atuam de forma racional, com o intuito de cumprir seus
objetivos, se os mesmos forem possíveis; e
• Adaptabilidade: os agentes se adaptam aos hábitos, métodos de trabalho e preferências
de um usuário.
44
Os atributos pesquisados podem ser visualizados na Tabela 3, onde estão aplicados aos
agentes do Gilgamesh.
Tabela 3. Propriedades dos agentes do Gilgamesh
Agente Propriedades Interface Sistema Especialista
Autonomia, Continuidade Temporal, Veracidade.
Busca de Produto Autonomia, Iniciativa, Veracidade, Benevolência.
Arrematante Sociabilidade, Reativo, Continuidade Temporal, Orientação por Objetivos, Veracidade, Adaptabilidade.
Ofertante Sociabilidade, Reativo, Continuidade Temporal, Orientação por Objetivos, Veracidade, Adaptabilidade.
Web Crawler Autonomia, Iniciativa, Continuidade Temporal, Veracidade.
3.1.2.2 Classificação e Descrição dos Agentes
Os agentes podem ser caracterizados através dos seguintes tipos de agentes identificados por
Nwana (1996, apud VAHL JÚNIOR, 2003):
• Agentes Colaborativos: cooperam com outros agentes para que sejam realizadas tarefas
de usuários que representam;
• Agentes de Interface: aprendem a realizar tarefas para seus usuários;
• Agentes Móveis: percorrem as redes, interagindo com diferentes computadores,
capturando informações e retornando assim que suas tarefas estiverem realizadas; e
• Agentes de Informação/Internet: fazem gerência, manipulação e captura de informações
de fontes distribuídas.
A Tabela 4 classifica os agentes do sistema Gilgamesh de acordo com as características
levantadas e outras informações complementares sobre os agentes como: inteligência,
funcionamento e número de agentes ativos no sistema.
45
Tabela 4. Classificação e caracterização dos agentes do Gilgamesh
Agente Tipo Inteligência Funcionamento Número de instâncias
Interface Sistema Especialista
Colabotativo Não Estabelece interface de requisições e resultados entre os agentes dos leilões e os Sistemas especialistas.
Um agente executando.
Busca de Produto
Colabotativo Não Busca informações que caracterizem um produto em uma página.
Um agente para cada Página Web encontrada peloAgente Web Crawler.
Arrematante Colabotativo Sim. Inteligência representadas através de regras do Sistema Especialista.
Assumem o papel do usuário arrematante em um leilão.
Vários agentes, normalmente mais do que um por leilão.
Ofertante Colabotativo Sim. Inteligência representadas através de regras do Sistema Especialista.
Assumem o papel do usuário ofertante em um leilão.
Vários agentes. Um por leilão.
Web Crawler
Informação/ Internet
Não Recuperam páginas na Web através da técnica de Web crawling.
Vários agentes.
3.1.3 Modelo de Casos de Uso
Os casos de uso são utilizados para documentar o sistema do ponto de vista de qualquer
elemento externo que interaja com o software (pessoa, outro sistema de informação, dispositivos de
hardware e outros) (STEVENS e POOLEY, 2000). No Gilgamesh, as descrições dos casos de uso
foram divididas em duas sessões: casos de uso da ferramenta e casos de uso dos agentes. Esta
divisão ocorreu para facilitar o estudo do sistema de maneira mais independente dos agentes,
segmentando melhor os passos do projeto.
3.1.3.1 Casos de Uso do Sistema
Os casos de uso do sistema estão organizados em três grupos: funcionalidades gerais,
módulo de leilões e módulo de busca de produtos na Web.
46
Funcionalidades gerais
As funcionalidades gerais do sistema são as atividades mais básicas que podem ser
realizadas no Gilgamesh. Na Figura 16, pode-se visualizar os casos de uso da ferramenta. Os
pacotes “Módulo de Leilões” e “Módulo de Busca de Produtos” estão representados para
demonstrar as outras funcionalidades da ferramenta.
Figura 16. Casos de uso da ferramenta Gilgamesh
No Gilgamesh, as funcionalidades gerais são operadas por dois tipos de usuários (atores):
• Visitante: pessoa que nunca se autenticou no sistema (não possui conta de usuário); e
• Usuário: pessoa que possui uma conta de usuário e está autorizada a utilizar o Gilgamesh
e suas funcionalidades.
Solicita Cadastro
O caso de uso “Solicita Cadastro” é utilizado para um usuário que não tenha sido cadastrado
no sistema. Esta funcionalidade permite que um Visitante da aplicação se torne um Usuário e possa
47
usar o sistema. O requisito desse caso de uso é “a ferramenta terá acesso somente a usuários
cadastrados e identificados” (RF02).
O cenário principal desse caso de uso segue os seguintes passos:
1. O Visitante solicita cadastro;
2. A aplicação Cliente apresenta a tela de cadastro;
3. O Visitante preenche os campos com as informações de cadastro e confirma;
4. A aplicação Cliente envia as informações a aplicação Servidor;
5. A aplicação Servidor verifica a validade do cadastro;
6. A aplicação Servidor envia confirmação de cadastro a aplicação Cliente; e
7. A aplicação Cliente envia ao Visitante a confirmação de cadastro.
Caso no passo cinco o cadastro não seja validado, será efetuado o cenário de exceção:
1. A aplicação Servidor envia a rejeição do cadastro a aplicação Cliente; e
2. A aplicação Cliente envia mensagem ao Visitante, informando os erros nos dados
enviados e solicitando verificação dos campos.
Se tudo ocorrer perfeitamente, ao final da execução do caso de uso “Solicita Cadastro”, o
usuário estará cadastrado e poderá utilizar as demais funcionalidades do sistema.
Autentica-se
Para garantir a validade das operações mantidas na ferramenta, cada usuário deve possuir
seu cadastro. O caso de uso “Autentica-se” foi modelado para que seja identificado o usuário que
faça operações no Gilgamesh. O requisito desse caso de uso é “A ferramenta terá acesso somente a
usuários cadastrados e identificados” (RF02). A pré-condição para este caso de uso é a de que o
usuário deve possuir um cadastro no sistema.
O cenário principal para esse caso de uso divide-se em:
1. Autenticação de Usuário {principal}
2. O Usuário solicita autenticação no sistema;
3. A aplicação Cliente envia dados da autenticação a aplicação Servidor;
4. A aplicação Servidor verifica autenticidade;
48
5. A aplicação Servidor envia uma mensagem informando o sucesso da autenticação a
aplicação Cliente; e
6. A aplicação Cliente mostra a tela principal do sistema.
Caso no passo três, seja verificado que o usuário não pôde ser autenticado, executa-se o
cenário de exceção:
1. A aplicação Servidor envia uma mensagem de erro de validação de usuário a aplicação
Cliente; e
2. A aplicação Cliente envia uma mensagem de erro de autenticidade ao Usuário.
Logo após a execução, o Usuário terá sido identificado pelo sistema, permitindo o acesso as
funcionalidades do mesmo.
Atualiza Cadastro
Partindo-se do princípio de que o sistema deve permitir que o Usuário altere algumas
informações de seu cadastro, foi modelado o caso de uso “Atualiza Cadastro” (RF12). A pré-
condição para que isto aconteça é a de que o usuário já deve ter se autenticado.
O caso de uso “Atualiza Cadastro” executa em seu cenário principal o seguinte fluxo:
1. O Usuário solicita cadastro;
2. A aplicação Cliente solicita informações do Usuário a aplicação Servidora;
3. A aplicação Servidor busca na base de dados as informações do Usuário;
4. A aplicação Servidor envia uma mensagem a aplicação Cliente contendo informações do
Usuário;
5. A aplicação Cliente mostra interface com o formulário de cadastro e os dados do
Usuário a ele mesmo;
6. O Usuário faz as modificações e confirma;
7. A aplicação Cliente envia as modificações à aplicação Servidor;
8. A aplicação servidor verifica a validade das alterações;
9. A aplicação Servidor grava os dados na base;
10. A aplicação Servidor envia uma mensagem a aplicação Cliente informando o sucesso
das alterações; e
11. A aplicação Cliente envia mensagem de sucesso ao Usuário.
49
Caso no passo oito, os dados não são válidos, o seguinte cenário de exceção deve ser
executado:
1. A aplicação Servidor envia uma mensagem a aplicação Cliente informando que não foi
possível validar as alterações;
2. A aplicação Cliente envia mensagem ao Usuário, informando os possíveis problemas; e
3. O Usuário preenche novamente o cadastro.
Logo após executar corretamente os passos da atualização, o Usuário terá seus dados
atualizados.
Módulo de leilões
O módulo de leilões engloba a parte de leilões virtuais do sistema Gilgamesh. Na Figura 17,
pode-se visualizar os casos do módulo de leilões.
50
Figura 17. Casos de uso do módulo de leilões
No módulo de leilões, dois usuários (atores) operam sobre o sistema. Esses usuários são
especializações do Usuário. Isto acontece, pois qualquer usuário autenticado no sistema pode fazer
lances ou gerar leilões. Os usuários que acessam os casos de uso do módulo corrente são:
• Ofertante: usuário que gera os leilões; e
• Arrematante: usuário dá lances nos leilões.
Cria Leilão
O caso de uso “Cria Leilão” foi projetado para que um Ofertante disponha da funcionalidade
de criação de leilões. Esta funcionalidade partiu do requisito funcional “o usuário poderá criar
leilões” (RF03). Para que isto aconteça basta que o usuário esteja autenticado no sistema.
51
Como cenário principal desse caso de uso, segue-se o fluxo:
1. O Ofertante solicita a criação do leilão;
2. A aplicação Cliente apresenta a tela de criação de leilões;
3. O Ofertante insere os dados do leilão;
4. A aplicação Cliente envia os dados da criação de leilão a aplicação Servidor;
5. A aplicação Servidor insere o leilão na base de dados;
6. A aplicação Servidor envia mensagem de sucesso a aplicação Cliente; e
7. A aplicação Cliente envia mensagem de sucesso ao Ofertante.
Como resultado da execução do caso de uso, o Ofertante cria o leilão com as configurações
desejadas.
Encerra Leilão
Um Ofertante pode encerrar o leilão no momento que desejar, proclamando um vencedor
(RF07). Devido a esta condição, o caso de uso “Encerra Leilão” foi projetado. Para que um
Ofertante encerre um leilão, basta estar autenticado no sistema e ser o criador do leilão que deseja
encerrar.
No cenário principal, o seguinte fluxo é apresentado:
1. O Ofertante seleciona o leilão que deseja encerrar na interface principal do sistema e
solicita encerramento;
2. A aplicação Cliente solicita a aplicação Sevidor o encerramento do leilão;
3. A aplicação Servidor grava informações de encerramento de leilão na base;
4. A aplicação Servidor envia informações ao vencedor (arrematante) do leilão;
5. A aplicação Servidor envia mensagem de sucesso a aplicação Cliente; e
6. A aplicação Cliente envia mensagem de sucesso ao Ofertante.
Depois de executar solicitar encerramento do leilão, o vencedor do leilão é proclamado.
52
Verifica Leilões Criados
Um Ofertante precisa saber a situação dos seus leilões (RF08). A partir dessa necessidade, o
caso de uso “Verifica Leilões Criados” foi projetado. Para acessar esta funcionalidade no sistema,
basta o usuário estar autenticado.
O cenário principal apresenta os seguintes fluxos:
1. O Ofertante solicita a visualização dos leilões criados na tela principal;
2. A aplicação Cliente solicita a aplicação Servidor a listagem dos leilões do Ofertante que
fez a solicitação;
3. A aplicação Servidor busca informações dos leilões, baseando-se no Ofertante;
4. A aplicação Servidor envia as informações dos leilões do Ofertante a aplicação Cliente;
e
5. A aplicação Cliente lista na interface as informações referentes aos leilões do Ofertante.
Depois de solicitar a visualização dos próprios leilões, os Ofertantes poderão visualizar as
informações de seus leilões.
Submete Lances
Um usuário pode participar de um leilão criado, assumindo o papel de arrematante (RF04).
Para cobrir esta funcionalidade, foi projetado o caso de uso “Submete Lances”. Para submeter um
lance basta o usuário estar autenticado no sistema.
O cenário principal da submissão de lances passa pelo seguinte fluxo:
1. O Arrematante solicita a submissão de lances;
2. A aplicação Cliente exibe a interface de submissão de lances ao Arrematante;
3. O Arrematante insere as informações necessárias ao cabeçalho de leilões e Solicita busca
de lances;
4. A aplicação Cliente solicita as informações da tela do cadastro de leilões a aplicação
Servidor;
5. A aplicação Servidor busca os leilões em aberto que possuem o produto escolhido;
6. A aplicação Servidor envia todos os leilões encontrados em aberto para a aplicação
Cliente;
53
7. A aplicação Cliente lista os leilões para o Usuário;
8. O Arrematante adiciona ou remove leilões a sua lista de lances e faz suas escolhas
quanto aos leilões;
9. O Arrematante confirma participação nos leilões;
10. A aplicação Cliente envia os dados dos lances a aplicação Servidor;
11. A aplicação Servidor insere os dados na base de dados;
12. A aplicação Servidor informa sucesso a aplicação Cliente; e
13. A aplicação Cliente informa ao Arrematante sucesso da operação.
Logo após a realização da tarefa, o Arrematante terá seus lances utilizados no leilão.
Confirma Participação em Leilão
O sistema deve fornecer uma lista de leilões nos quais o Arrematante poderá participar,
baseando-se nos interesses atuais (de acordo com leilões que participa atualmente) (RF13). Para que
o usuário possa aceitar ou não estas sugestões do sistema, o caso de uso “Confirma Participação em
Leilão” foi projetado. Para que esta funcionalidade esteja disponível, o usuário deverá estar
autenticado no sistema.
1. O cenário principal do caso de uso está listado a seguir:
2. A aplicação Servidor verifica que há leilões livres e possíveis de serem aceitos pelo
Arrematante;
3. A aplicação Cliente avisa o Arrematante de possíveis leilões dos quais ele poderia
participar; e
4. O Arrematante confirma a participação nos leilões e submete os lances para os mesmos
(caso de uso "Submeter Lance").
O Arrematante aceita a participação nos leilões, os quais ele poderá submeter lances.
Módulo de busca de produtos
O módulo de busca de produtos é responsável pela busca de preços de produtos no
repositório de dados. Estas informações são provenientes de sites de lojas virtuais. Na Figura 18,
pode-se visualizar os casos do módulo de busca de produtos.
54
Figura 18. Caso de uso do módulo de busca de produto
No módulo de busca de preços, há apenas o operador (ator) do sistema Usuário. Esse usuário
é uma pessoa autenticada no sistema que possui acesso a busca de produtos.
Solicita Busca de Produto
Para que o sistema permita a busca de produtos, baseando-se em menor preço (RF09 e
RF10), foi projetado o caso de uso “Solicita Busca de Produto”. Para efetuar uma busca de
produtos, basta apenas que o usuário esteja autenticado no sistema (operador Usuário).
No cenário principal, a seguinte seqüência acontece:
1. O Usuário solicita busca de produtos, informando uma palavra-chave;
2. A aplicação Cliente envia a requisição de busca com a palavra-chave para a aplicação
Servidor;
3. A aplicação Servidor busca a informação na base de dados, baseando-se na palavra-
chave;
4. A aplicação Servidor envia a aplicação Cliente o resultado da busca; e
5. A aplicação Cliente mostra os resultados da busca na interface.
Depois da solicitação, o Usuário terá disponível informações do produto pesquisado.
3.1.3.2 Casos de Uso dos Agentes
Os casos de uso dos agentes estão organizados em dois grupos: módulo de leilões e módulo
de busca de produtos na Web. Esses casos de uso foram criados para facilitar a implementação dos
agentes e descrever suas funcionalidade
55
Agentes e módulo de leilões
As funcionalidades dos módulos de leilões descrevem os comportamentos que o sistema
deve permitir que os agentes executem. Na Figura 19, pode-se observar os casos de uso dos agentes
descritos nesta sessão.
Figura 19. Casos de uso dos agentes do módulo de leilões
Os atores dos módulos de leilões se dividem entre:
• Agente Ofertante: agente que fornecerá e gerenciará o serviço de leilão;
• Agente Arrematante: agente que submete lances aos Ofertantes; e
• Agente Interface Sistema Especialista: agente responsável por gerar interface entre os
agentes da Aplicação Servidor e a execução das regras do Sistema Especialista.
56
Processa Requisições ao Sistema Especialista
Para que os agentes da aplicação possam receber o resultado da execução das regras do
Sistema Especialista, o Agente Interface Sistema Especialista. Esta funcionalidade foi modelada
através do caso de uso “Processa Requisições ao Sistema Especialista”. Para isto, basta que o agente
em questão esteja executando.
Como cenário principal apresenta-se:
1. O Agente Interface Sistema Especialista carrega a lista de requisições ao Sistema
Especialista;
2. O Agente Interface Sistema Especialista solicita a execução de cada requisição a
Aplicação Sistema Especialista;
3. A Aplicação Sistema Especialista retorna os resultados ao Agente Interface Sistema
Especialista; e
4. O Agente Interface Sistema Especialista submete os resultados aos agentes requisitantes.
Ao final da tarefa, os agentes que requisitaram a execução das regras obtém os resultados
solicitados ao Agente Interface Sistema Especialista.
Disponibiliza Serviço de Leilão
O Agente Ofertante disponibiliza um serviço de leilão para a aplicação. Esse processo foi
modelado pelo caso de uso “Disponibiliza Serviço de Leilão”. Para que esse serviço seja
disponibilizado, basta que o sistema agende a execução dos leilões.
Como cenário principal do caso de uso, pode-se apresentar:
1. A aplicação Servidor busca leilões abertos que não estão executando no momento;
2. A aplicação Servidor executa o Agente Ofertante; e
3. O Agente Ofertante informa a aplicação Servidor que seus serviços estão disponíveis
para lances.
No final do fluxo de operação, o Agente Ofertante disponibiliza o serviço de leilão.
Recebe Lances
57
Para que um leilão possa receber propostas de compra, o sistema e o Agente Ofertante
devem trocar informações sobre os lances. Com o intuito de projetar esta informação, o caso de uso
“Recebe Lances” foi modelado. Para que um leilão receba lances é necessário que o “Agente
Ofertante” do leilão esteja executando.
Como cenário principal, o caso de uso apresenta:
1. A aplicação Servidor busca todos os lances para os leilões que estão sendo executados;
2. A aplicação Servidor envia os lances aos seus respectivos Agentes Ofertantes; e
3. Os Agentes Ofertantes recebem os lances.
Logo após a execução desta funcionalidade, o “Agente Ofertante” recebe os lances
realizados.
Finaliza Leilão
Um Agente Ofertante deve poder finalizar um leilão, de acordo com o critério que foi
configurado, e sinalizar um vencedor. Essa funcionalidade foi modelada através do caso de uso
“Finaliza Leilão”. Para que o leilão seja finalizado, basta que o critério de encerramento seja
satisfeito.
Como cenário principal, apresenta-se:
1. O Agente Ofertante verifica que a condição de término do leilão foi satisfeita;
2. O Agente Ofertante envia uma mensagem a aplicação Servidor solicitando término do
leilão;
3. A aplicação Servidor grava informações de finalização do leilão; e
4. A aplicação Servidor informa o vencedor do leilão sobre sua vitória.
Ao final da execução da funcionalidade expressa por esse caso de uso, o leilão é finalizado e
um vencedor é sinalizado.
Submete Lances
Um Agente Arrematante deve possuir um mecanismo que permita a submissão de lances a
leilões. Essa funcionalidade é projetada pelo caso de uso “Submete Lances”. Para que a submissão
de lances seja possível, basta que o Agente Arrematante esteja executando.
58
Apresenta-se o seguinte cenário principal, para esse caso de uso:
1. O Agente Arrematante solicita a aplicação Servidor as configurações de lances de seu
escopo;
2. A aplicação Servidor busca configurações do lance na base de dados;
3. A aplicação Servidor retorna as configurações dos Lances;
4. O Agente Arrematante recebe as informações da aplicação Servidor;
5. O Agente Arrematante solicita informações do leilão que irá participar, através do
Agente Ofertante;
6. O Agente Ofertante retorna as informações; e
7. O Agente Arrematante submete o lance ao Agente Ofertante.
Ao final do processo de submissão de lances, o Agente Arrematante possui um lance
submetido ao Agente Ofertante.
Agentes e módulo de busca de produtos
As funcionalidades dos módulos de produtos descrevem os comportamentos que o sistema
deve permitir que os agentes de busca executem. Na Figura 20, pode-se observar os casos de uso
dos agentes descritos nesta sessão.
Figura 20. Casos de uso dos agente do módulo de busca de produtos
Os atores dos módulos de busca de produtos se dividem entre:
59
• Agente Web Crawler: agente responsável pela varredura nas páginas à procura de novos
links de produtos; e
• Agente Busca Produto: agente que varre uma página, previamente armazenada pelo
Agente Web Crawler, a procura de informações de produtos.
Acessa Links na Web
Para que um Agente Web Crawler possa acessar páginas Web, o caso de uso “Acessa Links
na Web”. Para que esta funcionalidade possa ocorrer, no mínimo um Agente Web Crawler deve
estar executando.
Como cenário principal do caso de uso, apresenta-se:
1. O Agente Web Crawler solicita página através de uma URL; e
2. O aplicativo Servidor busca e retorna página solicitada ao Agente.
Após a solicitação de acesso, o Agente Web Crawler recebe a página solicitada.
Busca Links na Página
O Agente Web Crawler varre uma página da Web em busca de links de produtos. Para que
esta funcionalidade esteja disponível, foi projetado o caso de uso “Busca Links na Página”. Para
que haja essa busca, o Agente Web Crawler deve estar executando.
Como cenário principal, apresenta-se:
1. O Agente Web Crawler solicita ao aplicativo Servidor a página para análise;
2. O aplicativo Servidor busca a página na base de dados;
3. O aplicativo Servidor retorna a página ao Agente; e
4. O Agente Web Crawler procura links (do mesmo domínio) nas páginas.
Após a busca, o agente disponibilizará os links encontrados na página.
60
Armazena Informações
Os agentes do módulo de busca de preços precisam armazenar o resultado de suas pesquisas
em um repositório. Para isso, o caso de uso “Armazena Informações” foi projetado. Para efetuar
esse armazenamento, um dos agentes de busca deve estar executando.
O cenário principal apresenta-se através do fluxo a seguir:
1. O Agente (Web Crawler ou de Busca de Produto) informa as informações necessárias
para a gravação; e
2. A aplicação Servidor grava as informações na base de dados.
Ao final do procedimento, as informações provenientes das pesquisas são armazenadas.
Busca Informações de Produtos
O Agente Busca Produto tem como função principal localizar informações referentes a
produtos em uma página gravada em um repositório pelo Agente Web Crawler. Essa
funcionalidade foi projetada através do caso de uso “Busca Informações de Produtos”.
Como cenário principal apresenta-se:
1. O Agente Busca Produto solicita a aplicação Servidor a página a ser analisada;
2. A aplicação Servidor retorna a página a ser analisada pelo Agente;
3. O Agente Busca Produto busca informações de uma oferta na página retornada pela
aplicação Servidor;
4. O Agente Busca Produto envia as informações dos produtos encontrados a aplicação
Servidor; e
5. A aplicação Cliente insere as informações de produtos na base de dados.
Logo após a pesquisa, todos os produtos e dados pertinentes, encontrados na página, são
armazenados em um repositório (base de dados).
61
3.1.4 Modelos de Interação
Nesta sessão, para descrever o modelo de interação no sistema foram utilizados diagramas
de seqüência. Segundo Bezerra (2002), o principal objetivo desse tipo de diagrama é demonstrar
como as mensagens são enviadas ao decorrer do tempo.
Os diagramas de seqüência do Gilgamesh foram divididos em seqüências da ferramenta,
seqüências do módulo de leilões, seqüências do módulo de busca de preços e seqüências dos
agentes.
3.1.4.1 Diagramas de Seqüência da Ferramenta
Para demonstrar a função mais comum a todos os usuários, foi elaborado o diagrama de
seqüência presente na Figura 21. Esta figura apresenta como ocorre a solicitação de cadastro de um
usuário. As entidades que fazem parte deste diagrama são:
• Visitante: o usuário é representado como o Visitante, descrito no caso de uso “Solicita
Cadastro”, ou seja, um usuário sem cadastro no sistema Gilgamesh;
• Cadastro de Usuário: interface de cadastro entre o Visitante e o sistema Gilgamesh;
• Ferramenta Lado Cliente: programa da ferramenta Gilgamesh que fica executando na
máquina do usuário;
• Ferramenta Lado Servidor: programa da classe Servidor que é executado em uma
máquina dedicada ao sistema Gilgamesh;
• GUsuário: instância no sistema responsável por coletar informações e processar funções
necessárias ao usuário; e
• Banco de Dados: repositório de dados utilizado para armazenar informações do
Gilgamesh.
O diagrama demonstra que um Visitante faz a solicitação de cadastro na ferramenta
informando seus dados a interface do sistema. Esta interface está compreendida a versão Cliente do
Gilgamesh que envia uma mensagem ao servidor informando os dados cadastrais. Os dados são
processados por uma instância da classe GUsuário. Caso os dados sejam aceitos, as informações são
gravadas no banco de dados e uma mensagem de sucesso se propaga pelas camadas da aplicação,
até finalmente, sinalizar positivamente ao Visitante. Caso os dados cadastrais não sejam aceitos,
62
uma mensagem identificando o erro é transmitida ao Visitante, para que o mesmo possa incluir os
dados de maneira correta.
Figura 21. Diagrama de seqüência de cadastro de usuário
3.1.4.2 Diagramas de Seqüência do Módulo de Leilões
Com intuito de modelar as principais funções do módulo de leilões, foram elaborados dois
diagramas de seqüência: criação de leilões e submissão de lances.
Criação de leilões
A função de criação de leilões foi projetada para que um usuário do sistema possa configurar
um novo leilão no sistema Gilgamesh, que a partir do momento de sua criação até seu
encerramento, ficará disponível a lances de interessados.
63
A Figura 22 demonstra o diagrama de seqüência da função de criação de leilões. Nesse
diagrama podem ser visualizadas as seguintes entidades:
• Ofertante: usuário autenticado no sistema que está solicitando a criação de um leilão, ou
visualizando resultados dos outros previamente criados;
• Interface de Criação de Leilões: interface entre o Ofertante e o sistema Gilgamesh;
• Ferramenta Lado Cliente: programa da ferramenta Gilgamesh que fica executando na
máquina do usuário;
• Ferramenta Lado Servidor: programa da classe Servidor que é executado em uma
máquina dedicada ao sistema Gilgamesh;
• GLeilão: instância da classe GLeilão responsável por processar e armazenar informações
de um leilão; e
• Banco de Dados: repositório de dados onde os leilões serão armazenados.
O diagrama demonstra como funciona o processo de criação de leilões. Primeiramente, o
Ofertante insere as informações necessárias para a configuração de leilões. Logo depois a aplicação
Cliente envia ao servidor a solicitação de criação de leilão. A aplicação servidor utiliza-se da
instância da classe GLeilão para processar e verificar os dados da configuração. Caso os dados
estejam corretos, o leilão é cadastrado no bando de dados. Se os dados não estiverem corretos, o
sistema dispara uma mensagem ao Ofertante identificando os possíveis erros de configuração,
possibilitando dessa maneira uma correção dos dados.
64
Figura 22. Diagrama de seqüência de criação de leilões
Submissão de lances
A submissão de lances é uma funcionalidade indispensável para o sistema de leilões virtuais,
pois é a partir dessa que o arrematante configura seus lances a leilões da ferramenta. A Figura 23
mostra o diagrama de seqüência desse processo. As entidades envolvidas são:
• Arrematante: usuário autenticado no sistema que submete lances e verifica a posição dos
mesmos;
• Interface de Submissão de Lances: interface entre o Arrematante e o sistema Gilgamesh;
• Ferramenta Lado Cliente: programa da ferramenta Gilgamesh que fica executando na
máquina do usuário;
• Ferramenta Lado Servidor: programa da classe Servidor que é executado em uma
máquina dedicada ao sistema Gilgamesh;
• GLance: instância da classe GLance. Esta classe é responsável pelo processamento e
armazenamento dos lances no banco de dados; e
65
• Banco de Dados: repositório de dados no qual os lances são armazenados.
O diagrama de seqüência demonstra a seqüência de funcionamento de submissões de lances
na ferramenta Gilgamesh. Primeiramente, o Arrematante configura seus lances e os submete através
da interface de submissão. A aplicação Cliente envia informações à aplicação Servidor que se
utiliza objeto da classe GLance para validar os lances. Se os lances forem aceitos, estes são
armazenados no banco de dados, e o Arrematante recebe uma mensagem de sucesso. Caso
contrário, uma mensagem identificando as inconsistências da configuração é enviada ao
Arrematante, para uma possível correção.
Figura 23. Diagrama de seqüência de sumissão de lances
3.1.4.3 Diagrama de Seqüência do Módulo de Busca de Preços
A funcionalidade principal do módulo descrito nessa sessão é o de efetuar buscas de preços
de produtos que um usuário tenha solicitado. Na Figura 24, o processo do módulo de busca de
preços é demonstrado a partir de um diagrama de seqüência. As entidades visualizadas nesse
diagrama são:
66
• Usuário: usuário autenticado no sistema Gilgamesh;
• Interface de Busca de Produtos: interface entre o Usuário e o sistema Gilgamesh;
• Ferramenta Lado Cliente: programa da ferramenta Gilgamesh que fica executando na
máquina do usuário;
• Ferramenta Lado Servidor: programa da classe Servidor que é executado em uma
máquina dedicada ao sistema Gilgamesh;
• GBusca: instância da classe GBusca que é responsável pela recuperação das informações
solicitadas na base de dados; e
• Banco de Dados: repositório de dados no qual se encontram as informações que a busca
deve recuperar.
No diagrama, pode-se visualizar que, primeiramente, o Usuário solicita a busca fornecendo
as informações de busca. A aplicação Cliente recupera estas informações da interface e submete a
solicitação à aplicação Servidor. Através do objeto da classe GBusca, o Servidor consegue
recuperar as informações do banco de dados. Estas informações são remetidas à aplicação Cliente e
logo depois ao Usuário.
Figura 24. Diagrama de seqüência de busca de produtos
67
3.1.4.4 Diagramas de Seqüência dos Agentes
Na modelagem do sistema Gilgamesh, dois diagramas de seqüência destacam
processamentos dos agentes: agentes do processo na busca de produtos na Web e agentes do
módulo de leilões.
Agentes do processo de busca de produtos na Web
Os agentes de busca de produtos na Web possuem a função de coletar informações sobre
produtos em sites de lojas virtuais. Na Figura 25, um diagrama de seqüência explica o
funcionamento desses agentes. As entidades envolvidas no diagrama são:
• Interface Web: interface na qual os agentes podem solicitar acesso a páginas Web;
• Agente Web Crawler: agente responsável por acessar e gravar as páginas Web de lojas
virtuais e procurar links de produtos;
• Agente de Busca de Produto: agente responsável por utilizar as páginas gravadas pelo
Agente Web Crawler para localizar informações de produtos e gravá-las no banco; e
• Banco de Dados: repositório no qual são armazenadas informações sobre produtos e a
busca de produtos na Web.
O diagrama de seqüência explicita que o Agente Web Crawler é executado antes do Agente
de Busca de Produto. O Agente Web Crawler, primeiramente, solicita o link que está no topo da fila
de busca e logo depois o acessa. A página é gravada e depois é feita uma varredura à procura de
links na página, que pertençam ao mesmo domínio do site. Estes links encontrados são inseridos no
final da fila de busca. Esse processo se repete até que a fila esteja vazia.
Concluindo o processo, o Agente de Busca de Produto recupera as páginas gravadas que
estão no banco de dados. Depois o agente busca produtos dentro de cada uma das páginas e grava
estas informações na base. Desse modo, os produtos são extraídos das páginas de lojas virtuais e
uma pesquisa de preços pode ser realizada.
68
Figura 25. Diagrama de seqüência dos agentes do processo de busca de produtos na Web
Agentes do módulo de leilões
Os agentes do módulo de leilões automatizam o processo de leilões. Este funcionamento é
demonstrado através do diagrama de seqüência presente na Figura 26. Para explicar melhor o
diagrama, estão listadas a seguir as entidades presentes no diagrama:
• Agente Ofertante: agente responsável pelas ofertas no leilão;
• Agente Arrematante: agente que submete os lances aos leilões;
• GilgaAgentManager: instância de classe de manipulação dos agentes; e
• Banco de Dados: repositório de dados no qual as informações de leilões são
armazenadas.
O diagrama descreve a seqüência do processamento dos leilões virtuais, bem como a troca
de mensagens entre eles. Observando o diagrama, verifica-se que, inicialmente, a instância da classe
GilgaAgenteManager realiza uma busca, na base de dados, por ofertantes e arrematantes válidos, e
que não foram inicializados. Em seguida, o GilgaAgenteManager inicializa os Agentes Ofertantes e
Arrematantes, repassando aos mesmos, informações de comportamento e as informações de
participantes de cada leilão. Depois de inicializado, e a cada novo lance, o Agente Ofertante solicita
69
novos lances aos Agentes Arrematantes que participam do mesmo leilão, informando também o
valor que está atualmente vencendo o leilão.
Cada Agente Arrematante, por sua vez, verificam se o lance que está vencendo no leilão até
o momento é maior que o máximo que o arrematante está disposto a pagar. Se for maior, o Agente
Arrematante abandona o leilão, caso contrário, o mesmo calcula o valor do seu novo lance e
submete essa informação ao Agente Ofertante. O Agente Ofertante recebe os valores dos lances dos
arrematantes do leilão e verifica se os mesmos são válidos. Caso os lances sejam válidos, o maior
deles é considerado como o vencedor daquele turno e é gravado na base de histórico de lances, do
Banco de Dados.
70
Figura 26.Diagrama de seqüência dos agentes envolvidos no processo de leilão
3.1.5 Diagramas de Classes
Segundo Bezerra (2002), o diagrama de classes é utilizado para representar o modelo de
classes. De todos os diagramas da UML, esse é o que possui mais termos de notação. Os diagramas
de classes, no projeto Gilgamesh, foram divididos em duas partes principais: classes da ferramenta e
as classes dos agentes.
71
3.1.5.1 Classes da Ferramenta
As classes da ferramenta são aquelas que são usadas em todo o Gilgamesh. Na Figura 27,
pode ser visualizado esse diagrama de classes. As classes presentes no diagrama são: GLance.
GLeilao, GUsuario, GProduto e GOferta.
Figura 27. Diagrama de classes da ferramenta
GLance
Classe que representa os lances submetidos aos leilões. A Tabela 5 e a Tabela 6 demonstram
os atributos e as operações, respectivamente.
Tabela 5. Atributos da classe GLance
Atributo Descrição do Atributo descricao: String Descrição do lance Produto: GProduto Produto do lance quantidade: int Quantidade proposta no lance valor: float Valor do lance
72
Tabela 6. Operações da classe GLance
Operação Parâmetros Descrição da Operação getDescricao(): String Retorna descrição do lance getProduto(): GProduto Retorna produto do lance getQuantidade(): int Retorna quantidade do lance getValor(): float Retorna valor do lance recoverData(): GLance Recupera informações a partir do banco setLance(): void String desc Insere informações do lance storeData(): void Armazena dados do leilão no banco de dados
GLeilao
Classe que representa as características de um leilão virtual. Nas Tabela 7 e Tabela 8 estão
descritos as informações de atributos e operações, respectivamente.
Tabela 7. Atributos da classe GLeilao
Atributo Descrição do Atributo descricao: String Descrição do leilão Lances: GLance Lances do leilão Ofertas: GOferta Ofertas do leilão tipo: String Tipo do leilão
Tabela 8. Operações da classe GLeilao
Operação Parâmetros Descrição da Operação getDescricao(): String Retorna a descrição do produto getLances(): GLance [] Retorna lances submetidos ao leilão getOfertas(): GOfertas Retorna as ofertas do leilão getTipo(): String Retorna o tipo do leilão recoverLeilao(): void String leilao Atualiza o objeto com os dados pertinentes a leilão
da base setLeilao(): void String tipo,
String descricao, GLance Lances, GOferta Oferta
Insere informações do leilão nos atributos
storeData(): void Armazena dados do objeto no banco
73
GUsuario
A classe GUsuario é a responsável de armazenar e processar as informações do usuário. A
Tabela 9 e a Tabela 10 descrevem, respectivamente, os atributos e as operações da classe.
Tabela 9. Atributos da classe GUsuario
Atributo Descrição do Atributo email: String Email do usuário nome: String Nome do usuário
Tabela 10. Operações da classe GUsuario
Operação Parâmetros Descrição da Operação getEmail(): String Retorna e-mail do usuário getNome(): String Retorna nome do usuário setEmail(): void String email Insere o email do usuário setNome(): void String nome Insere nome do usuário
GProduto
A classe GProduto representa um produto no Gilgamesh. A Tabela 11 e a Tabela 12
representam, respectivamente, a descrição dos atributos e operações da classe GProduto.
Tabela 11. Atributos da classe GProduto
Atributo Descrição do Atributo caracteristicas String[] Características do produto descricao String Descrição do produto
74
Tabela 12. Operações da classe GProduto
Operação Parâmetros Descrição da Operação getCaracteristicas(): String[]
Retorna as características do produto
getDecricao(): String Retorna a descrição do produto setProduto(): void String desc,
String carac[] Insere dados de produto
GOferta
A classe GOferta representa a oferta de um produto à venda. Na Tabela 13 e na Tabela 14
estão listadas as descrições dos atributos e das operações, respectivamente.
Tabela 13. Atributos da classe GOferta
Atributo Descrição do Atributo descricao: String Descrição da oferat Produto: GProduto Produto da oferta quantidade: int Quantidade ofertada valor: float Valor mínimo da oferta
Tabela 14. Operações da classe GOferta
Operação Parâmetros Descrição da Operação getDescricao(): String Retorna descrição da oferta getProduto(): GProduto Retorna produto da oferta getQuantidade(): int Retorna quantidade da oferta getValor(): float Retorna valor da oferta (preço unitário) recoverData(): void String leilão Atualiza dados do objeto com dados da base setOferta(): void String desc,
GProduto Produto, int qtd, float valor
Configura atributos do objeto oferta
storeData(): void Armazena dados da oferta no banco de dados
75
3.1.5.2 Classes dos Agentes
As classes dos agentes são aquelas que são usadas para implementar os agentes do
Gilgamesh. Na Figura 28, pode ser visualizada esse diagrama de classes. As classes presentes no
diagrama são classificadas como classe do módulo de leilões e classes do módulo de busca de
produto.
Figura 28. Diagrama de classes dos agentes do Gilgamesh
Classes do módulo de leilões
As classes do módulo de leilões são aquelas que projetam classes que serão implementadas
no módulo de leilões do Gilgamesh. Essas classes são: GAgOfertante, GAgArrematante e
GAgInterfaceCLIPS.
76
GAgOfertante
A classe GAgOfertante representa o Agente Ofertante do Gilgamesh. Na Tabela 15 e na
Tabela 16 podem ser visualizados, respectivamente, atributos e operações da classe.
Tabela 15. Atributos da classe GAgOfertante
Atributo Descrição do Atributo Leiloes[]: GLeilao Leilões nos quais o leiloeiro participa
Tabela 16. Operações da classe GAgOfertante
Operação Parâmetros Descrição da Operação finalizeLeilao(): void GLeilao Leilao Finaliza leilão recebeLance(): void GLance Lance Recebe lances recoverData(): void Atualiza informações do agente através do
banco de dados showVencedor(): GAgArrematante
Retorna vencedor do leilão
storeData(): void Armazena informações do ofertante no banco de dados
GAgArrematante
A classe GAgArrematante representa o Agente Arrematante do Gilgamesh. Na Tabela 17 e
na Tabela 18 podem ser visualizados, respectivamente, atributos e operações da classe.
Tabela 17. Atributos da classe GAgArrematante
Atributo Descrição do Atributo Lances[] GLance Lances do arrematante
77
Tabela 18. Operações da classe GAgArrematante
Operação Parâmetros Descrição da Operação recoverData(): void GUsuario Usuario Atualiza informações do agente de acordo com
o banco de dados storeData(): void Armazena informações do agente no banco de
dados submitLance(): void GLeilao Leilao Submete lances ao leilão
GAgInterfaceCLIPS
A classe GAgInterfaceCLIPS representa o Agente Interface Sistema Especialista do
Gilgamesh. Na Tabela 19 e na Tabela 20 podem ser visualizados, respectivamente, atributos e
operações da classe.
Tabela 19. Atributos da classe GAgBuscaLeilao
Atributo Descrição do Atributo lstRequisicoes: ArrayList Lista de requisições ao Sistema Especialista
Tabela 20. Operações da classe GAgBuscaLeilao
Operação Parâmetros Descrição da Operação setRequisicao(): void GilgaMessage
GMRequisicao Recupera resultado da execução da requisição a regra
getResultadoRequisicoes(): String
String nomeAgente Retorna resultado das requisições ao Sistema Especialista
Classes do módulo de busca de produtos
As classes do módulo de busca de preços são: GAgWebCrawler e GAgBuscaProduto.
GAgWebCrawler
A classe GAgWebCrawler representa o Agente Web Crawler do Gilgamesh. Na Tabela 21 e
na Tabela 22 podem ser visualizados, respectivamente, atributos e operações da classe.
78
Tabela 21. Atributos da classe GAgWebCrawler
Atributo Descrição do Atributo queueLinks: String[] Fila de links a serem varridos pelo agente
Tabela 22. Operações da classe GAgWebCrawler
Operação Parâmetros Descrição da Operação accessWeb(): String[] String url Acessa uma página Web e retorna a mesma seachLinks(): void String[] pagina Retorna links encontrados em uma página e os
grava no final da queueLinks
GAgBuscaProduto
A classe GAgBuscaProduto representa o Agente Busca Produto do Gilgamesh. Na Tabela
23 e na Tabela 24 podem ser visualizados, respectivamente, atributos e operações da classe.
Tabela 23. Atributos da classe GAgBuscaProduto
Atributo Descrição do Atributo listPaginas: String[][] Lista de páginas que foram armazenadas pelo Agente Web Crawler
Tabela 24. Operações da classe GAgBuscaProduto
Operação Parâmetros Descrição da Operação recoverData(): void Busca todas as páginas que o Agente Web
Crawler gravou no banco de dados e grava as mesmas na lista de páginas (lstPagina)
searchProduto(): void Procura informações de produtos nas páginas da lista lstPagina e grava estes produtos em uma tabela de ocorrências no banco de dados
79
3.1.6 Diagrama Entidade Relacionamento
A ferramenta Gilgamesh utilizou como repositório de informações um banco de dados. Para
que essa estrutura seja contemplada no projeto, foram projetados dois diagramas ER (Entidade
Relacionamento), um para o módulo de leilões e outro para o módulo de busca de preços.
3.1.6.1 Diagrama ER do Módulo de Leilões
Na Figura 29, pode-se observar o diagrama ER que demonstra o que o repositório de dados
do módulo de leilões terá como entidades e associações, ou seja, a estrutura da base de dados.
80
Diagrama ERFigura 29. Diagrama ER do módulo de leilões
81
Para o melhor entendimento das entidades presentes no diagrama, as próximas sub-sessões
descrevem cada uma delas.
Entidade GMSH_USUARIO
A entidade GMSH_USUARIO é utilizada para armazenar informações dos usuários que
utilizam o sistema Gilgamesh. Na Tabela 25 pode ser visualizada a estrutura da entidade
GMSH_USUARIO.
Tabela 25. Dicionário de dados da entidade GMSH_USUARIO
Chave Entidade Tipo Descrição usu_dtnascimento varchar Data de nascimento do usuário usu_email varchar E-mail do usuário PK usu_id integer Identificador do usuário usu_nome varchar Nome completo do usuário usu_senha varchar Senha do usuário usu_bairro varchar Bairro do usuário usu_cep varchar Código postal do usuário usu_cidade varchar Cidade do usuário usu_complemento varchar Complemento do endereço do usuário usu_cpf varchar CPF do usuário usu_endereco varchar Endereço do usuário usu_estado varchar Unidade federativa que o usuário reside usu_nendereco varchar Número da residência do usuário usu_usuario varchar Nome de usuário usu_pais varchar País do usuário
Entidade GMSH_PRODUTO
A entidade GMSH_PRODUTO é utilizada para armazenar informações de produtos. Na
Tabela 26 pode-se verificar uma descrição da estrutura dessa entidade.
Tabela 26. Dicionário de dados da entidade GMSH_PRODUTO
Chave Entidade Tipo Descrição pro_descricao varchar Descrição do produto pro_foto text Foto do produto FK pro_grupo integer Grupo do produto PK pro_id integer Identificador do produto FK pro_subgrupo integer Subgrupo do produto
82
Entidade GMSH_GRUPO
GMSH_GRUPO é a entidade que serve de repositório aos grupos de produtos (tipos de
produtos) existentes. A Tabela 27 demonstra a estrutura dessa entidade.
Tabela 27. Dicionário de dados da entidade GMSH_GRUPO
Chave Entidade Tipo Descrição gru_descricao varchar Descrição do grupo PK gru_id integer Identificador do grupo
Entidade GMSH_SUBGRUPO
A entidade GMSH_SUBGRUPO é um repositório que possui armazenado sub-grupos de
produtos existentes. A Tabela 28 demonstra como é a estrutura da entidade.
Tabela 28. Dicionário de dados da entidade GMSH_SUBGRUPO
Chave Entidade Tipo Descrição sgr_descricao varchar Descrição do sub-grupo PK sgr_id integer Identificador do sub-grupo de produto
Entidade GMSH_PRODCARAC
Na Tabela 29 pode-se visualizar a estrutura da entidade GMSH_PRODCARAC. Essa
entidade é a responsável por manter armazenados os relacionamentos entre produtos e suas
características.
Tabela 29. Dicionário de dados da entidade GMSH_PRODCARAC
Chave Entidade Tipo Descrição FK pca_caracteristica integer Característica do produto FK pca_produto integer Produto da característica
83
Entidade GMSH_CARACS
A composição da entidade GMSH_CARACS pode ser visualizada na Tabela 30. Essa
entidade armazena as características de produtos que estão no sistema.
Tabela 30. Dicionário de dados da entidade GMSH_CARACS
Chave Entidade Tipo Descrição crc_descricao varchar Descrição da característica PK crc_id integer Identificador da característica crc_chave varchar Característica
Entidade GMSH_OFERTA
GMSH_OFERTA é uma entidade que mantêm informações das ofertas disponibilizadas no
sistema. A Tabela 31 demonstra a estrutura da entidade GMSH_OFERTA.
Tabela 31. Dicionário de dados da entidade GMSH_OFERTA
Chave Entidade Tipo Descrição ofe_descricao varchar Descrição da oferta PK ofe_id integer Identificador da oferta FK ofe_leilao varchar Leilão da oferta FK ofe_produto integer Produto da oferta ofe_qtdtotal Integer Quantidade total da oferta ofe_qtdvend Integer Quantidade vendida da oferta ofe_vlrunit Real Valor unitário da oferta
Entidade GMSH_LANCE
GMSH_LANCE é a entidade que armazena informações sobre os dados dos lances
realizados nos leilões do sistema. A estrutura dessa entidade pode ser visualizada na Tabela 32.
84
Tabela 32. Dicionário de dados da entidade GMSH_LANCE
Chave Entidade Tipo Descrição FK lce_agentearremat integer Agente responsável pelo arremate (se houver) FK lce_arrematante integer Arrematente de qual o lance é atribuído lce_data varchar Data de criação do lance lce_hora varchar Hora de criação do lance PK lce_id integer Identificados da tabela de lances FK lce_tparrematante integer Tipo de arrematante (agente ou humano) lce_vlrinc1 real Primeiro valor de incremento lce_vlrinc2 real Segundo valor de incremento lce_vlrinc3 real Terceiro valor de incremento lce_vlrinc4 real Quarto valor de incremento
Entidade GMSH_TPARREMAT
A entidade GMSH_TPARREMAT armazena os tipos de arrematantes existente no sistema.
Na Tabela 33 pode-se visualizar a estrutura dessa entidade.
Tabela 33. Dicionário de dados da entidade GMSH_TPARREMAT
Chave Entidade Tipo Descrição tar_descricao varchar Descrição do do tipo do arrematante PK tar_id integer Identificador do tipo do arrematante
Entidade GMSH_TPAGENT
GMSH_TPAGENT armazena informações dos tipos dos agentes do sistema de leilões:
arrematantes ou ofertantes. A estrutura pode ser visualizada na Tabela 34.
Tabela 34. Dicionário de dados da entidade GMSH_TPAGENT
Chave Entidade Tipo Descrição tpa_descricao varchar Descrição do tipo do agente PK tpa_id integer Identificador de tipo de agente
85
Entidade GMSH_LEIAGENT
A entidade GMSH_LEIAGENT armazena informações de agentes que participam de leilões.
A estrutura da entidade pode ser visualizada na Tabela 35.
Tabela 35. Dicionário de dados da entidade GMSH_LEIAGENT
Chave Entidade Tipo Descrição PK lag_id integer Identificador do agente lag_nome varchar Nome do agente FK lag_tipo integer Tipo do agente (ofertante ou arrematante) FK lag_usuario integer Usuário nome do agente
Entidade GMSH_TRANS
A entidade responsável por armazenar informações sobre transações em um leilão é a
GMSH_TRANS. A Tabela 36 demonstra a estrutura dessa entidade.
Tabela 36. Dicionário de dados da entidade GMSH_TRANS
Chave Entidade Tipo Descrição ttr_descricao varchar Descrição do tipo da transação PK ttr_id integer Identificador de tipo de transação
Entidade GMSH_LANCFECHADO
A entidade que armazena lances vitoriosos em leilões é GMSH_LANCFECHADO. A
Tabela 37 demonstra a estrutura da entidade.
Tabela 37. Dicionário de dados da entidade GMSH_LANCFECHADO
Chave Entidade Tipo Descrição FK lfe_lance integer Lance realizado FK lfe_oferta integer Oferta de um leilão ao qual o lance se aplica lfe_qtd integer Quantidade do lance lfe_valor real Valor do lance
86
Entidade GMSH_TRANSAGENT
As transações que ocorrem com os agentes em relação aos leilões são armazenadas na
entidade GMSH_TRANSAGENT. A Tabela 38 demonstra a estrutura dessa entidade.
Tabela 38. Dicionário de dados da entidade GMSH_TRANSAGENT
Chave Entidade Tipo Descrição FK tag_agente integer Agente da transação tag_data varchar Data da transação tag_descricao varchar Descrição da transação tag_horario varchar Horário da transação PK tag_id integer Identificador da transação FK tag_leilao varchar Leilão no qual a transação ocorreu
Entidade GMSH_LEILAO
A entidade GMSH_LEILAO armazena as informações dos leilões do sistema. Pode
visualizar a estrutura dessa entidade na Tabela 39.
Tabela 39. Dicionário de dados da entidade GMSH_LEILAO
Chave Entidade Tipo Descrição FK lei_agente integer Agente ofertante lei_descricao varchar Descrição do leilão lei_dtcriacao varchar Data de criação do leilão lei_duracao integer Duração em horas do leilão lei_hrcriacao varchar Horário de criação do leilão PK lei_id varchar Identificador do leilão Fk lei_ofertante integer Usuário ofertante do leilão lei_status integer Status do leilão
0 = Ativo 999 = Concluído
FK lei_tipo integer Tipo do leilão lei_dtinicio varchar Data de início do leilão
Entidade GMSH_DETLANCE
A entidade GMSH_DETLANCE armazena as informações dos itens de cada lance. Pode
visualizar a estrutura dessa entidade na Tabela 39.
87
Tabela 40. Dicionário de dados da entidade GMSH_DETLANCE
Chave Entidade Tipo Descrição dtl_ativo varchar Atividade do lance
‘S’ = ativado ‘N’ = desativado
PK dtl_id integer Código do detalhamento do lance FK dtl_lance integer Código do lance referenciado FK dtl_oferta integer Código da oferta do leilão FK dtl_leilao integer Código do leilão dtl_ordem integer Ordem de prioridade do item dtl_qtd integer Quantidade almejada para o lance dtl_vlrunit real Valor unitário máximo disposto a se pagar
3.1.6.2 Diagrama ER do Módulo de Busca de Preços
Na Figura 30, pode-se observar o diagrama ER que demonstra o que o repositório de dados
do módulo de busca de preços de produtos terá como entidades e associações, ou seja, a estrutura da
base de dados.
88
Figura 30. Diagrama ER do módulo de busca de produtos
Entidade GMSH_SITE
A entidade GMSH_SITE armazena as informações sobre os sites que deverão ser varridos
na busca de produtos. Pode visualizar a estrutura dessa entidade na Tabela 41.
Tabela 41. Dicionário de dados da entidade GMSH_SITE
Chave Entidade Tipo Descrição PK ste_id integer Código do site ste_url varchar URL principal do site
89
Entidade GMSH_PRODRECUP
A entidade GMSH_PRODRECUP armazena os dados dos produtos recuperados através dos
agentes do módulo. Pode-se visualizar a estrutura dessa entidade na Tabela 42.
Tabela 42. Dicionário de dados da entidade GMSH_PRODRECUP
Chave Entidade Tipo Descrição PK prc_id integer Código do produto recuperado prc_caracteristicas varchar Características do produto recuperado prc_descricao varchar Descrição do produto recuperado prc_preco real Preço do produto FK prc_site integer Código do site onde o produto foi encontrado prc_url varchar URL na qual o produto foi recuperado
Entidade GMSH_LINK
A entidade GMSH_LINK armazena as informações sobre os links que estão sendo visitados
na busca de produtos. A estrutura da entidade pode ser observada na Tabela 43.
Tabela 43. Dicionário de dados da entidade GMSH_LINK
Chave Entidade Tipo Descrição FK lnk_site integer Código do site lnk_url varchar URL do link lnk_visitado varchar Descreve se a URL já foi processada pelos
agentes ‘S’ = processada ‘N’ = não foi processada
Entidade GMSH_PAGINA
A entidade GMSH_PAGINA armazena as páginas Web recuperadas pelos agentes e as
informações das mesmas. A estrutura da entidade pode ser visualizada na Tabela 44.
90
Tabela 44. Dicionário de dados da entidade GMSH_PAGINA
Chave Entidade Tipo Descrição FK pag_site integer Código do site pag_url varchar URL da página Web pag_conteudo text Código HTML da página
Entidade GMSH_CRITERIO
A entidade GMSH_CRITERIO armazena o domínio ou endereço que a busca deve ocorrer.
A estrutura da entidade pode ser vista na Tabela 45.
Tabela 45. Dicionário de dados da entidade GMSH_CRITERIO
Chave Entidade Tipo Descrição FK crt_site integer Código do site crt_criterio varchar Critério de finalização da busca. Domínio ou
endereço.
Entidade GMSH_TEMPLATE
A entidade GMSH_TEMPLATE armazena o padrão que deve ser utilizado para identificar
produtos em um determinado site. A estrutura da entidade pode ser observada na Tabela 46.
Tabela 46. Dicionário de dados da entidade GMSH_TEMPLATE
Chave Entidade Tipo Descrição FK tmp_site integer Código do site tmp_template varchar Padrão para a busca de informações de
produtos.
3.1.7 Árvores de Decisão
Os agentes Ofertantes e Arrematantes utilizam conhecimento por meio de um Sistema
Especialista para resolverem suas tarefas. Para modelar este conhecimento, utilizou-se árvores de
decisão. Essas estruturas de dados são utilizadas para representar o conhecimento de uma aplicação
91
específica através de um conjunto de regras. As árvores de decisão são constituídas por
(REZENDE, 2003):
• Nó da folha: que corresponde a atributos que descrevem o fenômeno de interesse;
• Nó de decisão: contém um teste sobre um determinado atributo; e
• Ligação entre nós: contêm uma alternativa ao teste, evidenciado pelo nó de decisão, que
leva a um determinado caminho da árvore.
A seguir encontram-se as duas árvores de decisão que representam o conhecimento do
especialista no qual os agentes foram baseados.
3.1.7.1 Árvore de Decisão do Arrematante
O agente Arrematante é responsável pela submissão de lances pré-configurados por um
usuário em um leilão. Na Figura 31, pode-se observar a árvore de decisão desse agente.
Inicialmente se o lance máximo aceito pelo agente (Lance Máximo) for menor do que o lance que
está vencendo o leilão até o momento (Lance Atual Leilão) o Arrematante sai do leilão, pois o
mesmo não pode continuar em um leilão onde o preço máximo que se está disposto a pagar foi
ultrapassado. Caso contrário deve-se estipular o valor do lance a ser dado no leilão. Este valor será
estabelecido de acordo com o valor do lance que está vencendo o leilão. São quatro tipos de
incremento pré-configurados previamente pelo usuário. Depois de estabelecido o tipo de
incremento, formula-se o valor do lance a ser dado, baseado no valor que está vencendo o leilão
acrescido do incremento do tipo. Se o valor do lance for menor ou igual ao valor máximo de lance
configurado para o Arrematante, submete-se o valor do lance calculado, senão envia-se o valor
máximo de lance permitido pelo agente.
92
Figura 31. Árvore de decisão do agente Arrematante
3.1.7.2 Árvore de Decisão do Ofertante
O agente Ofertante é responsável por criar e gerenciar determinado leilão configurado
previamente pelo usuário. Na Figura 32, é demonstrada a árvore de decisão do agente. Ao receber
os lances, o agente Ofertante verifica se o lance é válido ao leilão. Se o lance recebido (Lance) for
menor ou igual ao lance que está vencendo o leilão (Lance Atual), o agente deve descartar o lance.
Logo após a aprovação inicial do lance, verifica-se se o lance foi submetido por um usuário
diferente do que criou o leilão. Caso o usuário Ofertante seja o mesmo que o Arrematante, o lance é
descartado, senão o lance é aceito. Essa restrição existe devido a uma regra de negócio (RN01) do
sistema que impede lances de reserva (lances efetuados pelo próprio Ofertantes).
93
Figura 32. Árvore de decisão do agente Ofertante
3.2 IMPLEMENTAÇÃO
Após a modelagem da ferramenta, as implementações foram realizadas com o intuito de
construir o modelo proposto, como sistema funcional. Nessa sessão são abordadas informações
sobre a implementação da ferramenta Gilgamesh. Os tópicos abordados são: tecnologias abordadas
na conexão entre aplicações, na construção da base de dados, na construção da ferramenta, agentes
e sistema especialista, além da descrição da implementação da interface.
3.2.1 Utilização do RMI
Remote Method Invocation (RMI) é uma tecnologia que têm como princípio prover a
computação distribuída utilizando a Orientação a Objetos. O RMI possui como base uma outra
tecnologia, chamada de Remote Procedure Calls (RPC), que permite programas com estrutura
procedural fazerem chamadas a funções em programas residentes em outras máquinas. Uma das
principais desvantagens do RPC (e um dos grandes motivos para a criação do RMI) é que a
tecnologia só permite um conjunto limitado de tipos de dados, o que não permite a manipulação de
objetos criados em Java (DEITEL, DEITEL e SANTRY, 2001).
RMI é a implementação do RPC em Java, mas suportando a manipulação de objetos
distribuídos (implementados na linguagem Java). Uma vez que a sessão do Servidor RMI esteja
iniciada, uma aplicação Cliente pode obter objetos remotamente.
94
Devido ao suporte oferecido a tecnologia de objetos distribuídos em Java e implementar
toda a complexidade da comunicação remota, o RMI foi utilizado no sistema Gilgamesh. A
utilização do RMI foi distribuída da seguinte forma (Figura 33):
• Aplicação Servidor: implementa a sessão Servidor RMI que espera uma conexão da
Aplicação Cliente. A Aplicação Servidor implementa um Cliente RMI que obtêm a
execução das regras através da Aplicação de Sistema Especialista;
• Aplicação Cliente: implementa a sessão Cliente RMI que se conecta a Aplicação
Sevidor, a fim de enviar e receber informações necessárias a manipulação do usuário no
sistema; e
• Aplicação de Sistema Especialista: sendo responsável por manter e executar as regras do
Sistema Especialista implementado para o sistema Gilgamesh, a Aplicação de Sistema
Especialista implementa a sessão Servidor RMI a fim de estabelecer um canal de
comunicação entre os agentes, presentes na Aplicação Servidor, e seus conhecimentos,
presentes no Sistema Especialista.
Figura 33. Uso do RMI e distribuição das aplicações
Com a utilização do RMI, pôde-se distribuir ainda mais os componentes do sistema
Gilgamesh, de maneira segura, e de fácil manutenção, já que o gerenciamento das conexões são
todos realizados pela mesma tecnologia.
95
3.2.2 Base de Dados
Para armazenar os dados provenientes das ações do sistema e de seus usuários, o Gilgamesh
necessitou de um repositório não volátil de informações: uma base de dados. Para isso, se utilizou
um sistema gerenciador de banco de dados (SGBD) pois o mesmo permite suporte, gerenciamento
das informações armazenadas, alterações mais simplificadas, além de um controle relacional das
tabelas do banco de dados.
Como sistema gerenciador de banco de dados, utilizou-se o PostgreSQL. As motivações
para a utilização do mesmo podem ser ressaltadas devido sua licença de software livre, a
possibilidade da utilização de recursos mais arrojados no código SQL (Structured Query Language),
como por exemplo o recurso de subqueries (consultas aninhadas dentro de outra consulta SQL).
3.2.3 IDE NetBeans
NetBeans é uma IDE (Integrated Development Environment) robusta, de código aberto e
livre de licenças, para a linguagem de programação Java, que provê o necessário para o
desenvolvimento de sistemas Cliente/Servidor, Web e aplicações móveis (NETBEANS, 2006).
O NetBeans foi utilizado para o desenvolvimento do sistema Gilgamesh, devido as suas
características de software livre de licença e a facilidade de desenvolvimento de interfaces através
de um sistema de desenho de telas. Com a IDE, foi possível testar todo o sistema Gilgamesh e seus
componentes complexos. A depuração de código funcionou corretamente durante todo o processo
de desenvolvimento, possibilitando o isolamento de erros.
A IDE possibilitou maior rapidez e fácil integração com as diferentes tecnologias utilizadas
no desenvolvimento do sistema.
3.2.4 Implementação dos Agentes
Com o intuito de não demandar muito tempo no desenvolvimento de agentes, pesquisou-se
frameworks para o desenvolvimento de agentes. Dentre os pesquisados, o JADE foi o que
apresentou características mais semelhantes às necessidades do projeto (descritas no tópico 2.4.1.6,
desse documento). Os fatores que mais influenciaram a escolha foram: (i) não onerar o projeto com
custos (licença livre de valores), (ii) seguir os padrões estabelecidos pela FIPA, entidade que
96
normatiza o uso em geral de agentes e (iii) o framework é para a linguagem Java, a qual o
Gilgamesh foi implementado.
As trocas de mensagens ocorrem entre os agentes do módulo de leilões, devido a
necessidade de comunicação contínua entre os mesmos. A Tabela 47 demonstra quais as mensagens
que são enviadas no módulo. A coluna “Tipo de Mensagem” especifica qual a mensagem que está
sendo enviada, a coluna “Descrição da Mensagem” descreve a mensagem quanto a sua função, a
coluna Agente Remetente e Destino, informam, respectivamente, o agente que envia e o que recebe
a mensagem.
Tabela 47. Trocas de mensagens entre agentes do módulo de leilões
Tipo de Mensagem
Descrição da Mensagem Agente Remetente
Agente Destino
Entrada de Arrematante
Identifica a entrada de um Agente Arrematante em um lelião
Agente Arrematante
Agente Ofertante
Requisição de Lance
O Agente Ofertante solicita os lances aos Agentes Arrematantes
Agente Ofertante
Agente Arrematante
Submissão de Lance
O Agente Arrematante submete seu lance ao responsável pela oferta do leilão (Agente Ofertante)
Agente Arrematante
Agente Ofertante
Finalização dos Lances do Arrematante
O Agente Arrematante informa sua saído do leilão ao Agente Ofertante
Agente Arrematante
Agente Ofertante
Finalização do Leilão
O Agente Ofertante comunica o fim do leilão aos Agentes Arrematantes
Agente Ofertante
Agente Arrematante
Os agentes presentes no módulo de busca de preços de produtos trabalham de maneira
cooperativa, no entanto, no momento da criação dos mesmos as tarefas são divididas , com o intuito
de alcançar um objetivo, fragmentando o problema para ser resolvido particionadamente.
3.2.5 Implementação do Sistema Especialista
Linguagens de computador são desenvolvidas com o intuito de atender a manipulação de
dados procedurais. Pessoas, entretanto, resolvem problemas usando o raciocínio abstrato, o que se
torna complexo de representar em uma linguagem convencional de computador. Para otimizar a
representação de um raciocínio, utilizam-se sistemas baseados em regras, que é uma das técnicas
mais indicadas para a criação de Sistemas Especialistas (RILEY, 2004).
97
Com o intuito de melhorar e facilitar o desenvolvimento de Sistemas Especialistas existentes
em 1984 na NASA (National Aeronautics and Space Admistration), o Departamento de Inteligência
Artificial criou o CLIPS (C Language Integrated Production System) (RILEY, 2004). Uma
desvantagem do CLIPS é que o mesmo foi adaptado a poucas linguagens, tendo como referência
principal, entre elas, a linguagem C e FORTRAN.
Uma das alternativas de APIs que utilizam CLIPS para desenvolvimento na linguagem Java
é o JClips (CLIPS para Java). A API permite o controle do mecanismo CLIPS e a recepção de
informações através de mensagens que as regras retornam. Uma outra vantagem do JClips é que sua
licença de uso é livre (MENKEN, 2005).
Como o sistema Gilgamesh possui fins científicos e não pretende utilizar-se de ferramentas
ou linguagens que onerem o desenvolvimento com alguma taxa de uso, o JClips se tornou a
alternativa mais viável.
O JClips é utilizado como mecanismo que executa as regras que contêm a inteligência dos
agentes ofertantes e arrematantes no módulo de leilões. Entretanto, essa API possui a desvantagem
de apenas permitir uma instância funcionando na mesma máquina (MENKEN, 2005). Também foi
observado durante o desenvolvimento do sistema Gilgamesh, que as execuções das regras no
sistema não podem ser realizadas mais de uma vez simultaneamente, com a mesma instância.
3.2.5.1 Contornando Dificuldades: JClips
Com o intuito de possibilitar a utilização do JClips no sistema, foi realizada uma abordagem
de isolamento do Sistema Especialista do resto da aplicação:
1. Primeiramente, uma nova aplicação foi desenvolvida a fim de executar as regras do
Sistema Especialista. Esta aplicação possui apenas uma instância da API do JClips;
2. Na seqüência, foi incorporado no projeto do SE a tecnologia RMI, com a finalidade de
fornecer à Aplicação Servidor do Gilgamesh um canal de comunicação com a Aplicação
Sistema Especialista; e
3. Depois, uma conexão Cliente RMI foi configurada na Aplicação Servidor, com o intuito
de estabelecer uma conexão com a Aplicação de Sistema Especialista.
98
Por meio dessas implementações e alterações, foi possível estabelecer a conexão do sistema
com o Sistema Especialista. Para resolver o problema de execução em paralelo no JClips,
serializou-se as requisições de execução das regras, realizadas a partir dos agentes da Aplicação
Servidor. Para atingir esse objetivo, os seguintes procedimentos foram realizados:
• As requisições de execução de regras são enviadas dos agentes a um único agente,
Agente Interface Sistema Especialista, que gerencia essas requisições e as submete a
Aplicação de Sistema Especialista;
• No Agente Interface Sistema Especialista, as requisições são executadas uma a uma, a
fim de tornar o processo seqüencial, ou seja, uma requisição é enviada a Aplicação
Sistema Especialista somente depois de sua anterior ter sido executada pelo JClips (na
Aplicação SE).
Com o sistema alterado, o JClips funcionou corretamente. Na Figura 34, pode-se observar
como ficou o lado Servidor do sistema Gilgamesh. O processo de Aplicação do Servidor (principal
do Gilgamesh) e o processo de Aplicação de Sistema Especialista recebe as requisições dos agentes
de maneira seqüencial.
Figura 34. Resolução dos problemas do JClips
A Figura 35 demonstra como funciona a requisição ao Sistema Especialista. Os agentes
arrematantes ou ofertantes fazem requisições de execuções de regras a Aplicação Servidor. Depois,
a Aplicação Servidor insere a requisição em uma lista. Na seqüência, a requisição que está a mais
tempo na lista é enviada para a Aplicação Sistema Especialista (possui instância do JClips), onde é
executada. Os resultados são enviados a Aplicação Servidor e armazenados em um repositório, de
99
onde o agente interessado pode retirar os resultados da execução. Nesse processo é executada uma
requisição por vez.
Figura 35. Funcionamento da solução aos problemas com JClips
3.2.6 Implementação dos Web crawlers
Para implementação dos Web crawlers, utilizou-se a tecnologia de agentes do framework
JADE. A função desses agentes no sistema Gilgamesh é, em síntese, acessar páginas na Web,
gravar as mesmas no banco de dados, e finalmente, localizar todos os links das páginas acessadas
para que outros Web crawlers continuem a busca em outros endereços.
A tarefa mais complexa dos Web crawlers é localizar referências a URLs no corpo de uma
página Web. Com o intuito de facilitar e otimizar as buscas pelos links, utilizou-se o NekoHTML.
De acordo com Clark (2006), o NekoHTML é um simples rastreador de código HTML
(HyperText Markup Language) que utiliza balanceamento de tags em um esquema de referências,
disposto em árvore, que permite aos programadores analisarem gramaticalmente documentos
HTML usando padrões XML. O NekoHTML é compatível com Java 1.1, sendo utilizado como API
para o Java.
Para os Web crawlers, o NekoHTML foi utilizado para buscar as URLs referenciadas pelos
links. Utilizando algoritmo de busca recursiva sobre a árvore gerada pelo NekoHTML, foi possível
recuperar os links presentes na página. Em seguida esses links foram gravados e o conteúdo da
página também.
3.2.7 Implementação dos Agentes de Busca de Preços
100
Os agentes de busca de preço possuem o objetivo de recuperar as páginas gravadas pelos
Web crawlers na base de dados e localizar os preços e o nome dos produtos, existentes nas ofertas
da página recuperada.
O processo de busca das informações de produtos utilizado foi dividido nos seguintes
passos:
1. Recuperação de página salva pelos Web crawlers: o processo de Web crawling grava o
conteúdo das páginas na qual visita, no banco de dados. Através desse conteúdo,
disposto em HTML, os Agentes de Busca de Produto podem abrir as informações para
análise sem precisar acessar a Web para isso;
2. Quebra de conteúdos da página: com o código HTML recuperado, o Agente de Busca de
Produtos quebra o conteúdo da página, separando cada texto encontrado nas tags HTML
em uma lista. Esse processo é utilizado com o intuito de ignorar as tags HTML e
recuperar apenas o conteúdo texto da página. Para o procedimento foi utilizado o
NekoHTML, que separou as tags enquanto um algoritmo inseria os conteúdos do mesmo
em uma lista. Na Figura 36, pode ser visualizado o resultado do processo. Do lado
esquerdo o código HTML e do lado direito os conteúdos depois do procedimento;
101
... <table> <tr> <td><font size=4> <b>Java: como programar</b> </font> </td> <td> De: R$ 152,00 </td> <td> Por: R$ 122,00 </td> <td> <a href=’actioncompra.aspx?prod=156’>Comprar</a> </td> <tr> </table> ...
Código HTML
... 1. “Java: como programar” 2. “De: R$ 152,00” 3. “Por: R$ 122,00” 4. “Comprar” ...
Código “quebrado” (Lista)
Figura 36. Código quebrado em busca de conteúdos
3. Filtragem dos conteúdos da lista: após o procedimento de extração de conteúdos da tags,
o Agente de Busca de Produtos retira conteúdos desnecessários da lista gerada no
processo anterior (Lista de Conteúdos). Isso é realizado com o intuito de facilitar a busca
por produtos, retirando assim itens que poderiam atrapalhar;
4. Busca por preços: como uma das principais funcionalidades do Agente de Busca de
Produtos, a busca de preços procura informações que contenham valores dos produtos na
Lista de Conteúdos. Para isso, parte-se da procura pelo caractere chave “$”. Depois, o
algoritmo busca valores possíveis para serem computados como preços. Se dois valores
forem encontrados em seqüência e são tomados como se pertencessem a mesma oferta,
pega-se o menor, pois os mesmos podem ser um demonstrativo de um preço anterior em
comparação com o atual. Esse processo pode ser visualizado na Figura 37;
102
... 955. “WEREWOLF STORYTELLER SCREEN” 956. “R$” 957. “53” 958. “, “ 959. “93” 960. “R$” 961. “38” 962. “,” 963. “52” ...
Lista de Conteúdos
Caractere chave encontrado (“$”)
Valores dos preços
O menor dos preços é coletado
como preço do produto. (R$ 38,52)
Figura 37. Busca por preço de produto
5. Busca por nome de produto: a busca por nome de produto ocorre depois de localizado o
preço. A partir do primeiro preço encontrado, busca-se um nome válido em direção ao
topo da Lista de Conteúdos. O procedimento foi representado na Figura 38; e
... 955. “WEREWOLF STORYTELLER SCREEN” 956. “R$” 957. “53” ...
Lista de Conteúdos
Busca realizada a partir do primeiro caractere chave, em direção ao
topo da Lista de Conteúdos
Nome de produto válido encontrado
(WEREWOLF STORYTELLER
SCREEN)
Figura 38. Busca por nome de produto
6. Inclusão do produto: com as informações de preço e nome do produto, o mesmo pode
ser incluído na base de dados.
103
O processo de busca por produtos se repete diversas vezes, até que todas as posições com o
caractere chave (“$”) sejam examinadas. Quando a Lista de Conteúdos for completamente varrida,
o agente acaba sua execução.
3.3 TESTES
Tendo em mente que a ferramenta deve funcionar para que o usuário possa tirar o maior
proveito possível de suas funcionalidades, foram realizados testes com o sistema Gilgamesh. A fim
de validar a ferramenta quanto a sua funcionalidade, foram executados dois testes: um baseado no
Guia de Avaliação da Qualidade de Produto de Software (aconselhado pelo governo federal) e outro
baseando nas funcionalidades do sistema.
3.3.1 Guia de Avaliação da Qualidade de Produto de Software
O Guia de Avaliação da Qualidade de Produto de Software foi desenvolvido pelo Centro de
Pesquisas Renato Archer (CenPRA) com o intuito de apoiar a avaliação da qualidade de software,
tendo em vista as perspectivas do usuário final. O guia é composto por uma série de questões que
podem ser integradas em um questionário com o objetivo de avaliar o software (CENTRO DE
PESQUISAS RENATO ARCHER, 2005).
A partir do guia proposto pelo CenPRA, adaptou-se um questionário a fim de avaliar o
sistema Gilgamesh quanto às perspectivas do Usuário. O questionário foi respondido avaliando
questões do software, por seus idealizadores (orientando desse trabalho). Todas as questões foram
respondidas de acordo com o que foi visualizado no software.
As questões foram divididas em alguns quesitos, onde depois da realização dos testes, pode-
se concluir que:
• Quesito Documentação: foi avaliada neste quesito, a qualidade das informações
levantadas no projeto e nesse trabalho de conclusão. O que pôde ser levantado de acordo
com as respostas é que, para que seja entregue ao usuário final, seria interessante
elaborar um manual detalhando todos os requisitos do projeto e como se deve instalar a
ferramenta. Outros resultados, mais positivos, são que a documentação está bem dividida
em tópicos, e a ferramenta está bem detalhada de modo que os exemplos oferecidos,
auxiliam o usuário no primeiro contato com a ferramenta;
104
• Quesito Interface: neste quesito foi possível avaliar a interface do Gilgamesh. Como
deficiências apontadas, se destacam a falta de alertas ou diálogos que ensinem o usuário
a usar a ferramenta, enquanto a mesma estiver sendo executada pelas primeiras vezes.
Quanto aos resultados positivos podem se destacar a distribuição de menus e opções em
níveis hierárquicos, a previsibilidade da interface, dando a noção adequada do que o
usuário deve fazer e em qual seqüência, sem a necessidade de um tutorial; e
• Quesito Funcionalidade: foi avaliado neste quesito o fluxo de funcionalidade do sistema.
A única observação negativa encontrada na ferramenta é a ausência de um usuário
administrador. Em compensação as funcionalidades da ferramenta não apresentaram
erros. Além disso, outro parecer positivo constatado nos testes foi que os usuários só
podem ter acessos privilegiados aos leilões que criam e aos lances que configuram.
Com os testes realizados através do questionário, pôde-se verificar que a ferramenta
Gilgamesh, apesar de detectados alguns problemas, possui funcionalidade, interface e
documentação que realmente condizem com o proposto. Dessa forma, a ferramenta se coloca em
uma versão próxima da que deve ser disponibilizada aos usuários. O questionário e as respostas
podem ser visualizados no capítulo de Apêndice deste documento.
3.3.2 Teste Baseado nas Funcionalidades do Sistema
Para a validação do sistema Gilgamesh, foram realizados ensaios de execução sobre
funcionalidades do sistema implementado. Os testes foram realizados pelo autor do projeto,
focando-se nas principais funções e opções da ferramenta. Na Tabela 48 pode-se visualizar os
resultados destes testes.
105
Tabela 48. Testes sobre as funcionalidades do Gilgamesh
Função Descrição da Função Resultados Entrada de novos leilões no sistema
Quando um Agente Ofertante entra no sistema e abre um leilão
Os Agentes entraram no leilão imediatamente após sua criação. Procedimento correto.
Entrada de novos arrematantes no sistema
Quando Agentes Arrematantes entram no sistema
Os Agentes Arrematantes entraram no sistema imadiatamente após a configuração dos lances pelo usuário. Procedimento correto.
Submissão de lances
Quando os Agentes Arrematantes submetem lances
Os Agentes Arrematantes submeteram seus lances corretamente de acordo com as regras de leilão. Procedimento correto.
Solicitação de Lances
Quando o Agente Ofertante solicita lances a seus arrematantes
As solicitações ocorreram perfeitamente. O Arrematante que está vencendo não recebe a solicitação, devido as regras do leilão. Procedimento correto.
Seleção de melhor lance por turno
Seleção do melhor entre os lances recebidos pelo Agente Ofertante
Os lances foram selecionados de maneira correta. Procedimento correto.
Finalização de leilão
Finalização de um leilão Os Agentes Ofertantes encerraram os leilões no momento certo. A finalização e a declaração dos vencedores foi feita de maneira correta.
Busca por páginas
Quando um Agente Web Crawler consulta a Internet com o intuito de recuperar uma página Web.
Os Agentes Web Crawlers buscaram as páginas. Links indisponíveis não causaram falhas na aplicação. Acarretou sobrecarga do sistema computacional na busca.
Recuperação das URLs nos conteúdos
A varredura de um Agente Web Crawler em busca de links nas páginas recuperadas
Os endereços dos links foram recuperados nas páginas. Alguns endereços recuperados não são válidos, mas são descartados no processo de busca por produto.
Busca por produtos
Busca por produto a partir de páginas recuperada pelos Agentes Web Crawlers. Função efetuada por Agentes de Busca de Produtos
A busca teve bons resultados e realmente conseguiu recuperar a maioria dos produtos e seus preços nos sites testados (Submarino, Americanas.com e Moonshadows Livraria). Acarretou sobrecarga do sistema computacional na busca.
Com base nos resultados obtidos nos testes sobre as funcionalidades do sistema pode-se
dizer que o sistema funcionou sem apresentar problemas que comprometam a utilização da
ferramenta. Em termos de funções, o Gilgamesh realiza todas a fim de cumprir seus objetivos.
Deve-se cuidar mais atentamente da sobrecarga computacional que os Agentes de Busca de Produto
e os Web Crawlers acarretaram.
106
3.4 A FERRAMENTA
A fim de demonstrar o funcionamento da ferramenta Gilgamesh, esta sessão explana
informações sobre o funcionamento, bem como detalhes das regras de negócio do sistema. A
demonstração é dividida em três partes: funções gerais da ferramenta, módulo de leilões e módulo
de busca de preços de produtos.
3.4.1 Funções Gerais da Ferramenta
Para o uso mais simples da ferramenta é necessário conhecer alguns procedimentos básicos
que são fundamentais, tais como: o cadastro de usuário, a autenticação no sistema e interface
principal do sistema.
3.4.1.1 Cadastro de Usuário
No cadastro de usuário, uma pessoa pode solicitar, através de preenchimento de um
formulário, que sua participação no sistema seja assegurada. Figura 39 pode-se visualizar a
interface onde o cadastro é realizado.
107
Figura 39. Cadastro de usuário
Os dados que devem ser preenchidos são descritos abaixo:
• Nome Completo: nome completo do usuário que está solicitando o cadastro;
• Data de Nascimento: data de nascimento do usuário;
• CPF: cadastro de pessoa física, com intuito de fornecer identificação única a cada
usuário;
• Endereço: logradouro do usuário;
• Nº: número da residência ou prédio no qual o usuário vive;
• Complemento: campo que identifica complemento do endereço do usuário;
• Bairro: bairro ou distrito do usuário;
• Cidade: cidade do usuário;
108
• Estado: unidade federativa onde a residência do usuário está localizada;
• País: país no qual o usuário reside;
• E-Mail: endereço para correspondência eletrônica;
• Nome de Usuário: nome da conta de usuário;
• Senha: senha que será requerida para a autenticação do usuário; e
• Repita a Senha: campo para validar se a senha digitada é realmente a que o usuário
deseja.
Através do correto preenchimento e da confirmação de cadastro do usuário, será possível
usar as funcionalidades presentes na ferramenta Gilgamesh.
3.4.1.2 Autenticação no Sistema
Para que o usuário seja validado e possa realizar operações na ferramenta Gilgamesh, é
necessário que o usuário tenha realizado seu cadastro, informando todos os dados necessários (visto
no item anterior). A Figura 40 demonstra a interface de cadastro de usuário. Caso o usuário não
possua conta de usuário, ele deve se cadastrar primeiramente em “Desejo-me cadastrar no
Gilgamesh”. Se o usuário já possui uma conta, basta apenas inserir seu “Nome de Usuário” e
“Senha” que a autenticação ocorrerá.
Figura 40. Autenticação no sistema
109
Depois de se autenticar no sistema, o usuário poderá utilizar as funcionalidades presentes na
ferramenta Gilgamesh. Essa autenticação permite que haja maior segurança, pois é possível a
completa identificação dos usuários que utilizam à ferramenta.
3.4.1.3 Interface Principal do Sistema
O sistema Gilgamesh possui uma interface principal na qual são desencadeados todos os
comandos do usuário sobre a ferramenta. A Figura 41 demonstra como tal interface pode ser
visualizada.
Figura 41. Interface principal do sistema
Na interface podem ser visualizados os menus principais, localizados na parte superior da
imagem (Gilgamesh, Leilões, ...). Nesses menus podem ser localizadas as principais funções do
sistema, tais como criar leilões e lances.
Além das principais funcionalidades, a ferramenta dispõe de uma listagem, em árvore,
contendo as ações do usuário, afim de que o mesmo possa: monitorar o andamento dos leilões e
lances estabelecidos, e efetuar buscas a preços de produtos localizados na Web. Quando o usuário
110
clica sobre uma das folhas da árvore de listagem, imediatamente à sua direita (na tela de Palco)
serão visualizadas informações sobre estado atual do item selecionado.
Essa interface foi desenvolvida com o intuito de fornecer maior comodidade ao usuário no
acompanhamento de seus leilões e lances automatizados, bem como um acesso rápido ao módulo de
busca de produtos na Web.
3.4.2 Módulo de Leilões
No módulo de leilões, a ferramenta Gilgamesh tem o objetivo principal de automatizar o
processo de arremate nos lances. Isso significa que os leilões e lances da ferramenta funcionam
automaticamente, bastando apenas que o usuário estabeleça uma pré-configuração. Para explicar
como ocorre essa pré-configuração, dividiu-se o módulo de leilões em: pré-configuração de leilões
e pré-configuração de lances.
3.4.2.1 Pré-configuração de Leilões
Os leilões no Gilgamesh ocorrem de maneira autônoma. O usuário que cria um leilão não
precisa se preocupar com a monitoração contínua. Isso é possível graças a pré-configuração dos
leilões, chamada na ferramenta de cadastro de leilões. A interface na qual o usuário executa essa
tarefa pode ser visualizada na Figura 42.
111
Figura 42. Interface do cadastro de leilões
Para cadastrar um leilão, é necessário preencher informações de identificação e descrição do
mesmo:
• Título do Leilão: título com o qual o leilão será apresentando;
• Descrição do Leilão: descrição detalhada do leilão;
• Tipo de Leilão: tipo de modelo a ser utilizado no leilão. A único tipo implementado para
essa versão do Gilgamesh é o leilão direto;
112
• Duração Máxima: número de horas que o leilão irá durar ao máximo; e
• Data de Início: data na qual o leilão estará aberto.
Depois de estabelecidas as configurações iniciais do leilão, deve-se estabelecer as ofertas do
leilão. Primeiramente, o usuário deve selecionar o produto que fará parte da oferta. Para fazer isso,
o mesmo deve clicar sobre o botão “Carregar Produto”. Na Figura 43 pode-se visualizar a interface
de seleção de produto. Nesta interface, o usuário deve selecionar um produto clicando sobre o
mesmo e depois clicando no botão selecionar.
Figura 43. Interface do seleção de produtos
Após a seleção do produto, o usuário deverá inserir as informações adicionais a oferta:
• Descrição da Oferta: texto descritivo sobre a oferta;
• Quantidade: quantidade, em unidades, disponível para a oferta; e
113
• Valor Inicial por Unidade: menor valor aceito para lances feito sobre as ofertas (valor
unitário, sobre cada peça).
Inserindo todas as informações sobre as ofertas, os usuários poderão inserir a mesma
clicando sobre o botão “Adicionar Oferta”. Caso se deseje descartar a oferta, deve-se clicar sobre o
botão “Descartar Oferta”. O usuário poderá repetir o processo de inclusão de ofertas quantas vezes
desejar. A única restrição nesse caso é que não pode haver duas ofertas com o mesmo produto.
Caso o usuário deseje alterar ou excluir uma oferta, o mesmo deve clicar sobre a oferta
desejada, localizada na grid de ofertas e selecionar a opção desejada nos botões “Editar” ou
“Excluir”.
Para gravar a configuração do leilão, deve-se clicar em “Salvar Leilão”. Caso o usuário
deseje descartar o leilão, deverá clicar em “Descartar Leilão”. Uma informação importante é que
depois de salvo, um leilão não pode ser alterado, apenas interrompido.
3.4.2.2 Pré-configuração de Lances
Os lances na ferramenta Gilgamesh foram criados para funcionarem de maneira autônoma,
ou seja, sem a necessidade do acompanhamento por seu usuário. Para que isso seja possível, basta
que o usuário que deseja criar um lance faça uma pré-configuração, chamada no sistema de cadastro
de lances. A Figura 44 demonstra como é visualmente a primeira parte da interface de cadastros de
lances.
114
Figura 44. Cadastro de lances
Para iniciar o cadastro do lance, é necessário escolher o tipo de lance que se deseja fazer:
• Lance automático (por agente): tipo no qual um agente envia um ou mais lances
automaticamente para os leilões, baseado em seu cadastro; e
• Lance único: tipo no qual o usuário estabelece um lance fixo a todos os leilões
selecionados.
Depois de escolher qual tipo de lance será realizado, o usuário deverá selecionar um produto
no qual o lance deverá ser submetido. Para isso, deve-se clicar sobre o botão “Carregar Produto” e
escolher um produto na lista e clicar sobre “Selecionar” (o mesmo procedimento de carregar o
produto no cadastro de leilão). Fazendo isso, a ferramenta demonstra todos os leilões disponíveis
para aquele produto, na listagem “Leilões”. Para visualizar maiores informações sobre um
determinado leilão, o usuário deve clicar sobre um dos itens da lista e visualizar as informações no
campo “Detalhes do Leilão”, logo à direita.
O usuário, em seguida, deve escolher os leilões que deseja na listagem e adicioná-los ao
lance, clicando no botão “Adicionar”. O mesmo leilão não pode ser escolhido duas vezes. Se o
usuário escolheu o tipo de lance automático (interface localizada na Figura 45), o usuário deverá
115
selecionar a prioridade na qual seus lances serão submetidos. Os leilões mais acima da lista de
“Leilões Selecionados” possuem maior prioridade. Essa funcionalidade foi desenvolvida, pois os
lances ocorrem somente em um leilão por vez. Para aumentar ou diminuir a prioridade de um leilão,
o usuário deve utilizar os botões “p/ cima” ou “p/ baixo”. Caso um leilão deva ser removido, o
usuário deve selecionar o leilão na listagem e clicar no botão “Remover”.
Figura 45. Tipo automático de lances
Depois de terminar a escolha das prioridades dos leilões, o usuário deverá informar o valor
máximo que está disposto a pagar por cada unidade da oferta em questão. Em seguida, o usuário
deve definir os quatro incrementos, ou seja, valores que serão somados aos lances que estão
vencendo o leilão. Cada incremento identifica o valor que será somado ao lance vencedor, caso o
este se enquadre à condição proposta abaixo de cada tipo. Há quatro tipos de incrementos que
podem ser configurados: para lances menores que cem reais, menores que mil reais, menores que
dez mil reais e maiores ou iguais a dez mil reais. Um exemplo do funcionamento desse mecanismo
pode ser demonstrado da seguinte maneira: supondo que os incrementos foram configurados em 2,
5, 50, 500 reais respectivamente e o lance que está vencendo o leilão é de 101 reais, o valor que será
submetido será o de 106 reais (101 + 5). A soma do valor cinco se deve ao lance estar enquadrado
no segundo tipo de incremento (“< $1000”).
Se o usuário escolher o tipo de lance único (interface visualizada na Figura 46), ele deve
inserir, para cada leilão, e sua respectiva linha na tabela de “Valores de Lance”, a quantidade
solicitada no lance (na coluna “Qtd. Lance”) e o valor unitário do lance (na coluna “Valor Unit.
Lance”).
116
Figura 46. Tipo de lances únicos
Depois de definidas as configurações do lance, o usuário pode clicar em “Salvar
Configurações do Lance” com o intuito de efetivar a configuração. Caso o usuário não deseje mais
os lances, o mesmo pode selecionar a opção “Descartar Configurações de Lance”. É importante
ressaltar que os lances não podem ser alterados, apenas paralisados.
3.4.3 Módulo de Busca de Preços de Produtos
O módulo de busca de preços de produtos tem o objetivo de fornecer ao usuário comodidade
na pesquisa por produtos, provenientes de uma base preenchida através dos agentes do Gilgamesh
que recuperam informações de produtos em lojas virtuais. Para que o usuário tenha acesso a esta
função, basta que o mesmo clique sobre a opção “Busca por preços de produtos na Web”, presente
no menu disposto em árvore, da interface principal. Logo depois, imediatamente ao lado do menu, a
interface de busca (Figura 47) por produtos estará disponível.
Figura 47. Interface de busca por preços de produtos
117
Para efetuar a busca por um produto, basta digitar a palavra chave e clicar no botão
“Buscar”. Em seguida, o Gilgamesh fará uma busca por produtos que possuam referências
semelhantes às palavras digitadas como “Palavra-chave”. Depois a ferramenta disponibiliza ao
usuário uma listagem de ocorrências de produtos, ordenadas pelo menor preço.
4 CONCLUSÃO
Desenvolver uma aplicação englobando mais de uma área de conhecimento é uma tarefa que
exigiu o entendimento dos conceitos relacionados. Para o projeto da ferramenta Gilgamesh foram
relacionadas as áreas de Inteligência Artificial e a de Comércio Eletrônico.
Levantando temas de domínio extra-curricular encontra-se a pesquisa por funcionamento de
leilões, que visou entender os conceitos mais relevantes ao projeto. Por meio das referências
analisadas, foi possível estabelecer padrões de comportamento de leilões, bem como efetuar uma
análise sobre ferramentas de sistemas de leilões, onde encontrou-se características que seriam
essenciais para o Gilgamesh.
Compondo outro módulo da ferramenta, a busca de preços foi estudada de acordo com as
literaturas levantadas, que propiciaram estratégias para abordagem na implementação da tecnologia.
Umas das maiores contribuições a essa parte do trabalho foram os artigos que continham
informações sobre a heurística dos mecanismos de Web crawling. Esses elementos somados ao
entendimento do funcionamento do site de busca Google foram determinantes no aspecto de tipo de
busca a ser utilizada. Na conclusão desses estudos, seguiu-se a pesquisa com a análise de
ferramentas que dispunham de busca de preços, que resultou em comparações entre tecnologias e
decisões sobre que características que o Gilgamesh compartilharia com sistemas que possuem busca
de preços de produtos.
Depois de analisar a literatura sobre conceitos que a ferramenta Gilgamesh agrega, foi
iniciada uma pesquisa sobre as tecnologias que seriam utilizadas para a idealização do projeto.
Inicialmente, pesquisou-se frameworks para implementação de agentes. Devido a documentação
facilitada, o não comprometimento com licenças pagas de software e a utilização do padrão
estabelecido pela FIPA, foi selecionado o framework Jade. Para os agentes principais do módulo de
leilões, concluiu-se que deveria ser utilizado como heurística, um sistema especialista, devido a
facilidade em se retratar o raciocínio de ofertantes e arrematantes através de regras. Depois,
verificou-se quais sistemas especialistas poderiam ser utilizados no Gilgamesh, e concluiu-se que a
melhor opção seria o JClips, pois utiliza a linguagem CLIPS para formação das regras e possui
licença livre para uso. O JClips apresenta problemas em ambientes que funcionam de maneira
concorrente. Para solucionar isso, serializou-se a comunicação do Gilgamesh com o sistema
especialista. A pesquisa foi finalizada com a decisão de qual banco de dados seria utilizado. A
119
opção mais interessante foi o PostgreSQL, pois além de ser um sistema gerenciador de banco de
dados, está livre de licenças pagas e permite o uso de mecanismos de programação mais arrojados,
como por exemplo, subqueries.
Por meio das tecnologias selecionadas, iniciou-se a modelagem, e em seguida, a
implementação do sistema Gilgamesh na linguagem Java, utilizando a IDE Netbeans. A modelagem
do sistema projetou todas as funções do Gilgamesh, atentando para os objetivos do projeto. Depois,
foi iniciado o processo de implementação que produziu inicialmente os cadastros, sem qualquer
complicação. Devido a tecnologia de desenho de formulários (janelas) do Netbeans, os processos de
criação das interfaces foi facilitado. Na seqüência, as implementações dos agentes de leilões foram
realizadas utilizando as tecnologias Jade e JClips, para criar agentes e a inteligência dos mesmos.
Complicações surgiram a partir uso JClips, já que este Sistema Especialista não funciona bem com
mecanismos que executam paralelamente. A solução foi separar o SE em uma outra aplicação e
serializar as solicitações de execução de regras através do uso de uma lista de solicitações.
Para o módulo de buscas de preços de produtos os agentes foram desenvolvidos utilizando o
framework Jade e o analisador gramatical NekoHTML com base nas técnicas pesquisadas para
estabelecer mecanismos de Web crawling e em heurísticas de busca de preços. Para facilitar o
processo de varredura por busca de informações em conteúdos HTML, foi utilizado o analisador
NekoHTML, que fragmentou as tags e possibilitou uma melhor abordagem para os algoritmos de
busca por URLs e por informações de produtos.
Os testes realizados com a ferramenta se basearam em questionário de avaliação de
software, desenvolvido pelo CenPRA, e análise das funções do Gilgamesh. Pôde-se constatar no
questionário que apesar de todo o esforço de documentação, seria necessário um manual mais
elaborado para que os usuários possam usar a ferramenta de forma mais simplificada. Outra
informação levantada a partir do questionário é a ausência de dicas na ferramenta quando há uma
execução de alguma função pelo usuário, a fim de conduzir o usuário nas suas tarefas. Com o teste
sobre as funcionalidades do Gilgamesh, foi possível verificar que os agentes do módulo de busca de
preços de produtos ocupam recursos computacionais demasiadamente, a ponto de prejudicar o
desempenho da máquina na qual executa.
Como futuros trabalhos com o projeto Gilgamesh, podem-se citar: (i) o incremento do
projeto com outros módulos de ferramentas de comércio eletrônico; (ii) inclusão de mais tipos de
leilões (adicionando comportamentos aos agentes); (iii) uma melhoria do algoritmo de
120
reconhecimento de informações de produtos; (iv) utilização de sistemas de recomendação na
ferramenta; (v) ampliação da estrutura de Web crawling.
Espera-se que o Gilgamesh possa participar ou contribuir de alguma forma, abrindo rotas
para que mais trabalhos acadêmicos possam aproveitar das vantagens fornecidas pelas tecnologias
de Inteligência Artificial em sinergia com as oportunidades encontradas no Comércio Eletrônico.
REFERÊNCIAS BIBLIOGRÁFICAS
BARONE, Dante Augusto Couto. Sociedades Artificiais: a nova fronteira da inteligência nas máquinas. Porto Alegre: Bookman, 2003. ISBN 85-363-0124-4
BELLIFEMINE, Fabio; CAIRE , Giovanni; RIMASSA , Giovanni; POGGI , Agostino; TRUCCO , Tiziana; CORTESE , Elisabetta; QUARTA Filippo; VITAGLIONE, Giosuè; LHUILLIER, Nicolas; PICAULT, Jérôme. Jade - Java Agent DEvelopment Framework. Disponível em: <http://jade.tilab.com/>. Acessado em: 15 maio 2006
BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistema com UML. Rio de Janeiro: Elsevier, 2002. ISBN: 85-352-1032-6
BONDFARO. O que é Bondfaro. Disponível em: <http://www.bondfaro.com.br/bondfaro/out/corporate_out.jsp?pg=100&sk=1>. Acesso em: 23 mar. 2006.
BRIN, S.; PAGE, L. The anatomy of a large-scale hypertextual web search engine. In: WORLD-WIDE WEB CONFERENCE, 7., 1998, Brisbane. Proceedings… New York: Elsevier, 1998. 26 p.
BUSCAPÉ. Sobre o BuscaPé.. Disponível em: <http://www.buscape.com.br/bp_inst_oque_e.asp >. Acesso em: 23 mar. 2006.
CASTILHO, Carlos; BAEZA-YATES, Ricardo. A new model for web crawling. In: INTERNATIONAL WORLD WIDE WEB CONFERENCE, 11., 2002, Honolulu. Procedings... [S.l.: s.n.], 2002. ISBN 1-880672-20-0
CASTRO, P. A. L. Uma Infra-estrutura para Agentes Arrematantes em Múltiplos Leilões Simultâneos. 2003. 114 f. Dissertação de Mestrado em Engenharia Elétrica – Escola Politécnica da Universidade de São Paulo, Universidade de São Paulo, São Paulo, 2003.
CLARK, Andy. CyberNeko HTML Parser 0.9.5. Disponível em: <http://people.apache.org/ ~andyc/neko/doc/html/>. Acesso em: 25 set. 2006.
CENTRO DE PESQUISAS RENATO ARCHER. Guia de Avaliação da Qualidade de Produto de Software. Divisão de Qualidade de Software. São Paulo: CenPRA, 2005.
CROVELLA, M.; LINDEMANN, C.; REISER, M. Internet performance modeling: the state of the art at the turn of the century. Performance Evaluation, New York, n. 42, p. 91-108, 2000. ISSN 0166-5316
DEITEL, Harvey; DEITEL, Paul; SANTRY, Sean. Advanced Java 2: how to program. 1.ed. New Jersey: Prentice Hall, 2001. ISBN 0130895601
FARACO, Rafael Ávila. Uma Arquitetura de Agentes para Negociação Dentro do Domínio do Comércio Eletrônico. 1998. 100 f. Dissertação de Mestrado em Engenharia de Produção – Programa de Pós-Graduação em Engenharia de Produção, Universidade Federal de Santa Catarina, Florianópolis, 1998.
122
FIPA-OS. FIPA-OS: Developers Guide. Brampton; Ontário; Canadá, 2001. Disponível em: <http://fipa-os.sourceforge.net/docs/Developers_Guide.pdf>. Acessado em: 20 abril 2006.
GUTTMAN, R. H.; MOUKAS, A. G.; MAES, P. Agent-mediated electronic commerce: a survey. Knowledge Engineering Review, New York, v. 13, n. 3, p. 1-10, 1998. ISSN 0269-8889
HÜBNER, Jomi Fred; SICHMAN, J. S. SACI: Uma ferramenta para implementação e monitoração da comunicação entre agentes. In: INTERNATIONAL JOINT CONFERENCE, 7TH IBERO-AMERICAN CONFERENCE ON AI, 15TH BRAZILIAN SYMPOSIUM ON AI (IBERAMIA/SBIA 2000), 7/15., 2000, Atibaia, São Paulo, Brasil. Proceedings... São Carlos: ICMC/USP, 2000. p. 47–56.
HÜBNER, Jomi Fred. Um Modelo de Reorganização de Sistemas Multiagentes. 2003. 246 f. Tese de Doutorado em Engenharia Elétrica – Escola Politécnica da Universidade de São Paulo, Universidade de São Paulo, São Paulo, 2003.
KLEMPERER, P. Auction theory: a guide to literature. Journal of Economics Surveys, [Malden], v. 13, n. 3, p. 227-286, 1999. ISSN 0950-0804
LABROU, Yannis; FININ, Tim; PENG, Yun. Agent Communication Languages: the current landscape. IEEE Intelligent Systems, Maryland, v. 14, n. 2, p.45-52, 1999. ISSN 0885-9000
LUGER, George F. Inteligência Artificial: estruturas e estratégias para a solução de problemas complexos. 4. ed. Porto Alegre: Bookman, 2004. ISBN 85-363-0396-4
MEIRELLES, Aluísio Telles de. História do Comércio Internacional. São Paulo: Século XXI, 1983.
MENKEN, Maarten. JClips: CLIPS for Java. [S.l.: s.n.], 2005. Disponível em <http://www.cs.vu. nl/~mrmenken/jclips/>. Acesso em: 6 set. 2006.
MERCADOLIVRE. O que é Mercadolivre. Disponível em: <http://www.mercadolivre.com.br/ brasil/ml/p_loadhtml?as_menu=MPRESS&as_html_code=SML_01>. Acesso em: 13 mar. 2006.
NASCIMENTO JR., Cairo L. Nascimento; YONEYAMA, Takashi. Inteligência Artificial: em controle e automação. 1. ed. São Paulo: Edgard Blücher, 2000. ISBN 85-212-0310-1
NETBEANS. Netbeans IDE. Disponível em: < http://www.netbeans.org/products/ide/>. Acesso em: 15 out. 2006.
O’BRIEN, James A. Sistemas de Informação e as Decisões Gerenciais na Era da Internet. 2. ed. São Paulo: Saraiva, 2004. ISBN 85-020-4407-9
ODELL, James. FIPA: welcome to the Foundation for Intelligent Physical Agents. Disponível em: <http://www.fipa.org>. Acesso em: 20 abr. 2006.
PESHAVE, Monica.; DEZHGOSHA, Kamyar. How search engines work and a web crawler application. In: ANNUAL MIDWEST INSTRUCTION AND COMPUTING SYMPOSIUM, 38., 2005, Eau Claire. Proceedings… Cedar Falls: [s.n.], 2005. 15 p.
123
REZENDE, Solange Oliveira. Sistemas Inteligentes: fundamentos e aplicações. 1. ed. Barueri: Manole, 2003. ISBN: 85-204-1683-7
RILEY, Gary. What is CLIPS. [S.l.: s.n.], 2004. Disponível em <http://www.ghg.net/clips/ WhatIsCLIPS.html>. Acesso em: 6 set. 2006.
RUSSEL, S.; NORVIG, P. Inteligência Artificial: referência completa para cursos de computação. 2. ed. Rio de Janeiro: Elsevier, 2004. ISBN: 8-535-21177-2
SANDHOLM, Tuomas. eMediator: a next generation electronic commerce server. In: INTERNATIONAL CONFERENCE ON AUTONOMOUS AGENTS. 4., 2000, Barcelona. Proceedings… New York: ACM Press, 2000, p. 341-348. ISBN:1-58113-230-1
SILVA, Leonardo Ayres de Morais e. Estudo e Desenvolvimento de Sistemas Multiagentes usando JADE: Java Agent Development framework. 97 f. Curso de Informática, Universidade de Fortaleza. UNIFOR, Fortaleza, 2003.
SOUZA, Eliane Moreira Sá de. Uma Estrutura de Agentes para Assessoria na Internet. 1996. Dissertação de Mestrado em Engenharia de Produção – Programa de Pós-Graduação em Engenharia da Produção, Universidade Federal de Santa Catarina, Florianópolis, 1996.
STEVENS, Perdita; POOLEY, Rob. Using UML: software engineering with objects and components. 2. ad. [SL]: Addison-Wesley, 2000. ISBN 0-201-64860-1
TURBAN, Efraim; POTTER Richard E.; RAINER, R. Kelly. Administração de Tecnologia da Informação: teoria e prática. Rio de Janeiro: Campus, 2003. ISBN 8535210237
VAHL JÚNIOR, José Cláudio. Uso de Agentes de Interface para adequação de bate-papos ao contexto de Educação a Distância. 2003. Mestrado em Ciência da Computação – Universidade Estadual de Campinas, Campinas, 2003.
WIKIPEDIA. A Enciclopédia Livre. Gilgamesh. Disponível em <http://pt.wikipedia.org/wiki/Gilgamesh>. Acesso em: 12 outubro 2005.
WILDER, Clinton. Intelligent Agents Add Spark to Electronic Commerce: Andersen tests World Wide Web search system. Information Week, [S.l.: s.n.], 1995. Disponível em: <http://www.informationweek.com/537/37mtand.htm>. Acesso em: 29 de julho 2006.
WOOLDRIDGE, Michael; JENNINGS, Nicholas R. Intelligent Agents: theory and practice. Knowledge Engineering Review, New York, v. 10, n. 2, p. 115-152, 1995. ISSN 0269-8889
WURMAN, Peter R.; WELLMAN, Michael. P.;WALSH William. E. The michigan internet Auctionbot: a configurable auction server for human and software agents. In: INTERNATIONAL CONFERENCE ON AUTONOMOUS AGENTS. 2., 1998, Minneapolis. Proceedings… New York: ACM Press, 1998. p. 301-308. ISBN 0-89791-983-1
APÊNDICES
A QUESTIONÁRIO DE TESTES
Para que a ferramenta Gilgamesh pudesse ser validada e que seu funcionamento pudesse ter
comprovação em algum critério, foi desenvolvido um questionário baseado no “Guia de Avaliação
da Qualidade de Produto de Software”, criado pelo Centro de Pesquisas Renato Archer (CenPRA).
A.1 QUESTIONÁRIO DE AVALIAÇÃO DE QUALIDADE DE PRODUTO DE SOFTWARE
A partir dessa sessão será apresentado o questionário aplicado com as devidas respostas. As
questões foram divididas em três quesitos: documentação, interface e funcionalidade.
A.1.1 Quesito Documentação
O quesito documentação visou analisar as informações provenientes do projeto do sistema e
dos textos produzidos para este trabalho de conclusão. A seguir podem ser visualizadas as questões
abordadas para o quesito documentação e suas devidas respostas:
1. Especificação dos requisitos de hardware na descrição do produto especifica:
• (NÃO) o processador necessário para colocar o produto em uso. Ex.: 486 DX, Pentium;
• (NÃO) o tamanho da memória principal para colocar o produto em uso;
• (NÃO) os dispositivos de entrada de dados necessários para colocar o produto em uso.
Ex.: kit multimídia, mouse, teclado, scanner;
• (NÃO) os dispositivos de saída de dados necessários para colocar o produto em uso. Ex.:
kit multimídia, impressoras, plotters, monitores SVGA, etc;
• (NÃO SE APLICA) placas de expansão de memória necessárias para colocar o produto
em uso; R: O software não necessita de tais dispositivos;
• (NÃO SE APLICA) os tipos dos periféricos auxiliares necessários para colocar o
produto em uso. Ex.: hardlock, etc; R: O Gilgamesh não necessita de nenhum periférico
auxiliar;
126
• (NÃO SE APLICA) a capacidade dos periféricos necessários para colocar o produto em
uso. Ex.: monitor de alta resolução, impressora de alta resolução, scanner de mesa; R: O
Gilgamesh utiliza-se apenas de hardware necessários para execução em um sistema
operacional com uma máquina virtual Java compatível;
• (NÃO SE APLICA) placas de rede necessárias para colocar o produto em uso. Ex.: NE
2000, etc; R: O software utilizará perfeitamente qualquer placa de rede devidamente
instalada e configurada em um sistema operacional compatível; e
• (NÃO SE APLICA) unidade de fax-modem necessária para realizar tarefas específicas.
R: O software funcionará em uma intranet, caso um servidor Gilgamesh também se
encontre na mesma rede.
2. Especificação dos requisitos de software na descrição do produto especifica:
• (NÃO SE APLICA) o software de sistema operacional necessário para colocar o produto
em uso. Ex.: Windows 95, DOS 6.2, etc; R: Devido a portabilidade da máquina virtual
Java. Somente é necessário que o sistema operacional seja compatível com Java;
• (SIM) para ambiente de rede, o software necessário para colocar o produto em uso. Ex.:
LAN, Novell, etc; R: Para que o Gilgamesh funcione em uma rede, é especificado que
há a necessidade da execução do Servidor Gilgamesh; e
• (SIM) outros produtos de software fundamentais para colocar o produto em uso. Ex.:
Visual Basic, Access, Delphi, etc. R: Os requisitos especificam o banco de dados que
serão utilizados.
3. Identificação das tarefas que podem ser executadas utilizando-se o produto:
• (SIM) estão identificadas as tarefas que podem ser executadas utilizando-se o software.
Onde: A documentação do projeto traz a descrição de todas as tarefas que podem ser
realizadas no sistema.
4. Declaração sobre a usabilidade da interface. A documentação apresenta, através de texto,
imagens ou fotos, se a interface com o usuário é feita através de:
127
• (SIM) linhas de comando;
• (SIM) menus;
• (SIM) janelas;
• (SIM) teclas de função;
• (NÂO) teclas de atalho; R: Para a ferramenta, as teclas de atalho se resumem as
definidas como padrão pelo sistema operacional;
• (SIM) barra de botões; e
• (NÃO SE APLICA) som. R: O funcionamento do sistema e seus avisos independem de
som.
5. A documentação apresenta:
• (SIM) Apresenta um texto introdutório e/ou de apresentação. Apresentando:
• (SIM) uma descrição geral do produto e do que fazem suas funções;
• (SIM) uma visão geral da estrutura da documentação;
• (SIM) é de fácil compreensão;
• (SIM) uma idéia clara do conteúdo da documentação;
• (SIM) uma ordem na apresentação das informações; e
• (SIM) termos técnicos que podem dificultar o entendimento de usuários leigos. R:
Termos técnicos são evitados, mas são abordados em alguns momentos. Usuários
leigos poderiam ter dificuldades para a compreensão da documentação.
6. Organização. A documentação:
• (NÃO) instrui o usuário, orientando-o na aprendizagem; R: Devido ao caráter científico
do texto, a aprendizagem não foi priorizada;
• (SIM) é organizada visando facilitar o entendimento pelo usuário;
• (SIM) permite uma fácil identificação das funções;
128
• (SIM) evita fazer muitas referências a itens que serão apresentados em capítulos
posteriores;
• (SIM) tem uma organização lógica e evolutiva, aumentando gradativamente o nível de
complexidade da informação na organização dos capítulos, ilustrações, índices e
glossário;
• (NÃO) contém um tópico dedicado a apresentar ao usuário os símbolos e convenções
usadas na documentação; Ex.: nome de comando em negrito, parâmetros em itálico,
ícones utilizados; R: Pois o padrão da documentação deve seguir os preceitos para um
Trabalho de Conclusão de Curso de Ciência da Computação da UNIVALI;
• (NÃO) contém um tópico dedicado a apresentar ao usuário os símbolos e convenções
apresentadas pela interface. Ex.: nome de comando em negrito, parâmetros em itálico,
ícones, utilizados; R: Pois o padrão da documentação deve seguir os preceitos para um
Trabalho de Conclusão de Curso de Ciência da Computação da UNIVALI;
• (SIM) possui os componentes numerados corretamente. Ex.: capítulos, sub-capítulos,
tópicos, etc; e
• (SIM) utiliza recursos para destaque nas informações relevantes. Ex.: negrito, itálico,
palavras em letra maiúscula, numeração, sombreamento de texto.
7. Exemplos: A documentação:
• (SIM) possui exemplos para auxiliar a compreensão do assunto tratado;
• (SIM) os exemplos são claros e precisos, não dando margem a interpretações ambíguas;
• (SIM) os exemplos são fáceis de entender;
• (SIM) os exemplos são suficientes;
• (SIM) os exemplos são apropriados ao tipo de aplicação do software;
• (SIM) os exemplos são apropriados ao tipo de usuário a que se destinam;
• (SIM) os exemplos citam fontes úteis para informações adicionais; e
• (SIM) os exemplos estão no mesmo idioma da documentação.
129
A.1.2 Quesito Interface
O quesito interface visou avaliar a camada de comunicação da ferramenta Gilgamesh. As
questões e respostas podem ser visualizadas a seguir:
1. Aplicabilidade. A interface:
• (SIM) está organizada em grupos segundo uma forma lógica facilmente compreendida
pelo usuário; R: A organização da interface obedece um hierarquia de funções;
• (SIM) faz uso de identificadores que representam claramente seu significado. Ex.:
títulos, ícones, etc; R: Os indicadores estão claros, pois os significados são simples e sua
representação pode ser mais sucinta;
• (NÃO) informa ao usuário sobre o que um botão, menu, ícone ou caixa de diálogo faz ao
posicionar o cursor do mouse sobre ele em bales explicativos ou barra de status que
aparecem na posição do cursor; R: Como esta foi a primeira versão do software, detalhes
como esse ficaram incompletos, ou mesmo, ausentes;
• (NÃO DE APLICA) utiliza o mesmo identificador para uma dada função no produto
como um todo; R: Todos os identificadores na ferramenta são únicos nessa versão;
• (NÃO) orienta o usuário nos passos a serem executados para a realização de uma
determinada tarefa; R: No projeto e implementação do sistema esses passos não foram
identificados como indispensáveis para a ferramenta;
• (NÃO) possibilita a realização da tarefa desejada com um número reduzido de passos;
R: As tarefas foram elaboradas para não consumirem o tempo do usuário, portanto, o
usuário terá que executar os mesmo passos sempre, pois os mesmos já estão reduzidos;
• (NÃO) permite a criação de atalhos para acesso às funções diretamente; R: Não há
funções de criação de atalhos;
• (NÃO SE APLICA) permite desabilitar alguns diálogos e apresentações iniciais. Ex.:
"Dicas do dia" do Word; R: O software não possui apresentações iniciais; e
• (NÃO) permite nomear rótulos ou comandos segundo a necessidade ou preferência do
usuário. R: Os rótulos possuem nomes fixos.
130
2. Aspectos Visuais. As telas:
• (SIM) apresentam uma distribuição uniforme de seu conteúdo, levando em consideração
o espaço disponível; R: As telas do software está com as funcionalidades bem dispostas;
• (SIM) possuem áreas de seleção dos itens de menu dimensionadas de forma a facilitar
sua visualização; R: Cada item de seleção possui áreas dimensionadas;
• (SIM) apresentam somente informações necessárias e utilizáveis sensíveis ao contexto;
R: As informações dispostas nos campos mudam de acordo com itens selecionados;
• (SIM) seguem um padrão na distribuição dos objetos facilitando o entendimento dos
mesmos; R: A distribuição dos objetos é organizada e padronizada;
• (SIM) facilitam a leitura e identificação das funções; R: As telas facilitam a visualização
das funções, pois as mesmas estão destacadas;
• (SIM) facilitam a leitura e identificação dos campos de entrada de dados e seus
formatos. Ex.: datas, horas, medidas, intervalos; R: O sistema facilita a entrada de
valores, identificando cada item da data e descrevendo os itens que devem ser inseridos
em campos incomuns;
• (SIM) apresentam os campos de entrada de dados compatíveis com a necessidade; R:
Todos os campos do sistema são compatíveis com as necessidades de entrada;
• (SIM) exibem as mensagens com bom aspecto visual, utilizando com moderação
negrito, itálico e sublinhado; R: As mensagens são objetivas e diretas, sem uso de
neologismos e expressões técnicas;
• (SIM) utilizam tipos e tamanhos de letras de fácil visualização; R: As letras e os tipos
foram escolhidos de acordo com um padrão de visualização e de fácil reconhecimento da
informação expressa pelos textos; e
• (SIM) apresentam contrastes de cores, facilitando a leitura. R: Itens desativados, por
exemplo, apresentam cores menos realçadas.
3. Localização. A interface:
131
• (SIM) está estruturada de forma a agrupar as tarefas do software em áreas funcionais; R:
Cada grupo de funções está organizado de forma que facilite a compreensão do usuário;
• (SIM) dispõe os objetos de interação (opções de menu, etc) numa ordem lógica. Ex.:
freqüência de uso, grau de importância, alfabética, etc; R: Os menus seguem grau de
importância; e
• (NÃO) apresenta informações adicionais em uma barra de status. R: O sistema não
possui barra de status.
4. Mensagens apresentadas. A interface:
• (SIM) exibe mensagens de orientação ao usuário. Havendo mensagens de orientação ao
usuário, elas:
• (SIM) orientam o usuário, de forma efetiva e eficiente na execução da tarefa
desejada;
• (SIM) são auto-explicativas, isto é, quando uma determinada mensagem é
apresentada, ela é imediatamente compreendida pelo usuário sem a necessidade de
consultas adicionais a outras fontes;
• (SIM) se limitam apenas ao contexto da tarefa que está sendo realizada; R: O escopo
das explicações não fogem aos das tarefas realizadas no momento.
• (SIM) são controláveis pelo usuário. Ex.: em relação ao tempo de exposição na
tela,como continuar com o diálogo, etc; R: O usuário possui total controle sobre as
janelas de mensagens, podendo arrastá-las e fechá-las o momento que bem entender;
• (SIM) estão de acordo com a expectativa do usuário, obedecendo a suas
características, tais como conhecimento específico da tarefa, educação e experiência;
R: As mensagens foram definidas de acordo com a experiência e a educação do
usuário, que se espera como perfil;
• (SIM) utilizam de uma linguagem instrutiva, polida, neutra e não agressiva. R: As
mensagens evitam neologismos, são diretas, mas não agressivas; e
132
• (SIM) é apropriado para o aprendizado, isto é, orienta e guia o usuário no sentido de
aprender a usar o software. R: Todas as mensagens indicam ao usuário, seu erro,
incitando o mesmo a não cometer o mesmo erro.
5. Definição. A interface:
• (SIM) possui as funções de interface bem definidas, de forma a não deixar dúvidas sobre
o que fazem. Ex.: Identificação dos Rótulos, Legendas, Cabeçalhos, Opções de Menu,
etc; R: Todas as funções são agrupadas, de acordo com a semelhança ou o tipo, e bem
definidas;
• (SIM) é bem estruturada de modo a facilitar a seleção das opções relevantes à execução
do software. Ex.: menus em níveis hierárquicos, posicionamento de botões; R: São
utilizadas hierarquias de menus e de funções;
• (NÃO) orienta bem o usuário na compreensão e execução da tarefa. Ex.: Por meio de
caixas de diálogo, mensagem de alerta, mensagens de orientação apresentadas na barra
de status, linhas de comando, balões explicativos, som; R: O sistema Gilgamesh não
orienta o usuário no uso, através dos meios descritos para esse critério;
• (SIM) mostra as principais funções para executar as tarefas propostas pelo software; R:
As principais funções ficam na tela principal; e
• (NÃO SE APLICA) mostra funções não inerentes ao software. Ex.: instalação,
desinstalação, backup. R: Devido ao software ser interpretado, a instalação e remoção da
ferramenta não requer conhecimento específico. Backups não são necessários, pois as
informações ficam no lado Servidor da aplicação.
6. Coerência. As funções do software expressadas na interface através de menus, barra de botões, teclas de atalho e de função, caixas de diálogo, etc:
• (SIM) possuem uma estrutura que permite uma interação rápida e fácil com o usuário; R:
A implementação da ferramenta focou em produzir interfaces para que o usuário pudesse
usufruir da ferramenta de maneira rápida e fácil, sem muitas complicações;
133
• (SIM) possuem uma estrutura que facilita a localização e seleção da opção relevante à
execução da tarefa; R: As tarefas da ferramenta com o usuário estão organizadas em
menus, sub-menus a fim de facilitar o trabalho do usuário;
• (SIM) possuem uma estrutura que orienta o usuário na seqüência de passos necessários
para uma execução eficiente e eficaz da tarefa; R: Os cadastros são um exemplo disso:
as informações estão dispostas na tela na seqüência em que devem ser preenchidas; e
• (SIM) possuem uma estrutura de interação uniforme ao longo de todo o software,
facilitando o uso para que o usuário não precise aprender o software a cada nova tarefa.
R: As interfaces das tarefas foram desenvolvidas de modo padronizado, e tarefas
semelhantes possuem interfaces semelhantes.
7. Harmonia. A interface:
• (SIM) quando apresenta menus com muitas opções, organiza-as em grupos separados
entre si por traços simples, e compostos por até 7 opções (+ - 2) relacionadas
logicamente; R: Na interface principal, há menus de acesso rápido dispostos em árvore,
contendo os leilões, lances e a opção de início de uma busca por produto;
• (NÃO) possui características próprias ao tipo de aplicação a que se destina. Ex.:
Técnico, diversão, aprendizagem, etc; R: O software foi desenvolvido no modelo
Cliente/Servidor com o intuito de desvencilhar os problemas de incompatibilidade com
navegadores diferentes e fornecer um outro meio de conexão, mais adaptável a natureza
da aplicação;
• (SIM) apresenta somente as informações pertinentes à execução da tarefa; R: Para
execução das tarefas, somente informações relevantes são solicitadas; e
• (NÃO SE APLICA) apresenta funções que, quando analisadas em conjunto, se
complementam permitindo uma continuidade das tarefas. R: As funções do software não
se complementam. Cada uma possui suas próprias características e particularidades.
A.1.3 Quesito Funcionalidade
No quesito funcionalidade, as funções do sistema foram avaliadas. A seguir, podem ser
visualizadas questões e respostas realizadas para o quesito:
134
1. Acesso Seletivo. O software:
• (SIM) tem implementado o recurso para acesso seletivo. Ex.: Permite acesso de usuários
a determinadas tarefas através de senhas. R: Todos os usuários possuem as mesmas
tarefas perante Gilgamesh. Mas o sistema possui controle de usuário;
• (SIM) é compatível com o tipo de informação que manipula;
• (SIM) impede a utilização das funções não autorizadas; R: Usuários só podem acessar
funções de leilões ou lances que criaram; e
• (SIM) permite gerenciamento das senhas de acesso. R: Cada usuário possui sua senha de
acesso aos seus dados.
2. Ocorrência de falhas:
• O software:
• (NÃO) apresentou falhas durante execução do software. R: Os testes realizados não
capturaram falhas na ferramenta.
• As falhas:
• (NÃO SE APLICA) ocorreram numa única situação dentro do software;
• (NÃO SE APLICA) impossibilitaram a avaliação do software;
• (NÃO SE APLICA) provocaram reset no computador;
• (NÃO SE APLICA) causaram propagação de erros, percebida durante a avaliação;
• (NÃO SE APLICA) provocaram perda de trabalhos realizados anteriormente a sua
ocorrência; e
• (NÃO SE APLICA) são seguidas de mensagens orientando o usuário em como
proceder.
3. Violação de Uso. Em qual situação de violação de uso o software apresentou propagação de erros (tais como perda de dados, resultados incorretos, comportamento imprevisto, etc): R: Os testes realizados não capturaram falhas na ferramenta.
135
• (NÃO) no reset;
• (NÃO) na entrada de um volume de dados fora dos limites permitidos;
• (NÃO) na entrada de dados fora dos limites permitidos (formatação e/ou valores do
campo);
• (NÃO) nos dados inconsistentes. Ex.: datas inválidas; e
• (NÃO) nos dados insuficientes. Ex.: campos definidos com preenchimento obrigatórios
deixados em branco.