Framework para Sistema de Raciocínio Baseado em Casos · centro universitÁrio vila velha curso de ciÊncia da computaÇÃo diego lima ervatti patrick peyneau andrade rafael zacchÉ

CENTRO UNIVERSITÁRIO VILA VELHA

CURSO DE CIÊNCIA DA COMPUTAÇÃO

DIEGO LIMA ERVATTI

PATRICK PEYNEAU ANDRADE

RAFAEL ZACCHÉ DE SÁ SILVA

Framework para Sistema de Raciocínio

Baseado em Casos

VILA VELHA

2010

DIEGO LIMA ERVATTI




Baseado em Casos

Trabalho de Conclusão de Curso apresen-tado ao Centro Univertário Vila Velha comorequisito parcial para a obtenção do graude Bacharel em Ciência da Computação.Orientador: Erlon Pinheiro

VILA VELHA

2010

DIEGO LIMA ERVATTI




Baseado em Casos

BANCA EXAMINADORA

Prof. Msc. Erlon PinheiroCentro Universitário Vila VelhaOrientador

Prof. Msc. Hudson RamosCentro Universitário Vila Velha

Prof. Msc. Marcello NovaesCentro Universitário Vila Velha

Trabalho de Conclusão de Curso

aprovado em 26/11/2010.

Autorizo que a UVV, sem ônus, promova a publicação de minha monografia em

página própria na Internet ou outro meio de divulgação de trabalho científico.

Assinaturas

Prof. Msc. Erlon PinheiroCentro Universitário Vila VelhaOrientador

Diego Lima ErvattiCentro Universitário Vila Velha

Patrick Peyneau AndradeCentro Universitário Vila Velha

Rafael Zacché de Sá SilvaCentro Universitário Vila Velha

26/11/2010

Dedico este trabalho a Deus que tornou possível todo o nosso trabalho

e vida. A minha mãe, Ana Regina, pelo apoio mais do que completo

durante toda minha trajetória, à minha avó e minha irmã, America e

Priscila, pelo incentivo à minha formação e à minha namorada Katyùcia

que durante todo o tempo foi compreensiva, e presenteou-me com

todo o seu apoio e carinho.

Diego

Dedico este trabalho primeiramente a Deus pelo dom da vida e saúde

para o desenvolvimento deste trabalho. Aos meus pais, José e

Rosangela, pelo apoio, incentivo, carinho e compreensão em toda

minha trajetória acadêmica, aos meus primos Adson e Gileno por

estarem sempre dispostos a ajudar, as minhas avós, Dulce e Maria,

que compartilharam comigo os momentos de tristezas e também de

alegrias, nesta etapa em que está sendo vencida. A toda minha família

e aos meus eternos amigos que foram compreensivos em minhas

ausências.

Patrick

Dedico este trabalho primeiramente a Deus, pois sem Ele nada seria

possível e não estaríamos aqui reunidos e desfrutando juntos destes

momentos que nos são tão importantes. Aos meus pais, Leonardo e

Marinete, e minha irmã Fernanda pelo esforço, dedicação e

compreensão em todos os momentos desta e de outras caminhadas.

Aos meus avós, Antônio e Claudete, e a todos os meus primos, tias e

tios pelo incentivo, cooperação e apoio. Em especial, a minha

companheira Karoliny pelo seu carinho, preocupação e dedicação

durante todo o curso, compartilhando comigo os momentos de

tristezas e também de alegrias, nesta etapa em que, com a graça de

Deus, está sendo vencida. Em fim, a todos uma gratidão eterna.

Rafael

AGRADECIMENTOS

Aos amigos que aqui chamamos de equipe, no que concerne à dedicação, com-

prometimento e compartilhar além de conhecimento os momentos de descontração.

A todos os nossos professores, em especial ao nosso orientador Erlon Pinheiro. Ao

amigo Jovani que nos apoiou com seu conhecimento em algumas das tecnologias

aplicadas ao nosso sistema.

A todos aqueles que, direta ou indiretamente, colaboraram para que este trabalho

atingisse seus objetivos propostos.

“Se vi mais longe, foi por estar de pé sobre ombros de gigantes”

Isaac Newton

LISTA DE TABELAS

1 Exemplo de uma representação atributo-valor. . . . . . . . . . . . . . . 23

2 Representação da distância geométrica. . . . . . . . . . . . . . . . . . . 27

3 Representação nearest neighbour ponderado. . . . . . . . . . . . . . . 27

4 Tabela de demonstração de similaridade local. . . . . . . . . . . . . . . 29

5 Estrutura de dados (Wangenheim, 2003). . . . . . . . . . . . . . . . . . 32

6 Algoritmo de recuperação seqüencial (Wangenheim, 2003). . . . . . . . 33

7 Algoritmo de recuperação de dois níveis (Wangenheim, 2003). . . . . . 34

8 Princípio da recuperação em árvores k-d [Wangenheim, 2003]. . . . . . 36

9 ALGORITMO recupere (K: árvore k-d) (Wangenheim, 2003). . . . . . . 36

10 Rede de recuperação de casos (Wangenheim, 2003). . . . . . . . . . . 37

11 Descrição dos casos de uso Cadastrar Cliente. . . . . . . . . . . . . . . 58

12 Descrição dos casos de uso Consultar Produto - RBC e Realizar Compra. 59

13 Descrição dos casos de uso Consultar Produto - RBC e Realizar Compra. 60

14 Requisitos Não-Funcionais. . . . . . . . . . . . . . . . . . . . . . . . . . 61

15 Classe Cliente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

16 Classe Endereço. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

17 Classe Carro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

18 Caso Venda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

LISTA DE FIGURAS

1 Ciclo de vida do raciocínio baseado em casos [Wangenheim, 2003]. . . 22

2 Representação orientada a objetos. . . . . . . . . . . . . . . . . . . . . 24

3 Espaço de busca bidimensional hipotético e a árvore k-d de busca corres-

pondente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Modelo MAC/FAC (Wangenheim, 2003). . . . . . . . . . . . . . . . . . . 33

5 Princípio básico de métodos de recuperação orientados a índices. . . . 36

6 Algoritmo 1 - IBL1 [Wangenheim, 2003]. . . . . . . . . . . . . . . . . . . 45

7 Ciclo de vida - JSF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8 Estrutura do JPA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

9 Diagrama de Casos de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . 57

10 Diagrama do Domínio do Problema. . . . . . . . . . . . . . . . . . . . . 62

11 Diagrama de Sequência CSU02: Consultar Produto RBC. . . . . . . . . 65

12 Diagrama de Sequência CSU03: Comprar Produto. . . . . . . . . . . . 66

13 Diagrama de Estados - Objeto ManageRBC. . . . . . . . . . . . . . . . 67

14 Diagrama de pacotes - Padrão MVC Estendido. . . . . . . . . . . . . . . 70

15 Diagrama de Classe do Modelo. . . . . . . . . . . . . . . . . . . . . . . 71

16 Diagrama de Classe da Visão. . . . . . . . . . . . . . . . . . . . . . . . 72

17 Diagrama de Classe do Controle. . . . . . . . . . . . . . . . . . . . . . . 73

18 Diagrama de Classe do Framework RBC. . . . . . . . . . . . . . . . . . 74

19 Diagrama de Classe do Framework RBC. . . . . . . . . . . . . . . . . . 75

20 Modelagem do banco de dados. . . . . . . . . . . . . . . . . . . . . . . 76

21 Diagrama de componentes. . . . . . . . . . . . . . . . . . . . . . . . . . 77

22 Diagrama de Sequência Revisado - CS02: Consultar Produto RBC. . . 78

23 Diagrama de Sequência Revisado - CS03: Comprar Produto. . . . . . . 79

24 Tela de login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

25 Tela principal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

26 Tela de consulta personalizada. . . . . . . . . . . . . . . . . . . . . . . . 81

27 Tela de exibição do caso adaptado. . . . . . . . . . . . . . . . . . . . . . 82

28 Cálculo de similaridade global - Cálculo de similaridade do valor da venda. 92

29 Cálculo de similaridade local - Cálculo de similaridade do estado cívil do

cliente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

30 Cálculo de similaridade local - Cálculo de similaridade do número de

filhos do cliente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

31 Cálculo de similaridade local - Cálculo de similaridade da classe social

do cliente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

32 Cálculo de similaridade local - Cálculo de similaridade da categoria do

carro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

33 Cálculo de similaridade local - Cálculo de similaridade do modelo do carro. 94

34 Cálculo de similaridade local - Cálculo de similaridade da cor do carro. . 95

35 Código da recuperação dos casos mais similares. . . . . . . . . . . . . 96

36 Código da adaptação composicional - Parte 1. . . . . . . . . . . . . . . 97







43 Script de criação do database rbc e tabelas carro e endereco. . . . . . 103

44 Script de tabelas cliente e venda. . . . . . . . . . . . . . . . . . . . . . . 104

SUMÁRIO

RESUMO

1 INTRODUÇÃO 16

1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.3 Método . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.4.1 Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . 19

1.5 Descrição dos Capítulos . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2 Referêncial Teórico 21

2.1 Raciocínio Baseado em Casos - RBC . . . . . . . . . . . . . . . . . . . 21

2.1.1 Representação de Casos . . . . . . . . . . . . . . . . . . . . . . 22

2.1.2 Representação atributo-valor . . . . . . . . . . . . . . . . . . . . 23

2.1.3 Representação orientada a objetos . . . . . . . . . . . . . . . . 24

2.1.4 Representação utilizando redes semânticas . . . . . . . . . . . . 25

2.1.5 Representação utilizando árvore k-dimensional . . . . . . . . . . 25

2.1.6 Similaridade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.1.7 Modelos de similaridade global simétrica . . . . . . . . . . . . . 26

2.1.8 Medidas de similaridade local . . . . . . . . . . . . . . . . . . . . 29

2.1.9 Recuperação de casos . . . . . . . . . . . . . . . . . . . . . . . 30

2.1.10 Reutilizar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.1.11 Revisão de casos . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.1.12 Reter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.2 Framework Java Server Faces - FSF . . . . . . . . . . . . . . . . . . . . 46

2.3 Prime Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.3.1 Ciclo de vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.3.2 Faces Config (algaworks) . . . . . . . . . . . . . . . . . . . . . . 48

2.3.3 Backing beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.4 Java Persistence API - JPA . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.5 Plataforma de Desenvolvimento Java . . . . . . . . . . . . . . . . . . . 49

2.5.1 Padronização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.5.2 Principais Características . . . . . . . . . . . . . . . . . . . . . . 50

2.5.3 Máquina Virtual Java . . . . . . . . . . . . . . . . . . . . . . . . . 51

3 Estudo de viabilidade 52

3.1 Oportunidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.2 Ameaças . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.3 Fraquezas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.4 Forças . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.5 Mercado potêncial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.6 Benefícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4 Levantamento de Requisitos 55

4.1 Requisitos Funcionais do Software . . . . . . . . . . . . . . . . . . . . . 55

4.2 Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.3 Descrição do Ator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.4 Descrição dos Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . 57

4.5 Requisitos Não-Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . 60

5 Especificação de Análise 62

5.1 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2 Dicionário de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3 Modelagem de Interações . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.4 Transição de Estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6 Projeto de software 68

6.1 Arquitetura do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.2 Distribuição dos Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.2.1 Diagrama de Classe do Modelo . . . . . . . . . . . . . . . . . . . 71

6.2.2 Diagrama de Classe da Visão . . . . . . . . . . . . . . . . . . . . 72

6.2.3 Diagrama de Classe do Controle . . . . . . . . . . . . . . . . . . 73

6.2.4 Diagrama de Classe do Framework RBC . . . . . . . . . . . . . 73

6.2.5 Diagrama de Classe DAO . . . . . . . . . . . . . . . . . . . . . . 75

6.3 Estrutura de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.4 Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.5 Revisão dos diagramas de sequência . . . . . . . . . . . . . . . . . . . 77

7 Mapa de navegabilidade e Telas do protótipo 80

8 Ferramentas de desenvolvimento 83

8.1 Framework RBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

8.2 Framework RBC implementado . . . . . . . . . . . . . . . . . . . . . . . 84

8.2.1 Classe CalculoSimilaridade.java . . . . . . . . . . . . . . . . . . 85

8.2.2 Classe Recuperar.java . . . . . . . . . . . . . . . . . . . . . . . . 85

8.2.3 Classe Reutilizar.java . . . . . . . . . . . . . . . . . . . . . . . . 85

8.2.4 Classe Revisar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

8.2.5 Classe Reter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

9 Domínio da aplicação 87

10 CONCLUSÃO 88

REFERÊNCIAS 90

Anexo 1 92

Anexo 2 96

Anexo 3 97

Anexo 4 103

RESUMO

Com o crescente número de transações comerciais de varejo efetuadas na rede mundialde computadores, torna-se eminente a busca por conquistar estes consumidores.Pensando nisso, os desenvolvedores dos sites de comércio eletrônico têm sido obri-gados a inovar para manter-se na briga pelo mercado. Sabe-se que para um vendedoroferecer o produto correto a um cliente (com mais chances de ser vendido), este deveidentificar algumas características do interessado de acordo com o escopo. Num ambi-ente online, isto se torna difícil, devido às limitações que são impostas pela tradicionalforma de navegar, escolher um produto e comprar na internet. O Raciocínio Baseadoem Casos, ramo da Inteligência Artificial, pode influenciar fortemente de maneira posi-tiva neste aspecto, pois tem como premissa resolver um dado caso a partir de soluçõesde casos análogos que foram bem sucedidas no passado. Com o uso desta tecnolo-gia, é possível sugerir produtos, negociar descontos e entregas, além de conhecerseus clientes, assim como um vendedor de carne e osso. Esta é a solução abordadapor este trabalho onde foi desenvolvido um framework para esta tecnologia e tambémum protótipo de um sistema de vendas de carros online.

Palavras chaves: Inteligência Artificial, Raciocínio Baseado em Casos, Raciocínio emInteligência Artificial, Sistema de vendas, Tecnologia.

16

1 INTRODUÇÃO

Sites de comércio eletrônico vêm ganhando cada vez mais adeptos, recebendo

milhares de visitas todos os dias. Esse aumento nas transações online foi impulsion-

ado graças à entrada de grandes varejistas. José Calazans, analista de mídia do

Ibope, diz que lojas como Americanas, Ponto-Frio, Wall-Mart e Casas Bahia estão

"puxando a audiência".

Pesquisas, realizadas pela empresa de cartões de crédito Visa, mostram que a

popularização das conexões banda larga e a maior penetração de computadores nos

lares contribuem ainda mais para o crescimento do comércio eletrônico e, por conse-

quência, o uso do cartão de crédito, o que demonstra que os brasileiros estão dispos-

tos a gastar na rede.

O consumidor online, na visão de Cristiano Leoz, quer ainda mais do que um catá-

logo de ofertas. Para que ele efetive a compra e volte mais vezes ao site, precisa e

quer ter uma experiência agradável, de preferência, antes, durante e após a compra.

"Oferecer um conteúdo atraente e diferenciado ou uma opção de entretenimento são

ações simples, mas que funcionam bem no relacionamento com os clientes. A criativi-

dade e a busca por um diferencial são imprescindíveis, assim como a transparência

da marca", explica.

Atualmente existem milhares de sites de e-commerce, estes por sua vez, retornam

quantidade excessiva de informações que apresentam pouca ou nenhuma relevân-

cia quando comparada à informação desejada. Para oferecer produtos relevantes ao

usuário, há uma necessidade de conhecer seus interesses, bem como ter conheci-

mento do que ele já comprou, e não somente dele, mas dos usuários que possuem

características semelhantes.

A Inteligência artificial (IA) por sua vez é uma área de pesquisa que busca por

artifícios computacionais que simulem a capacidade humana de resolver problemas.

Diferentes métodos são empregados para simular a forma como humanos pensam,

17

dentre uma ampla variedade está o Raciocínio Baseado em Casos (RBC).

Em síntese pode-se afirmar que o RBC resolve um dado problema a partir de

soluções de problemas análogos que foram bem sucedidas no passado. Com o RBC,

as buscas realizadas por usuários anteriores, atualmente desperdiçadas, podem servir

para um novo usuário, ajudando-o a encontrar o que deseja. Partindo dessa premissa

foi desenvolvido um sistema de vendas online diferente do que está consolidado no

mercado, um sistema capaz de simular um vendedor real, sugerir produtos, negociar

descontos, negociar entregas e, sobretudo, conhecer seus clientes.

1.1 Motivação

Uma das características marcantes dos seres humanos, é a capacidade de re-

solver problemas extremamente complexos e, à medida que sua experiência cresce,

capazes de resolver de forma habitual e com crescente aptidão, problemas mal definidos

e com conhecimento incompleto. Essa característica é altamente desejável em sis-

temas de IA. Ao observar sistemas tradicionais de IA, sistemas de bancos de dados e

de recuperação de informações pode-se notar que eles veem falhando em satisfazer

esta expectativa. O RBC é uma tecnologia capaz de superar alguns desses problemas

[Leake, 1996].

Os Sistemas de Gerenciamento de Bancos de Dados (SGBD) têm sido largamente

utilizados em sites de e-commerce. Sua maior vantagem é sua capacidade de recu-

perar grandes quantidades de dados de forma eficiente, porém muitas vezes trazem

informações irrelevantes que acabam sendo descartadas.

Em comparação com o RBC, bancos de dados são projetados para realizar bus-

cas exatas em sua base de dados, enquanto o objetivo de um sistema de RBC é

justamente realizar acessos com base em buscas inexatas [Leake, 1996]. Em muitas

aplicações reais, casos que correspondem exatamente a uma nova situação podem

não ser encontrados em uma base de casos. Em domínios em que situações como

essa ocorrem, sistemas de bancos de dados não fornecem uma solução adequada e

quando se fala em vendas online, a falta de uma solução acarretará à perda de um

comprador em potencial.

18

1.2 Justificativa

De acordo com dados da Pesquisa Nacional por Amostra de Domicílios (Pnad), di-

vulgados em 08 de Setembro de 2010, pesquisa essa relativa ao ano de 2009, houve

um crescimento de 112,9 no número de pessoas que declararam ter usado a rede

mundial de computadores entre meados da década e o ano passado. Em 2009, in-

forma a pesquisa que 67,9 milhões de pessoas declararam ter usado a internet.

Tendo em vista o elevado número de clientes em potencial, ou seja, pessoas dis-

postas a visitar e comprar produtos de forma online. Há uma necessidade de entender

e conhecer cada cliente individualmente, conhecer suas preferências, seu trabalho,

quanto estão dispostos a gastar, dentre outras informações, para então oferecer pro-

dutos ou soluções que se adéquem ao seu perfil, levando o mesmo a efetivar a com-

pra, garantindo sua comodidade e satisfação.

Para tornar esse sonho uma realidade, se faz necessário uma solução inteligente,

solução esta capaz de conhecer de forma única cada cliente, para então sugerir pro-

dutos que se enquadrem aos seus interesses.

1.3 Método

A metodologia que permitirá a este trabalho atingir seus objetivos será a revisão

bibliográfica, tendo como base o referencial teórico levantado no artigo desenvolvido

anteriormente pelo grupo.

Dentre os instrumentos utilizados estão presentes a análise de casos realizada

com um experiente vendedor - para apoio ao desenvolvimento do ambiente de vendas

online - e o material bibliográfico, que será granularizado em sua seção, caracteri-

zando uma pesquisa qualitativa.

1.4 Objetivos

O conceito de RBC pode ser aplicado nas mais variadas áreas, porém como já

dito, o comércio eletrônico vem ganhado cada vez mais adeptos, o que influenciou na

escolha do domínio do problema.

Dentro deste cenário, objetiva-se a concepção e desenvolvimento de um frame-

19

work que por meio de Raciocínio Baseado em Casos, recupere, reutilize, revise e

retenha todas as vendas realizadas e com base nas semelhanças entre eles e nas

compras realizadas, ajude os clientes na escolha do produto que se encaixe ao seu

perfil.

1.4.1 Objetivos específicos

• Realizar o levantamento do estado da arte que envolve o Raciocínio Baseado

em Casos;

• Utilização dos conceitos do ciclo de vida do RBC para o desenvolvimento de um

framework ;

• Implementar um protótipo utilizando o framework desenvolvido, juntamente, com

outros frameworks para então criar um site de vendas online.

1.5 Descrição dos Capítulos

Nos capítulos que se seguem serão apresentados:

• Capítulo 2: Conceitos de engenharia de software, padrão de projeto, estudo

sobre o ciclo de vida do framework JavaServer Faces e Hibernate JPA. Um es-

tudo da tecnologia Raciocínio Baseado em Casos apresentando o ciclo de vida,

estratégias de recuperação, adaptação, revisão e retenção.

• Capítulo 3: Estudo da viabilidade, oportunidades, ameaças, fraquezas, forças,

o mercado em potêncial e os benefícios do sistema.

• Capítulos 4, 5 e 6: O levantamento dos requisitos de software, sua especifi-

cação de analise, de projeto, bem como ferramentas e políticas utilizadas no

desenvolvimento da aplicação.

• Capítulo 7: Descrição do mapa de navegabilidade e apresentação dos protóti-

pos de tela.

• Capítulo 8: Descrição de ferramentas estudadas e utilizadas, e descrição da

implementação do framework RBC, que implementa métodos do ciclo de vida

do RBC, desenvolvido neste projeto.

20

• Capítulo 9: Descrição do domínio de aplicação para suporte à vendas.

• Capítulo 10: Conclusão e projetos futuros.

21

2 Referêncial Teórico

Neste capítulo será abordado todo estado da arte que abrange o conceito de

Raciocínio Baseado em Casos.

2.1 Raciocínio Baseado em Casos - RBC

Entre as habilidades inteligentes está a habilidade para armazenar e recuperar

eficientemente grande quantidade de informação, além da capacidade de adaptar ou

modificar um conteúdo [Rezende, 2005].

Os primeiros aspectos do RBC foram infundidos nos trabalhos de Schank e Abel-

son sobre memória dinâmica e modelo cognitivo. O RBC originou-se em modelos

cognitivos da solução de problemas e aprendizado de novas situações, no geral, seria

gravar essas situações em memória como se fossem roteiros, ou seja, algumas coisas

ocorrerão sempre conforme o esperado.

CYRUS foi o primeiro sistema de RBC, desenvolvido por Janet Kolodner na Yale

University, seu enfoque era solução de problemas diplomáticos. Após esse sistema,

diversos outros surgiram como: Mediator, Persuader, Chef, Julia, Hypo, Protos, Casey,

Pantdex, dentre outros, cada um com enfoque específico.

O objetivo do RBC é tentar resolver um problema com base em experiências pas-

sadas. Conforme Luger (2004), os sistemas RBC compartilham uma estrutura comum.

Para cada novo problema:

• Recuperam o caso mais similar na base de casos;

• Reutilizam este caso para resolver o problema;

• Revisam a solução indicada;

• Retém a experiência representando o caso atual para referências futuras.

22

Figura 1: Ciclo de vida do raciocínio baseado em casos [Wangenheim, 2003].

2.1.1 Representação de Casos

Todo conhecimento que envolve sistemas de RBC são armazenados sob a forma

de casos, casos estes que representam um conhecimento específico de experiências

ou episódios concretos.

Não existe um conteúdo exato do que será representado por um caso, seu con-

teúdo é totalmente dependente da aplicação. O que há de comum entre eles é que

todos tem como objetivo representar uma situação ocorrida que poderá futuramente

ser relembrada, adaptada e aplicada a uma nova solução.

Exemplos de como casos podem conter diferentes conteúdos:

Comércio eletrônico: lista das características do produto (por exemplo, marca:

fiat, modelo: siena, cor: prata, preço: R$ 30.000).

Comércio eletrônico: lista das características do produto (por exemplo, nome:

mesa, tipo: madeira, cor: marfim).

Várias estratégias podem ser adotadas para representação de casos, tais como:

representação atributo-valor, orientação a objetos, redes semânticas e árvores k-d.Existem

outras formas de representação de casos, mas somente as citadas serão abordadas

no presente trabalho.

O Ponto mais difícil na solução de problemas baseado em casos, independen-

temente da estrutura de dados selecionada para a representação dos casos, é a es-

23

colha das características relevantes para a indexação e a recuperação de casos [Luger

2004], que é apresentado na seção 5.

“A representação do caso significa codificar o conhecimento contido nos casos

mediante uma ampla gama de formalismos representacionais ou linguagens desen-

volvidas no âmbito da IA, permitindo armazená-lo em uma forma simples, concisa,

completa e clara ”[Russell, 2004].

A metodologia a ser adotada para representar um caso dependerá do contexto ao

qual o RBC está sendo aplicado e como os dados armazenados serão alterados.

2.1.2 Representação atributo-valor

A representação atributo valor é a forma mais simples de representação de casos,

na qual um item é representado por um par atributo-valor [Wangenheim, 2003].

Esta representação pode ser vista na tabela 1.

Atributos ValorDescrição “Carro,siena, prata”Ano 2010Cor PrataMarca FiatModelo SienaPreço R$ 35.125,00

Tabela 1: Exemplo de uma representação atributo-valor.

A representação de casos atributo-valor pode ser definida basicamente por tipos

como: booleano, data, símbolo (ordenado, não-ordenado ou taxonomia), número e

string.

Existem inúmeras vantagens na utilização de par atributo-valor, tais como:

• Representação simples e fácil de programar;

• Fácil implementação de medidas de similaridade;

• Fácil armazenamento, podendo ser armazenado em SGBD1 relacionais;

• Recuperação eficiente.

1Sistema de gerenciamento de banco de dados.

24

Porém apresenta desvantagens como:

• Não é capaz de representar informações estruturais;

• Não é capaz de representar informações relacionais.

É recomendável que pares atributo-valor sejam usados somente para tarefas de diag-

nóstico que têm que lidar com grandes bases de casos.

2.1.3 Representação orientada a objetos

Nesta representação os casos são vistos como objetos2, que por sua vez são

agrupados por tipos similares formando uma classe3.

Essa representação permite a modelagem de relacionamento entre diferentes tipos

de objetos, tais como: relações taxonômicas, relações composicionais e relações es-

peciais.

Figura 2: Representação orientada a objetos.

Algumas vantagens dessa representação:

• Representação estruturada e natural de casos;

• Representação direta de informações estruturais e relacionais;

• Armazenamento compacto.

Porém possui as seguintes desvantagens:

• Cálculo de similaridade complexo;

• Recuperação de casos complexa.2Instância de uma classe.3Estrutura que abstrai um conjunto de objetos com características similares.

25

2.1.4 Representação utilizando redes semânticas

É uma forma de representação do conhecimento determinada como um grafo di-

recionado no qual os vértices representam unidades conceituais, e as arestas repre-

sentam relacionamentos entre essas unidades [Real, 2003].

O tipo de rede semântica utilizada em RBC denomina-se Rede de Recuperação de

Casos (RRC)4. Esta é uma forma eficiente e flexível de recuperação de casos, capaz

de entender termos vagos e ambíguos, além da eficiente manipulação de bases de

casos de tamanho razoável [Wangenheim, 2003].

De acordo com [Wangenheim, 2003] o conceito fundamental das RRC são as

Entidades de Informação (EI). Um caso consiste de um conjunto de EI, e a base de

casos em uma rede com nodos para as EI observadas no domínio e nodos adicionais

denotando os casos particulares.

2.1.5 Representação utilizando árvore k-dimensional

Árvore k-d é uma árvore de pesquisa binária k-dimensional onde cada nível desta

árvore se ramifica baseando-se no discriminador, que por sua vez, tem como base

uma medida estatística denominada amplitude interquartil5 [Goetze, 2005]. Sua di-

visão é feita alternadamente utilizando as coordenadas x, y de acordo com a profundi-

dade da árvore [Heredia, Iochpe, Comba, 2003], como pode ser observado na figura

3.

A construção da árvore k-d é feita por uma função recursiva que verifica a possi-

bilidade de continuar a divisão dos dados para adicionar novas ramificações.

Essa é a estrutura de dados comumente utilizada por ser aplicável a qualquer

tipo de sistema, onde se queira fazer recuperação de chaves secundárias ou mul-

tichaves, visando à criação de estruturas de índices sobre base de casos que con-

tenham grandes quantidades de dados. Porém, possui a desvantagem de gerar ár-

vores de grande profundidade e sua inserção balanceada é extremamente custosa.

4Do inglês, Case Retrieval Nets.5É dada pela diferença entre o quartil superior e o quartil inferior.

26

Figura 3: Espaço de busca bidimensional hipotético e a árvore k-d de busca corres-pondente.

2.1.6 Similaridade

O objetivo do RBC é recuperar casos de sua base que sejam o mais similar pos-

sível ao problema a ser resolvido. Os casos recuperados não precisam ser necessari-

amente idênticos a situação atual, porém quanto maior o nível de similaridade melhor

será a solução encontrada.

Casos podem ser considerados similares se eles forem úteis para a solução do

caso atual e seu nível de similaridade varia entre 0 e 1, onde 0 é a dissimilaridade total

e 1 a coincidência absoluta. Apresentam-se nesta seção vários métodos heurísticos

para determinar o caso de maior utilidade.

2.1.7 Modelos de similaridade global simétrica

A similaridade global simétrica é calculada entre objetos com base nos seguintes

modelos: similaridade como distância geométrica, nearest neighbour, distância eucli-

diana, distância euclidiana ponderada e métrica do quarteirão (distância de Manhat-

tan).

27

Distância geométrica

Consiste em determinar o menor valor de similaridade para encontrar o vizinho

mais próximo, por exemplo, considere os três casos, chamados A, B e C, onde o caso

A se refere ao caso atual.

Nessa medida calcula-se a distância de x e y para A. A distância x e y em relação

a A para o caso B é de 5 e 1, respectivamente, enquanto que a distância x e y entre

os casos A e C é 5 e 2, respectivamente.

Portanto:

Eixo A B CX - 5 5Y - 1 2

Tabela 2: Representação da distância geométrica.

• A distância de A ao caso B: d1 = x1 + y1 = 5+1 = 6;

• A distância de A ao caso C: d2 = x2 + y2 = 5+2 = 7.

Conclui-se então que o valor mais próximo de A é o caso B.

Nearest neighbour ponderado [Watson, 1999]

Semelhante a distância geométrica, porém utiliza o conceito de peso para cada

atributo. Por exemplo, podemos considerar que o modelo de um produto possui um

peso maior do que a cor do produto.

Portanto temos:

Eixo A B C Modelo CorX - 5 5 1 1Y - 1 2 1 0

Tabela 3: Representação nearest neighbour ponderado.

• A distância de A ao caso B: d1 = x1 ∗ p1 + y1 ∗ p2 = 5∗1+1∗1 = 6;

• A distância de A ao caso C: d2 = x2 ∗ p1 + y2 ∗ p2 = 5∗1+2∗0 = 5.

28

Conclui-se então que o valor mais próximo de A é o caso C.

A fórmula pode ser generalizada para:

sim(Q,C) =n

∑i=1

f (Qi,Ci)wi (2.1)

• Q = problema atual;

• C = caso recuperado da base;

• N = número de casos da base;

• F = similaridade local(a princípio utilizaremos F=1);

• W = peso.

Distância euclidiana

Dado um problema Q e um caso C representados por índices Q = (q1,q2, ...,qn) e

C = (c1,c2, ...,cn).

A distância euclidiana representa a real distância entre dois pontos em um espaço

qualquer e é dada por:

d(Q,C) =

√n

∑i=1

(qi− ci)2 (2.2)

Distância euclidiana ponderada

Inserindo pesos W, podemos estender a distância euclidiana para:

d(Q,C) =

√n

∑i=1

wi(qi− ci)2 (2.3)

29

Métrica do quarteirão (distância de Manhattan, distância pombalina ou distânciade taxi)

É uma medida neutra, avalia todas as diferenças de forma idêntica.

d(Q,C) =n

∑i=1|qi− ci| (2.4)

2.1.8 Medidas de similaridade local

Ao término do cálculo de similaridade global, pode haver a necessidade de um

cálculo mais preciso que atue sobre os atributos, essa medida de similaridade é de-

nominada similaridade local. A medida de similaridade deve ser definida em relação

Atributos Situação atual Caso 1 Valor similaridadeDescrição Carro, siena, prata Carro, siena 1Ano 2010 2009 0.9Cor Prata Preto 0.5Marca Fiat Fiat 1Modelo Siena Siena 1Preço R$ 35.125,00 R$

32.540,000.8

Tabela 4: Tabela de demonstração de similaridade local.

ao tipo específico de um tributo, tais como: número, símbolo binário, símbolo (orde-

nado, não-ordenado, taxonômico), conjunto, intervalo, string, dentre outros.

Número

Pode ser expressa pelo módulo da diferença entre valores, será utilizado o preço

do carro como exemplo: |preo1− preo2|.

Função escada

Se o caso é totalmente útil ou totalmente inútil, então a similaridade local deve ser

definida por meio de uma função escada.

• F(p1, p2) = 0;

• |p1− p2| ≥ S sendo ’S’ o ponto do degrau.

30

O preço dos carros poderá ser considerado igual quando sua diferença for menor

que R$ 350,00, e sua similaridade será 1, para valores maiores de R$ 350,00 será

considerado dissimilar e assumir o valor de similaridade igual a 0.

Tipo escalar

As medidas de similaridade para tipos numéricos possuem um problema como:

valores muito grandes têm o mesmo valor de similaridade que valores muito pequenos,

por exemplo: a similaridade de 30.120 e 30.110 é igual à similaridade de 10 e 20, isso

ocorre porque a distância é a mesma.

Ao atribuir valores diferentes de similaridade de acordo com o tamanho do valor, é

possível adotar uma escala logarítmica onde a similaridade de valores pequenos será

menor que a similaridade de valores grandes.

Strings

É aconselhável substituir strings por valores simbólicos, porém existem alguns en-

foques para cálculo da similaridade entre strings:

Correspondência exata: as strings serão consideradas similares se e somente

se forem escritas da mesma forma.

Correção ortográfica: grau de similaridade é expresso pegando-se o número de

caracteres iguais dividido pelo número total de caracteres da maior string, por exemplo,

"writeln"e "write", o grau de similaridade será 5/7=0.7.

Contagem de palavras: nesse caso conta-se o número de palavras idênticas, por

exemplo, "carro siena vermelho quatro portas"e "carro siena vermelho duas portas",

então o número de palavras idênticas é 4 e o número total de palavras da consulta é

5, logo a similaridade será 4/5= 0.8.

2.1.9 Recuperação de casos

Seu objetivo é encontrar um ou mais casos na base de conhecimento que seja si-

milar ao caso atual, ou seja, que pode ser útil à situação atual. Para isso, é necessário

casar a descrição do caso atual com os casos armazenados, baseando-se em uma

medida de similaridade. Esta seção irá detalhar a estrutura geral da recuperação de

31

casos.

O processo de recuperação pode ser formalmente descrito por um conjunto de

subtarefas que devem ser realizadas pelo sistema RBC, são estas: assessoramento

da situação, casamento e seleção.

O assessoramento da situação, mais complexa dentre as três subtarefas, utiliza

conhecimento e pode exigir uma iteração proativa com o usuário. O objetivo é en-

contrar os casos potencialmente úteis a situação atual, logo, é necessária utilizar a

situação atual como entrada para o processo de recuperação. Para isto, são utilizados

índices (características) que são relevantes para encontrar o caso adequado chama-

dos descritores de entrada.

Quando a primeira descrição da situação atual estiver incompleta, o assessora-

mento elabora índices relevantes para permitir a recuperação de casos adequados.

Neste contexto, a seleção de testes que deverão ser feitos é muito importante para

o ganho de informação potencial, aumentando as evidências associadas à situação

corrente. Este procedimento é chamado de Levantamento de Sintomas Dirigido.

O casamento de casos consiste em associar a descrição do caso atual com um

ou mais casos da base de casos de acordo com as medidas de similaridade.

Os algoritmos responsáveis por esta etapa da recuperação de casos podem ser

caros computacionalmente por necessitar da combinação de busca e comparação de

casos, no entanto existem deferentes técnicas de recuperação que podem ser apli-

cadas para tornar o processo mais ágil.

Qual técnica utilizar? Depende da estruturação da base de casos, índices e me-

didas de similaridade. A partir do conjunto de casos similares gerado pela etapa de

casamento, é realizada a escolha de um caso, considerado o mais similar.

Dentre as características da recuperação de casos, estão a qualidade da solução

gerada e a eficiência do processo de solução. Visando estes pontos, os conceitos de

matemáticos de correção e completeza da solução são aplicados.

Um método é considerado correto, se uma relação de similaridade definida pelo

método entre um caso e o problema atual também existe no conceito de similaridade

desenvolvido para a aplicação.

Um método é considerado completo, se toda relação de similaridade represen-

tada no modelo do sistema também se encontra no resultado deste método de recu-

32

peração.

Recuperação Sequencial

Técnica mais simples, onde a medida de similaridade é calculada sequencialmente

para todos os casos na base de casos. Permite a determinação dos ’m’ casos mais

similares. Vantagens:

• Comprovadamente completa e correta. Completa porque analisa todos os casos

da base, e correta porque aplica diretamente e na íntegra o conceito de similari-

dade definido pelo sistema a cada caso;

• Implementação simples;

• Aceita utilização de medidas de similaridade arbitrárias;

• Permite consultas ad-hoc independentes do conceito de similaridade. Desvan-

tagens:

• Performance fraca para bases de casos grandes;

• Esforço de recuperação constante, independente da complexidade e do número

de casos a serem recuperados;

• Esforço de recuperação não pode ser reduzido ou limitado por conhecimento

adicional.

TIPOS:1. Tipocaso = ...2. SimCaso = REGISTRO3. case: TipoCaso;4. similaridade: [0..1]5. FIM;

VARIAVEISListaCasoSim: VETOR[1..m] DE SimCasoCaseBase: ARRAY[1..n] DE TipoCaso (* base de casos *)Consulta: TipoCaso

Tabela 5: Estrutura de dados (Wangenheim, 2003).

Recuperação de dois níveis

Neste método, o princípio é reduzir ao máximo o número de comparações de ca-

sos por meio da aplicação de limitações adequadamente escolhidas à base de casos.

33

1. FUNÇÃO SelecRel(CaseBase, Consulta, m): ListaCasoSim2. INÍCIO3. ListaCasoSim[1..m].similaridade :=04. PARA 1:=1 TO n FAÇAi. SE sim(Consulta, CaseBase[i])>ListaCasoSim[m].similaridadeii. ENTÃO insira CaseBase[i] em ListaCasoSim

5. RETORNE ListaCasoSim6. FIM

Tabela 6: Algoritmo de recuperação seqüencial (Wangenheim, 2003).

Assim, são excluídos da comparação com a descrição do problema atual os casos

para os quais se podem determinar, com certeza, que não serão úteis para a solução

Isto significa que aqui serão aplicadas heurísticas para a redução do espaço debusca, para agilizar o processo de recuperação. Baseado no modelo MAC/FAC6, ométodo de recuperação de dois níveis funciona por meio dos seguintes processos:

1. Pré-seleção de possíveis candidatos;

2. Ordenação dos candidatos de acordo com o conceito de similaridade.

No primeiro passo, denominado passo-MAC, candidatos potenciais à solução são

determinados a partir do conjunto de todos os casos por meio de similaridades no

nível mais baixo da descrição sintática dos casos.

No segundo passo, denominado passo-FAC, os melhores candidatos são escolhi-

dos a partir do conjunto de casos pré-selecionados. Isto é realizado por meio de com-

parações mais complexas, com aplicação de análise estrutural dos casos ou mesmo

de todo o conceito de similaridade.

Figura 4: Modelo MAC/FAC (Wangenheim, 2003).

6Do inglês, Many Are Called; Few Are Chosen.

34

1. FUNÇÃO RestrigeBase(CaseBase, Consulta, m): ConjCasos2. INÍCIO3. ...4. RETORNE(ConjCasos)5. FIM

6. FUNÇÃO Selec2N(CaseBase, Consulta, m): ListaCasoSim7. INÍCIO8. RETORNE (SelecSeq(RestringeBase(CaseBase,Consulta,m),Consulta,m))9. FIM

Tabela 7: Algoritmo de recuperação de dois níveis (Wangenheim, 2003).

Este modelo pode ser facilmente mapeado em um banco de dados relacional. No

primeiro passo, uma série de consultas (que representam o predicado SIM()) recupera

o conjunto de candidatos potenciais. A medida de similaridade calculada por meio da

aplicação do conceito SIM() sobre cada informação pode ser usada como chave para

ordenação desta tabela.

A utilização deste método provê uma melhora de desempenho considerável, caso

o número de candidatos potenciais seja consideravelmente menor do que o total de

casos na base. A complexidade será equivalente a soma dos custos para aplicar a

pré-seleção a todos os casos da base mais os custos da determinação sequencial da

medida de similaridade para os casos selecionados no primeiro passo.

Esta melhoria na performance pode ter um preço: a possibilidade de erros de

recuperação. Estes possíveis erros são classificados em dois tipos:

• Erro α: um caso suficientemente similar à consulta não é selecionado no primeiro passo;

• Erro β : um caso que não é suficientemente similar à consulta é selecionado no primeiro

passo como candidato potencial.

Desta forma, a eficiência deste método fica por conta dos erros α e β , o erro α

influencia diretamente na eficiência do método, pois afeta a completeza do resultado.

Caso o erro β , se apresente em grande número, o desempenho do algoritmo é afetado,

pois casos irrelevantes aparecerão no conjunto de potenciais candidatos. Isto deve ser

controlado pela escolha do predicado de pré-seleção SIM().

Determinação de SIM()

Existem vários enfoques para se determinar a SIM(), dentre eles:

• Igualdade: todos os atributos de um caso correspondem aos atributos do caso em

questão;

35

• Igualdade parcial: pelo menos um atributo de um caso corresponde ao atributo do caso

em questão;

• Similaridade local: todos ou k atributos de um caso são similares aos atributos do caso

em questão;

• Similaridade local parcial: pelo menos um dos atributos de um caso é suficientemente

similar a um atributo do caso em questão;

Vantagens:

• Possível vantagem de performance;

• Correção do método;

• Custo de recuperação é variável;

• Utilização de conhecimento;

• Consultas ad-hoc são possíveis.

Desvantagens:

• Possibilidade de erros;

• Ganho em performance não é garantido;

• Difícil definição do predicado SIM().

Recuperação Orientada a Índices

Este método é executado em duas fases, primeiro seleciona os índices adequadosa serem utilizados, então efetua a recuperação baseada nestes índices:

1. Pré-processamento: todos os casos são analisados com base em critérios tomados a

partir da consulta e uma estrutura de índices para o acesso é gerada.

2. Recuperação: os casos mais similares são determinados a partir da estrutura de índices

gerada anteriormente.

A principal vantagem desse método é o ganho de performance devido à compara-

ção de casos durante a recuperação. É necessário atingir um equilíbrio entre custos

de recuperação de casos, complexidade de processamento e manutenção de uma

estrutura complexa de índices.

36

Figura 5: Princípio básico de métodos de recuperação orientados a índices.

Suas desvantagens são: custos de processamento elevados, o esforço de imple-

mentação e a não possibilidade de efetuar consultas ad-hoc.

Recuperação com árvores k-d

Na recuperação com árvores k-d, o espaço de busca é estruturado com base em

sua densidade observada, a recuperação então, é feita nesta estrutura.

1. Desça a árvore até uma folha2. Calcule a similaridade para os casos na folha3. Determine término4. Determine mais candidatosa. SE repositorios intersectam ENTAOb. Pesquise em ramos alternativos

5. Retorne a p.37. Pare se não há repositórios que intersectam

Tabela 8: Princípio da recuperação em árvores k-d [Wangenheim, 2003].

1. INÍCIO2. SE K é folha ENTÃO3. PARA cada caso F de K FAÇA4. SE sim(Q,F) > scq[m] ENTÃO5. Insira F em scq6. SENÃO (* nodo interno *)7. SE Ai é o atributo e vi o valor que rotulam K8. SE Q[Ai] ≤ vi ENTÃO9. recupere(K≤)10. SE Teste-EIL é verdade ENTÃO11. recupere(K>)12. SENÃO13. recupere(K>)14. SE Teste-EIL é verdade ENTÃO15. recupere(K≤)16. SE Teste-EDL é verdade ENTÃO17. Termine recuperação com scq18. FIM

Tabela 9: ALGORITMO recupere (K: árvore k-d) (Wangenheim, 2003).

Principais vantagens:

• Recuperação extremamente eficiente;

• Esforço de recuperação depende do número m de casos que se deseja recuperar;

37

• Extensão incremental se mais casos se tornarem disponíveis;

• Armazenamento dos casos em uma base de dados fácil de ser realizado.

Desvantagens:

• Esforço maior na criação da estrutura de índices da árvore k-d.

Redes de Recuperação de Casos

Os principais passos do processo de recuperação são:

1. Ativação das Eis dadas por meio do caso de recuperação;

2. Prorrogação dessa ativação de acordo com a similaridade por meio de toda a rede de

EI até que nodos de casos sejam alcançados;

3. Coleta da ativação adquirida nos nodos de caso associados, a qual reflete a similaridade

à consulta.

Formalmente, pode-se definir uma rede de recuperação de casos básica como

descrito abaixo:

N=[E, C, S, F, T) onde:. E é um conjunto finito de nodos EI;. C é um conjunto finito de nodos de casos;. S É uma medida de similaridade S: E x E→ R que descreve asimilaridade local S (e’, e”) entre duas EIs e’, e”;. F é uma função de relevância F: E x C→ R que descreve arelevância (peso) F(e,c) da EI e para o nodo de caso c;. T é o conjunto de funções de propagação tn: RE → Rpara cada nodo n ε E ∪ C.

Tabela 10: Rede de recuperação de casos (Wangenheim, 2003).

Vantagens:

• Representação de medidas de similaridade compostas;

• Capacidade de manipular consultas incompletas;

• Medidas de similaridade sensíveis a contexto;

• Recuperação eficiente;

• Recuperação completa;

• Recuperação e representação flexíveis de casos.

38

Desvantagens:

• Construção inicial requer custos computacionais altos;

• Sensível a inconsistências nos dados armazenados;

• Falta de nodos para atributos numéricos e muitos passos de propagação são necessários

se o grau de conectividade é alto e com muitas EI semelhantes.

Qual o melhor método?

O método que melhor irá se adaptar a uma aplicação dependerá dos seguintesaspectos:

• Representação de casos: casos se apresentam em uma estrutura fixa, pré-definida, ou

sem formato e pode variar de acordo com a situação do sistema;

• Estrutura de Base de casos: tamanho desta base, do conhecimento a ser aplicado ou a

eficiência que será necessária;

• Medida de similaridade: locais, globais ou até mesmo os dois tipos, dependendo da

situação.

2.1.10 Reutilizar

A partir de um caso armazenado na base, sua solução e os detalhes de como o

mesmo foi realizado são objetos que podem ser analisados para a solução de um novo

problema no sistema. O simples fato de se utilizar um caso armazenado caracteriza a

reutilização em sistemas de RBC.

O processo de reutilização se dá através da adaptação de soluções encontradas

de casos anteriores, que podem ser utilizadas na solução de novos casos, porém,

espera-se que esta adaptação não seja necessária, e sim, que o sistema possa en-

contrar uma solução em potencial para o problema apresentado.

Conforme [Wangenheim, 2003], ao invés de se adaptar um caso recuperado, pode-

se optar pela inclusão de uma grande quantidade de casos na base, possibilitando

uma solução garantida a todo problema apresentado no sistema. A principal dificul-

dade existente no processo de adaptação, está na definição de como realizá-la. A

39

adaptação pode ocorrer de forma automática, porém, devem-se levar em conside-

ração os seguintes detalhes: as diferenças entre os casos (atual e o passado) e que

detalhes do caso passado podem ser utilizados no caso atual.

Várias técnicas já foram pesquisadas e desenvolvidas para o processo automa-

tizado de adaptação. Conforme [Wangenheim, 2003], as estratégias de adaptações

são as seguintes:

• Adaptação nula;

• Adaptação transformacional;

– Adaptação substitucional;

– Adaptação estrutural;

• Adaptação gerativa/derivacional;

– Inicialização;

– One-shot replay ;

– Replay entrelaçado;

• Adaptação composicional;

• Adaptação hierárquica.

Em meio a essas técnicas, a questão é como utilizar a solução de um caso ar-

mazenado para o caso proposto. A solução se daria através da transferência completa

ou parcial do caso similar, ou utilizando fragmentos dos casos candidatos, gerando as-

sim uma solução com o conjunto de informações obtidas.

Estratégia de adaptação

Para tornar possível a adaptação automática de casos, as técnicas desenvolvidas

enfocam dois aspectos: as diferenças entre o caso passado (onde a solução é con-

hecida e deve ser adaptada) e o caso atual, e qual parte do caso recuperado pode ser

transferida para o caso novo. Com base nisto abordaremos a estratégia de adaptação

composicional que será utilizada neste projeto.

40

Adaptação composicional

Esta estratégia de adaptação consiste na combinação de vários componentes de

soluções aplicáveis, adaptados de vários casos anteriores, para a produção de uma

nova solução composta. Isto é possível se a solução consistir de diferentes partes

que possam ser adaptadas de forma mais ou menos independente. É muito efetiva

se houver poucos conflitos entre componentes, de forma que uma modificação em um

componente não possua efeitos colaterais em outras partes do caso.

O algoritmo de adaptação composicional consiste basicamente em:

• Recupere casos similares para a situação presente, que satisfaçam pelo menos

parcialmente os requisitos;

• Componha uma solução para a nova situação combinando partes destes casos;

• Resolva os conflitos.

2.1.11 Revisão de casos

Nesta seção é abordada as questões de aprendizado do sistema. Quando umcaso não correto é selecionado, há a necessidade de armazenar esta situação a fimde evitar possíveis erros no futuro. Da mesma forma, quando a solução gerada forconsiderada correta, o sistema deve “aprender” com o sucesso e reter o caso. Arevisão de casos consiste em duas tarefas:

• Avaliar a solução e fazer a retenção, no caso de sucesso;

• Caso contrário, reparar a solução com base no conhecimento específico ou informações

do usuário.

Primeiramente, a revisão se concentra em encontrar falhas nas soluções apre-

sentadas, considerando o resultado da aplicação destas soluções através de moni-

toração automática ou interação com o usuário. Em seguida, as falhas encontradas

são reparadas ou explicadas.

Quando uma explicação é dada para uma falha, significa que a solução em questão

não gera os resultados esperados, esta explicação então, é utilizada para modificar a

solução ou a forma como o sistema chegou à solução de maneira que o caso obtenha

sucesso e a falha não ocorra futuramente.

41

Quando uma falha é reparada, é recomendado que este reparo seja feito em pos-

síveis falhas similares, nos casos armazenados na base de casos.

“Um bom sistema RBC deve ser projetado de forma a oferecer uma interface para

captação de feedback sobre o resultado da aplicação da solução fornecida”[Wangenheim,

2003].

2.1.12 Reter

O objetivo é sempre reter o conhecimento, toda vez que um novo problema for

solucionado, a base de casos terá que ser estendida, agregando este novo caso de

sucesso à base de conhecimento.

A retenção automatizada de um novo caso em RBC pode ser mais complexa do

que apenas inserir um novo caso que obteve sucesso. Utilizam-se técnicas de Apren-

dizado de Máquina.

Neste capítulo abordaremos algumas filosofias de retenção de casos e técnicas

utilizadas em cada uma delas.

Tipos de retenção

• Sem retenção de casos: Geralmente aplicado onde se tem um domínio satis-

fatório do conhecimento necessário para a estruturação da aplicação. Neste

caso, a retenção de novos registros não se faz necessário, pois o mesmo não

contribuirá com a otimização na performance da aplicação.

• Retenção de soluções de problemas: Este tipo de retenção é a que caracteriza

de forma específica o aprendizado no RBC. Quando solucionado um problema,

o conhecimento a experiência é armazenada para ser utilizada como um auxiliar

nos novos problemas.

• Retenção de Documentos: Aqui a retenção ocorre separada ao processo de

solução de um problema. Sempre que disponibilizado um novo conhecimento

no sistema, seja através de documentos, descrições, ou qualquer outro tipo, o

processo de retenção é ativado.

42

Fases do processo de retenção

O processo de retenção pode ser refinado em três fases: extração de conheci-

mento, indexação de casos e integração na base de casos.

Extração de conhecimento

É a aquisição das informações necessárias para a estruturação de uma solução na

tomada de decisão. Esse novo conhecimento adquirido será integrado a um caso que

já exista na base, assim como, pode ser construído um novo caso. Trabalhos como

este que está sendo proposto, são áreas de estudos e pesquisas que vem sendo

realizadas dentro da extração de conhecimento.

As fontes para novas experiências podem ser:

• Para sistemas de retenção de solução problemas: A solução do problema, estru-

tura do caminho de solução, Representação do conhecimento usado, histórico de

adaptação de casos, protocolos de solução gerados pelo sistema, explicações e

justificativas.

• Para sistemas de retenção de documentos: documentos, manuais técnicos, des-

crições de produtos, base de dados online com resumos de conhecimento em

uma área.

Baseando-se na informação adquirida, um novo caso poderá ser; construído, inte-

grado em um caso existente ou um caso similar poderá ser generalizado para inserir

a nova experiência.

Para qualquer uma das situações citadas acima teremos que levantar o que deve

ser utilizado como fonte de aprendizado e como estruturar a nova experiência.

Indexação

É a fase que decide qual a melhor forma de indexar os casos para futuras recu-

perações. Uma solução para este problema seria utilizar todas as entidades como

índices.

43

Integração de Casos

Esta fase realiza a inclusão, exclusão ou modificação de casos na base. A in-

tegração pode realizar um ajuste nos índices existentes e nos pesos dos mesmos,

proporcionando o refinamento dos casos. O objetivo é que em consultas futuras a

recuperação dos casos venha a ser feita em uma base de casos atualizada.

Aprendizado Baseado em Casos

RBC implica em uma forma de aprendizado por analogia, em que, por meio da

transformação e extensão de conhecimento existente, uma tarefa ou problema similar

são executados ou removidos.

Algoritmos para aprendizados baseado em casos pertencem à classe de algorit-

mos de aprendizado de instâncias, os chamados Algoritmos-IBL7.

Algoritmos-IBL: Como Algoritmos Aprendem Simbolicamente

Sempre que um sistema altera seu conhecimento de forma constante, através da

adição de novos padrões, ou outro tipo de alteração, podemos falar de um processo de

aprendizado. Uma alteração do desempenho do sistema através da adição de novos

caos na base de casos é uma estratégia geralmente aceita e muito utilizada.

Algoritmos IBL aprendem a categorizar um conjunto de classes de objetos de

forma incremental com base em exemplos de instâncias dessas categorias.

Componentes Algoritmos IBL

Segundo [Wangenheim, 2003] existem três componentes presentes em todas as

classes de algoritmos-IBL:

• Função de Similaridade: Computa a similaridade entre uma instância de treina-

mento i e as instâncias em uma dada descrição conceitual.

• Função de Classificação: Recebe o resultado da "Função de Similaridade"e

provê uma classificação para i.7Do inglês, Instance-Based Learning

44

• Atualizador do descritor conceitual: Decidir quais instâncias incluir na des-

crição conceitual.

As funções de similaridade e classificação têm o objetivo de determinar como o

conjunto de instâncias salvas na descrição conceitual será utilizado para predizer va-

lores para o atributo de categoria. Descrições conceituais IBL contêm, portanto, além

do conjunto de instâncias, também estas duas funções.

Dimensões de Performance

De acordo com [Wangenheim, 2003], para supervisionar o desempenho de algo-

ritmos de aprendizado usamos as cinco seguintes dimensões:

• Generalidade: Representa as classes de conceito que podem ser aprendidos e

descritos pelo algoritmo em questão. IBL é capaz de aprender quaisquer con-

ceitos cujos limites sejam dados pela união de um número finito de hipercurvas

fechadas de tamanho finito.

• Acurácia: É a acurácia da classificação provida pela descrição conceitual.

• Taxa de Aprendizado: É a velocidade com a qual a acurácia classificatória

aumenta durante o aprendizado.

• Custos de Incorporação: Custos que decorrem da atualização da descrição

conceitual por meio da inclusão de uma instância única.

• Requisitos de Armazenamento: Tamanho da descrição conceitual, que em

algoritmos-IBL é definida com o número de instâncias que necessitam ser salvas

para prover uma performace classificatória adequada.

Algoritmo IBL1

O algoritmo IBL1 é o mais simples algoritmo de aprendizado baseado em instân-

cias. A função de similaridade é a seguinte:

sim(x,y) = −n

∑i=1

f (xi,yi) (2.5)

45

Onde os casos são descritos através de n entidades. Definimos f (xi,yi) = (xi,yi)2

para entidades de valor numérico, e f (xi,yi) = (xi14yi) para entidades booleanas e de

valor simbólico ou textual (Wangenheim, 2003).

Entidades ausentes são consideradas como sendo maximamente diferentes do

valor presente. Se ambos faltam, então vale f (xi,yi) = 1.

De acordo com [Wangenheim, 2003], o algoritmo IBL1 é capaz de processar

padrões de forma incremental, e possui uma política simples para lidar com valores

desconhecidos.

As funções de similaridade e de classificação de IBL1 provêem uma descrição con-

ceitual extensiva a partir do conjunto de padrões salvos. IBL1 possui um desempenho

relativamente bom, mas realiza um número desnecessário de cálculos de similaridade

durante a predição.

Figura 6: Algoritmo 1 - IBL1 [Wangenheim, 2003].

46

2.2 Framework Java Server Faces - FSF

Segundo [Geary, 2007] Java Server Faces ou simplesmente JSF, é uma tecnologia

para desenvolvimento web que utiliza um modelo de interfaces gráficas baseado em

eventos. Esta tecnologia foi definida pelo JCP (Java Community Process), o que a

torna um padrão de desenvolvimento.

JSF tem como base o padrão MVC (Model-View-Controller ), o que diminui a com-

plexidade do desenvolvimento dos sistemas, garantindo que a separação entre visu-

alização e regras de negócio seja clara.

Em JSF, o controle é feito através de um servlet8 chamado Faces Servlet, por

aquivos XML9 de configuração e por vários manipuladores de ações e observadores

de eventos. O Faces Servlet recebe as requisições dos usuários na web, redireciona

para o modelo e envia uma resposta. Os arquivos de configuração possuem infor-

mações sobre mapeamentos de ações e regras de navegação. Os manipuladores de

eventos são responsáveis por receber os dados da camada de visualização, acessar o

modelo e devolver o resultado para o usuário através do Faces Servlet, [Bauer, 2007].

O modelo é representado por objetos de negócio, que executa uma lógica ao re-

ceber dados vindos da camada de visualização.

A visualização é composta por uma hierarquia de componentes (component tree),

o que torna possível a construção de interfaces mais ricas e complexas.

2.3 Prime Faces

PrimeFaces é um conjunto de componentes de código aberto para JSF com mais

de 90 componentes. Essa tecnologia é mantida pela Prime Technology (Empresa de

desenvolvimento de software).

Com PrimeFaces, é possível criar interfaces ricas com componentes interativos e

amigaveis, além de permitir a utilização dos conceitos de Ajax10 de forma eficaz e

eficiente.8Servlet é um componente do lado servidor que gera dados HTML e XML para a camada de apre-

sentação de um aplicativo Web.9eXtensible Markup Language), linguagens de marcação para necessidades especiais.

10Do inglês, Asynchronous Javascript And XML

47

2.3.1 Ciclo de vida

A Figura 7 apresenta o ciclo de vida do JSF.

Figura 7: Ciclo de vida - JSF.

Fase 1 - Recuperar a tela (Restore view )

Nesta fase o request vem através do Controller do FacesContext11. O Controller

examina o request e extrai dele o identificador da visão que é determinado pelo nome

da página JSP12 ou XHTML13. É através dessa identificação que o framework do JSF

localiza os componentes para a tela atual. Se a visão ainda não existe, ela será criada,

caso contrário a visão será apenas reutilizada pelo Controller.

Fase 2 - Aplicar valores da requisição (Apply Request Values)

O propósito dessa fase é fazer com que cada componente recupere seu estado

corrente. O componente deve primeiro ser criado ou recuperado a partir do FacesCon-

11Arquivo de configuração do JSF12Do inglês, Java Server Pages13Do inglês, eXtensible Hypertext Markup Language

48

text, seguido por seus valores. Os valores dos componentes são geralmente recuper-

ados por parâmetros de request, no entanto eles podem ser recuperados dos cabeça-

lhos ou cookies14 gerados.

Fase 3 - Processo de validação (Process Validation)

É nessa fase que ocorrem as validações. Esta validação pode ser criada pelo de-

senvolvedor ou obtida diretamente do JSF. Os valores são validados de acordo com as

regras de validação da aplicação. Se um valor estiver errado é gerado uma mensagem

de erro e adicionada no FacesContext e o componente é marcado como inválido.

Fase 4 - Atualização dos valores no modelo (Update Model Values)

Esta é a fase onde é atualizado o valor no lado do servidor, atualizando a pro-

priedade dentro do seu Backing Bean. Somente as propriedades que estão sendo

manipuladas no componente é que serão atualizadas. Note que esta fase só irá acon-

tecer após a fase de validação, o que lhe garante que os dados que estão indo para

o Bean sejam válidos a nível de tela pois os mesmos poderão ser inválidos a nível de

regras de negócio de sua aplicação.

Fase 5 - Invocar a aplicação (Invoke Application)

Nesta fase o Controller do JSF invoca a aplicação para manipular o envio do form.

O valor do componente sempre estará convertido, validado e aplicado aos objetos de

modelo, e então aplicando as regras de negócio.

Fase 6 - Renderizar resposta (Render Response)

Esta fase irá exibir a tela com todos os componentes em seu estado atual.

2.3.2 Faces Config (algaworks)

Para instanciar um managed bean e determinar seu escopo, utiliza-se um ar-

quivo de configuração XML. Este arquivo é processado quando a aplicação é inici-

14Grupo de dados trocados entre o navegador e o servidor de páginas, colocado num arquivo(ficheiro) de texto criado no computador do usuário.

49

ada. Quando uma página referencia um bean, a implementação do JSF o inicializa de

acordo com as configurações contidas neste arquivo.

Na versão 2.0 do JSF o arquivo faces-config.xml é utilizado opcionalmente para

criar regras de navegação, e basicamente para declarar PhaseListener15.

2.3.3 Backing beans

Em algumas ocasiões, o bean pode precisar ter acesso aos componentes da

página JSF ou XHTML. O acesso direto aos componentes é diferente do acesso aos

valores. Este acesso dá a possibilidade de inspecionar e até modificar propriedades

do componente que está sendo renderizado para o usuário, que as vezes pode até

não estar disponível como um atributo da tag JFS.

Para esta ligação entre os componentes da página e propriedades de beans, pre-

cisamos criar um backing bean. Um bean deste tipo é igual ao managed bean. A única

diferença é que ele, além de fazer li-gações de valor, pode também fazer ligação de

componentes, porém a forma de configurá-lo no arquivo "faces-config.xml"é a mesma.

2.4 Java Persistence API - JPA

Segundo [Magazine , 2010] JPA é um framework utilizado na camada de per-

sistência com intuito de trazer uma maior produtividade, com impacto principal na

forma como é controlada a persistência dos dados dentro do Java.

O Java Persistence API - JPA define um caminho para mapear Plain Old Java

Objects POJOs para um banco de dados, estes POJOs são chamados de beans de

entidade. Beans de Entidades são como qualquer outra classe Java, exceto que este

tem que ser mapeado usando Java Persistence Metadata, para um banco de dados.

A Figura 8 apresenta a estrutura do JPA.

2.5 Plataforma de Desenvolvimento Java

Segundo [Sun, 2003] Java é uma linguagem de programação orientada a ob-

jeto desenvolvida na década de 90 por uma equipe de programadores chefiada por

15Interface que permite monitorar todas as fases do ciclo de vida da aplicação

50

Figura 8: Estrutura do JPA.

James Gosling, na empresa Sun Microsystems. Diferentemente das linguagens con-

vencionais, que são compiladas para código nativo, a linguagem Java é compilada

para um bytecode16 que é executado por uma máquina virtual. A linguagem de pro-

gramação Java é a linguagem convencional da Plataforma Java, mas não sua única

linguagem.

2.5.1 Padronização

Em 1997 a Sun Microsystems tentou submeter a linguagem a padronização pelos

órgãos ISO/IEC e ECMA, mas acabou desistindo. Java ainda é um padrão de fato,

que é controlada através da Java Community Process (JCP). Em 13 de Novembro de

2006, a Sun lançou a maior parte do Java como software livre sob os termos da GNU

- General Public License (GPL). Em 8 de Maio de 2007 a Sun finalizou o processo,

tornando praticamente todo o código Java como software de código aberto, menos

uma pequena porção da qual a Sun não possui direitos autorais, [Sun, 2003].

2.5.2 Principais Características

Linguagem Java foi projetada tendo em vista os seguintes objetivos:

16Resultado de um processo semelhante ao dos compiladores de código-fonte que não é imediata-mente executável.

51

• Orientação a objetos;

• Portabilidade - Independência de plataforma;

• Recursos de Rede - Possui extensa biblioteca de rotinas que facilitam a coope-

ração com protocolos TCP/IP, como HTTP e FTP;

• Segurança - Pode executar programas via rede com restrições de execução;

• Sintaxe similar a C/C++;

• Facilidades de Internacionalização - Suporta nativamente caracteres Unicode;

• Simplicidade na especificação, tanto da linguagem como do "ambiente"de exe-

cução (JVM17);

• É distribuída com um vasto conjunto de bibliotecas (ou APIs);

• Possui facilidades para criação de programas distribuídos e multitarefa (múltiplas

linhas de execução num mesmo programa);

• Carga Dinâmica de Código - Programas em Java são formados por uma coleção

de classes armazenadas independentemente e que podem ser carregadas no

momento de utilização.

2.5.3 Máquina Virtual Java

Máquina virtual Java (JVM18) é um programa que carrega e executa os aplica-

tivos Java, convertendo os bytecodes em código executável de máquina. A JVM é

responsável pelo gerenciamento dos aplicativos, à medida que são executados.

Graças à máquina virtual Java, os programas escritos em Java podem funcionar

em qualquer plataforma de hardware e software que possua uma versão da JVM,

tornando assim essas aplicações independentes da plataforma onde funcionam.

17JVM, do inglês Java Virtual Machine18Do inglês, Java Virtual Machine - JVM

52

3 Estudo de viabilidade

A característica principal dos empreendedores é sua obstinação em gerar novos

negócios e produtos. O estudo de viabilidade engloba dois aspectos: um aspecto

relacionado com as questões estritamente econômicas e, outro, que implica em definir

as relações que as pessoas envolvidas no projeto vão estabelecer entre si, porém

somente a primeira será abordada.

3.1 Oportunidades

• Empresas que utilizem da internet como forma de vendas online (e-commerce);

• Empresas que ofereçam suporte online;

• Hospitais (como no auxilio a um médico a descobrir qual doença um paciente

possui);

• Marketing (sistema seria capaz de conversar sobre a empresa);

• Educação à distância;

• Restaurante (garçom virtual);

• Facilidade para os visitantes de um site encontrarem informações (basta per-

guntar, ao invés de precisar navegar por todo o site e ler grandes quantidades

de texto);

• A navegação torna-se mais excitante, estimulando os visitantes a conhecerem

melhor outras áreas do site.

3.2 Ameaças

Desconfiança das pessoas em acreditar em uma máquina, que dê:

53

• Sugestões;

• Soluções.

3.3 Fraquezas

Falta de motivação da equipe devido à complexidade da aplicação, para criar uma

solução que realmente seja útil para o usuário o RBC deve ser utilizando juntamente

com outros conceitos de IA, tais como:

• Linguagem natural;

• Reconhecimento de padrões;

• Raciocínio baseado em casos;

• Análise sintática, semântica, morfológica;

• Sistemas especialistas.

3.4 Forças

• Softwares utilizados são todos livres;

• Grande número de artigos, trabalhos e projetos científicos que podem ser utiliza-

dos como suporte;

• Não há necessidade de equipamentos caros, computadores domésticos são o

suficiente para o desenvolvimento.

3.5 Mercado potêncial

• Em 24 de junho de 2009 o Brasil tinha 1,59 milhões de varejistas [voltados ao

consumidor final];

• 15,2 milhões de pessoas que já tiveram pelo menos uma experiência de compra

pela internet;

54

• Mais de 86 % dos consumidores estão satisfeitos com o comércio eletrônico:

fruto da credibilidade que vem aumentando, comodidade, parcelamento, varias

formas de pagamento e frete grátis.

3.6 Benefícios

• Aumentar o efetivo de compras;

• Mantém o usuário focado no produto;

• Sistema se mantém focado no cliente;

• Sistema oferece o produto mais adequado ao cliente.

55

4 Levantamento de Requisitos

Para desenvolvimento do trabalho foi feito o levantamento dos requisitos e análise

das funcionalidades seguindo metodologias sólidas de engenharia de software, definindo

as características que o sistema deve ter.

4.1 Requisitos Funcionais do Software

Serão apresentados as principais características deste software no que diz res-

peito a sua camada de negócios, detalhando as funcionalidades que atingem direta-

mente a espectativa dos usuários, que no caso, são clientes que utilizam o ambiente

web para realizar suas compras.

O sistema irá interagir com uma base de dados que será alimentada pela própria

aplicação, aplicando o conceito de aprendizagem de máquina, que permite a possibi-

lidade de uma máquina aprender sem a interação do homem.

Os principais requisitos funcionais são apresentados a seguir:

• Possibilidade de realizar uma consulta personalizada;

• Vendedor Interativo;

• Listar casos similares;

• Possbilidade de realizar a venda do produto oferecido;

• Possibilidade de alterar atributos do produto apresentado;

• Possibilidade de cadastrar-se no sistema.

A opção da consulta personalizada visa aplicar o conceito de recuperação e reuti-

lização do ciclo de vida do RBC, onde é recuperado uma lista de casos mais similares

56

ao caso atual e adaptado ao perfil do cliente corrente, apresentando o produto que

seja o mais similar a seu perfil.

A opção do vendedor interativo visa inserir a figura de um vendedor em um ambi-

ente web, para que a interação com o cliente aproxime-se da forma como é feita em

lojas convencionais.

A opção listar casos similares deverá listar os casos recuperados da base de con-

hecimento que são os mais similares ao perfil do cliente.

A opção realizar a venda visa vender o produto oferecido além de reter a venda na

base de dados como um novo caso de sucesso.

A opção de alterar atributos visa revisar o produto oferecido ao cliente, para que

o sistema possa reter um caso de forma coerente, e em uma próxima consulta, apre-

sentar o produto mais similar ao perfil do cliente com uma acurácia ainda maior.

A opção de cadastro deverá inserir na base de dados um novo cliente.

4.2 Casos de Uso

Um caso de uso é uma técnica de modelagem usada para descrever o que um

novo sistema deve fazer. Ele é construído através de um processo interativo no qual

as discurssões entre o cliente e os desenvolvedores do sistema conduzem a uma

especificação do sistema da qual todos estão de acordo.

Os casos de uso têm por objetivo:

• Decidir e descrever os requisitos funcionais do sistema;

• Fornecer uma descrição clara e consistente do que o sistema deve fazer;

• Permitir descobrir os requisitos funcionais das classes e operações do sistema.

A Unified Modeling Language (UML1) será utilizada para demonstrar as modela-

gens do sistema, para uma melhor compreensão de suas funções e e características.

Na UML o modelo de casos de uso consiste de diagramas que mostram os atores,

os casos de uso e seus relacionamentos.1É uma linguagem de modelagem não proprietária de terceira geração, permitindo que desenvolve-

dores visualizem os produtos de seus trabalhos em diagramas padronizados.

57

Na Figura 9 temos o diagrama de casos de uso da aplicação. Observe que temos a

projeção dos requisitos funcionais da aplicação de forma clara e de fácil compreensão

de nossos fornecedores de requisitos.

Figura 9: Diagrama de Casos de Uso.

4.3 Descrição do Ator

Cliente Web: É responsável por cadastrar-se no sistema, realizar a consulta per-

sonalizada e realizar a compra do produto oferecido pelo sistema.

4.4 Descrição dos Casos de Uso

A descrição dos casos de usos apresenta uma forma simples de expor as fun-

cionalidades de um sistema computacional, assim como o diagrama de casos de uso

da UML, concedendo ao cliente a oportunidade de ter maior grau de certeza e com-

preensão ao validar as funções desejadas por ele para um sistema de informação.

Também permite um melhor aproveitamento de tempo nas fases de projeto, imple-

58

mentação e testes visto que as regras de negócio estarão sempre à disposição da

equipe desenvolvedora através dos documentos específicos de cada caso de uso.

Segue a descrição dos casos de uso vistos no diagrama apresentado na Tabela

11, 12 e 13, conforme a seguinte ordem:

• CSU01 - Cadastrar Cliente.

• CSU02 - Consultar Produto - RBC;

• CSU03 - Compra produto;

CSU01 - Cadastrar ClienteSumário: Ator realiza o cadastro do cliente.Ator: Cliente WebPré-Condições: Cliente Web deverá estar no ambiente do sistema.Risco: Alto Prioridade: Alto1.1. Fluxo Básico: Cadastrar Cliente1.1.1. Este caso de uso inicia quando o ator opta por cadastrar-se no sistema1.1.2. O sistema solicita seus dados1.1.3. O ator informa seus dados e confirma o cadastro (#E1)1.1.4. O sistema exibe mensagem de sucesso1.1.5. O ator confirma a mensagem1.1.6. O caso de uso se encerra.1.3 Fluxos Exceções1.3.1. (#E1) - Dados Obrigatórios1.3.1.1. Caso os dados obrigatórios não sejam fornecidos, é emitida uma mensagem de erroinformando a falha e solicitando os dados1.3.1.2. Retornar ao ponto de entrada de dados.

Tabela 11: Descrição dos casos de uso Cadastrar Cliente.

59

CSU02 - Consultar Produto RBCSumário: Ator realiza a manutenção compra de um produto personalizado.Ator: Cliente WebPré-Condições: Cliente Web deverá estar cadastrado no ambiente do sistema.Risco: Alto Prioridade: Alto1.1. Fluxo Básico: Comprar Produto1.1.1. Este caso de uso inicia quando o ator opta por consultar um novo produto1.1.2. O sistema solicita que o ator faça o login1.1.3. O ator informa o usuário e senha (#E1)1.1.4. O sistema exibe mensagem de sucesso1.1.5. O ator consulta um produto personalizado (#A1)1.1.6. O sistema exibe o produto mais similar ao perfil do usuário1.1.7. O caso de uso se encerra.1.2. Fluxos Alternativos1.2.1. (#A1) - Recuperaçã e Adaptação do caso atual1.2.1.1. O sistema faz a validação do usuário logado no sistema (#E2)1.2.1.2. O sistema aplica a similaridade e recupera os casos mais similares da base de casos1.2.1.2. O sistema reutiliza os casos mais similares, adaptando ao caso atual1.2.1.3. O sistema exibe o caso atual com as informações do produto1.2.1.4. O sistema retorna uma mensagem de sucesso na recuperação e adaptação do caso1.2.1.5. Este caso de uso se encerra.1.3 Fluxos Exceções1.3.1. (#E1) - Dados Obrigatórios1.3.1.1. Caso os dados obrigatórios não sejam fornecidos, é emitida uma mensagem de erro informando a falha e solicitando osdados1.3.1.2. Retornar ao ponto de entrada de dados.

Tabela 12: Descrição dos casos de uso Consultar Produto - RBC e Realizar Compra.

60

CSU01 - Comprar ProdutoSumário: Ator realiza a manutenção compra de um produto personalizado.Ator: Cliente WebPré-Condições: Cliente Web deverá estar cadastrado no ambiente do sistema.Risco: Alto Prioridade: Alto1.1. Fluxo Básico: Comprar Produto1.1.1. Este caso de uso inicia quando o ator opta por comprar o produto sugerido pelo sistema1.1.2. O vendedor on-line (Sistema) pergunta se o ator gostou do produto sugerido (#A1) (#A2) (#A3)1.1.3. O ator confirma compra1.1.4. O sistema gera o código do Produto automaticamente1.1.5. O sistema retorna uma mensagem de sucesso1.1.6. O ator confirma a mensagem1.1.7. O caso de uso se encerra.1.2. Fluxos Alternativos1.2.1. (#A1) - Revisar Modelo1.2.1.1. O ator informa que não gostou do produto sugerido pelo sistema1.2.1.2. O sistema percorre a árvore-KD e busca o caso mais similar diferente do caso atual1.2.1.2. O sistema exibe o caso mais similar ao ator1.2.1.3. O ator e confirma a revisão1.2.1.4. O sistema retorna uma mensagem de sucesso1.2.1.5. O ator confirma a mensagem1.2.1.6. Este caso de uso se encerra.1.2.2. (#A2) - Revisar Atributos1.2.2.1. O ator informa que gostaria de revisar os atributos1.2.2.2. O sistema informa as opções1.2.2.3. O ator seleciona as opções e confirma a revisão1.2.2.4. O sistema retorna uma mensagem de sucesso1.2.2.5. O ator confirma a mensagem1.2.2.6. Este caso de uso se encerra.1.2.3. (#A3) - Comprar1.2.3.1. O ator informa que gostou do produto sugerido1.2.3.2. O sistema solicita o numero de parcelar da compra1.2.3.3. O ator confirma a solicitação do pedido1.2.3.4. O sistema retorna uma mensagem de sucesso1.2.3.5. O ator confirma a mensagem1.2.3.6. Este caso de uso se encerra.1.3 Fluxos Exceções1.3.1. (#E1) - Dados Obrigatórios1.3.1.1. Caso os dados obrigatórios não sejam fornecidos, é emitida uma mensagem de erro informando a falha e solicitando osdados

Tabela 13: Descrição dos casos de uso Consultar Produto - RBC e Realizar Compra.

4.5 Requisitos Não-Funcionais

A observação de alguns pontos importantes, se faz necessária, no que diz respeito

aos requisitos mínimos de hardware para a correta execução do programa.

• NF01 - CPF válido: O sistema só permitirá CPF válidos;

• NF02 - Identificação do cliente: O usuário deverá estar logado para realizar a

consulta personalizada;

• NF03 - Número de produtos listados: O sistema só permitirá um produto listado

para o caso adaptado e 30 produtos para a lista de casos mais similares;

• NF04 - Tipo de interface: Sistema Web;

61

• NF05 - Armazenamento de dados: SGBD centralizado e Base de Casos;

• NF06 - Perfis de usuários: Cliente Web.

Requisitos Não-FuncionaisNome Categoria Desejável PermanenteNF01 - CPF válido Segurança X XNF02 - Identificação do cliente Segurança X XNF03 - Número de produtos listados Interface X XNF04 - Tipo de interface Interface X XNF05 - Armazenamento de dados Persistência X XNF06 - Perfis de usuários Segurança X X

Tabela 14: Requisitos Não-Funcionais.

62

5 Especificação de Análise

Na fase de análise, o objetivo maior é o de estudar os requistos do sistema de tal

forma, que leve o analista (por meio de decomposições) à compreensão e ao entendi-

mento de como o sistema analisado funciona.

5.1 Diagrama de Classes

De posse da visão dos casos de uso, o que se vê na Figura 10, revela os objetos

do domínio do problema e suas relações de forma a produzirem os resultados visíveis.

Figura 10: Diagrama do Domínio do Problema.

Algumas observações importantes para o diagrama apresentado são necessárias.

No diagrama de classes temos a classe Cliente, que estará associada à classe carro

através da classe venda, que é a classe que representa o caso para o contexto do

63

sistema, onde um cliente poderá comprar um ou vários carros e um carro somente

possuirá um único cliente como dono. Também é apresentado a classe Endereço

que está associada a classe Cliente, onde um cliente somente possuirá apenas um

endereço e um endereço estará associado a um ou vários clientes.

Os métodos de cada classe, serão apresentados no projeto de software.

5.2 Dicionário de Dados

Segundo [Pressman, 2002], um dicionário de dados nada mais é do que uma

coleção de todos os elementos de dados que são pertinentes para um sistema. A

seguir vemos a descrição desses elementos:

Cliente (Representa todos os clientes cadastrados no sistema.)endereco: *Objeto endereço, possui os dados de endereço do cliente* Endereçonome: *Nome do cliente* Textocpf: *CPF do cliente* TextograuEscolar: *O grau escolar do cliente* TextoclasseSocial: *A classe social do cliente* TextoestadoCivil: *O estado civil do cliente* Textohobby: *O hobby do cliente* Textoestilo: *O estilo do cliente* TextonumeroTel: *O número do telefone do cliente* TextonumeroCel: *O número do celular do cliente* Textofilhos: *O número de filhos que o cliente possui* Dígitologin: *O nome de usuário do cliente* Textosenha: *A senha do cliente* TextoconfSenha: *A senha de confirmação do cliente* Textosimilaridade: *Valor da similaridade local calculada na recuperação deste objeto cliente* Pontoflutuante

Tabela 15: Classe Cliente.

Endereço (Representa todos os endereços cadastrados no sistema.)cep: *Número de CEP da localidade* Textopais: *Nome do país* Textoestado: *Nome do estado* Textocidade: *Nome da cidade* Textobairro: *Nome do bairro* Textorua: *Nome da rua* Textonumero: *Número da residência* Textoreferencia: *Descrição do Ponto de referência* Texto

Tabela 16: Classe Endereço.

64

Carro (Representa os carros do sistema.)modelo: *Modelo do carro* Textoano: *Ano do carro* Dígitomarca: *Marca do carro* Textocategoria: *Categoria do carro* Textocor: *Cor do carro* Textopreco: *Preço do carro* Ponto flutuantepotencia: *Potência do carro* Ponto flutuantesimilaridade: *Valor da similaridade local calculada na recuperação deste objeto carro* Pontoflutuante

Tabela 17: Classe Carro.

Venda (Representa os casos da Base de casos.)id: *Identificação da venda* Dígitocarro: *Objeto carro, carro que foi vendido* Carrocliente: *Objeto cliente, Cliente que realizou a compra* ClientedataVenda: *Data em que a venda foi realizada* DatavalorVenda: *Valor total da venda* Ponto flutuantenumeroParcelas: *Número de parcelas* Dígitosimilaridade: *Valor da similaridade local calculada na recuperação deste objeto venda* Pontoflutuanteglobal: *Valor da similaridade global calculada na recuperação deste caso venda* Ponto flutu-ante

Tabela 18: Caso Venda.

5.3 Modelagem de Interações

O princípio da interação entre objetos é o conceito de mensagem. Uma mensagem

é uma solicitação de execução de uma operação em outro objeto.

A interação entre objetos para dar suporte à funcionalidade de um caso de uso

denomina-se realização de um caso [BEZERRA, 2004]. A realização de um caso de

uso descreve o comportamento de um ponto de vista interno ao sistema. As Figuras

11 e 12 mostram através do diagramas de sequência, a interação existente entre os

objetos de modo a permitir a realização dos casos de uso, assim como a visualização

da lógica dos cenários de casos de uso.

65

Figura 11: Diagrama de Sequência CSU02: Consultar Produto RBC.

66

Figura 12: Diagrama de Sequência CSU03: Comprar Produto.

5.4 Transição de Estados

Um objeto muda de estado quando acontece algum evento interno ou externo ao

sistema. Quando um objeto muda de um estado para outro, diz-se que ele realizou

uma transição entre estados. Os estados e as transições de estados de um objeto

constituem o seu ciclo de vida [BEZERRA, 2004].

Quando transita de um estado para outro, um objeto normalmente realiza determi-

nadas ações dentro do sistema.

A classe "ManageRBC"apresenta os seguintes estados durante a execução da

aplicação. Observe na Figura 13 o seu comportamento.

Este objeto possui as regras do ciclo de vida da aplicação RBC, chamando as

classes Recuperar.java, Reutilizar.java, Revisar.java e Reter.java para a construção e

retenção de um novo caso de sucesso na base de casos.

67

Figura 13: Diagrama de Estados - Objeto ManageRBC.

68

6 Projeto de software

A tecnologia escolhida para a implementação deste projeto, proposta oferecida

pela Sun MicroSystems, é a plataforma Java. Mais precisamente o framework MVC1

JavaServer Faces - JSF para desenvolvimento de aplicações web. Por ser uma tec-

nologia aberta e gratuita, esta se tornou a escolha de implementação mais viável.

6.1 Arquitetura do sistema

Devido a complexidade do sistema a ser desenvolvido e devido a preocupação

de garantir a alta coesão e o baixo acoplamento a arquitetura MVC seria um bom

ponto de partida, contudo, ela desconsidera o componente de maior prioridade para

os Sistemas de Raciocínio Baseado em Casos: a gerência de dados.

Pelo motivo citado o sistema é desenvolvido baseado em uma arquitetura centrada

no conceito de implementação em camadas, seguindo a arquitetura MVC estendida.

Esse modelo é a evolução do modelo MVC e considera quatro componentes básicos

que são:

• Componente de domínio do problema (Model);

• Componente de interação humana (View);

• Componente de gerência de tarefas (Controller );

• Componente de gerência de dados (DAO2).

No padrão MVC estendido existem funções/objetivos/escopos diferentes para o

1Model-view-controller. É um padrão de arquitetura de software que visa a separar a lógica de negó-cio da lógica de apresentação, permitindo o desenvolvimento, teste e manutenção isolado de ambos.

2É um padrão para persistência de dados que permite separar regras de negócio das regras deacesso a banco de dados.

69

Modelo, Visão, Controle e Data Access Object (DAO), onde cada um destes pode ser

alterado separadamente, sem interferir/intervir na área de atuação do outro.

Para uma melhor estruturação do sistema e com objetivo de facilitar a adição de

novos módulos, bem como, melhorar sua manutenção o modelo MVC estendido será

acrescido de outras camadas tais como: façade e business object.

Assim, podemos apresentar essas "camadas"e classifica-las da seguinte maneira:

Modelo (Model): Na arquitetura MVC estendida o modelo corresponde aos sub-

sistemas responsáveis por controlar e coordenar tarefas (Casos de uso). Não possui

as regras de negocio, sua implementação é composta por métodos get/set.

Visualização (View): Tem como responsabilidade permitir o acesso aos dados do

modelo via controlador além de definir como esses dados devem ser apresentados.

Essa camada é responsável únicamente pela exibição dos dados ao usuário final do

sistema.

Controle (Controller ): Define o comportamento da aplicação e é ele que interpreta

as ações do usuário e as mapeia para chamadas do DAO e do BO. É também o único

responsável por tratar as exceções do sistema.

Objeto de acesso a dados - DAO (Data Acess Object): Corresponde aos subsis-

temas responsáveis pelo armazenamento e recuperação de objetos (Persistência dos

Objetos).

Objeto de negócio - BO (Business Object): Classe espelho do modelo que contém

somente as regras de negócio (Objeto de Negócio).

Fachada (Façade): Sua finalidade é provêr uma interface facilitando assim o acesso

a um conjunto de classes.

Tanto a framework que é responsável por realizar o ciclo de vida do RBC como

a aplicação web que é responsável por exibir e interagir com o usuário, foram desen-

volvidos tendo como premissa o modelo MVC.

Pode-se afirmar, portanto, que a arquitetura MVC estendida fornece uma maneira

de dividir as funcionalidades envolvidas na manutenção e apresentação dos dados de

uma aplicação, facilitando assim o mapeamento desses conceitos nos domínios dos

sistemas desenvolvidos.

70

6.2 Distribuição dos Pacotes

Os pacotes estão distribuídos de acordo com o padrão MVC, possibilitando uma

separação lógica de tarefas desempenhadas pelo sistema como um todo, bastando

que os pacotes utilizados apenas apresentem uma interface de acesso. A Figura 14,

mostra a distribuição de pacotes da aplicação.

Figura 14: Diagrama de pacotes - Padrão MVC Estendido.

71

6.2.1 Diagrama de Classe do Modelo

A Figura 15 apresenta as classes do modelo. Aqui se encontram classes persis-

tentes e de regras de negócio.

Figura 15: Diagrama de Classe do Modelo.

72

6.2.2 Diagrama de Classe da Visão

A Figura 16 apresenta as classes da visão. Aqui se encontra classe que imple-

menta a interface com o usuário do sistema. O padrão de interface adotado é o apre-

sentado pelo JSF. A classe "RBC"é uma classe XHTML que possui componentes da

biblioteca PrimeFaces 2.2 que lançam os eventos de interação do usuário para a ca-

mada de controle da aplicação, e apresenta o caso atual ao usuário.

Figura 16: Diagrama de Classe da Visão.

73

6.2.3 Diagrama de Classe do Controle

A Figura 17 apresenta as classes do controle. A classe "ManageRBC"é o backing

bean que implementa os métodos "Get"e "Set", e funciona também como um façade,

explicados na seção 6.1 deste capítulo. Todo o acesso da camada de visão ao modelo

passa por esta classe de controle, ou seja, esta é a fachada da aplicação.

Figura 17: Diagrama de Classe do Controle.

6.2.4 Diagrama de Classe do Framework RBC

A Figura 18 apresenta as classes do framework RBC que possui os métodos re-

sponsáveis pelo ciclo de vida RBC da aplicação. A classe Recuperar possui os méto-

dos res-ponsáveis pela recuperação dos casos mais similares da base de casos, é

responsável também pela construção da árvore. A classe Reutilizar possui os méto-

dos responsáveis por adaptar as soluções dos casos mais similares, recuperados pela

classe Recuperar, e adaptar à solução do caso atual utilizando adaptação composi-

cional, explicada no capítulo Referencial Teórico na seção Adaptação composi-

cional. A classe Revisar possui os métodos responsáveis por revisar o caso atual,

construído pela classe Reutilizar. A classe Reter possui os métodos responsáveis

74

para a retenção do novo caso de sucesso na base de casos. A classe CalculoSimi-

laridade possui os métodos responsáveis pelo cálculo de similaridade Global e Local

entre os casos recuperados.

Figura 18: Diagrama de Classe do Framework RBC.

75

6.2.5 Diagrama de Classe DAO

A Figura 19 apresenta as classes Data Access Object - DAO. A classe Som-

bra possui os métodos de funcionalidades para banco de dados, tais como obter

as conexões, mapear objetos Java para tipos de dados Structured Query Language

(SQL3) ou executar comandos SQL. As outras três classes VendaService, CarroSer-

vice e ClienteService extendem da classe Sombra abstraindo comando SQL do de-

senvolvedor e melhorando a manutenção do sistema.

Figura 19: Diagrama de Classe do Framework RBC.

3Do inglês, É uma linguagem de pesquisa declarativa para banco de dados relacional.

76

6.3 Estrutura de dados

Dentro do contexto de um SGBD, um dicionário de dados é um grupo de tabelas,

habilitadas apenas para leitura ou consulta, ou seja, é uma base de dados propria-

mente dita, que define com precisão os elementos de dados, entre outras coisas.

Durante a fase de análise foi criado a modelagem do banco de dados e revisado

na fase de especificação de projeto e implementação, conforme Figura 20.

Figura 20: Modelagem do banco de dados.

Este projeto utilizará o SGBD MySQL Server 5.1 para persistência dos casos. Foi

criado um script4 SQL para a criação do banco de dados e as tabelas Cliente, Carro,

Endereco e Venda, apresentado no anexo 4 deste documento.

4Programa de computador que é interpretado em tempo de execução por uma aplicação específica.

77

6.4 Diagrama de componentes

A aplicação é composta por quatro componentes, que se distinguem por suas

funções encapsulados e interfaces de acesso, delineando suas fronteiras e dependên-

cias para com outros componentes. A Figura 21 mostra o diagrama de componentes

da aplicação onde vemos os componentes de interface com o usuário (view), gestão

de tarefas(controller ), domínio do problema(model), persistência(DAO) e ciclo de vida

do RBC(Framework RBC).

Figura 21: Diagrama de componentes.

6.5 Revisão dos diagramas de sequência

No decorrer das modelagens e criação do protótipo, observou-se a necessidade

do refinamento das interações do sistema. As Figuras 22 e 23, mostram os diagramas

de sequência revisados dos casos de uso CSU02 - Consultar Produto RBC e CSU03

- Comprar Produto.

78

Figura 22: Diagrama de Sequência Revisado - CS02: Consultar Produto RBC.

79

Figura 23: Diagrama de Sequência Revisado - CS03: Comprar Produto.

80

7 Mapa de navegabilidade e Telasdo protótipo

A aplicação possui somente uma tela. Através de comandos nesta tela, os com-

ponentes são renderizados. Em função disto, não foi possível elaborar o mapa de

navegabilidade. As figuras abaixo apresentam as telas do protótipo funcional da apli-

cação.

Figura 24: Tela de login.

81

Figura 25: Tela principal.

Figura 26: Tela de consulta personalizada.

82

Figura 27: Tela de exibição do caso adaptado.

83

8 Ferramentas dedesenvolvimento

Existem inúmeras ferramentas (shells1) para desenvolvimento de Sistemas de

Raciocínio Baseado em Casos no mercado. Dentre as quais destacam-se: CBR-

Works, MyCBR2 e JColibri3.

Para o desenvolvimento da aplicação Web, dentre uma ampla gama de tecnolo-

gias disponíveis, e visando a garantia da portabilidade e reusabilidade, foi escolhida a

framework para desenvolvimento web Java Server Faces (JSF).

8.1 Framework RBC

A metodologia RBC pode ser aplicada em um problema de forma ad-hoc4 ou a par-

tir da especialização de infra-estruturas que englobem as diversas tarefas necessárias

ao raciocínio.

O shell CBR-Works, desenvolvido pela TecInno/empolis, é um dos shells de RBC

mais poderosos disponíveis, podendo ser utilizado para desenvolvimento de soluções

inteligentes aplicados a diversos domínios e ambientes operacionais. Possui uma in-

terface intuitiva e com poucos cliques é possível criar uma aplicação simples utilizando

RBC. Sua grande desvantagem é ser um shell proprietário, possuindo um alto custo,

o que para o desenvolvimento do projeto proposto torna-se inviável.

MyCBR é um shell de código fonte aberto para o desenvolvimento de soluções

1Shells, de maneira genérica, é um programa que faz a intermediação do contato entre o usuário eo computador.

2http://mycbr-project.net/3http://gaia.fdi.ucm.es/projects/jcolibri/4Termo usado em computação para resolver determinado problema ou realizar uma tarefa especí-

fica.

84

que utilizam do RBC. Seu objetivo é ser fácil de usar e fornecer GUIs5 poderosas para

modelagem do sistema. Sua confortável interface gráfica permite que até mesmo os

novatos em RBC criem rapidamente suas primeiras aplicações. No entanto, garante

a flexibilidade suficiente para permitir que usuários experientes possam implementar

aplicações avançadas de RBC. Apesar de sua interface amigável é uma ferramenta

que apresenta certas dificuldades ao realizar a interação com aplicações Java6.

Em particular, o shell jColibri desenvolvido pelo Grupo de Aplicações de Inteligên-

cia Artificial da Universidade Complutense de Madri (Espanha) e licenciado através da

Licença Pública Geral. Esta apresenta shells para projetar RBC e APIs7 para integrar

a metodologia às aplicações.

O jColibri dispõe de funcionalidades para uso de ontologias na representação de

casos e conta com uma biblioteca de métricas de similaridade para ontologias [Mar-

tins, 2009].

O que torna o shell jColibri particularmente adequado à implementação do sistema

proposto, é que dentre os shells pesquisados, ele possui maior quantidade de material

disponível para estudos e possui a integração de suas bibliotecas com a linguagem

Java.

Apesar das vantagens do JColibri, ao longo do desenvolvimento encontramos inú-

meras dificuldades no aprendizado, além do mais, tornou-se difícil integra-lo ao sis-

tema de vendas online desenvolvimento utilizando o framework Java Server Faces

(JSF). Por esse motivo, passamos a desenvolver nossa própria framework, o que

garantiu total controle sobre a aplicação e melhores resultados nos testes realizados.

8.2 Framework RBC implementado

Diante do que foi proposto, percebeu-se a necessidade da utilização de uma

framework como apoio ao desenvolvimento de aplicações.

Em desenvolvimento de software, um framework é uma abstração que une códigos

comuns entre vários projetos de software provendo uma funcionalidade genérica.

Dentre as diversas vantagens do uso de uma framework, está tanto a facilidade5Do inglês, Graphical User Interface.6Linguagem de programação Orientada a Objetos.7Do inglês, Application Programming Interfaces.

85

para a detecção de erros, quanto a abstração de soluções do problema que estamos

tratando, o que ocasiona numa maior produtividade.

No entanto, ao contrário do conceito de bibliotecas, o framework é quem dita o

fluxo de controle da aplicação. O framework RBC foi projetado de acordo com as

quatro fases básicas do ciclo de vida do raciocínio baseado em casos: recuperar,

reutilizar, revisar e reter.

8.2.1 Classe CalculoSimilaridade.java

Na fase de recuperação, faz-se necessária a realização de cálculos de similaridade

global e local. Para isso, foi desenvolvida a classe "CalculoSimilaridade".

No anexo 1 é apresentado alguns desses cálculos, onde definimos o peso ao qual

cada atributo receberá, e então é feito o cálculo de similaridade.

8.2.2 Classe Recuperar.java

Ainda na fase de recuperação, é necessária a recuperação dos casos mais simi-

lares da base de dados, e para isso foi desenvolvida a classe "Recuperar"que realiza

a recuperação destes casos. A Figura 35 apresenta o método de recuperação imple-

mentado nesta classe.

No anexo 2 é apresentado a classe que contém os métodos implementados nesta

classe.

8.2.3 Classe Reutilizar.java

A fase de reutilização consiste em adaptar as soluções dos casos mais similares

ao problema atual e adaptar a solução montando o caso atual, e para isso foi desen-

volvida a classe "Reutilizar".

No anexo 3 é apresentado o algoritmo de adaptação composicional implementado

nesta classe.

86

8.2.4 Classe Revisar

A revisão é realizada na interação do usuário com a interface do sistema, objeti-

vando encontrar a solução mais próxima da perfeição para cada utilizador do sistema.

São de grande apoio, as ferramentas de interface do Primefaces, que foram utilizadas

para criar um ambiente mais agradável ao usuário final.

8.2.5 Classe Reter

Esta classe é responsável por persistir na base de dados o caso ou solução deter-

minada pelo sistema como mais adequada.

87

9 Domínio da aplicação

O domínio da aplicação desenvolvida é de suporte a vendas. Segundo (Wangen-

heim, 2003) o objetivo do suporte a vendas é oferecer auxílio à venda de produtos,

estimando custos ou realizando análises de mercado. Inclui também aplicações de

comércio eletrônico inteligente.

Comércio eletrônico pode ser definido como qualquer atividade de comunicação

em forma eletrônica realizada para oferecer suporte a atividades comerciais. Isto pode

se inserir em diferentes momentos da venda, da pré-venda à pós-venda.

Durante a pré-venda, um cliente, expressa um desejo e é provido com toda a infor-

mação solicitada sobre produtos e serviços. Isto geralmente é realizado com utiliza-

ção de catálogos eletrônicos de produtos disponíveis pela Internet. Durante a venda,

um cliente e um agente de vendas negociam produtos e serviços, incluindo preços,

des-contos especiais, forma de entrega, etc. A tarefa é descobrir as necessidades

do cliente e oferecer-lhe um produto ou serviço adequado. Geralmente este é um

processo complexo, com muitas interações entre comprador e vendedor.

Neste contexto, o objetivo do RBC é oferecer ao cliente serviços e facilidades

melhores de seleção. Por exemplo, durante a situação de pré-venda, o RBC pode

ser aplicado para oferecer catálogos de produtos inteligentes (e não apenas listas de

produtos estáticas), capazes de oferecer um produto ou serviço similar, caso o produto

requisitado pelo cliente não esteja disponível, ou, então, capazes simplesmente de

oferecer um produto com base em um conjunto de características fornecidas pelo

usuário.

88

10 CONCLUSÃO

O projeto sistema de raciocínio baseado em casos nasceu com o intuito de suprir a

carência da figura de um vendedor em um ambiente web. O estudo da tecnologia RBC

proporcionou ao grupo a capacidade de desenvolver uma solução capaz de sanar esta

necessidade.

Ao iniciar o projeto se fez necessário o estudo várias outras tecnologias, como: As

shells MyCBR, JColibri, JSF, PrimeFaces, e Hibernate JPA.

O foco principal do trabalho foi revisado devido à dificuldade relacionada à shell

JColibri. Muito tempo foi investido para aquisição de conhecimento sobre a ferramenta,

e com uma minuciosa análise e planejamento do prazo disponível para elaboração do

trabalho, surgiu a estima e oportunidade de mudar o foco do mesmo para o desen-

volvimento de um framework próprio, fazendo com que a construção do protótipo do

sistema de vendas online utilizando a tecnologia RBC ficasse em segundo plano. Con-

cluída a construção do framework, a construção do protótipo foi iniciada, abordando

apenas a consulta e apresentando o ciclo de vida completo da tecnologia RBC.

O resultado foi satisfatório, onde o framework ficou bem estruturado, abstraindo as

estratégias de recuperação, adaptação, revisão e retenção do controle da aplicação.

O sistema construído aplica todas as fases do ciclo de vida da tecnologia RBC.

A oportunidade de aprender novas tecnologias foi acolhida, por exemplo, o estudo

realizado durante o projeto sobre Java Server Faces (JSF), mostrou o caminho para a

construção de sites com interfaces ricas, permitindo novas oportunidades de aplicação

no âmbito profissional e porque não, pessoal.

Entre as propostas para o futuro, estão a aplicação o conceito de processamento

de linguagem natural ao framework RBC construído para que seja possível dialogar

com o cliente, assim como o uso de redes neurais1 para treinar a parte do sistema

1Sistemas computacionais estruturados numa aproximação à computação baseada em ligações.

89

representada pelo vendedor(Existe a idéia de tornar este vendedor portátil a outras

aplicações do gênero, talvez em forma de applet2). Em conjunto, aplicar também, o

conceito de ontologia na base de dados do sistema, para que o mesmo seja capaz

de reconhecer palavras genéricas, como exemplo a palavra "coisa", que para uma

máquina pode ser considerado qualquer objeto, de acordo com o contexto da frase

onde a palavra foi aplicada. Também é proposto implementar técnicas de mineração

de dados3 para encontrar padrões de vendas e gerar relatórios para auxílio a tomadas

de decisões.

2Software aplicativo que é executado no contexto de outro programa.3Do inglês Data Mining, processo de explorar grandes quantidades de dados à procura de padrões

consistentes, como regras de associação ou sequências temporais, para detectar relacionamentos sis-temáticos entre variáveis, detectando assim novos subconjuntos de dados.

90

REFERÊNCIAS

[1] Alves, F. C. (19 de Abril de 2005). Aplicação de Técnicas de Mineração de Dadosa uma Base de um Sistema Gerenciador de Informações para UTI. Dissertação deMestrado , p. 112.

[2] Andrade, F. V. (19 de Novembro de 2008). Predição de Tempo de Execução deTarefas em Grades Computacionais para Recursos não Dedicados , p. 107.

[3] BEZERRA, E. (2004). Princípios de Análise e Projeto de Sistemas com UML. 3a.ed. [S.l.]: Campus.

[4] BAUER, C. (2006). Java Persistence With Hibernate. 2a. ed.

[5] GEARY, D. (2007). Core JavaServer Faces. 2a. ed.

[6] Goetze, A. R. (11 de Abril de 2005). Unisinos. Acesso em 3 deMaio de 2010, disponível em Universidade do Vale do Rio dos Sinos:http://www.inf.unisinos.br/ ari/estrut/kdtree/kd-tree.html

[7] Heredia, L. R., Iochpe, C., e Comba, J. (2003). Explorando a multidimensional-idade da KD-Tree para suporte a temporalidade em dados espaciais vetoriais dotipo ponto. Instituto de Informática da UFRGS , p. 8.

[8] Luger, G. F. (2004). Inteligência artificial (4a ed.). (P. Engel, Ed.) Porto Alegre:Bookmann.

[9] Martins, D. (Julho de 2009). Uma abordagem para recuperação de informaçõessensível ao contexto usando retroalimentação implícita de relevância. p. 107.

[10] Nisanbayev, Y., Ko, I. S., Abdulaev, S., Na, H., e Lim, D. (2009). E-commerce Ap-plications of the Hybrid Reasoning Method. International Conference on New Trendsin Information and Service Science ,p. 5.

[11] Pressman, R. S. (2002) Engenharia de Software. 5a. ed. [S.l.]: McGraw-Hill.

[12] Real, R. (21 de Março de 2003). Redes semânti-cas . Acesso em 3 de Maio de 2010, disponível emhttp://www.inf.ufrgs.br/gppd/disc/cmp135/trabs/rodrigo/T1/html/index.html

[13] Rezende, S. O. (2005). Sistemas Inteligentes (1a ed.). Barueri: Manole.

[14] Russell, S. J. (2004). Inteligência artificial (2 ed.). Rio de Janeiro: Norving.

[15] Toniazzo, L. H. (Junho de 2005). Módulo de Recuperação de Conhecimento paraAuxílio na Tomada de Decisão em um Sistema de Ouvidoria. p. 66.

91

[16] Wangenheim. (2003). Raciocínio Baseado em Casos. Barueri: Manole.

[17] Watson, I. (1999). Case-based reasoning is a methodology not a technology. El-sevier , p. 6.

92

Anexo 1

Figura 28: Cálculo de similaridade global - Cálculo de similaridade do valor da venda.

Figura 29: Cálculo de similaridade local - Cálculo de similaridade do estado cívil docliente.

93

Figura 30: Cálculo de similaridade local - Cálculo de similaridade do número de filhosdo cliente.

Figura 31: Cálculo de similaridade local - Cálculo de similaridade da classe social docliente.

94

Figura 32: Cálculo de similaridade local - Cálculo de similaridade da categoria docarro.

Figura 33: Cálculo de similaridade local - Cálculo de similaridade do modelo do carro.

95

Figura 34: Cálculo de similaridade local - Cálculo de similaridade da cor do carro.

96

Anexo 2

Figura 35: Código da recuperação dos casos mais similares.

97

Anexo 3

Figura 36: Código da adaptação composicional - Parte 1.

98


99


100


101


102



103

Anexo 4

Figura 43: Script de criação do database rbc e tabelas carro e endereco.

104

Figura 44: Script de tabelas cliente e venda.

Documents

Framework para Sistema de Raciocínio Baseado em Casos · centro universitÁrio vila velha curso de ciÊncia da computaÇÃo diego lima ervatti patrick peyneau andrade rafael zacchÉ