Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA DE HELP DESK UTILIZANDO RACIOCÍNIO BASEADO EM CASOS
Área de Inteligência Artificial
por
José Vanderlei de Menezes
Anita Maria da Rocha Fernandes, Drª. Orientadora
Itajaí (SC), junho de 2006
i
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA DE HELP DESK UTILIZANDO RACIOCÍNIO BASEADO EM CASOS
Área de Área de Inteligência Artificial
por
José Vanderlei de Menezes Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Anita Maria da Rocha Fernandes, Drª.
Itajaí (SC), junho de 2006
ii
SUMÁRIO
LISTA DE ABREVIATURAS..................................................................iv
LISTA DE FIGURAS.................................................................................v
LISTA DE TABELAS...............................................................................vi LISTA DE EQUAÇÕES ..........................................................................vii RESUMO..................................................................................................viii ABSTRACT................................................................................................ix
1. INTRODUÇÃO ......................................................................................1 1.1. OBJETIVOS ..................................................................................................... 4 1.1.1. Objetivo Geral................................................................................................ 4 1.1.2. Objetivos Específicos...................................................................................... 4 1.2. METODOLOGIA............................................................................................. 5 1.3. ESTRUTURA DO TRABALHO ..................................................................... 6
2. FUNDAMENTAÇÃO TEÓRICA ........................................................8 2.1. INTELIGÊNCIA ARTIFICIAL...................................................................... 8 2.1.1. Histórico ......................................................................................................... 8 2.1.2. Técnicas de Inteligência Artificial ............................................................... 10 2.2. RACIOCÍNIO BASEADO EM CASOS........................................................ 10 2.2.1. Tipos de Problemas Resolvidos Através de RBC ....................................... 12 2.2.2. Principais Etapas do Ciclo de Desenvolvimento de um Sistema de RBC.. 13 2.3. PESQUISA E ANÁLISE DE SOLUÇÕES SIMILARES............................. 26 2.3.1. O iHotel......................................................................................................... 26 2.3.2. SistLog .......................................................................................................... 28 2.3.3. RBC para o Problema de Suporte ao Cliente nas Empresas de Prestação de Serviço de Software: O Caso Datasul............................................................... 32 2.3.4. Avaliação Geral Sobre as Soluções Estudadas ........................................... 34 2.4. TECNOLOGIAS UTILIZADAS NO SISTEMA.......................................... 35 2.4.1. Java ............................................................................................................... 35 2.4.2. JSP ................................................................................................................ 38 2.4.3. Padrão MVC ................................................................................................ 41 2.4.4. MySQL ......................................................................................................... 42 2.4.5. NetBeans ....................................................................................................... 44
3. DESENVOLVIMENTO ......................................................................46 3.1. INTRODUÇÃO .............................................................................................. 46 3.2. SISTEMA PROPOSTO ................................................................................. 46 3.3. MODELAGEM DO SISTEMA ..................................................................... 48 3.3.1. Análise de Requisitos ................................................................................... 48 3.3.2. Diagramas de Casos de Uso ......................................................................... 49
iii
3.4. ANÁLISE DOS DADOS ................................................................................ 52 3.5. ESTRUTURAÇÃO DO RBC......................................................................... 52 3.5.1. Aquisição do Conhecimento ........................................................................ 53 3.5.2. Representação dos Casos ............................................................................. 54 3.5.3. Método de Recuperação............................................................................... 56 3.5.4. Adaptação..................................................................................................... 58 3.6. IMPLEMENTAÇÃO DO PROTÓTIPO DO SISTEMA ............................. 59 3.6.1. Arquitetura do Sistema................................................................................ 60 3.6.2. Módulos do Sistema ..................................................................................... 64 3.7. VALIDAÇÃO E TESTES .............................................................................. 72
4. CONCLUSÃO ......................................................................................73
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................75
A MODELAGEM DO SISTEMA..........................................................78 A.1 DIAGRAMAS DE CASOS DE USO ............................................................. 78 A.2 DIAGRAMAS DE SEQUENCIA .................................................................. 85 A.3 DIAGRAMAS ENTIDADE RELACIONAMENTO.................................... 89 A.4 DESCRIÇÃO DAS TABELAS DE DADOS ................................................. 91 A.5 DESCRIÇÃO DOS ATRIBUTOS DAS TABELAS ..................................... 91
iv
LISTA DE ABREVIATURAS
AAAI Innovative Application in Artificial Inteligence Award ASP Active Server Pages B2B Business to Business B2C Business to Consumer CAD/CAM Computer Aided Design/Computer Aided Manufacturing CPU Central Processing Unit EI Entidade de Informação FO Ficha de Ocorrência HOMER Hotline Mit Erfahrung HTML HiperText Markup Language IA Inteligência Artificial IB3 Instance Based 3 IBL Instance Based Language ID3 Induction of Decision IDE Integrated Development Environment IE Internet Explorer IIS Internet Information Server J2EE Java 2 Enterprise Edition JDB Java Debugger JDBC Java DataBase Connectivity JDK Java Development Kit JRE Java Runtime Environment JSP Java Server Pages JVM Java Virtual Machine MOP Memory Organization Packets MVC Model View Controller ODBC Open DataBase Connectivity ODBMS Object-Oriented Database Management System RBC Raciocínio Baseado em Casos RRC Rede de Recuperação de Casos SC Santa Catarina TCC Trabalho de Conclusão de Curso UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí XML eXtensible Markup Language
v
LISTA DE FIGURAS
Figura 1. Ciclo de um RBC Fonte: Adaptado de Fernandes (2003) ................................................14 Figura 2. Estrutura de dados da recuperação seqüencial Fonte: Wangenheim & Wangenheim (2003)
..............................................................................................................................................24 Figura 3. Algoritmo de recuperação seqüencial Fonte: Wangenheim & Wangenheim (2003).........24 Figura 4. Cadastro de Notas Fonte: Miranda (2000).......................................................................30 Figura 5. Cadastro de Pesos Fonte: Miranda (2000) .......................................................................30 Figura 6. Tela Resultado da Consulta Fonte: Miranda (2000).........................................................31 Figura 7. Tela de consulta do Help Desk Fonte: Adaptado de Lagemann (1988) ............................33 Figura 8. Tela com caso recuperado Fonte: Adaptado de Lagemann (1988) ...................................34 Figura 9. Modelo de ambiente de desenvolvimento Java Fonte: Adaptado de Saofrancisco (2006) 37 Figura 10. Fluxo de uma solicitação de um arquivo JSP. Fonte: Unicap (2001)..............................39 Figura 11. Exemplo de arquitetura de servlets. Fonte: Adaptado de ADTMAG (2006) ..................41 Figura 12. Arquitetura do padrão MVC. Fonte: Adaptado de JAVANOROESTE (2006) ...............42 Figura 13. Requisitos Funcionais ...................................................................................................48 Figura 14. Requisitos Não-Funcionais ...........................................................................................49 Figura 15. Use Case do Administrador ..........................................................................................50 Figura 16. Use Case do Cliente......................................................................................................52 Figura 17. Fluxo de consulta ao RBC. ...........................................................................................53 Figura 18. Estrutura de um caso.....................................................................................................55 Figura 19. Exemplo de arquitetura do sistema em um servidor Linux. Fonte: Adaptado de AKADIA
(2006)....................................................................................................................................61 Figura 20. Estrutura de diretórios do NetBeans..............................................................................62 Figura 21. Estrutura de pacotes......................................................................................................64 Figura 22. Exemplo do arquivo conf.properties Fonte: PortalJava (2005).......................................64 Figura 23. Tela inicial do sistema ..................................................................................................65 Figura 24. Tela consulta de casos parte 1 .......................................................................................65 Figura 25. Tela lista de produtos vazia...........................................................................................66 Figura 26. Tela lista de produtos preenchida. .................................................................................66 Figura 27. Tela consulta de casos parte 2. ......................................................................................67 Figura 28. Tela resultado da consulta.............................................................................................67 Figura 29. Tela de login.................................................................................................................68 Figura 30. Tela estrutura de produto. .............................................................................................69 Figura 31. Tela cadastro de problemas. ..........................................................................................70 Figura 32. Tela cadastro de estados................................................................................................70 Figura 33. Tela estrutura de um caso..............................................................................................71 Figura 34. Diagrama de Seqüência – Consulta Caso ......................................................................86 Figura 35. Diagrama de Seqüência – Manutenção de Usuários .....................................................87 Figura 36. Diagrama de Seqüência – Manutenção de Casos...........................................................88 Figura 37. Modelo Lógico .............................................................................................................89 Figura 38. Modelo Físico...............................................................................................................90
vi
LISTA DE TABELAS
Tabela 1. Atributos do caso e seus parâmetros. ..............................................................................57 Tabela 2. Atribuição de valores para atributos do método Contagem. ............................................57 Tabela 3. Atribuição de valores ao atributo “Como está o nível de ruído?”. ...................................57 Tabela 4. Valores dos atributos dos casos. .....................................................................................58 Tabela 5. Descrição das Tabelas de Dados utilizadas no Sistema. ..................................................91 Tabela 6. Dicionário de Dados da Tabela Caso. .............................................................................91 Tabela 7. Dicionário de Dados da Tabela Caso_Problema. ............................................................92 Tabela 8. Dicionário de Dados da Tabela Atendimentos. ...............................................................92 Tabela 9. Dicionário de Dados da Tabela Problema. ......................................................................92 Tabela 10. Dicionário de Dados da Tabela Estado. ........................................................................92 Tabela 11. Dicionário de Dados da Tabela Grupo. .........................................................................92 Tabela 12. Dicionário de Dados da Tabela Conjunto......................................................................92 Tabela 13. Dicionário de Dados da Tabela Prod_Conjunto. ...........................................................93 Tabela 14. Dicionário de Dados da Tabela Conj_Problema............................................................93 Tabela 15. Dicionário de Dados da Tabela Produto........................................................................93 Tabela 16. Dicionário de Dados da Tabela Usuário........................................................................93 Tabela 17. Dicionário de Dados da Tabela Prob_Estado. ...............................................................93
vii
LISTA DE EQUAÇÕES
Equação 1......................................................................................................................................19 Equação 2......................................................................................................................................21 Equação 3......................................................................................................................................22 Equação 4......................................................................................................................................22 Equação 5......................................................................................................................................22 Equação 6......................................................................................................................................23 Equação 7......................................................................................................................................23 Equação 8......................................................................................................................................23 Equação 9......................................................................................................................................23
viii
RESUMO
MENEZES, José Vanderlei de. Sistema de Help Desk Utilizando Raciocínio Baseado em Casos. Itajaí, 2006. 100, Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2006. Um dos grandes problemas que as indústrias de máquinas enfrentam na atualidade é fazer com que o Setor de Atendimento ao Cliente tenha capacidade de realizar um atendimento rápido, seguro e eficaz, fazendo com que os clientes tenham mais confiança e satisfação ao adquirirem seus produtos. Com o objetivo de auxiliar estas empresas em seu processo de atendimento, foi desenvolvido um sistema de Help Desk onde o cliente obtém informações e tira dúvidas sobre problemas que possam ocorrer com os produtos adquiridos, com acesso on-line e disponível 24 horas por dia. Através disso diminui-se o fluxo de atendimento via telefone diretamente com os atendentes e, além disso, proporciona para a empresa um histórico de informações sobre todos os problemas encontrados em seus produtos. Este Sistema baseou-se na técnica de RBC (Raciocínio Baseado em Casos), utilizando-se para o cálculo de similaridade o método do Vizinho Mais Próximo juntamente com o de Contagem de Características. Para seu desenvolvimento foi utilizado a linguagem de script JSP (Java Server Pages) que utiliza a tecnologia e componentes Java, e como banco de dados foi utilizado o MySQL. Palavras-chave: Help Desk. Raciocínio Baseado em Casos. Inteligência Artificial.
ix
ABSTRACT
One of the great problems that the industries of machines face in the present time is to make with that the Sector of Attendance to the Customer has capacity to carry through a fast attendance, safe and efficient, making with that the customers have more confidence and satisfaction when acquiring its products. With the objective of assisting these companies in its process of attendance, a system of Help Desk was developed where the customer gets information and takes off doubts on problems that can occur with the acquired products, with access on-line and available 24 hours per day. Through this the attendance flow diminishes itself saw telephone with the attendants directly and, moreover, it provides for the company a description of information on all the problems found in its products. This System was based on the RBC technique (Reasoning Based on Cases), using for the calculation of similarity the method of the Neighbor Next together with the one to Counting of Characteristics. For its development the language of script JSP was used (Java Server Pages) that it uses the technology and Java components, and as data base was used the MySQL. Keywords: Help Desk. Case-Based Reasoning. Artificial Intelligence.
1. INTRODUÇÃO
Este projeto teve como objetivo desenvolver um sistema de Help Desk para Web que utiliza
a técnica de Inteligência Artificial do Raciocínio Baseado em Casos para prover aos clientes de uma
empresa da cidade de Navegantes. Através deste sistema o cliente tem um livre acesso através da
Internet, 24 horas por dia para fazer consultas em uma base de conhecimento e tentar resolver seus
problemas sem ter que entrar em contato pelo telefone com a empresa.
A Internet – Internetwork System (sistema de interconexão de rede de comunicação) é um
dos meios de comunicação mais utilizado do mundo. Atualmente milhões de pessoas já se utilizam
de seus computadores para obter informações, receber e-mail (eletronic mail – correio eletrônico),
fazer investimentos e outros negócios afins que antes eram feitos com um custo muito maior e em
algumas das vezes sem sucesso. Internet é muito mais do que uma rede de computadores ou
serviços de informações, ela pode dar ao ser humano a liberdade de se comunicar, informar, e se
divertir (KUHNEN, 2000).
O Raciocínio Baseado em Casos é uma técnica usada para encontrar soluções para um novo
problema usando soluções adotadas para problemas similares já resolvidos. A idéia básica de RBC
é que os humanos modificam a estratégia de solução de um novo problema baseados em
conhecimento e experiências com problemas passados similares, adaptando as soluções, usando-os
para explicar novas situações, criticando novas soluções, ou inferindo sobre fatos para interpretar
novas situações ou criar uma solução para o problema atual (LAGEMANN, 1998).
Sistemas Help Desk, são sistemas facilitadores de informação, mas comunmente são tratados
somente como um Sistemas de Suporte Técnico. A moderna concepção de Help Desk, porém, vai
muito além do mero conceito de suporte técnico, pois a principal característica dos sistemas Help
Desk hoje é a de facilitador de “quaisquer informações” ao usuário, não importando se esta
facilitação seja de natureza técnica computacional ou não. O conteúdo desta facilitação, portanto,
pode ser dos mais variados tipos, nem mesmo importa se a tecnologia usada na modelagem do Help
Desk venha a envolver componentes inteligentes ou não. Dizemos então um sistema help desk
constitui um mecanismo computacional facilitador de informação do tipo help desk = <Pergunta,
Resposta>, onde tanto a Pergunta em apreço se refere àquela de clientes e/ou usuários quaisquer, e
a Resposta do sistema se refere a um apoio informacional bem definido em seu domínio.
2
O atendimento a clientes é um ponto que merece atenção especial dentro de uma indústria,
seja ela de qual ramo for. São os clientes que compram os produtos e por isso necessitam de
orientações sobre utilização, procedimentos de montagem, características técnicas, e principalmente
reclamações e dúvidas sobre o mau funcionamento dos produtos ou sobre procedimentos de
utilização aplicados de maneira errada.
Com a inclusão da informática dentro das indústrias este tipo de atendimento tem tido uma
melhora constante, e dentro de uma indústria de produtos de jardinagem da cidade de Navegantes-
SC, não é diferente. Foi pensando nisto que se levantou a necessidade de criação de um sistema
informatizado para automatizar o acesso dos clientes às informações sobre os produtos, sem que
fosse preciso ligar diretamente para o Setor de Atendimento ao Cliente.
Melhorar o atendimento ao cliente é no momento uma das maiores preocupações das
corporações, e por isso a grande maioria delas decidiu colocar à disposição de seus clientes,
ferramentas que facilitem esta interação. Entre as ferramentas mais utilizadas estão os sistemas de
Help Desk, que são sistemas que utilizam técnicas de Inteligência Artificial (IA), por exemplo,
Raciocínio Baseado em Casos (RBC), agentes, dentre outras. Estes sistemas são disponibilizados
através da Internet, para que o próprio cliente possa acessar o suporte da empresa, e através de uma
interface amigável e cognitiva possa descrever seu problema e tentar resolvê-lo sem ter que entrar
em contato diretamente com a empresa. Este tipo de sistema diminui significativamente o suporte
telefônico e conseqüentemente reduz os custos destinados ao atendimento ao cliente.
Muitos destes Help Desk são voltados para a Internet, e dentro de pouco tempo ela será o
meio de comunicação mais utilizado do mundo, pois atualmente milhões de pessoas utilizam seus
computadores para obter informações, receber e-mail, conversar a longa distância com custo
reduzido, fazer compras, manipular suas contas bancárias, fazer investimentos no mercado externo
etc., através da maior rede do mundo. A Internet pode ser vista também como um grupo de recursos
de informação global, onde esses recursos são tão vastos que estão além da compreensão do ser
humano (KUHNEN, 2000).
A utilização de técnicas de IA no desenvolvimento de sistemas computacionais possibilita
agregar aspectos da cognição humana na resolução de problemas que exigem conhecimentos
especialistas (RAMALHO, 1999).
3
Um sistema de Help Desk para Web utilizando Raciocínio Baseado em Casos envolve
diferentes conceitos de diversas áreas da Ciência da computação como banco de dados, engenharia
de software, redes, linguagem de programação multiplataforma e técnicas de inteligência artificial.
Os sistemas de RBC atualmente aparecem como uma solução muito aplicável a diversas
áreas, e algumas destas áreas podem ser citadas, como: Call Centers, suporte técnico e Help Desk,
hotelaria, suporte a decisão, suporte a vendas, e muitas outras áreas.
Tomando como base uma indústria de máquinas para jardinagem situada da cidade de
Navegantes, que atende todo território nacional, foi proposto o desenvolvimento de um sistema de
Help Desk inteligente voltado especificamente para o Setor de Atendimento ao Cliente, pois o
atendimento atualmente é realizado através do telefone e possui um grande número de chamadas
diariamente, que são atendidas de maneira lenta e às vezes incorreta, o que acarreta custos tanto
para a empresa quanto para o cliente.
A grande motivação para o desenvolvimento deste sistema foi principalmente devido à
necessidade de possuir um meio de comunicação rápido e de fácil acesso que possibilitasse uma
conexão direta entre a indústria e o cliente final. A solução desenvolvida possibilita esta interação
direta do usuário final através da utilização de um sistema de Help Desk, que permite um
diagnóstico preliminar rápido sobre os principais problemas que as máquinas podem apresentar.
Uma importante vantagem da implementação deste sistema é a associação de novas
tecnologias como IA e RBC, com o aproveitamento da base de dados e ferramentas de software
(sistema operacional, gerenciador de banco de dados e linguagens de programação) já existentes na
empresa. Outra vantagem que espera-se alcançar, é a melhoria da prestação de serviço ao cliente, o
que vai possibilitar uma redução dos custos com o suporte para a indústria que atualmente tem um
alto custo para manter canais de comunicações com os técnicos que atendem os clientes. Para os
clientes, está proporcionando um acesso facilitado, com um tempo de retorno em muitas situações
menor e sem ter que utilizar o serviço telefônico, e assim, reduzindo os custos em chamadas
telefônicas.
Esta ferramenta é fundamental para que a indústria se alinhe aos avanços tecnológicos e
permita que seja referência no atendimento ao cliente à distância dentro de um cenário nacional. As
técnicas de RBC que foram empregadas permitem ao cliente além de um livre acesso através da
4
Web, à realização de rápidos diagnósticos sobre suas principais dúvidas referentes aos produtos
adquiridos.
1.1. Objetivos
1.1.1. Objetivo Geral
O objetivo geral deste trabalho foi desenvolver um Help Desk Inteligente para Web,
utilizando Raciocínio Baseado em Casos, que auxilie no atendimento dos clientes e colaboradores
do Setor de Atendimento ao Cliente de uma indústria fabricante de máquinas para jardinagem,
situada na cidade de Navegantes.
1.1.2. Objetivos Específicos
Os objetivos específicos deste projeto de pesquisa foram:
o Pesquisar e analisar soluções similares;
o Relacionar as vantagens e desvantagens dos sistemas pesquisados;
o Compreender as metodologias utilizadas para o desenvolvimento de um RBC;
o Determinar os requisitos exigidos pelo sistema;
o Definir a forma de representação dos casos;
o Escolher o melhor método para recuperação dos casos;
o Desenvolver estratégias de adaptação dos casos;
o Analisar as variáveis necessárias;
o Realizar a modelagem conceitual do sistema;
o Escolher a ferramenta para construção da interface do sistema;
o Implementar o sistema; e
o Realizar testes e validação do sistema.
5
1.2. Metodologia
Para uma melhor elaboração deste trabalho, o mesmo foi dividido em etapas, e embora estas
etapas não sejam baseadas em nenhuma metodologia específica, elas seguem um modelo que muito
se assemelha ao espiral, de forma que a cada fase concluída a mesma pode ser revisada e avaliada.
A metodologia seguida para o desenvolvimento deste projeto baseou-se nos aspectos descritos a
seguir.
O levantamento bibliográfico foi realizado através de estudos sobre conceitos de Inteligência
Artificial, mais especificamente sobre Sistemas de Raciocínio Baseado em Casos e todas as etapas
que envolvem esta técnica, como a representação dos casos, a indexação, recuperação, ajuste da
situação e aprendizado. Também foram pesquisados alguns conceitos sobre Help Desks para web e
atendimento ao cliente. Todos os estudos e pesquisas necessários para o desenvolvimento deste
trabalho foram realizados através de consultas a livros, artigos, dissertações e sites da Web.
O ponto inicial foi uma seleção de materiais considerados importantes para o
desenvolvimento de um projeto na área de pesquisa de IA. Tendo em mãos este material, iniciou-se
então o processo de estudo e redação dos primeiros capítulos a fazer parte da documentação do
TCC.
Em uma primeira etapa foi realizado um estudo sobre o problema a ser resolvido, e de que
forma desenvolver uma aplicação que melhor solucionasse o caso. Para isto, foi realizada uma
pesquisa sobre sistemas de Help Desks e sistemas de RBC que pudessem contribuir para a
formulação e estruturação do sistema a ser desenvolvido.
Posteriormente foi planejada, através de reuniões realizadas junto à empresa, qual seria a
melhor forma de aplicação do sistema, para que o mesmo tivesse um aproveitamento abrangente no
auxílio aos problemas levantados, e assim foi definido um esboço para início do projeto.
Após ter uma idéia preliminar do que se precisava alcançar, foi realizado um estudo sobre as
tecnologias disponíveis para utilização no desenvolvimento do projeto, tendo em vista dois pontos
principais: aumentar o conhecimento sobre tecnologias e metodologias atualmente disponíveis, e
obter ferramentas que pudessem atender as necessidades apresentadas para o desenvolvimento do
sistema.
6
A análise e a modelagem conceitual foram realizadas segundo conceitos de UML (Unified
Modeling Language) aplicados às características do escopo do sistema, como, portabilidade para
Web, utilização de técnicas de IA, banco de dados, etc. Para melhor representação e documentação
do sistema, foram utilizados os principais diagramas UML como: diagrama de casos de uso,
diagrama de seqüência e diagrama de entidade relacionamento, para que facilitassem a etapa de
implementação do protótipo.
A escolhas das ferramentas para implementação do sistema foi realizada principalmente
através de um estudo sobre ferramentas multiplataforma que possibilitam uma maior
compatibilidade para distribuição do sistema, e ferramntas freeware ou Open Source, pois além de
serem muito utilizadas no mercado e atenderem os requisitos para o desenvolvimento do sistema,
não houve custo de aquisição para a empresa. Da mesma maneira também foi escolhida a IDE para
implementação do modelo, servidor de páginas, e modelo de implementação a ser adotado.
A última etapa realizada foi a implementação completa de um protótipo do sistema na
linguagem de programação Java, mais especificamente JSP (Java Server Pages), bem como foi
realizado o levantamento das informações necessárias para população da base inicial de casos, onde
ficou a cargo dos técnicos da empresa a alimentação da base, bem como a criação das variáveis
necessárias para alimentar a base do sistema. Na seqüência foram realizados testes de cadastros em
todos os módulos bem como a validação dos primeiros resultados obtidos na consulta de casos
através do módulo de suporte, onde o cliente terá o acesso.
1.3. Estrutura do Trabalho
O presente trabalho está dividido em quatro capítulos: introdução, fundamentação teórica,
desenvolvimento e conclusões.
Introdução: este capítulo é composto pela introdução, que é uma descrição geral sobre o
problema, sua justificativa e como resolver; pelos objetivos gerais e específicos, que definem quais
as atividades que se pretende desenvolver para alcançar os objetivos; a metodologia, que descreve
como cada objetivo foi alcançado; e a estrutura do trabalho que está sendo descrita;
Fundamentação teórica: este capítulo é composto por vários sub-capítulos que descrevem
a Inteligência Artificial, suas definições, características e principais técnicas envolvidas no presente
trabalho; a técnica de Raciocínio Baseado em Casos, problemas que podem ser resolvidos através
7
desta técnica, etapas que compreendem o ciclo de desenvolvimento de um RBC, e seus respectivos
métodos;
Desenvolvimento: este capítulo é composto pelas etapas de análise dos requisitos
necessários para o desenvolvimento do protótipo, modelagem e estruturação da base de
conhecimento criada e os principais diagramas de casos de uso e de seqüência. Também descreve
como foi desenvolvido o sistema; quais as tecnologias e metodologias, e como elas foram
utilizadas; como foram associadas as etapas do ciclo de vida do RBC ao projeto; a estrutura geral do
sistema, instruções sobre a operação e os módulos que compõe o sistema;
Conclusões: este capítulo é composto pela etapa de testes e validações do sistema, sobre
como qual foi seu comportamento e quais objetivos foram alcançados; pela descrição de alguns
problemas enfrentados, possíveis falhas de modelagem, considerações sobre o processo de
desenvolvimento como um todo, bem como indicações para trabalhos futuros que possam vir a
serem feitos nesta área de estudos.
2. FUNDAMENTAÇÃO TEÓRICA
2.1. INTELIGÊNCIA ARTIFICIAL
A palavra inteligência vem do latim inter (entre) e legere (escolher). Portanto, inteligência
significa aquilo que permite ao ser humano escolher entre uma, duas ou várias opções, ou ainda a
habilidade de realizar uma determinada tarefa de forma eficiente. A palavra artificial vem do latim
artificiale, e significa algo não natural (produzido pelo homem). Assim, inteligência artificial é um
tipo de inteligência produzida pelo homem para dotar as máquinas de algum tipo de habilidade que
simula a inteligência do mesmo (FERNANDES, 2003).
A Inteligência Artificial (IA) busca prover máquinas com a capacidade de realizar algumas
atividades mentais do ser humano. Em geral são máquinas com algum recurso computacional, de
variadas arquiteturas, que permitem a implementação de rotinas não necessariamente algorítmicas.
As atividades realizadas por estas máquinas podem envolver a sensopercepção (como tato, audição
e visão), as capacidades intelectuais (como aprendizado de conceitos e de juízos, raciocínio
dedutivo e memória), a linguagem (como as verbais e gráficas) e atenção (decisão no sentido de
concentrar as atividades sobre um determinado estímulo) (NASCIMENTO JR. & YONEYAMA,
2000).
IA é o estudo de como fazer os computadores realizarem tarefas que, no momento, são feitas
melhor por pessoas (Rich, 1983 apud NASCIMENTO JR. & YONEYAMA, 2000). Para Luger e
Stubblefield, Inteligência Artificial é o ramo da computação preocupada com a automação de
comportamento inteligente (FERNANDES, 2000).
2.1.1. Histórico
A história da Inteligência Artificial teve início na década de 40, marcada pela Segunda
Guerra Mundial, com o desenvolvimento do computador para realizar o cálculo da bomba atômica,
pois era necessária uma grande quantidade de cálculos precisos. O computador também foi utilizado
para o planejamento de ações estratégicas de exércitos, sendo que a partir daí surgiram os jogos por
computador (MÜLLER, 2005).
O primeiro esforço conjunto para estudar IA foi o encontro no Darthmouth College, em
1956. Este encontro foi também o primeiro entre os quatro pesquisadores do campo da IA nos
9
Estados Unidos durante duas décadas: McCarthy, Minsky, Newell e Simon. Neste encontro e no
livro publicado a seguir com o título de “Automata Studies”, no qual surgiu o primeiro artigo
tratando redes neurais como um paradigma da arquitetura computacional, nasceram
simultaneamente os dois paradigmas da Inteligência Artificial: simbólica e conexionista.
(BARRETO, 1997). Já em 1965, Zadeh propõe a base lógica difusa, também chamada de lógica
nebulosa ou fuzzy logic, que lida com a avaliação de expressões lógicas contendo valores incertos
(RABUSKE, 1995).
Na década de 90 “as redes neurais tiveram uma explosão exponencial de aplicações e
desenvolvimento de modelos”. Surgiram centenas de propostas de novos modelos e
aperfeiçoamento dos mesmos. Foram construídos os Sistemas Híbridos que permitem a construção
de grandes sistemas abrangendo uma forma mais completa de representação do comportamento
humano (MÜLLER, 2005).
Nos últimos anos, ocorreu uma mudança nos conteúdos e nas metodologias de investigação
da IA. Hoje é comum aprimorar o trabalho em teorias existentes do que propor novas,
demonstrando resultados com teoremas e experiências rigorosas em detrimento da intuição, por
exemplo. De acordo com Müller (2005), os sistemas atualmente existentes permitem:
o conduzir um automóvel em uma auto-estrada;
o fazer o reconhecimento de voz (passar de voz para texto);
o fazer tradução;
o detectar avarias;
o diagnosticar doenças; e
o ganhar do campeão mundial de xadrez.
10
2.1.2. Técnicas de Inteligência Artificial
Os pesquisadores de IA, nos últimos anos têm se preocupado mais com a aplicação dos
conceitos dela no mundo real do que com o desenvolvimento de novos teoremas. Estas novas
pesquisas têm dividido a IA em muitos ramos, entre eles estão: Sistemas Especialistas,
Processamento da Linguagem Natural, Redes Conexionistas, Algoritmos Genéticos, Conjuntos
Difusos, Agentes Inteligentes e Raciocínio Baseado em Casos.
Este trabalho utilizou um desses ramos, mais especificamente a técnica de Raciocínio
Baseado em Casos, que é o campo de estudo da IA que se utiliza de uma grande biblioteca de casos
passados para consulta e resolução de problemas atuais. Estes problemas são resolvidos através da
recuperação e consulta de casos que já foram solucionados anteriormente e da conseqüente
adaptação das soluções encontradas nas resoluções (FERNANDES, 2003).
2.2. RACIOCÍNIO BASEADO EM CASOS
Diariamente as pessoas se deparam com problemas variados, e sem perceber os resolvem,
algumas vezes de forma rápida, outras vezes de uma forma mais lenta. Mas como estes problemas
podem ser resolvidos? O que é utilizado para resolvê-los? Para resolver problemas usa-se um
recurso importante que o ser humano possui, a memória. Isto permite que pessoas tomem uma
decisão em relação a algum problema, baseando-se em situações semelhantes que já viveram no
passado. Se no passado essa decisão foi aplicada com sucesso, então a mesma é aplicada
novamente, caso contrário toma-se uma nova decisão para que no futuro se possa reutilizá-la
novamente.
A resolução de um problema utilizando Raciocínio Baseado em Casos (RBC) consiste em
identificar um problema atual, buscar a experiência mais semelhante em um conjunto de casos e
aplicar o conhecimento dessa experiência passada na resolução do problema atual. Esse conjunto de
casos representa a base de casos ou memória do sistema (RAMALHO, 1999).
RBC é uma técnica de Inteligência Artificial que resolve os novos problemas através da
recuperação e adaptação de soluções anteriores. A inspiração inicial de RBC advém da maneira
como o raciocínio humano recorda e explica as experiências passadas para solucionar novos
problemas (KUHNEN, 2000).
11
Segundo Wangenheim e Wangenheim (2003), Raciocínio Baseado em Casos é um enfoque
para a solução de problemas e para o aprendizado baseado em experiências passadas. RBC resolve
problemas ao recuperar e adaptar experiências passadas – chamadas casos – armazenadas em uma
base de casos. Um novo problema é resolvido com base na adaptação de soluções de problemas
similares já conhecidas.
O estudo de RBC é guiado por duas motivações primárias: a primeira, oriunda da
ciência cognitiva, é o desejo de modelar o raciocínio e o aprendizado humano. A segunda,
proveniente da IA, é o desejo de desenvolver tecnologias para a construção de sistemas inteligentes
cada vez mais efetivos (RAMALHO, 1999).
Os seres humanos são considerados robustos resolvedores de problemas. Muitas vezes
resolvem problemas difíceis apesar do conhecimento limitado e incerto. Além disso, com a
experiência adquirida o desempenho deles melhora cada vez mais. Todas essas qualidades são
desejáveis em um sistema de IA para o mundo real. Portanto, existem boas razões para se utilizar
um RBC (Leake, 1996 apud RAMALHO, 1999):
o Aquisição do conhecimento: o conhecimento presente em um sistema de RBC fica
armazenado na própria base de casos;
o Manutenção do conhecimento: um usuário do sistema pode ser habilitado para adicionar
novos casos na base de casos sem a intervenção do especialista;
o Eficiência crescente na resolução de problemas: a reutilização de soluções anteriores
ajuda a incrementar a eficiência na resolução de problemas. O RBC armazena tanto as
soluções bem sucedidas como as que não obtiveram sucesso. Isto faz com que eventuais
insucessos sejam evitados;
o Qualidade crescente das soluções: quando os princípios de um domínio não são bem
conhecidos, regras não são a melhor solução. Nessa situação, as soluções sugeridas pelos
casos refletem o que realmente aconteceu em uma determinada circunstância; e
o Aceitação do usuário: um dos pontos chaves para o sucesso de um sistema de IA é a
aceitação do usuário. Os sistemas de RBC podem comprovar o seu raciocínio
apresentando ao usuário os casos armazenados na base. Este é um dos grandes
problemas enfrentados por outras técnicas de IA como as Redes Neurais.
12
A origem da técnica de RBC é atribuída a uma pesquisa na área da ciência cognitiva
desenvolvida por Schank e Abelson em 1977. Neste trabalho eles afirmaram que todo o
conhecimento é armazenado no cérebro como um script. Estes scripts compõem uma memória
conceitual, descrevendo informações sobre eventos típicos como um almoço em um restaurante ou
uma consulta médica. Porém, experimentos com fatos mostraram que somente os scripts não
representavam o conhecimento armazenado na memória. Era comum as pessoas misturarem fatos
parecidos como consulta médica e consulta dentária no momento da lembrança (LAGEMANN,
1998).
O primeiro sistema que pode ser considerado como um RBC foi o CYRUS, desenvolvido
por Janet Kolodner. Esse sistema foi baseado no modelo de memória dinâmica de Schank e na
teoria dos MOP’s (Memory Organization Packets) para aprendizagem e solução de problemas
(FERNANDES, 2003).
Outras bases para RBC e outros conjuntos de modelos foram desenvolvidos por Bruce
Porter e seu grupo. Inicialmente, eram endereçados os problemas de aprendizado de máquina e de
conceitos aprendidos para classificação de tarefas. Essa linha de desenvolvimento deu origem ao
sistema PROTOS que enfatiza a integração do domínio geral de conhecimento e especifica o
conhecimento de casos dentro de uma estrutura de representação unificada (KUHNEN, 2000).
2.2.1. Tipos de Problemas Resolvidos Através de RBC
Sistemas de RBC já estão presentes em diversos tipos de aplicações como suporte ao
consumidor, controle de qualidade, manutenção de aeronaves, planejamento de processos, apoio à
decisão, roteamento de mensagens, Help Desks computadorizados, predições, pesquisas
jurisprudências etc (Lee, 1998 apud KUHNEN, 2000).
A utilização de RBC fornece uma abordagem diferente de banco de dados, tornando-se uma
ferramenta ideal para a tarefa de diagnóstico. Em um RBC uma consulta a uma base de
conhecimento avalia ao máximo todos os casos, para escolher os mais similares em relação ao
contexto do problema (caso) atual. No procedimento de diagnóstico médico, leva-se em conta um
conjunto de sintomas e de resultados de exames que serão os dados de entrada do sistema de acordo
com o domínio escolhido (SILVA, 2000).
13
Independente do tipo de aplicação, os sistemas de RBC resolvem problemas utilizando o
mesmo princípio: comparam o caso de entrada com os casos armazenados na memória (base de
casos). A pesquisa pelos casos mais semelhantes é realizada por algoritmos que calculam o grau
de similaridade entre o caso de entrada e os casos da base. Se esta pesquisa retornar um
caso idêntico ao caso de entrada, o caso encontrado pode ser usado diretamente para
resolver o problema. Porém, se o caso recuperado não for idêntico ao caso de entrada, talvez
seja necessário que o usuário (ou o próprio sistema) faça uma adaptação da solução encontrada para
resolver o problema. Quando é apropriado, novos casos podem ser acrescentados à base de casos
para expandir o conhecimento do sistema (Buta, 1997 apud RAMALHO, 1999).
2.2.2. Principais Etapas do Ciclo de Desenvolvimento de um Sistema de RBC
O processo de desenvolvimento de um sistema de RBC é uma tarefa iterativa e não se
encaixa em uma metodologia genérica. A seguir serão descritas algumas destas etapas que são
consideradas as mais importantes segundo Fernandes (2003):
o Representação dos casos: é a representação do conhecimento processado em forma de
casos que futuramente serve para sugerir uma solução para um problema;
o Indexação: é a associação de rótulos em casos, de maneira a caracterizá-los para
posteriormente recuperá-los em uma base de conhecimento;
o Recuperação: esta etapa tem por objetivo recuperar os casos mais similares,
identificando-os através de características relevantes a solução;
o Ajuste da situação: esta etapa tem por objetivo transformar novos casos que não estejam
no formato da base no formato ideal; e
o Aprendizagem: é a acumulação de novas experiências na base de conhecimento.
A Figura 1 ilustra passo a passo cada uma das principais etapas que fazem parte do ciclo de
um RBC.
14
Figura 1. Ciclo de um RBC Fonte: Adaptado de Fernandes (2003)
2.2.2.1. Representação dos Casos
Um caso é definido pela representação do conhecimento contido em uma experiência vivida
que conduz o indivíduo a alcançar seus objetivos. Todo caso é composto por Problema, que
descreve o estado do mundo real onde o caso ocorre; e Solução, que contém o estado das soluções
derivadas para o problema. Pode-se ainda visualizar o caso pela representação do espaço do
problema e pela representação do espaço da solução (LAGEMANN, 1998).
Segundo Ramalho (1999), muitos autores definem um caso como sendo uma abstração de
uma experiência, que deve estar descrita em termos de seu conteúdo e contexto. Estas
experiências precisam ser organizadas em unidades bem definidas chamadas base de
conhecimento ou memória de casos. (RAMALHO, 1999).
Existem muitas formas de representação de casos que podem ser utilizadas em um RBC,
tais como: representações atributo-valor, orientadas a objetos, redes semânticas, e muitas outras.
Elas representam o formalismo com os quais será representado o conhecimento para a solução do
15
problema, e determinar qual a melhor forma é uma tarefa um pouco difícil, mas a forma mais
utilizada é a descrição através de atributos. Algumas aplicações requerem um conhecimento
profundo do domínio do problema, não dispensando a presença de um especialista. Muitos sistemas
de RBC usam sofisticadas representações dos casos para expressar o conhecimento, com atributos
de um caso referindo-se a outros casos. A representação dos casos é uma das mais importantes
etapas do processo de desenvolvimento de um sistema de RBC (RAMALHO, 1999).
2.2.2.1.1. Representações Atributo-Valor
É a forma mais simples utilizada para representação dos casos. É realizada por vetores
atributo-valor, sendo que um caso é representado por um conjunto de pares atributo-valor. O
conjunto de atributos pode ser fixo, ou pode variar entre casos individuais. Cada atributo geralmente
é associado a um domínio (tipo de dados), ou faixa para seus possíveis valores. Tipos básicos de
dados geralmente são utilizados neste método como: número (real ou inteiro), booleano, data,
símbolo (ordenado, não ordenado ou taxonomia), e string.
Para este tipo de representação é muito importante a escolha de atributos relevantes e com
significância preditiva no comportamento dos objetos representados. Este tipo de representação
possui muitas vantagens, dentre elas: representação simples e fácil de implementar; simplifica a
implementação de medidas de similaridade eficientes; fácil de armazenar; e sua representação é
eficiente e possível.
2.2.2.1.2. Representações Orientadas a Objetos
Assim como nas linguagens de programação, descrevem o domínio particionando-o com
relação a seus objetos. São de muita importância em domínios de aplicação muito complexos que
podem conter casos com estruturas variáveis. Neste contexto, um objeto representa uma entidade do
domínio, e os estados de um objeto podem ser modificados apenas através dos serviços que ele
fornece.
Objetos de tipos similares agrupados formam classes. Elas definem o espaço de estado, e as
operações de seu tipo que podem ser aplicadas sobre objetos da classe. Um objeto concreto de uma
classe é uma instância, que é um conjunto de dados que obedece uma estrutura e tipos de atributos
definidos em uma classe. Este tipo de representação permite uma modelagem que pode relacionar
16
objetos de diferentes tipos como: relações taxionômicas e relações composicionais
(WANGENHEIM & WANGENHEIM, 2003).
Segundo Wangenheim & Wangenheim (2003), as vantagens da modelagem orientada a
objetos são:
o Representação dos casos estruturada e natural;
o Representações estruturadas e relacionais podem ser representadas diretamente;
o Armazenamento mais compacto do que em representações atributo-valor; e
o Informação estrutural pode ser utilizada para a adaptação da solução.
2.2.2.1.3. Redes Semânticas
É um tipo específico de grafo utilizado para representar conhecimento na forma de um
grafo, similar a uma rede. Uma situação ou uma entidade quase sempre possui uma estrutura
composta, que é representada com nodos representando unidades conceituais e arestas dirigidas
representando relacionamentos entre estas unidades. Um tipo específico de rede semântica é a Rede
de Recuperação de Casos (RRCs).
RRCs são capazes de trabalhar com termos vagos e ambíguos podendo manipular bases de
casos de tamanho razoável de forma eficiente. As RRCs baseiam-se em princípios de Redes Neurais
para pesquisar na base de casos. Uma RRC é considerada como uma Entidade de Informação (EI),
que é uma parte atômica de um caso ou de uma consulta. Um caso-RRC consiste em um descritor
de caso único e uma série de entidades de informação.
2.2.2.1.4. Árvores k-d
A idéia básica em utilizar árvores como estrutura de recuperação e armazenamento é a de
estruturar o espaço de busca com base na densidade observada. O principal exemplo de estruturas
de árvores utilizadas em um RBC são árvores k-d, que são árvores de pesquisa binária k-
dimencionais. Elas representam dados estruturados de acordo com k-chaves, e são árvores de busca
binária onde em cada nível se utiliza uma chave diferente, dentre suas k chaves, sendo k os atributos
dos casos armazenados.
17
Em uma árvore k-d, uma busca é realizada de forma incremental para achar dentro de um
conjunto de casos o caso mais similar. Isso é feito de maneira que se construa uma árvore que
divide o espaço de busca em partes, levando-se em conta a similaridade entre os casos. As folhas da
árvore que contêm um subconjunto específico de casos não mais divididos, são chamadas de
repositório de casos.
2.2.2.2. Indexação
Para Kolodner, (1993), indexação de casos é a associação de rótulos em casos de forma a
caracterizá-los para posteriormente recuperá-los em base de casos, mas esta não é uma tarefa
simples, pois para construir uma boa coleção de índices para um conjunto de casos, é necessário se
ter em mente o que faz um índice "bom" e como escolhê-lo.
As informações são indexadas para que possam mais fácil e rapidamente serem recuperadas.
Em livros, por exemplo, há a preocupação com a correta identificação das necessidades futuras de
recuperação para melhor definir quais informações farão parte dos índices (LAGEMANN, 1998).
Os índices de um caso são tão importantes como os índices de livros em uma biblioteca. A
indexação se faz necessária para que os casos possam ser recuperados, sendo ela quem determina
quais os atributos que devem ser comparados para se avaliar a similaridade entre o caso de entrada e
os casos da base (Kolodner & Leake, 1996; Weber-Lee, 1998 apud RAMALHO, 1999).
A indexação é a essência do RBC, pois orienta a avaliação da similaridade, e determina o
que comparar entre os casos para determinar sua similaridade. Assim, um RBC além de usar índices
com os objetivos de facilidade e rapidez na recuperação, também os usa para realizar eficientemente
a atribuição de similaridade entre os casos (LAGEMANN, 1999).
Segundo Kolodner (1993) uma boa indexação deve ter as seguintes características:
o Antecipar o vocabulário que será usado na recuperação;
o Utilizar os conceitos que são normalmente usados para descrever os casos através de
características superficiais ou mais abstratas;
o Antecipar as circunstâncias nas quais a recuperação será realizada; e
o Ser suficientemente concreto para facilitar a reorganização em futuras situações.
18
A seleção de índices é o processo de identificação de descritores para um caso particular. A
comunidade de RBC tem proposto diversos gridlines para a escolha de índices (KUHNEN, 2000):
o índices devem ser preditivos;
o predições feitas devem ser úteis;
o índices devem ser abstratos o suficiente para tornar o caso útil em uma variedade de
futuras situações; e
o índices devem ser concretos o suficiente para serem facilmente reconhecíveis em futuras
situações.
Uma difícil tarefa na definição dos índices é prever que tipos de necessidade irão surgir e
que tipos de informações serão necessárias para recuperar casos em situações futuras. Muitos
esforços foram feitos para estabelecer regras gerais de vocabulário de índices em classes
particulares nas tarefas de RBC, mas esta tarefa acaba ainda sendo desenvolvida para atender os
objetivos específicos da recuperação de cada aplicativo que use RBC (LAGEMANN, 1998).
Segundo Kolodner (1993), existem muitos métodos de indexação automática, e dentre eles
estão:
o Indexação por meio de Entidades de Informação (EIs): tendem a ser preditivas ao longo
de todo domínio;
o Indexação baseada em diferenças: que seleciona índices que diferenciam um caso do
outro;
o Métodos de generalização baseados em similaridade e em explicação: produzem um
conjunto apropriado de EIs como índices para casos abstratos (protótipo) a partir de
casos que compartilham um conjunto comum de EIs, enquanto as EIs não
compartilhadas são usadas para um segundo nível de indexação dos casos específicos; e
o Método de aprendizado por indução: identificam automaticamente EIs preditivas, que
são então usadas como índice.
19
2.2.2.3. Similaridade
Segundo Wangenheim & Wangenheim (2003), a primeira idéia concebe similaridade como
uma relação entre objetos ou fatos, que existe ou não existe. A segunda idéia pressupõe a idéia de
uma similaridade maior ou menor, enquanto o terceiro enfoque postula a quantificação da extensão
desta semelhança.
Segundo Fernandes (2003), um caso será similar ao outro quando as características que
representam realmente o conteúdo e o contexto do mesmo forem semelhantes.
Uma medida de similaridade sobre um universo U é uma função do tipo ilustrado na
Equação 1.
sim(x, y): (U x U -> [0,1]) Equação 1
Existem muitas medidas de similaridade que podem ser citadas como:
o Nearest Neighbour (vizinho mais próximo): é bastante simples para determinação da
similaridade entre dois casos. A idéia básica é que as ocorrências em uma base de casos
podem também ser vistas como pontos em um espaço multidimensional. O conceito do
Nearest Neighbour é uma soma, onde cada índice tem uma importância para determinar
o vizinho mais próximo ponderando os índices. Por exemplo, o modelo de uma máquina
é considerado mais importante do que a correia do motor;
o Distância de Haming: que é definida como o número de bits divergentes em dois vetores
x e y de mesmo tamanho; e
o Medida de similaridade invariante é aquela onde todos os atributos usados no seu cálculo
são simétricos.
2.2.2.4. Recuperação
Recuperar é o processo de retornar um ou mais casos da base de casos em resultado à
comparação de um novo caso com cada um dos casos da base. Essa comparação é feita por meio de
uma avaliação de similaridade. O resultado dessa comparação é a seleção de um caso ou uma
combinação de casos que sugere uma solução para o novo caso (KOLODNER, 1993).
20
É importante nesta etapa que o sistema de RBC possua meios de identificar os casos que
tenham um potencial para serem mais úteis. Determinar o quanto um caso pode ser útil, requer
considerações sobre quais são os propósitos a que ele se destina e quais dos seus aspectos foram
relevantes no passado. Os procedimentos de comparação estarão habilitados para determinar quais
dimensões de um caso devem ser focadas no julgamento da similaridade (Leake, 1996 apud
RAMALHO, 1999).
Considerando que a definição dos índices retrata todos os aspectos a serem considerados na
recuperação, os algoritmos de comparação poderão usá-los para se orientar na busca, determinando
quais características devem ser focadas no julgamento da similaridade. Qualquer caso pode ser
indexado de várias formas, entretanto, o importante é que o algoritmo de comparação esteja apto a
distinguir entre os aspectos relevantes em cada caso específico (LAGEMANN, 1998).
Dada uma especificação de entrada de um problema, o sistema realiza uma pesquisa na sua
memória de casos. Se existir um caso na base idêntico ao caso de entrada (o que é raro
acontecer), o caso recuperado pode ser usado diretamente para solucionar o problema. Porém, se
isso não acontecer (o caso é apenas similar ao problema de entrada), o sistema seleciona e
recupera os casos que mais se assemelham ao caso de entrada (KUHNEN, 2000).
2.2.2.4.1. Algoritmos de Recuperação
A seguir serão descritos alguns dos principais algoritmos de recuperação.
Matching e Ranking
Realiza uma procura em locais de memória diretamente através de heurísticas match e
ranking, acessando casos que podem ser úteis. Conforme Kolodner (1993), match é um processo
que compara dois casos entre si e determina o grau de similaridade entre eles. Ranking, ordena os
casos partially-matching conforme sua utilidade, determinando qual é melhor que os outros.
As entradas de dados para os processos de match e ranking são: novo problema que o
sistema está tentando resolver, o objetivo de uso para os casos recuperados, o conjunto de casos
recuperados, índices associados com cada caso recuperado, e critério de match razoável, indicando
quando os procedimentos de Match e Ranking devem parar.
21
Contagem de Características
Neste método, o cálculo da similaridade consiste da contagem dos atributos do caso
armazenado na base que coincidem com os atributos do caso de entrada. A cada atributo i do caso
armazenado na base igual ao atributo i do caso de entrada, soma-se 1 ao número de atributos
coincidentes entre os dois casos. O grau de similaridade entre o novo caso e o caso armazenado na
base é dado pelo percentual do número de atributos coincidentes entre os dois casos em função do
número de atributos considerados para a comparação destes.
Nearest Neighbour Retrieval (O Vizinho mais Próximo)
Esta é uma técnica muito utilizada por ter uma fácil implementação, e o primeiro passo para
aplicá-la é identificar as características essenciais para resolução do problema, sendo as mesmas
representadas por algum sistema de coordenadas, para que a medida de distância entre os casos
existentes e um novo caso possa ser medida. Ainda pode-se considerar outros fatores além dos
selecionados, o que fará com que atributos tenham pesos diferenciados.
A similaridade entre um novo caso e um caso existente é determinada para cada atributo.
Esta medida deve ser multiplicada por um fator peso, e calculada a somatória de todos os atributos,
permitindo assim estabelecer uma medida de similaridade entre os casos.
Nenhum algoritmo de recuperação informa qual a distância que será alimentada pela
distância real. Para isto existem várias medidas de distância como: distância euclidiana, distância
euclidiana quadrada, city-bloch, chebychev, percentual, etc.
A fórmula de similaridade pelo vizinho mais próximo, segundo Fernandes (2003), é
representada como ilustrado na Equação 2.
Similaridade(N, F) = wFN ii
n
ii
f *),(1�
=
Equação 2
Onde:
N = novo caso
F = caso existente
22
n = número de atributos
i = atributo individual variando de 1 a n
f = função de similaridade para o atributo i nos casos N e F
w = peso do atributo i.
O cálculo será aplicado para toda a base de casos para que se obtenha um ranking dos
mesmos. A similaridade normalmente varia de um intervalo entre 0 e 1, sendo 0 atribuído ao caso
sem similaridade e atribuído 1 ao caso que tiver a similaridade exata (FERNANDES, 2003).
Como saber qual algoritmo de recuperação especifica qual distância que será alimentada
pela distância real, existem várias medidas de distância que podem ser aplicadas, segundo
Fernandes (2003):
Distância Euclidiana: sendo a mais utilizada, trata somente da distância geométrica em um
espaço multidimensional. Sua fórmula pode ser representada como ilustrado na Equação 3.
distancia(x, y) = ½2)(���
��� −� yx
ii
i
Equação 3
Distância Euclidiana Quadrada: é o quadrado da distância euclidiana padrão. O espaço vai
crescendo à medida que os objetos aparecem. Sua fórmula pode ser representada como ilustrado na
Equação 4.
distancia(x, y) = 2)( yxi
ii−� Equação 4
Distância City-block (Manhattan): é a distância média entre as dimensões. Em muitos casos
esta medida gera resultados parecidos com a distância euclidiana, mas o efeito de grandes
diferenças é minimizado aqui. Sua fórmula pode ser representada como ilustrado na Equação 5.
distancia(x, y) = � −i
ii yx Equação 5
23
Distância Chebychev: indicada para casos em que seja necessário definir dois objetos como
diferentes, se os mesmos forem diferentes em qualquer dimensão. Sua fórmula pode ser
representada como ilustrado na Equação 6.
distancia(x, y) = yx iiMaximum − Equação 6
Distância Forte: aplicada quando a forma de incrementar ou decrementar o peso progressivo
alocado na dimensão do objeto é muito diferente. Sua fórmula pode ser representada como ilustrado
na Equação 7.
distancia(x, y) = ½
�
��
−�i
p
ii yx Equação 7
Distância Percentual: medida extremamente útil para dados em que a dimensão analisada for
natural. Sua fórmula pode ser representada como ilustrado na Equação 8.
distancia(x, y) = ( )
i
numberof yx ii≠
Equação 8
Conforme Fernandes (2003), havendo pesos diferentes para as características, a distância
entre o novo caso (N) e o caso existente (A) é dada pela fórmula representada como ilustrado na
Equação 9.
( ) ( )WYWXd yaxaa** += Equação 9
Recuperação Indutiva
Segundo Fernandes (2003), a técnica de recuperação indutiva é utilizada em ferramentas
comerciais mais poderosas, e classifica padrões entre os casos, particionando-os em conjuntos, ou
clusters. Cada conjunto possui casos similares, e um dos requisitos da indução é uma definição da
característica do novo caso. Casos que possuem descrição similar e referem-se a problemas
similares pretendem chegar a soluções similares.
24
Na recuperação indutiva são construídas árvores de decisão baseadas em dados de
problemas passados. Em sistemas de RBC, a base de casos é analisada por um algoritmo que irá
classificar ou indexar os casos. Um dos mais conhecidos é o algoritmo ID3. A técnica indutiva é
bem mais rápida que as demais, executando-se os casos em que a base de casos é muito grande. O
principal problema desta técnica é que em casos inéditos não haverá recuperação de nada
(LAGEMANN, 1988).
Recuperação Seqüencial
Segundo Wangenheim & Wangenheim (2003), a Recuperação Seqüencial é a mais simples
técnica de recuperação, pois nela a medida de similaridade é calculada seqüencialmente para todos
os casos da base, permitindo a determinação dos m casos mais similares. Para a determinação de
uma relação de preferência específica para a situação, aplica-se sucessivamente o conceito de
similaridade do sistema a cada um dos casos da base de casos. Depois todos os casos são ordenados
de acordo com a sua similaridade com a consulta, sendo o resultado os m casos mais similares. Este
método é um método de aplicação universal.
TIPOS: TipoCaso = ... SimCaso = REGISTRO Case : TipoCaso; similaridade: [0..1] FIM; VARIAVEIS: ListaCasoSim : VETOR [1..m] DE SimCaso CaseBase: ARRAY [1..n] DE TipoCaso (* base de casos *) Consulta : TipoCaso
Figura 2. Estrutura de dados da recuperação seqüencial Fonte: Wangenheim & Wangenheim (2003)
FUNCAO SelecRel(CaseBase,Consulta, m): ListaCasoSim INICIO ListaCasosSim[1..m].similaridade := 0 PARA i := 1 TO n FACA SE sim(Consulta,CaseBase[i]) > ListaCasoSim[m].similaridade ENTAO insira CaseBase[i] em ListaCasoSim RETORNE ListaCasoSim FIM
Figura 3. Algoritmo de recuperação seqüencial Fonte: Wangenheim & Wangenheim (2003)
Segundo Wangenheim & Wangenheim (2003), este processo possui vantagens tais como: o
processo é comprovadamente completo e correto, pois é aplicado seqüencialmente a todos os casos
da base de casos; sua implementação é extremamente simples; aceita utilização de medidas de
25
similaridade arbitrárias, pois não utiliza nenhum tipo de indexação; e permite consultas ad-hoc
independentes do conceito de similaridade, também por não possuir indexação.
Uma das principais desvantagens deste processo, conforme Wangenheim & Wangenheim
(2003), é a má performance para bases com um grande número de casos ocasionado pelo fato do
método ser aplicado seqüencialmente. Outras desvantagens são: esforço de recuperação constante,
independentemente da complexidade da consulta e do número de casos a serem recuperados; e o
esforço de recuperação não pode ser reduzido ou limitado por conhecimento adicional, como
conhecimento de domínio.
2.2.2.5. Adaptação
Pelo fato de nenhum problema passado ser exatamente igual a um problema atual, soluções
passadas geralmente são adaptadas para solucionar novos problemas (KOLODNER, 1993).
Adaptação pode ser uma simples substituição de um atributo da solução por outro ou uma complexa
e total modificação na estrutura da solução.
A adaptação pode ser feita de várias formas (LAGEMANN, 1998):
o Pela inclusão de um novo comportamento à solução recuperada;
o Pela eliminação de um comportamento da solução recuperada; ou
o Pela substituição de parte de um comportamento.
Podem ocorrer situações onde há a presença de mais de uma das formas. A etapa de ajuste
da situação é necessária quando o usuário encontra dificuldades em apresentar o problema de
entrada nos moldes dos casos da base. Se este problema ocorre, deve-se fazer os ajustes necessários
para que se possa comparar o caso de entrada com os casos da base (Weber-Lee, 1998 apud
KUHNEN, 2000) .
2.2.2.6. Aprendizagem
Na IA, quando se fala de aprendizagem, é comum pensar no aprendizado por generalização,
tanto pela indução quanto baseado em explicações. Enquanto a memória de RBC informa sobre
similaridades entre casos e também informa sobre quando generalizações podem ser formadas. O
RBC obtém a maioria do seu aprendizado de duas maneiras (LAGEMANN, 1998):
26
o Pela acumulação de novos casos; e
o Pela identificação de quais índices utilizar ou não na recuperação.
Algoritmos de Aprendizagem Baseados em Instâncias: a aprendizagem baseada em
instâncias (IBL – Instance Based Language) pode ser usada para selecionar casos para classificação
em RBC, ter uma única entrada – seqüência de instâncias. O IBL utiliza uma metodologia que
possui uma descrição conceitual, uma classificação e instâncias similares com classificações
similares (KUHNEN, 2000).
Os componentes do IBL são:
o função de similaridade – calcula a similaridade entre a instância de treinamento ‘i’ e as
instâncias na descrição conceitual;
o função de classificação – usa o valor da similaridade e o registro de classificação na
descrição conceitual para classificar ‘i’; e
o atualizador da descrição conceitual – mantém um registro da performance das
classificações e decide quais instâncias irão ser incluídas na descrição conceitual.
Algoritmo IB3 (Instance Based 3): o IB3 aceita uma instância se sua precisão de
classificação for significativamente maior que a freqüência observada da classe. Utiliza um
intervalo de confiança de proporção para determinar quanto uma instância é aceitável, medíocre ou
com ruído (KUHNEN, 2000). No IB3 são utilizados dois intervalos de confiança:
o precisão de classificação; e
o freqüências relativas observadas da classe.
2.3. Pesquisa e Análise de Soluções Similares
Para que fosse possível o desenvolvimento do sistema proposto foram pesquisados outros
sistemas de RBC, a fim de se obter um maior conhecimento sobre este tipo de ferramenta e utilizar
os conceitos já aplicados, e que deram certo para que se enquadrem na solução proposta este
projeto. Abaixo segue uma descrição resumida sobre o problema que foi resolvido, características e
métodos aplicados em cada uma das ferramentas estudas.
2.3.1. O iHotel
27
O iHotel foi um sistema desenvolvido por Kuhnen (2000). É um sistema de consulta sobre
informações hoteleiras que utiliza técnicas de Raciocínio Baseado em Casos para apresentar os
resultados ao cliente. Foi desenvolvido com a finalidade de auxiliar e facilitar o processo de escolha
de uma determinada hospedagem pelos clientes, bem como oferecer alguns informativos como:
mapas, fotos, links dentre outros. O iHotel trabalha com os atributos da indústria hoteleira que o
cliente considera relevante para sua estada em algum lugar. Este sistema não se restringe
especificamente a hotéis propriamente ditos, mas também pode ser utilizado para camping,
pousadas, chalés e todo tipo de hospedagem.
O sistema foi projetado para o ramo da hotelaria, e direcionado especificamente para o setor
de hospedagem em geral, de modo a facilitar a iteração entre o hóspede e a hospedagem, por meio
da consultas diferenciadas.
O iHotel é uma ferramenta multiplataforma que tem seu acesso provido via web. Foi
totalmente escrito utilizando a linguagem de programação PHP, e tem como servidor de banco de
dados o banco MySQL. O sistema utiliza a técnica de Inteligência Artificial, Raciocínio Baseado
em Casos para buscar em sua base de casos o melhor resultado para indicar ao cliente.
Alguns módulos do iHotel podem ser citados como:
Consulta i-hotel: o cliente acessa o sistema via web, obtém uma página dinâmica onde as
opções de consulta vêm direto da base de dados. O cliente preenche alguns campos obrigatórios e
outros campos que achar importantes e de acordo com seu perfil, e envia uma consulta para o RBC.
Hospedagens: o cliente acessa as soluções resultantes da consulta, que possuem
informações tais como: foto, endereço e dados da hospedagem.
Inteligência Artificial: o cliente acessa por meio do link Int. Artificial uma página Web
contendo informações sobre o uso da Inteligência Artificial neste sistema e uma introdução básica
do que é o Raciocínio Baseado em Casos.
Sistema: o cliente acessa pelo link Sistema uma página Web com informações sobre o
sistema propriamente dito, tais como: suas vantagens em relação a outros mecanismos de busca, a
importância do uso do Raciocínio Baseado em Casos e referências para o desenvolvimento.
28
A aquisição do conhecimento para a base de casos do iHotel foi desenvolvida com o auxilio
de um supervisor de campo, em um processo de extração do conhecimento a ser utilizado no
sistema. Primeiramente identificou-se quais os atributos do caso (dados da hospedagem) deveriam
ser armazenados na base de casos. Para o desenvolvimento da base de casos, utilizou-se segundo
sugestão do especialista, características da hospedagem, em que o usuário pudesse definir desde a
de maior até a de menor importância.
Para a representação dos casos do iHotel foi utilizado uma estrutura de frames para a
modelagem do conhecimento extraído do especialista, por esta ser uma estrutura para representação
de situações estereotipadas. Através de uma combinação de listas encadeadas o sistema modela a
memória de casos de forma dinâmica, carregando na memória da máquina apenas os atributos
relevantes para o cálculo da similaridade e recuperação dos casos.
Para a recuperação dos casos da base o iHotel utilizou uma combinação entre dois métodos:
o método de Contagem de Características (Features Count) e o método do Vizinho mais Próximo
(Nearest Neighbour), chamada de métrica híbrida, que possibilita uma recuperação do caso com
maior precisão para aquilo que está se pretendendo. A funcionalidade dos dois métodos ficou
disposta da seguinte forma: para alguns dos atributos, foi utilizado o método de Contagem de
Características e, para outros, o Vizinho mais Próximo, ficando a cargo do usuário a atribuição dos
pesos de cada característica do novo caso que ele está preenchendo para a recuperação dos casos
similares, deixando assim uma maior liberdade para que o usuário possa definir aquilo que mais tem
importância para ele.
A função para cálculo da distância aplicada na recuperação dos casos foi a Distância do
City-Block, que consiste em calcular o módulo da distância entre cada atributo do novo caso e o
atributo correspondente de cada caso armazenado na base. O limiar de similaridade foi estipulado
em no máximo dez casos a serem recuperados da base, sendo apenas listados como resultados os
dez casos mais similares. O resultado ideal para o problema é o de um caso que tem para o método
do Vizinho mais Próximo o menor valor encontrado no cálculo de distância City Block, ou seja, o
caso que tiver mais próximo do novo caso, e para o método da Contagem de Características o caso
que tiver o maior valor somado da contagem das características semelhantes.
2.3.2. SistLog
29
O SistLog foi um sistema desenvolvido por Miranda (2000). Este sistema foi criado para que
professores das disciplinas de algoritmos utilizassem como auxílio na correção de avaliações. Tem
como objetivo de padronizar as correções de avaliações da disciplina de algoritmos do curso de
Ciências da Computação da Univali, mantendo o padrão e coerência no método de avaliação dos
alunos, aproximando a forma de avaliação dos diversos professores.
O SistLog foi desenvolvido utilizando como ferramenta de programação e desenvolvimento
a IDE do Delphi 5.0. O banco de dados que foi utilizado para o sistema foi o Paradox 7.0, também
da empresa Borland.
O SistLog foi implementado utilizando a técnica de Raciocínio Baseado em Casos, ou seja,
consegue encontrar a melhor solução para um novo caso baseando nos casos armazenados na base
de casos que mais se assemelhem ao novo caso. Cada questão da avaliação é avaliada tendo como
parâmetro nove itens:
o A lógica de programação correta?;
o As estruturas de controle foram utilizadas adequadamente?;
o As saídas são solicitadas no problema?;
o Os dados que o usuário deve informar foram lidos?;
o As variáveis foram declaradas?;
o Todas as variáveis foram declaradas corretamente quanto ao tipo?;
o As variáveis que precisam ser inicializadas foram inicializadas corretamente?;
o Todas as variáveis declaradas foram utilizadas?; e
o Quanto a sintaxe, o algoritmo está correto?.
O usuário fornece os pesos de cada item de cada questão, e o peso de cada item para
recuperação montando assim a hierarquia para recuperação. O sistema vai buscar na base somente
as notas dos alunos que tiverem 98% de similaridade, e após isso ele faz uma pesquisa em uma
outra base de casos da qual trará observações pertinentes ao aluno, baseado na média de cada item,
por exemplo, se o aluno tirou 5,0 na média lógica, o sistema traz uma observação informando que o
aluno entra-se com problemas neste quesito. A Figura 4 mostra a tela de cadastro de notas do
SistLog.
30
Figura 4. Cadastro de Notas Fonte: Miranda (2000)
A Figura 5 mostra a tela de cadastro de pesos de itens de avaliação.
Figura 5. Cadastro de Pesos Fonte: Miranda (2000)
A Figura 6 mostra a tela de resultados da consulta do RBC.
31
Figura 6. Tela Resultado da Consulta Fonte: Miranda (2000)
Para a aquisição do conhecimento do SistLog, primeiro foram identificados os itens que
deveriam ser avaliados em cada questão, e como deveriam ser armazenados na base de casos. No
desenvolvimento da primeira base de casos foram utilizadas notas para cada item específico, que
seriam recuperados de acordo com o peso de recuperação determinado pelo usuário, e a segunda
base de casos foi constituída das médias de cada um dos itens.
Para a representação dos casos utilizou-se uma estrutura de frames para modelar o
conhecimento do especialista. Esta estrutura foi utilizada combinando listas encadeadas, para que a
memória de casos fosse modelada de forma dinâmica, carregando na memória somente os atributos
que fossem realmente necessários.
Os métodos de recuperação utilizados foram o do Vizinho Mais Próximo (Nearest
Neighbour) para a recuperação da nota do aluno, e o método de Contagem de Características
(Features Count) para a recuperação das observações pertinentes ao aluno. A definição dos pesos
32
de recuperação de cada característica de um novo caso a ser consultado fica a cargo do usuário, o
que deixa em aberto para escolha do que é mais importante ou não. Para o cálculo da distância foi
utilizada a função do city-block, sendo que serão recuperados no máximo dez casos da base, que
tenham no máximo a distância de 0,1 para que se tenha um maior nível similaridade.
2.3.3. RBC para o Problema de Suporte ao Cliente nas Empresas de Prestação de Serviço de Software: O Caso Datasul
Este sistema foi resultado por Lagemann (1998). É um sistema computacional com
inferência inteligente, criado para automatizar o atendimento dos clientes no suporte telefônico da
empresa Datasul. O objetivo deste sistema foi melhorar a prestação de serviço de suporte ao cliente
através de um sistema de um sistema de Help Desk, onde o usuário a partir de uma base de casos já
existente, pudesse realizar buscas e encontrar respostas para seus problemas através de problemas
muito similares aos seus, já resolvidos e armazenados na base de casos.
A Datasul é uma empresa com matriz em Joinville (SC) e filiais em São Paulo, Rio de
Janeiro, Minas Gerais, Rio Grande do Sul, franquias no Paraná, Ceará, Santa Catarina, Campinas e
Bahia e subsidiárias nos Estados Unidos, África do Sul e México. Na época era fundamental para a
empresa que uma proposta de solução gerasse o menor custo possível, aproveitando a base de dados
de FO´s (fichas de ocorrências) já cadastradas e toda a tecnologia já disponível na empresa.
Para o desenvolvimento do sistema foi utilizado o programa Progress como gerenciador de
banco de dados e linguagem de programação para a implementação da solução, já que é a
linguagem utilizada como base para os softwares da Datasul.
O conhecimento para a base de casos foi originado de um banco de dados de FO’s, e os
atributos escolhidos assumem diferentes funções, como descrever o caso, indexar o caso para
orientar a recuperação, descrever soluções e armazenar informações sobre o resultado do uso do
caso. Após a definição do conteúdo e o contexto dos casos, foram definidos os atributos que melhor
representam as experiências descritas nas fichas de ocorrência (FO´s) da empresa a serem
recuperadas.
A estrutura para representação dos sinônimos é baseada na teoria de listas circulares
duplamente encadeadas, e a função de distância que o sistema utiliza para calcular a similaridade é
a do city-block, sendo que o sistema também recorre a um conjunto de 21 regras, que são usadas
para determinar o valor da medida de similaridade. Estas regras foram definidas para que fossem
33
considerados, na comparação e na avaliação da similaridade, produtos e módulos que possuíssem
alguma semelhança na natureza do negócio. Esta função de similaridade definida, foi obtida a partir
de vários testes com validação da recuperação por parte dos especialistas da Datasul. As
similaridades dos atributos e seus pesos foram testadas com um grande número de combinações
possíveis e com diferentes números.
A Figura 7 mostra a tela de consulta do sistema de Help Desk.
Figura 7. Tela de consulta do Help Desk Fonte: Adaptado de Lagemann (1988)
A recuperação é feita pelo Help Desk considerando a medida de similaridade dos casos
candidatos. O sistema através da sua função de recuperação possibilita ao usuário informar um
limiar para a medida de similaridade para os casos que serão recuperados. Os casos recuperados são
listados possibilitando ao usuário acesso aos atributos problema detalhado e solução do problema.
A Figura 8 mostra o resultado da consulta.
34
Figura 8. Tela com caso recuperado Fonte: Adaptado de Lagemann (1988)
O autor conclui que em torno de 66% dos testes obteve-se sucesso, ou seja, uma solução
passada serviu para resolver um novo problema. Constatou-se que é possível aumentar o percentual
de sucesso instruindo o usuário do Help Desk a dirigir a descrição do problema para aproveitar
melhor as potencialidades do mecanismo de inferência, através do uso de palavras técnicas e pela
variação do limite do percentual de similaridade.
2.3.4. Avaliação Geral Sobre as Soluções Estudadas
Todas as ferramentas estudadas são ferramentas que utilizam técnica de Inteligência
Artificial Raciocínio Baseado em Casos como base, e talvez com algumas adaptações podem ser
utilizadas diretamente para o mercado. O sistema do caso Datasul e o iHotel possuem uma estrutura
que foi desenvolvida para atender um mercado e com poucas alterações podem alcançar este
propósito, já o SistLog foi desenvolvido para o meio acadêmico e talvez para seu uso em escala
necessite de uma pequena reestruturação para melhorar a usabilidade do sistema.
Das ferramentas estudas, o iHotel foi a que possui uma modelagem mais parecida com o
sistema proposto, pois além de utilizar o RBC e ser um Help Desk, possui acesso via web. Foi uma
ferramenta bem elaborada que possui um grande potencial comercial.
Outra consideração importante é sobre o SistLog, pois também utiliza RBC de uma forma
bem elaborada, pois possui duas bases de dados para que se possa dar uma resposta mais completa a
35
respeito da avaliação, mas possui um ponto desfavorável, que é o fato dela ter sido desenvolvida
utilizando o banco de dados Paradox 7.0. Pelo fato do Paradox ser um sistema de banco de dados
baseado em arquivos, para uma aplicação com utilização de RBC em que se utiliza muitas consultas
ao banco, seria um grande ponto desfavorável. Seus arquivos de dados contêm registros que
possuem uma ordem fixa, ou seja, o registro de número 1000 será sempre o mesmo registro, até que
seja movido fisicamente dentro do arquivo através de alguma operação de ordenação. Além disso a
aplicação deve ser utilizada aconselhavelmente com menos de 10 usuários concorrentes e não tem
um desempenho bom com bases de dados com tamanho superior a 100 MB. (CLUBEDELPHI,
2006).
O Help Desk do caso Datasul é um sistema que foi muito bem projetado no que diz respeito
a técnica de RBC aplicada, tendo uma grande base de conhecimento inicial e métodos de avaliação
da similaridade e recuperação bem refinados. Um ponto desfavorável desta ferramenta é a
acessibilidade, já que foi projetado para operar em sistema Desktop.
2.4. Tecnologias Utilizadas no Sistema
Para o desenvolvimento do sistema proposto, foi utilizado um conjunto de tecnologias de
mercado que atendem as necessidades descritas pelo modelo. Os motivos pelos quais estas
tecnologias serão utilizadas são descritos a seguir.
2.4.1. Java
Foi disponibilizada pela empresa Sun Microsystems no ano de 1995 e vem provocando
entusiasmo até hoje em programadores analistas e projetistas de software. Ela é um resultado de um
longo e consistente trabalho de pesquisa e desenvolvimento, o que a torna muito mais do que uma
simples linguagem de programação, ela é um ambiente de desenvolvimento e execução de
programas que exibe as facilidades proporcionadas pela orientação a objetos, extrema portabilidade
de código produzido, pelas características de segurança que apresenta e pela facilidade de
integração com outros ambientes, principalmente a Internet (SAOFRANCISCO, 2006).
O Java é uma linguagem que possui uma sintaxe semelhante ao C, e através dela torna-se
possível a criação de aplicativos como os applets, servlets e JavaBens. Foi desenvolvida dentro de
um processo colaborativo (Java Community Process) pela comunidade internacional de tecnologia.
A abertura deste processo fez surgir uma grande comunidade de desenvolvedores que oferecem
36
extensões, gratuitas ou não, para a resolução de questões fundamentais à programação de
aplicativos empresariais tais como, a persistência de dados, controle de transações, implementação
de segurança e gerenciamento de memória e cache. (CONSOLE, 2005).
Esta linguagem é utilizada com muito sucesso por muitas empresas. Um exemplo deste
sucesso é a segurança que está presente principalmente nas instituições financeiras, ou seja. O
Banco do Brasil, utiliza Java em 100% dos seus aplicativos BB-OfficeBank. A autenticação de
senha do Banco Bradesco também é feita com uma implementação Java. Além destes, existem
outros exemplos de sucesso. Eles optaram poelo Java por ser possível acessar seus programas de
qualquer tipo de equipamento, do mais modesto até o mais avançado, com plataforma Linux,
Windows NT, 2000 ou BeOS (sistema operacional desenvolvido pela Be Inc.) ou FreeBSD (sistema
operacional Unix baseado no Berkley 4.4 desenvolvido pela samaBSD), utilizando um navegador
Netscape, Mozilla ou IE (Internet Explorer) (CONSOLE, 2005).
2.4.1.1. Ambientes de Desenvolvimento
Para trabalhar com o ambiente Java faz-se necessário o uso de um dos ambientes de
desenvolvimento JDK (Java Developer’s Kit), estes ambientes podem ser obtidos gratuitamente
diretamente no site da Sun. O JDK (Java Development Kit) é composto basicamente por um
compilador (javac), uma máquina virual Java, um vizualizador de apllets (appletviewer), as
bibliotecas de desenvolvimento (packajes Java), um programa para composição da documentação
(javadoc), um depurador básico de programas JDB (Java Debugger), e uma versão run-time do
ambiente de execução JRE (Java Runtime Environment) (SAOFRANCISCO, 2006).
37
A Figura 9 ilustra o ambiente de desenvolvimento Java.
Figura 9. Modelo de ambiente de desenvolvimento Java Fonte: Adaptado de Saofrancisco (2006)
O JDK não é um ambiente visual de desenvolvimento, embora seja possível desenvolver
aplicações gráficas complexas utilizando somente o JDK. Outras fabricantes de software como
Microsoft, Borland, Symantec e IBM oferecem comercialmente ambientes visuais para o
desenvolvimento Java (SAOFRANCISCO, 2006).
Desde o seu lançamento o Java vem sofrendo aprimoramentos, pois devido ao aumento no
número de aplicações e, conseqüentemente, o aumento no número de bibliotecas padrão da
linguagem, foram criadas três divisões na plataforma a partir da versão 2 da linguagem: o J2SE, o
J2EE e o J2ME (INFOWESTER, 2005).
o J2SE: Java 2 Standard Edition é o ambiente de desenvolvimento mais utilizado, pois seu
uso é voltado a PCs e servidores, onde há bem mais necessidade de aplicações. Além
disso, pode-se dizer que essa é a plataforma principal, já que, de uma forma ou de outra,
o J2EE e o J2ME tem sua base aqui, por ser a plataforma mais abrangente do Java, o
J2SE é a mais indicada para quem quer aprender a linguagem;
o J2EE: o Java 2 Enterprise Edition é a plataforma Java voltada para redes, Internet,
intranets e afins. Possui bibliotecas especialmente desenvolvidas para o acesso a
servidores, a sistemas de e-mail, a banco de dados, etc. Por essas características, o J2EE
foi desenvolvido para suportar uma grande quantidade de usuários simultâneos.
o J2ME: o Java 2 Micro Edition é o ambiente de desenvolvimento para dispositivos
móveis ou portáteis, como telefones celulares e palmtops. Como a linguagem Java já era
38
conhecida e a adaptação ao J2ME não é complicada, logo surgiram diversos tipos de
aplicativos para tais dispositivos, como jogos e agendas eletrônicas.
2.4.2. JSP
O JSP (Java Server Pages), é uma tecnologia desenvolvida pela Sun Microsystems, usada
para servir conteúdo dinâmico para o usuário utilizando-se de uma lógica de dados no lado do
servidor. Permite ao desenvolvedor produzir aplicações que permitam o acesso à banco de dados
(que é o caso da empresa), a arquivos-texto, a captação de informações a partir de formulários, a
captação de informações sobre o visitante e sobre o servidor, o uso de variáveis e laços de repetição
entre outras características (UNITO ,2005).
Uma página JSP não é mais que uma página Web normal que contém porções de códigos em
Java e porções de códigos em Html junto com outros elementos como os servlets e os JavaBeans
que proporcionam informação adicional ao terminal no qual a página vai ser visualizada. O JSP não
oferece nada mais do que se possa conseguir com os servlets puros, entretanto, oferece a vantagem
de ser facilmente codificado, facilitando assim a elaboração e manutenção de uma aplicação, além
de permitir separar a programação lógica (parte dinâmica) da programação visual (parte estática),
facilitando o desenvolvimento de aplicações mais robustas, onde programador e designer podem
trabalhar no mesmo projeto, mas de forma independente. Outra característica do JSP é produzir
conteúdos dinâmicos que possam ser reutilizados (UNICAP, 2001).
As paginas JSP são um tipo de arquivo muito parecido com as páginas ASP, porém tem a
vantagem da portabilidade de plataforma podendo ser executado em muitos Sistemas Operacionais
como Microsoft Windows, Linux, Solaris, Mac OS, etc. Por definição, JSP usa Java como sua
linguagem de scripts, e por esse motivo o JSP se apresenta mais flexível e mais robusto do que
outras plataformas baseadas simplesmente em JavaScripts e VBScripts (UNICAP, 2001).
Antes que se possa usar o JSP é necessário instalar um servidor web, e um servidor JSP (que
inclui um servlet engine). Muitos servidores JSP já incorporam um servidor web, de modo que para
o desenvolver é suficiente ter somente um servidor. O NetBeans, ferramenta utilizada para o
desenvolvimento deste trabalho, já possui um servidor JSP (Tomcat) embutido por padrão. Para
executar um arquivo .jsp no NetBeans é muito simples, bastando clicar no botão executar, com o
arquivo selecionado. Esta ação instancia ambos, o servidor JSP e um browser, sendo os resultados
apresentados em seguida. As mensagens de erros emitidas pelo Tomcat dizem muito pouco ao
39
desenvolvedor, sendo para resolver alguns problemas é preferível, em muitos casos, usar o servidor
Resin (J2EEBrasil, 2005).
Quando o cliente faz a solicitação de um arquivo JSP, é enviado um object request para a
JSP engine. A JSP engine envia a solicitação de qualquer componente (podendo ser um JavaBeans
component, servlet ou enterprise Bean) especificado no arquivo. O componente controla a
requisição possibilitando a recuperação de arquivos em banco de dados ou outro dado armazenado,
em seguida, passa o objeto response de volta para a JSP engine. A JSP engine e o Web server
enviam a página JSP revisada de volta para o cliente, onde o usuário pode visualizar os resultados
através do navegador. O protocolo de comunicação usado entre o cliente e o servidor pode ser
HTTP ou outro protocolo. A Figura 10 ilustra a o fluxo de uma solicitação de um arquivo JSP.
Figura 10. Fluxo de uma solicitação de um arquivo JSP. Fonte: Unicap (2001)
2.4.2.1. Por que usar JSP?
Existem várias linguagens usadas para criar aplicações web, as principais entre elas são o
ASP, o PHP, o ColdFusion e Perl. Por que usar JSP? O JSP usa Java, que é uma das linguagens
mais populares atualmente e é interpretada, portanto o código escrito em uma arquitetura pode ser
portado para qualquer outra; o JSP é parte do pacote J2EE que é um dos modelos mais usados para
construir aplicações de grande porte, e é suportado por várias gigantes da computação como IBM,
Oracle, Sun, dentre outras. Uma das diferenças que pode ser fundamental para a escolha entre entre
40
o JSP e o ASP por exemplo, é que o ASP é da Microsoft e só roda em ambiente Windows, e
também todos os softwares necessários são pagos. JSP, é feito pela Sun e roda em qualquer
plataforma que tenha a máquina virtual de Java instalada, e tem vários softwares gratuitos para
disponibilizar a aplicação, por exemplo o Tomcat (PORTALWEBMOBILE, 2006).
Para este sistema, todas as páginas que fazem parte da interface foram desenvolvidas com o
JSP e Html. Componentes que fazem parte desta tecnologia também foram utilizados, como os
servlets, para o controle da aplicação e comunicação dos cadastros com as classes persistentes e os
beans que fazem a persistência do sistema.
2.4.2.2. JavaBeans
Um JavaBean, ou simplesmente um Bean, é uma classe de Java que segue um conjunto de
convenções simples de design e nomeação delineado pela especificação de JavaBeans. Os Beans
não precisam estender uma determinada classe ou implementar uma determinada interface. As
convenções de JavaBean são o que nos permitem desenvolver Beans, porque elas permitem que o
container Bean analise um arquivo de classe Java e interprete seus métodos como propriedades,
designando a classe como um Bean de Java.
Beans são simplesmente objetos Java., mas como seguem um padrão fica mais fácil
trabalhar com eles. Uma boa prática é colocar Bean no nome de uma classe que é um Bean, para
que seja melhor identificado. Assim uma classe que representa uma pessoa ficaria PessoaBean ou
BeanPessoa (PORTALWEBMOBILE, 2006).
2.4.2.3. Servlets
Servlets são programas Java que usam a API (Application Programming Interface) do Java
Servlet. Para se utilizar este tipo de arquivo com o JSP, é necessário empacotar os servlets em um
arquivo .WAR (Web Archive) ou módulo da Web para a implementação para o servidor de
aplicativos. Os servlets são executados em um servidor Web habilitado para Java e tem a finalidade
de estender as capacidades de um servidor, de maneira semelhante aos applets, que quando são
executados em um navegador, estendem as capacidades do mesmo. Os servlets podem suportar
conteúdo dinâmico de páginas da Web, fornecer acesso à banco de dados, atender a vários clientes
ao mesmo tempo e filtrar dados (WEBSPHERE, 2005).
41
Os servlets são programas que estendem as funcionalidades de um web server, gerando
conteúdo dinâmico e interagindo com os clientes, utilizando o modelo request/response. Eles não
são restritos ao modelo HTTP de request/response, onde na realidade são pequenas aplicações de
servidores, mas o modelo HTTP é o modelo mais comumente utilizado. A Figura 11 ilustra um
exemplo de uma arquitetura com servlets.
Figura 11. Exemplo de arquitetura de servlets. Fonte: Adaptado de ADTMAG (2006)
Optou-se pelo uso de servlets, pelo fato de ter uma estrutura que favorece seu acesso e
encaixar-se perfeitamente ao escopo do sistema. Para utilizá-los, foram encontradas algumas
dificuldades no que diz respeito a estrutura das classes que o servlet herda. Mas através de
pesquisas em sites oficiais Java e fóruns de discussão todas as dúvidas de funcionamento e
configuração foram sanadas.
2.4.3. Padrão MVC
MVC (Model View Controler), é o padrão para desenvolvimento Java para Web da SUN
Microsystems. Foi criado originalmente na linguagem Smalltalk para desenvolvimento de
aplicações gráficas. A sigla MVC vem do inglês Model View Controller (Modelo Visualização
Controle).
As camadas podem ser melhor descritas como segue:
o Model: é onde estão as regras de negócio e o acesso aos dados no sistema.
o View: é onde os dados serão apresentados ou requisitados ao usuário. Os dados são
acessados na base pela camada Model e repassados para a camada View para serem
apresentados, ou são requisitados pela camada View e repassados para a camada Model
para serem persistidos.
42
o Controller: o Controller é o responsável por fazer a ligação do View com o Model. É o
Controller que vai saber qual ação do Model deve ser chamada em cada requisição do
View.
Quando um sistema é desenvolvido utilizando a arquitetura MVC, os códigos referentes às
diferentes camadas ficam separados do resto do sistema, e sua manutenção se torna mais simples. A
troca completa de uma camada pode ser feita sem gerar efeitos nas outras, além do que múltiplas
camadas de visualização, podem compartilhar da mesma camada de negócios.
O ganho para o desenvolvimento é o de poder separar melhor as responsabilidades, diminuir
código JSP e aumentar a reusabilidade. Neste padrão é utilizada a arquitetura de implementação
com servlet, JavaBeans e JSPs. O Controle fica a cargo de um servlet que gerencia o fluxo da
aplicação Web, o Modelo é delegado para um JavaBeans e a Visualização é de responsabilidade de
uma JSP, que produz uma saída em Html para o navegador Web do cliente. A estrutura do padrão
MVC pode ser visualizada na Figura 12.
Figura 12. Arquitetura do padrão MVC. Fonte: Adaptado de JAVANOROESTE (2006)
2.4.4. MySQL
O MySQL é um servidor de banco de dados SQL multiusuário/multitarefa, que é formado
por uma implementação cliente/servidor que consiste em um servidor Mysqld e diferentes
programas e bibliotecas de clientes. O MySQL controla o acesso para que vários usuários possam
43
acessar os dados ao mesmo tempo, e assegura que só o usuário autorizado possa obter acesso.
Utiliza linguagem padrão de consulta SQL, que é uma linguagem padronizada para fazer operações
como inserção, atualizações, exclusões e acessos a informações de banco de dados. Os principais
diferenciais do MySQL são a velocidade, robustez e facilidade de utilização. É desenvolvido,
distribuído e tem suporte da MySQL AB. A MySQL AB é uma empresa comercial, fundada pelos
desenvolvedores do MySQL, cujos negócios é fornecer serviços relacionados ao sistema de
gerenciamento de banco de dados MySQL. (MYSQL, 2006).
2.4.4.1. Principais características do MySQL
O MySQL possui várias características e vantagens para o desenvolvimento, como
(MYSQL, 2006):
o Um dos melhores desempenhos do mercado;
o Está disponível sem nenhum custo, sob uma licença Open Source, ou a baixo custo sob
uma licença comercial, se necessário para aplicação;
o Trabalha com várias plataformas diferentes;
o É possível misturar tabelas para diferentes bancos de dados em uma mesma query;
o Fácil configuração;
o Capacidade de manipulação de tabelas com mais de 50.000.000 de registros;
o Fácil e eficiente na administração de privilégios de usuários;
o Sistema de senhas criptografadas flexível e seguro;
o Disponível como versão cliente/servidor ou embutida;
o Aceita diversos tipos de campos: tipos inteiros de 1, 2, 3, 4 e 8 bytes com e sem sinal,
FLOAT, DOUBLE, CHAR, VARCHAR, TEXT, BLOB, DATE, TIME, DATETIME,
TIMESTAMP, YEAR, SET e ENUM;
o Completo suporte a operadores e funções nas partes SELECT e WHERE das consultas;
o Suporte pleno às cláusulas SQL GROUP BY e ORDER BY;
Segundo Dumond & Paula (2005), o MySQL, em versões mais antigas possui algumas
limitações, como:
44
o Não implementa integridade referencial e chaves estrangeiras;
o Por padrão trabalha em modo autocommit, ou seja, não possui suporte a transações;
o Não suporta pesquisa em dois índices diferentes utilizando OR;
o No UNIX os nomes de tabelas e banco de dados são case sensitive (para todas as
versões); e
o Não suporta atributos obrigatórios.
2.4.5. NetBeans
Desenvolvido em Java, o NetBeans é um ambiente de desenvolvimento Open Source
produzido pela Sun Microsystems que tem como objetivo se tornar uma ferramenta RAD (Rapid
Application Development) para desenvolvimento de aplicativos Java nos mesmos moldes de seu
principal concorrente, o produto proprietário JBuilder, da Borland. Possui um sistema de
gerenciamento de projetos através da "montagem" de diretórios, como nos sistemas de arquivos
tradicionais do Linux, permitindo o desenvolvimento concorrente, ou seja, mais que um
programador pode trabalhar simultaneamente em um mesmo arquivo (LINUXMAGAZINE, 2006).
Seu editor de textos integrado oferece os recursos de completar automaticamente trechos de
código, visualizar métodos e atributos de objetos, identação de código e identificação, em tempo de
programação, dos trechos de código que possuem erros, o que aumenta a produtividade do
programador. Assim como em outras IDEs, o NetBeans possui visualizador de classes e ferramenta
para auxiliar na criação delas; porém, seu diferencial está no editor integrado de interfaces, que gera
automaticamente um código limpo e de fácil compreensão para leitores de código em texto puro,
caracterizando-o tanto como uma útil ferramenta RAD, quanto como um confiável framework para
produção de interfaces (LINUXMAGAZINE, 2006).
Além das funcionalidades de edição de código, possui recursos de depuração,
desenvolvimento de aplicações web utilizando Java Server Pages (JSP's) ou Servlets através do
servidor Tomcat e, em uma versão específica, funcionalidades para desenvolvimento de aplicações
móveis, além de recursos de análise de código através de técnicas de engenharia de software,
ferramentas de banco de dados e de códigos XML. E, por ser desenvolvido em Java, apesar de sua
performance poder deixar a desejar quando utilizado em máquinas mais antigas, é uma ferramenta
45
expansível e pode ser encontrada em versões para diversas plataformas (LINUXMAGAZINE,
2006).
46
3. DESENVOLVIMENTO
3.1. Introdução
Satisfazer o cliente é uma tarefa difícil de ser alcancada, mas com a era da informatização
muitas coisas começaram a mudar dentro das empresas. Os clientes são a peça chave para que uma
empresa consiga sobreviver, e para obter uma fidelidade maior dos clientes as empresas apostam
em melhorias contínuas usando todos os recursos tecnológicos ou não para deixar o cliente sempre
bem informado.
Como já citado, a melhoria no atendimento é um ponto fundamental para aumentar a
satisfação, e foi pensando neste aspecto que este projeto foi viabilizado em parceria com uma
indústria. Não basta somente possuir informações sobre o que os clientes compram, ou o quanto
eles compram, mas as empresas precisam saber também como anda a aceitação de seu produto;
quais os problemas que esses produtos apresentam ao cliente; como ajudar a resolver estes
problemas.
Este projeto possui como principal proposta, melhorar a iteração entre o cliente final e a
empresa, criando uma conexão direta onde o próprio cliente possa buscar as informações que
necessita, sem ter que entrar em contato via telefone. O objetivo é fornecer informações técnicas
sobre os problemas que os produtos apresentarem, e também captar uma maior quantidade de
informações sobre estes problemas através do Help Desk on-line. Desta forma esta base de
conhecimento, no futuro também pode ser utilizada para obter dados estatísticos sobre estes
problemas.
3.2. Sistema Proposto
Este sistema foi desenvolvido com o intuito de auxiliar a empresa no atendimento ao cliente
através deste canal de comunicação direto, e com isso diminuir a carga de atendimento via telefone
que o Setor de Atendimento ao Cliente hoje possui. Também é importante ressaltar que todo o
conhecimento para modelar a base de conhecimento foi obtido através de experiências passadas
enfrentadas em problemas que foram resolvidos pelos especialistas da empresa.
Como a empresa fabrica um grande número de modelos de máquinas, e cada modelo pode
ter características diferenciadas, o sistema teve que ser projetado para suportar essas diferenças
47
entre os diversos modelos, e também para que os novos modelos que surgirem possam ser
adicionados a base de conhecimento sem ter maiores transtornos. Ele possui uma base de dados
dinâmica, onde cada produto pode ter uma estrutura diferente e possuir uma base de conhecimento
que tenha atributos referentes a sua estrutura. Quando um novo produto é cadastrado, ele pode ser
definido com todos os atributos que aquele produto possui, formando assim uma base de
conhecimento para aquele produto.
No desenvolvimento deste sistema não foi utilizada nenhuma Shell de RBC. Para que se
obtivesse um maior conhecimento prático sobre a técnica de RBC, optou-se pela implementação
total do protótipo.
Para a implementação do protótipo foi utilizada a ferramenta de programação do NetBeans
5.0, que possui uma interface para programação muito boa para ser utilizada com o Java, além de
uma ferramenta de depuração que proporcionou uma maior comodidade para desenvolver. O JSP
foi a linguagem escolhida, primeiro porque utiliza Java e o Java possui um suporte total a
orientação a objetos; depois por ser uma linguagem multiplataforma muito utilizada na atualidade,
que apesar de ser em boa parte Open Source possui recursos fantásticos como a utilização dos
JavaBens e dos Servlets. Para desenvolvimento Java, foi utilizado o JDK 5.0, que é a última versão
lançada e serviu como base para a implementação das classes Java.
O Banco de dados utilizado foi o MySQL 4.01, que é a versão atual do banco de dados da
empresa, além de ser um banco de dados leve, possui uma alta capacidade de armazenamento e um
bom desempenho para utilização na web. Para conexão com o banco de dados foi utilizado o driver
JDBC (Java DataBase Connectivity) do MySQL mysql-connector-java-3.1.10-bin, que é uma das
versões mais recentes. O servidor de JSP foi o Apache Tomcat 5.5.9, também muito popular entre
programadores JSP. Este servidor foi instalado tanto no sistema operacional Windows XP, quanto
Linux, não apresentando nenhum tipo de problema em nenhum dos sistemas operacionais testados.
O desenvolvimento deste Sistema seguiu as seguintes etapas: modelagem do sistema, onde
foi realizada toda a análise e projeção através da definição dos requisitos, criação dos digramas de
caso de uso, diagramas de seqüência, modelos físico e lógico; definição das tecnologias utilizadas
para o desenvolvimento pelo sistema; depois foi realizada a estruturação do RBC, que é a seqüência
de desenvolvimento do RBC bem como a implementação dos métodos utilizados para cálculo da
similaridade; logo após foram realizados os testes de validação do protótipo.
48
3.3. Modelagem do Sistema
Para a modelagem do sistema proposto utilizou-se a ferramenta Enterprise Architect que
apesar de ser um software proprietário, é a ferramenta que atualmente a universidade disponibiliza
para este fim. Existem alternativas de modelagem UML como o i. e. JUDE, que é free e que
também poderia ser utilizado. Para representação foram utilizados os diagramas de casos de uso, de
seqüência e o modelo de dados além da análise de requisitos.
3.3.1. Análise de Requisitos
Para o sistema proposto, através das análises do problema apurado durante o período de
estudo, foram levantados alguns requisitos básicos para o funcionamento do Help Desk. O maior
objetivo desta seção é identificar e documentar o que é realmente necessário, desta forma
comunicando a todos os envolvidos no projeto da forma mais clara possível, de maneira não-
ambígua de modo que os riscos sejam identificados para que não ocorram imprevistos.
3.3.1.1. Requisitos Funcionais
Nesta seção são descritas diversas funções que o sistema precisa possuir, definindo assim a
funcionalidade desejada através da ocorrência de eventos internos ou externos ao sistema. A Figura
13 mostra os requisitos funcionais levantados.
Figura 13. Requisitos Funcionais
49
3.3.1.2. Requisitos Não-Funcionais
O objetivo desta etapa é permitir a portabilidade da aplicação entre diferentes plataformas e
tirar proveito das últimas tecnologias para o desenvolvimento de aplicações com interface através
da Internet. A Figura 14 mostra os requisitos não-funcionais levantados.
Figura 14. Requisitos Não-Funcionais
3.3.2. Diagramas de Casos de Uso
Estes diagramas mostram um conjunto de casos de uso e de atores e as respectivas relações
entre eles. Estes diagramas são importantes para organizar e modelar as funcionalidades principais
do sistema. São utilizados para obter uma melhor perspectiva funcional do sistema para a visão dos
seus utilizadores. A Figura 15 mostra o Use Case do Administrador do Sistema, onde pode ser
visualizado o cenário em que ele atua, bem como as funções que ele pode realizar.
50
Figura 15. Use Case do Administrador
UC 01 – Configura Usuário
Possibilita o cadastramento, alteração e exclusão e consulta dos usuários que fazem parte da
área restrita do sistema.
UC 02 – Consulta Casos
Este caso de uso descreve como um usuário que tem acesso à área restrita do sistema pode
acessar e utilizar a consulta de casos cadastrados.
UC 03 – Aprova Casos
Este caso de uso descreve como um usuário que tem acesso à área restrita do sistema pode
acessar e utilizar a consulta de casos pendentes, e como deve preceder para efetuar a aprovação dos
mesmos.
51
UC 04 – Cadastra Casos
Este caso de uso descreve como um usuário que tem acesso à área restrita do sistema pode
acessar o cadastro de novos casos e configurar um novo caso para inserção na base de
conhecimento.
UC 5 – Cadastra Produtos
Este caso de uso descreve como um usuário que tem acesso à área restrita do sistema pode
cadastrar, alterar, excluir e consultar produtos no sistema.
UC 06 – Cadastra Conjuntos
Este caso de uso descreve como um usuário que tem acesso à área restrita do sistema pode
cadastrar, alterar, excluir e consultar conjuntos no sistema.
UC 07 – Cadastra Problemas
Este caso de uso descreve como um usuário que tem acesso à área restrita do sistema pode
cadastrar, alterar, excluir e consultar problemas no sistema.
UC 08 – Cadastra Estados
Este caso de uso descreve como um usuário que tem acesso à área restrita do sistema pode
cadastrar, alterar, excluir e consultar estados de problemas no sistema.
UC 09 – Consulta Atendimentos
Este caso de uso descreve como um usuário que tem acesso à área restrita do sistema pode
acessar a consulta aos atendimentos efetuados pelo site.
UC 10 – Cadastra Grupo Produtos
Este caso de uso descreve como um usuário que tem acesso à área restrita do sistema pode
cadastrar, alterar, excluir e consultar grupo de produtos no sistema.
A Figura 16 mostra o Use Case do Cliente, onde o cliente tem como cenário principal a
Consulta de Casos que é a idéia base do Sistema Proposto. Neste cenário o Cliente pode definir o
problema que está procurando resolver, buscando possíveis soluções em problemas semelhantes que
já ocorreram.
52
Figura 16. Use Case do Cliente
UC 11 – Consulta Caso
Este caso de uso descreve como um usuário cliente pode acessar o site da empresa,
cadastrar-se e configurar um caso para consultar na base de dados do sistema.
A descrição detalhada de todos os cenários dos Casos de Uso, Diagramas de Seqüência,
diagramas de Entidade Relacionamento e tabelas que fazem parte do sistema, pode ser encontrado
na seção Apêndice A.
3.4. ANÁLISE DOS DADOS
A indústria em questão possui um pequeno cadastro com informações básicas sobre
atendimentos efetuados pelo setor de atendimento ao cliente nos últimos meses, contendo em sua
estrutura, informações sobre o produto, cliente, um campo de texto contendo a descrição da
ocorrência e outro com a ação tomada. Este cadastro, no entanto, possui muitas informações
incoerentes que precisam ser redefinidas para poder ser utilizado neste projeto.
Para tanto, foi realizada uma avaliação das informações existentes, através de relatórios
extraídos da base, onde o técnico da empresa analisou todos os registros e tudo o que foi
considerado incoerente foi descartado. O que foi considerado proveitoso passou por uma nova
avaliação de um técnico da empresa para que pudesse fazer parte da base inicial de casos nos
formatos propostos para o sistema de Help Desk.
3.5. ESTRUTURAÇÃO DO RBC
Após terem sido realizados as etapas do levantamento teórico, estudo de ferramentas de
RBC semelhantes e que possuíssem características que pudessem ser reaproveitadas no sistema
proposto, além de se ter desenvolvido uma pesquisa sobre as tecnologias a serem utilizadas e
realizar o projeto do sistema, iniciou-se o desenvolvimento do Sistema de Help Desk para Web
utilizando Raciocínio Baseado em Casos, começando pelas etapas que o ciclo de vida de um RBC
compreende. Um pequeno exemplo do fluxo geral do sistema pode ser visualizado como mostra a
53
Figura 17, que compreende as etapas que vão do acesso do cliente através da Internet onde ele
descreve o problema em uma tela padrão, quando o cliente submete a consulta o sistema aciona um
módulo de RBC para encontrar as soluções similares. Logo após o sistema exibe uma lista com os
casos mais similares, onde o cliente pode escolher um dos casos que se encaixe com o seu problema
ou descartar. Neste momento o sistema verifica se deve armazenar ou não o caso para
aprendizagem.
Figura 17. Fluxo de consulta ao RBC.
3.5.1. Aquisição do Conhecimento
Para o desenvolvimento de um sistema de RBC, faz-se necessário a utilização do
conhecimento junto a especialistas da área em que o sistema está sendo desenvolvido, pois somente
estes especialistas possuem o domínio total sobre o conhecimento necessário para o
desenvolvimento da aplicação. Para se adquirir tal conhecimento é preciso que se criem alguns
critérios, ou modelos para serem utilizados para a população da base de conhecimento do RBC.
O primeiro passo realizado foi realizar uma análise em conjunto com os técnicos da
empresa, onde foi definida uma metodologia para população da base inicial de conhecimento.
Decidiu-se que para a população inicial da base seriam cadastrados quatro produtos que possuem
um grande volume de vendas no mercado. Como a base trabalha de forma dinâmica, foram
54
identificados os atributos de cada produto escolhido, e só então cadastrado a estrutura do produto,
onde também foi definido o método para cálculo de similaridade e o peso de cada atributo. Para que
a definição da estrutura fosse realizada de maneira adequada foi fundamental a utilização do
conhecimento dos técnicos sobre os produtos e os problemas já foram apurados pelo setor de
assistência ao cliente.
Como a indústria possuía um pequeno cadastro de informações sobre os atendimentos
efetuados, foi realizada uma pesquisa sobre estas informações para apurar a possibilidade de
utilização das mesmas na população da base de conhecimento inicial. Como o cadastro não tinha
nenhum tipo de formatação de entrada de dados, ou seqüência de preenchimento, e servia somente
como uma anotação para auxilio dos técnicos como se fosse uma ficha do cliente, foi constatado
que poucos dados do que havia no cadastro era realmente útil para o escopo do sistema, e que o
trabalho de reutilização não seria viável.
Sendo assim, a população da base inicial de casos, bem como para a definição das variáveis
e seus respectivos pesos, ficou por conta dos técnicos do setor de assistência ao cliente da empresa,
pois são eles que possuem o conhecimento necessário para que os dados fiquem de uma forma
coerente na base de conhecimento. Como não foi possível reaproveitar os dados antigos que a
empresa possuía, o cadastramento dos casos foi iniciado com uma base totalmente limpa.
3.5.2. Representação dos Casos
Após ter-se definido os atributos durante a etapa de aquisição do conhecimento, fez-se
necessário identificar a melhor técnica para a representação dos casos de acordo com o modelo
proposto, onde foi definido como a memória de casos do sistema ficou disposta(WANGENHEIM &
WANGENHEIM, 2003).
Para representação da estrutura dos casos decidiu-se pela utilização de frames para
modelagem do conhecimento, pois esta estrutura possui características que atenderam às
necessidades apresentadas pelo modelo proposto, proporcionando uma representação que modela a
memória de casos de forma simplificada e dinâmica. Para tanto, foi utilizada uma estrutura de dados
formada por listas encadeadas com tamanho variável onde ficam armazenados os dados. Isso
possibilita carregar na memória somente os atributos relevantes para o cálculo da similaridade e
recuperação.
55
Um frame é uma estrutura de dados semelhante a uma rede contendo nós e relações, onde os
níveis superiores são fixos (os casos por exemplo), e representam verdades para determinada
situação, e os níveis mais baixos são chamados de slots, ou nodos terminais que devem ser
preenchidos com instâncias específicas de dados relativos ao conceito (neste caso as instâncias são
os atributos de cada caso) (MIRANDA, 2000).
A Figura 18 exibe a estrutura de um caso modelado no sistema.
Figura 18. Estrutura de um caso
Um caso para este sistema precisa possuir a seguinte estrutura:
o Código do caso: que é o código único de cada caso;
o Grupo de produtos: que é a classe a qual o produto pertence (ex. máquinas elétricas,
máquinas a gasolina, etc);
56
o Produto: que é o objeto principal de referência para o cliente;
o Conjunto: os conjuntos, que são as partes que servem para dividir os componentes dos
produtos em grupos, ex. motor, parte elétrica, etc. Cada produto pode ter n conjuntos;
o Problemas: cada problema faz parte de um conjunto, e um conjunto pode ter n
problemas. Por exemplo, no conjunto do motor podemos ter um problema de “o motor
está apanhando?”; e
o Estados do problema: cada problema pode possuir n estados, e seguindo o exemplo
anterior, se o conjunto motor de um produto possuir um problema de “o motor está
apanhando?”, as possíveis respostas podem ser: “normal”, que significa que não há
problemas com o motor, ou simplesmente “sim” que vai indicar que há algum problema.
3.5.3. Método de Recuperação
Na seqüência da implementação dos ciclos de vida do RBC, uma das principais etapas do
desenvolvimento é a definição dos métodos de recuperação de casos. São poucas às vezes em que
apenas um método de recuperação é utilizado, pois a combinação entre mais de um método permite
uma maior precisão para aquilo que está pretendendo-se recuperar (WANGENHEIM &
WANGENHEIM, 2003).
Na etapa de projeto do sistema foi definido pela utilização de uma combinação entre os
métodos de Contagem de Características, e o método do Vizinho mais Próximo (Nearest Neighbour
Retrieval). A combinação entre estas duas técnicas também pode ser chamada de Métrica Híbrida e
é muito utilizada em sistemas de RBC.
Como já citado anteriormente, ficou a cargo do técnico da empresa a definição dos
problemas (variáveis), e seus respectivos pesos a serem considerados no cálculo para recuperação
dos casos mais similares, pois somente o especialista pode avaliar a importância que cada variável
tem dentro de um determinado cenário. No sistema os pesos são distribuídos com valores de 1 a 10,
sendo os valor 1 o de menor importância, e o valor 10, o de maior importância para o cálculo.
Entre as funções que são utilizadas para a medida da distância, a fórmula para o cálculo de
distância aplicada para recuperação dos casos, foi a Distância City-Block, que considera o módulo
da distância de cada atributo do novo caso com os casos da base. O motivo pelo qual esta função foi
57
escolhida foi pelo fato de que, apesar de ser uma função de fácil implementação, encaixa-se
perfeitamente no projeto inicial do sistema.
A avaliação dos casos é feita seguindo os seguintes critérios: quando um caso é consultado
na base de conhecimento, primeiro o sistema busca para avaliação todos os casos que tenham
grupo, e produto iguais ao do caso consultado. Depois é realizada uma varredura em todos os casos
encontrados e verificado todos os problemas (variáveis), e estados dos problemas. A cada problema
pesquisado é realizada uma verificação para ver qual método de avaliação será aplicado para
calcular a similaridade. Se o método for o de Contagem de características é verificado se o estado
do problema do caso consultado é igual o do caso da base. Se for igual é aplicada a fórmula para
este método, senão passa-se para o próximo problema. Se for o método do Vizinho Mais Próximo, é
aplicada a fórmula da distância escolhida para verificar o quanto esta característica é parecida ou
não com o caso. Serão listados como resultado somente os dez casos mais similares.
Para exemplificar melhor o cálculo da similaridade toma-se como base os casos
denominados A e B armazenados na base de conhecimento. O novo caso é representado por N. Os
valores para os atributos considerados para este exemplo estão descritos conforme as Tabelas 1 a 4.
Tabela 1. Atributos do caso e seus parâmetros.
ATRIBUTOS MÉTODO PESO Como está o tubo de ventilação? Contagem 2 A extensão foi testada? Contagem 2 Como está o nível de ruído? Vizinho 4
Tabela 2. Atribuição de valores para atributos do método Contagem.
ATRIBUTOS VALORES Como está o tubo de ventilação? Normal / O tubo esta amassado A extensão foi testada? Sim / Não
Tabela 3. Atribuição de valores ao atributo “Como está o nível de ruído?”.
VALORES PESOS Normal 1 Médio 3 Alto 5
58
Os valores para os atributos dos casos está disposta como a seguir:
Tabela 4. Valores dos atributos dos casos.
ATRIBUTOS CASO N CASO A CASO B Como está o tubo de ventilação? Normal Normal O tubo está amassado A extensão foi testada? Sim Não Não Como está o nível de ruído? Médio Alto Normal
O cálculo para o Caso A fica disposto da seguinte forma:
ScoreContagem: ((1 * 0.1) + (0 * 0.3)) = 0.1
ScoreVizinho: (1 / |3 – 5|) * 0.4 = 0.2
ScoreTotalA: 0.1 + 0.2 = 0.3
O cálculo para o Caso B fica disposto da seguinte forma:
ScoreContagem: ((0 * 0.1) + (0 * 0.3)) = 0
ScoreVizinho: (1 / |3 – 1|) * 0.4 = 0.2
ScoreTotalB: 0 + 0.2 = 0.2
Na fórmula da distância do método do Vizinho Mais Próximo pode-se observar que é
aplicado a divisão do valor 1 sobre o valor do módulo. Este processo foi aplicado, pois para este
método o menor valor é o maior, e isto dificultava na hora de juntar com o score da Contagem de
Características, que é ao contrário. Esta divisão, portanto, tem a finalidade de inverter os valores do
método transformando o menor em maior e vice-versa, desta forma resolvendo o problema da
junção dos dois métodos.
Como ilustrado, calculando-se a similaridade entre o caso A e o caso N a obtém-se o valor
de 0.30, e a similaridade entre o caso B e o caso N é igual a 0,20. Avaliando-se as distâncias
calculadas entre os casos, pode-se afirmar que o vizinho mais próximo de N é o caso A, pois
alcançou a maior pontuação portanto possui maior similaridade.
3.5.4. Adaptação
Por fim, foi desenvolvido o método de adaptação para o sistema de Help Desk, cuja
característica de funcionamento é discutida a seguir:
59
Ao final de um acesso no módulo de suporte, o sistema automaticamente armazena os novos
casos na base. A princípio a forma de adaptação seguirá os seguintes critérios: o sistema armazenará
todos os casos que forem avaliados na base de conhecimento. O novo caso será inserido com um
status de pendente (campo da tabela de casos “resolvido” com valor igual a “N”), o que servirá para
diferenciá-lo de casos que já foram aprovados, e estão sendo utilizados na base de conhecimento
como base para as consultas. O administrador da base de conhecimento fará a avaliação dos novos
casos inseridos através de uma consulta de casos pendentes, onde serão listados somente os casos
com o status de não resolvido. Após a localização dos novos casos, o administrador faz uma
avaliação caso a caso, onde ele possui as seguintes opções: aplicar o novo caso na íntegra como foi
inserido pelo sistema, adaptá-lo de maneira que a base fique mais refinada ou simplesmente
descartá-lo.
3.6. Implementação do Protótipo do Sistema
Após terem sido concluídas todas as etapas de projeto e modelagem do sistema, a etapa de
implementação é a etapa onde é possível dar vida ao sistema proposto. Nesta etapa, além de colocar
em prática o que foi previamente definido, também foi possível verificar pequenos equívocos na
modelagem e projeto que puderam ser corrigidos para que o sistema tivesse um funcionamento
ideal.
Algumas alterações foram aplicadas principalmente na estrutura da base de conhecimento e
corrigidas na modelagem, como a mudança do nome das seguintes tabelas: “problema” para
“conjunto”, “prod_prob_causa” para “conj_problema”, “causa” para “problema”,
“prod_prob_causa_est” para “prob_estado”, e “caso_causa” para “caso_problema”. Com estas
mudanças obteve-se uma melhor visualização e um melhor entendimento da estrutura da base de
conhecimento.
Outra modificação importante da base de conhecimento foi que o relacionamento da tabela
“problemas”, que agora se tornou “conjuntos”, que antes era na tabela “caso”, passou para a tabela
“caso_problema”, desta forma dando uma maior flexibilidade e conseguindo armazenar todos os
conjuntos que fazem parte de uma máquina em um só local. Este processo deixa claro que neste
sistema cada máquina cadastrada possui uma base de conhecimento específica e dinâmica, o que
facilita o cadastramento de novas máquinas que forem surgindo, ou até mesmo a criação de novos
atributos na base de conhecimento, afetando somente a estrutura da máquina relacionada e não o
RBC como um todo.
60
3.6.1. Arquitetura do Sistema
Após completadas as alterações necessárias na base e definido as ferramentas que seriam
utilizadas para implementação, iniciou-se a etapa de definição da arquitetura do sistema, bem como
a aquisição e configuração das ferramentas a serem utilizadas, e o primeiro passo dado foi a busca
de todas as ferramentas necessárias para a implementação e implantação do sistema.
Como já citado no item 3.2, para a implementação deste projeto optou-se pela linguagem
Java, e para tanto, a primeira ferramenta buscada foi o ambiente de desenvolvimento Java, o J2SE
(Java 2 Standard Edition) 5.0, que foi baixado diretamente do site da Sun http://java.sun.com/j2se, e
posteriormente instalado e configurado em um sistema operacional Windows XP conforme manual
que acompanha o pacote.
O servidor para as páginas JSP Tomcat 5.5.9 foi baixado do site http://tomcat.apache.org/, e
também foi instalado e configurado utilizando seu manual próprio, onde por padrão ele fica rodando
como um serviço na porta 8080. O servidor de banco de dados do MySQL 4.01, foi baixado do site
do projeto do MySQL http://dev.mysql.com/downloads/ e instalado e configurado conforme o
manual. Após ter o banco de dados rodando foram criadas todas as tabelas que fazem parte da base
conforme a modelagem final definida.
Um exemplo da estrutura do sistema proposto pode ser observado na Figura 19, onde é
ilustrada a arquitetura final do sistema no servidor Linux da empresa que serviu como base. Da
estrutura do servidor Linux para o servidor Windows a única diferença é que para se evitar os
problemas de bloqueio de portas que muitas empresas possuem, o Tomcat teve que ser instalado
como módulo do servidor Apache que a empresa já possuía rodando na porta 80, para também
conseguir rodar na porta 80, em função de que em alguns locais testados as requisições da porta
8080 não serem aceitas.
61
Figura 19. Exemplo de arquitetura do sistema em um servidor Linux. Fonte: Adaptado de AKADIA (2006)
Desta forma, como pode ser observado o cliente pode fazer tanto requisições para o servidor
PHP quanto para o servidor JSP, todas através da porta 80. Quando o cliente faz uma chamada para
um JSP, o módulo Apache redireciona a requisição para o Catalina Container que aí sim interpreta o
JSP que por sua vez e processa as requisições através do JDK. Estas requisições podem ser para
utilização dos Servlets, Beans ou de acesso ao banco de dados. Processadas as requisições o retorno
é enviado ao cliente através da porta 80.
Para a implementação dos JSP’s, Servlets e dos Beans foi utilizada a IDE (Integrated
Development Environment) do NetBeans 5.0 que pode ser baixado do site
http://www.netbeans.org/downloads/index.html, sendo requisito para sua instalação ter uma versão
do JDK do Java instalado. Esta ferramenta possui uma interface de fácil entendimento e também
recursos que facilitam muito o trabalho do programador. O NetBeans já vem por padrão com um
servidor Tomcat integrado que fica rodando na porta 8084 cada vez que é executado o sistema.
Um dos recursos que o NetBeans possibilita e que foi utilizado para este sistema, foi o uso
do padrão MVC (Model View Controller) para o desenvolvimento. A estrutura de diretórios do
NetBeans pode ser visualizado na Figura 24, que demonstra o sistema e sua organização geral.
62
Figura 20. Estrutura de diretórios do NetBeans
Segundo a estrutura de pasta ilustrada na Figura 20, os diretórios de um projeto padrão do
NetBeans são os seguintes:
o Web Pages: diretório onde ficam armazenadas as páginas Web, ou seja, os arquivos JSP,
HTML, etc. No caso do Help Desk foram armazenados todos os JSP’s do projeto, e
adicionada uma nova pasta chamada imagens dentro da pasta Web Pages, onde foram
armazenas todas as imagens utilizadas;
o Web Services: diretório onde ficam armazenados os Web Services utilizados pelo
projeto;
o Configuration Files: diretório onde ficam os arquivos de configuração do projeto como
context.xml, web.xml, etc;
o Server Resources: diretório onde ficam armazenados os arquivos de recursos do usuário;
o Source Packages: diretório onde ficam armazenados os pacotes utilizados para o projeto.
Por padrão geralmente são colocados nestes pacotes os Beans e os Servlets;
o Test Packages: diretório onde ficam armazenados os pacotes com as classes de teste;
o Libraries: diretório onde ficam armazenadas as bibliotecas utilizadas no projeto; e
o Test Libraries: diretório onde ficam armazenas as bibliotecas de teste.
63
Neste sistema, como foi utilizado um padrão MVC para o desenvolvimento, para se obter
uma maior organização, cada entidade foi separada em pastas diferentes, e cada entidade foi
separada em quatro arquivos. A nomenclatura de cada arquivo por convenção seguiu o seguinte
padrão:
o nomedaclasseCt.class: classe responsável pelo controle da aplicação. Recebe requisições
do fluxo de tela e faz a comunicação com o modelo e a classe de acesso a persistência;
o nomedaclasseDb.class: classe que recebe as requisições do controle, acessa a
persistência e retorna o resultado ao controle;
o nomedaclasseFt.class: Servlet que se responsabiliza pelo fluxo de tela, ou seja, atende as
requisições e as distribui para o sistema. Esta classe acessa tanto o controle quanto faz
redirecionamentos para os JSP’s; e
o nomedaclasseMd.class:classe que armazena o modelo da entidade.
Além dos pacotes de cada entidade, para este sistema também foi criado um pacote
chamado utilitários, que contém a classe persistênciaMySQL.java, que é responsável pelo acesso
direto ao banco de dados MySQL, e é somente através desta classe que é possível realizar algum
tipo de operação no banco de dados, e o arquivo conf.properties, que é um arquivo de configuração
que contém as informações sobre nome do usuário, senha de acesso, nome do banco e driver a ser
utilizado para o acesso.
A Figura 21 exibe um exemplo de como ficou a estrutura do pacote da entidade caso e do
pacote de utilitários.
64
Figura 21. Estrutura de pacotes
O arquivo conf.properties, é um arquivo criado que contém propriedades divididas em pares
atributo-valor, separados pelo sinal de “=”. Este arquivo contém as informações necessárias para a
conexão com o banco de dados, e pode ser configurado em qualquer tempo, não necessitando
recompilar a aplicação para aplicar as novas configurações. Como citado anteriormente, neste
sistema este arquivo fica localizado dentro do pacote utilitários, e é lido diretamente pela classe de
persistência. A Figura 22 exibe um exemplo da configuração do arquivo conf.properties.
driver=com.mysql.jdbc.Driver url=jdbc:mysql://localhost:3306/Help Desk user=root pass=senha
Figura 22. Exemplo do arquivo conf.properties Fonte: PortalJava (2005).
3.6.2. Módulos do Sistema
Este sistema foi projetado e desenvolvido com dois módulos principais para acesso, sendo
eles módulo de consulta do cliente e o módulo de administração da base de conhecimento. O
módulo de consulta do cliente possui acesso liberado a qualquer usuário. Para se ter acesso ao
módulo de administração do sistema faz-se necessário que o usuário esteja logado no sistema para
ter acesso às opções disponíveis. A Figura 23 exibe a tela inicial do sistema.
65
Figura 23. Tela inicial do sistema
3.6.2.1. Módulo Cliente
Este é um módulo de acesso liberado para todos os usuários, e é o módulo onde é possível
configurar um problema de um determinado produto, e fazer consultas à base de conhecimento para
tentar obter uma possível solução. Ele possui uma interface onde o usuário cadastra suas
informações, seleciona o produto, e seleciona as opções que melhor retratem o problema que está
sendo avaliado. Na Figura 24 pode ser observada a primeira tela de consulta de casos, onde o
usuário deve preencher todos os campos obrigatoriamente. Esta tela é composta pelas informações
pessoais do usuário e pelos campos para identificação do produto a ser avaliado.
Figura 24. Tela consulta de casos parte 1
66
Um dos recursos utilizados nesta tela é o da tecnologia AJAX para busca da lista de
produtos de um grupo de produtos. A vantagem da utilização desta técnica é que não é necessário
recarregar a página para preencher a lista toda vez que um novo grupo é atualizado. O AJAX utiliza
JavaScript para fazer a requisição a uma outra página, através da variável XMLHTTPRequest.
Sendo assim toda vez que é selecionado um grupo de produtos é disparada uma função JavaScript
que faz a requisição da página de busca de produtos. Quando a lista é retornada, o componente é
atualizado automaticamente. A Figura 25 exibe a tela inicial para consulta de casos com a lista de
produtos vazia, pois nenhum grupo está preenchido.
Figura 25. Tela lista de produtos vazia.
Já na figura 26 pode-se observar como fica a lista de produtos depois de selecionado um
grupo de produtos.
Figura 26. Tela lista de produtos preenchida.
Após preenchidos todos os campos necessários, o usuário deve clicar sobre o botão
PROSSEGUIR para visualizar a próxima tela. Esta tela expõe todos os conjuntos com os problemas
de cada conjunto (expostos em forma de perguntas), e os estados de cada problema. Os estados são
as opções que o usuário deverá escolher para configurar o problema que deseja consultar (possíveis
respostas para as perguntas). A janela com as opções deste exemplo, pode ser visualizada como
mostra a Figura 27.
67
Figura 27. Tela consulta de casos parte 2.
Selecionadas todas as opções, conforme se apresenta o produto em questão, o usuário deve
clicar sobre o botão CONSULTAR para que o sistema realize uma busca na base de conhecimento e
retorne uma lista das possíveis soluções encontradas de acordo com os casos que foram
considerados mais similares. Somente os dez casos mais semelhantes serão apresentados para o
usuário. A Figura 33 exibe um exemplo da lista de casos retornados pelo RBC.
Figura 28. Tela resultado da consulta
68
3.6.2.2. Módulo Administrador
Nesta área, somente usuários cadastrados podem ter acesso através de um login e uma
senha. Neste módulo os usuários que tiverem o acesso podem fazer todas as configurações da base
de conhecimento do Help Desk, como, manutenção de usuários, produtos, casos, estruturação de
produtos, e consultas de casos. A Figura 29 exibe a tela onde o usuário está se logando no sistema
para ter acesso ao menu principal do sistema.
Figura 29. Tela de login.
Estando devidamente autenticado, o sistema exibe um menu com todas as opções
disponíveis para usuários com acesso restrito. Uma das principais opções que um usuário
administrador vai utilizar é o cadastro de produtos, pois é nele que o usuário vai definir a estrutura
da base de conhecimento para aquele determinado produto. Clicando sobre o ícone da coluna
ESTRUT., o usuário tem acesso à estrutura do produto da linha selecionada. Nesta estrutura o
usuário vai definir toda arquitetura da base de conhecimento para o produto em questão. A Figura
30 exibe uma estrutura de produto já definida.
69
Figura 30. Tela estrutura de produto.
O primeiro passo para se definir uma estrutura de um produto é clicar sobre o botão com o
símbolo de “+” em verde, onde aparece a mensagem “Abre a tela de cadastro de um novo
Conjunto”, quando o mouse é passado sobre ele. Aberta a tela de cadastro, somente é necessário
preencher o campo “Descrição do Conjunto”, e clicar sobre o botão CONFIRMAR. Este processo
deve ser repetido para todos os conjuntos que o produto possuir.
O segundo passo para se estruturar um produto, é definir os problemas que cada conjunto
pode possuir. Estes problemas devem ter sua descrição em forma de perguntas para facilitar ao
usuário o entendimento sobre o mesmo. Para tanto o administrador deve adicionar a pergunta no
campo “Descrição do Problema”, escolher um dos métodos disponíveis para avaliação deste
atributo, e definir o peso deste atributo. Para formulação de uma estrutura, deve-se ressaltar que o
administrador deve possuir um profundo conhecimento sobre o produto, para que se faça a melhor
escolha do método e do peso do atributo, de maneira que a base fique melhor modelada. A Figura
31 exibe a tela de cadastro de problemas.
70
Figura 31. Tela cadastro de problemas.
A terceira, e última etapa para estruturação de um produto, é fazer a definição de todos os
estados, ou para melhor entender, cadastrar todas as respostas possíveis para as perguntas
cadastradas nos problemas. Nesta tela pode se ter somente o campo “Descrição do Estado”, no caso
de ter sido escolhido o método de “Contagem de Características”, ou também ter o campo “Peso”,
no caso de ter sido escolhido o método do “Vizinho mais Próximo”, onde o administrador define o
peso para cada estado seguindo uma seqüência, onde o estado mais diferente recebe um peso maior,
e o estado mais parecido recebe um peso mais próximo, para que se facilite o cálculo da
similaridade. A Figura 32 exibe a tela de cadastro de estados com todos os campos.
Figura 32. Tela cadastro de estados.
71
Após ter sido definida a estrutura de um produto por completo, pode-se começar o
cadastramento dos casos na base de conhecimento para esta estrutura. O cadastro de casos é
dividido em duas etapas.
A primeira etapa é escolher o Grupo de Produtos, e o Produto a que o caso se refere, pois
desta forma o sistema busca a estrutura de um caso para este produto e monta na tela assim que o
usuário clicar na opção prosseguir. A Figura 33 exibe a tela de cadastro de um caso e toda a sua
estrutura.
Figura 33. Tela estrutura de um caso.
Nesta tela o administrador deve escolher todas as respostas para os problemas, de acordo
com o diagnóstico e a solução que serão descritos nos respectivos campos. No campo “Caso
Resolvido” o administrador escolhe se o caso fará parte da base para consulta, ou não, caso a opção
selecionada seja “Não”. Para adicionar o novo caso a base de conhecimento basta clicar sobre o
botão “Salvar”.
72
3.7. Validação e Testes
A etapa de validação e testes teve como objetivo principal analisar o comportamento dos
procedimentos implementados, colocando o sistema a prova com o que era esperado. Esta etapa foi
realizada com o auxílio de um técnico da empresa que avaliou alguns princípios de ergonomia, mas
o objetivo principal foi avaliar o comportamento geral do sistema mediante uma bateria de
consultas efetuadas na base de conhecimento.
Primeiramente, foi avaliada a ergonomia do sistema: telas, cores, indicações, etc. Em um
primeiro momento, foi verificado que na maioria do sistema a ergonomia está de acordo com o
esperado, no entanto, algumas telas como a de Estrutura do Produto necessitará de algumas
melhorias para facilitar o entendimento de cada informação, principalmente na parte de ergonomia.
Em outros testes realizados foram avaliadas as demais funcionalidades do sistema como o acesso e
os cadastros em geral que apresentaram resultados satisfatórios.
Durante os testes gerais sobre o comportamento e a coerência das respostas listadas pelo
Sistema, nas consultas realizadas, obteve-se uma avaliação dentro do esperado, excelente do ponto
de vista de resposta. Em torno de 71% dos testes obteve-se sucesso nessas respostas listadas pelo
sistema, ou seja, o sistema retornou uma resposta útil para o caso consultado.
Também foi constatado que é possível melhorar o percentual de acertos do sistema. Para isto
faz-se necessário uma avaliação dos atributos da base, fazendo um refinamento melhorado sobre a
distribuição dos pesos para cada atributo.
Embora a ferramenta não esteja totalmente funcional para campo, por se tratar de um
protótipo, o sistema de Help Desk foi considerado de uma forma geral dentro das expectativas,
alcançando os objetivos projetados inicialmente.
Para que a ferramenta seja utilizada com todo o potencial esperado, serão realizados mais
testes, pois é somente com estes que poderemos identificar possíveis desvios ou imprecisões nas
respostas, que poderão comprometer o resultado final proposto pelo sistema.
73
4. CONCLUSÃO
Empresas buscam constantemente aumentar o nível de satisfação de seus clientes, e o
Sistema desenvolvido teve como objetivo contribuir para este aumento principalmente nos
seguintes aspectos: disponibilizar um canal direto entre o cliente e a empresa 24 horas por dia, onde
o cliente conseguisse tentar resolver os problemas apresentados pelos produtos comprados, sem ter
que estar efetuando ligações telefônicas para a empresa; diminuir os gastos com ligações telefônicas
e de pessoal necessário para o atendimento; e formar uma base de conhecimento onde tudo fique
armazenado, para que essas informações possam ser reutilizadas em situações futuras.
Muitos sistemas, ou páginas de suporte técnico de empresas, proporcionam ao cliente
somente respostas sobre problemas pré-formatados de uma forma mais genérica, não deixando o
usuário livre para configurar um problema como um todo. Sendo assim, pode-se considerar o Help
Desk um sistema que poderá ter uma boa aceitação no mercado. Para isso, será imprescindível que
os responsáveis pela base de conhecimento realizem um trabalho sério e detalhado no
cadastramento da base de casos, já que o sistema possui uma base interativa e dinâmica que
necessita de constantes atualizações.
De um modo geral, a utilização da técnica de Raciocínio Baseado em casos se mostrou
muito eficiente diante dos objetivos propostos. Para que o sistema possa funcionar de uma forma
comercial e ser disponibilizado para campo, faz-se necessário uma população maior da base de
dados e uma análise mais aprofundada sobre a configuração de cada atributo, de modo que as
respostas sejam melhoradas e adaptadas as necessidades.
Como em todo projeto, durante a implementação do protótipo alguns problemas foram
encontrados, principalmente relativos às ferramentas utilizadas para a programação, como: a) o
depurador de erros para JSP não é claro, dificultando o entendimento em diversos momentos; b)
adaptação a tecnologias Web adotadas para o projeto, exigindo total domínio para utilização; c)
adaptação ao Java e a tecnologia orientada a objetos; d) implementação do protótipo seguindo o
padrão MVC, o que provocou um maior volume de tempo para a programação; e, e) problemas
relativos a instalação e configuração das ferramentas para plataformas diferentes. Todos os
problemas relativos a utilização das ferramentas foram resolvidos através das pesquisas na internet,
principalmente em fóruns.
74
A utilização do padrão MVC para o desenvolvimento em um primeiro momento provocou
um maior volume de programação, mas também proporcionou uma melhor organização e uma
maior facilidade na hora de realizar a manutenção do sistema. A utilização deste padrão de
desenvolvimento contribuiu muito para uma melhor formação no aspecto profissional aumentando
os conhecimentos e aprimorando as habilidades.
Outra técnica utilizada foi a do AJAX para a busca de informações e atualização de campos
em algumas telas. Esta técnica permitiu que o desgaste na busca destas informações fosse
minimizado sem precisar sair da tela para efetuar consultas e atualizações.
Este sistema não possui distinção entre textos com caixa alta ou caixa baixa, deixando a
cargo do técnico que populou a base de dados a responsabilidade sobre a formatação correta para
apresentação dos textos.
Para trabalhos futuros propõe-se o estudo e implementação de novos métodos de
recuperação o que pode proporcionar um melhor resultado final nas consultas, ou ainda adicionar
um campo descritivo onde o cliente possa também colocar uma descrição do problema enfrentado,
para que o sistema interprete este campo realizando a avaliação através de palavras chaves pré-
estabelecidas.
Outra sugestão para trabalhos futuros seria a implementação do sistema utilizando outra
técnica de Inteligência Artificial, como Agentes ou Linguagem Natural para que se possa observar o
comportamento do sistema também nestas técnicas.
REFERÊNCIAS BIBLIOGRÁFICAS
ADTMAG, Application Development Trends Computer Group. JavaServer Pages for Enterprise-Level Computing. Disponível em: < http://www.adtmag.com/java/articleold.aspx?id=1245>. Acesso em: 01 mai. 2006.
AKADIA, Akadia AG Information Technology. Web Database Access with Apache / Tomcat. Disponível em: < http://www.akadia.com/download/soug/tomcat/html/tomcat_apache.html >. Acesso em: 05 mai. 2006.
BARRETO, Jorge Muniz. Inteligência Artificial: no limiar do século XXI. Florianópolis: PPP, 1997.
CONSOLE. Java uma linguagem multiplataforma. Disponível em: < http://hd.com.br/ver_documento.htm?id=154>. Acesso em: 10 jun. 2005.
DUMOND, Gabriela F.; PAULA, Valéria C. Avaliação Técnica do Mysql Prodemge. Disponível < http://www.rau-tu.unicamp.br/nou-rau/softwarelivre/document/?view=1 > Acesso em: 10 jun. 2005.
FERNANDES, A. M. R. Inteligência Artificial: noções gerais. 1. ed. Florianópolis: Visual Books, 2003.
HOMER. Help Desk Systems. Disponível em: < www.cse.lehigh.edu/~munoz/cse395/classes /Help Desk.ppt >. Acesso em: 13 mar. 2005.
INFOWESTER. J2SE, J2EE e J2ME: uma breve explicação. Disponível em: < http://www.infowester.com/versoesjava.php>. Acesso em: 30 jul. 2005.
JAVANOROESTE. Grupo de Usuários Java do Noroeste Paulista: Introdução a Aplicações Web com Java. Disponível em: < www.javanoroeste.com.br/2006/cursointroweb/JavaWeb.pdf>. Acesso em: 13 mar. 2006.
J2EEBRASIL, o site da comunidade J2EE no Brasil: Servlets. Disponível em: < http://www.j2eebrasil.com.br/jsp/tutoriais/tutorial.jsp?idTutorial=001_013 >. Acesso em: 12 set. 2005.
KEYSTONE, Computer Group. Help Desk Services: Help Desk. Disponível em: <http://keystonegroup.co.uk>. Acesso em: 13 mar. 2005.
KOLODNER, Janet. Case-based reasoning. San Franciso: Morgan Kauffman, 1993.
KUHNEN, R. R. i-hotel: sistema de indicação de hospedagem utilizando a técnica de raciocínio baseado em casos. 2000. 115 f. Trabalho de Conclusão do Curso (Bacharelado em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2000.
LAGEMANN, Gerson Volney. RBC para o problema de suporte ao cliente nas empresas de prestação de serviço de software: o caso Datasul. 1998. Dissertação (Mestrado)–Programa de Pós-
76
Graduação em Engenharia de Produção, Universidade Federal de Santa Catarina, Florianópolis, 1998.
LINUXMAGAZINE.Linux Magazine – Tecnologia sem limites: Ambientes de desenvolvimento e ferramentas para construção e migração de aplicações. Disponível em: < http://www.linuxmagazine.com.br/issue/12/LM12_61-66.pdf >. Acesso em: 14 mar. 2006.
LUCASARTS. Yoda's Help Desk: support. Disponível em: <http://yodasHelp Desk. lucasarts.com>. Acesso em: 11 out. 2004.
MIRANDA, E. M. Protótipo de um Sistema de Auxílio à Avaliação de Algoritmos. 2000. 153 f. Trabalho de Conclusão do Curso (Bacharelado em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2000.
MYSQL. Manual de Referência do MySQL 4.1: Visão Geral do Sistema de Banco de Dados MySQL. Disponível em: < http://dev.mysql.com/doc/refman/4.1/pt/features.html>. Acesso em: 14 mar. 2006.
MÜLLER, D. N. Inteligência Artificial. Disponível em: <http://www.ulbra.tche.br/~danielnm/ia/defbas/de.html>. Acesso em: 05 jun. 2005.
NASCIMENTO JR., C. L.; YONEYAMA, T. Inteligência Artificial em controle e automação. 1. ed. São Paulo: E. Blücher, 2000. 218 p.
PORTALJAVA: a maior comunidade Java do Brasil. Disponível em: < http://www.portaljava.com.br>. Acesso em: 01 jul. 2005.
PORTALWEBMOBILE: WebMobile Magazine. Disponível em: < http://www.portalwebmobile.com.br/ >. Acesso em: 15 mai. 2006.
RABUSKE, Renato Antônio. Inteligência Artificial. Florianópolis: UFSC, 1995.
RAMALHO, Benício José Almeida, Sapiens: sistema de apoio ao ensino de graduação baseado na Internet. 1999. 91 f. Dissertação (Mestrado)–Programa de Pós-Graduação em Engenharia de Produção, Universidade Federal de Santa Catarina, Florianópolis: 1999.
SAOFRANCISCO.Universidade São Francisco: Introdução ao Java. Disponível em: < http://www.sin002ufsc.hpg.ig.com.br/apostilas/java_joao.zip >. Acesso em: 10 mar. 2006.
SILVA, A. O. DUNAS: protótipo de um sistema inteligente para avaliação da vulnerabilidade e gerenciamento dos sistemas de dunas costeiras. 2000. 86 f.Trabalho de Conclusão do Curso (Bacharelado em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2000.
SILVA, Deam James Azevedo; COSTA, Fábio Paraguaçu Duarte. Sistema de Raciocínio Baseado em Casos para o diagnóstico médico de doenças neurológicas. In: WORKSHOP DE INFORMÁTICA APLICADA A SAÚDE, 2., 2002, Itajaí. Anais do Congresso Brasileiro de Computação. Itajaí: UNIVALI, 2002. Disponível em: <http://www.cbcomp.univali.br/anais/pdf/2002/wsp038.pdf >. Acesso em: 20 mar. 2005.
77
THOMSON Laura; WELLING Luke. PHP e MySQL – Desenvolvimento Web. Rio de Janeiro:
Editora Campus, 2001.
TOMCAT. Tutorial Tomcat: Instalação e Configuração. Disponível em: < http://www.mhavila.com.br/topicos/java/tomcat.html>. Acesso em: 15 set. 2005.
UNICAP. Novas tecnologias web: JSP. Disponível em: < http://adao.dei.unicap.br/~almir/seminarios/2001.1/2mno/tecnologiasweb/jsp.htm>. Acesso em: 30 jul. 2005.
UNITO. Unito Sistemas: tecnologia. Disponível em: < www.unito.com.br/materia/view/131?languageCode=en>. Acesso em: 10 jun. 2005.
WANGENHEIM A. von; WANGENHEIM, C. G. von. Raciocínio Baseado em Casos. Baruerí: Manole, 2003.
WEBSPHERE. WebSphere software: Centro de Informações. Disponível em: < http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rweb_webxf.html>. Acesso em: 25 out. 2005.
A MODELAGEM DO SISTEMA
A.1 DIAGRAMAS DE CASOS DE USO
Descrição dos Cenários dos Use Cases do Administrador
UC 01 – Configura Usuário
Cadastra Novo Usuário {Fluxo Principal}.
1. Se Administrador logado no sistema.
2. O Sistema apresenta o menu para o usuário.
3. O Administrador escolhe a opção cadastro de usuário.
4. O Administrador informa os dados do novo usuário.
5. O Sistema insere um novo usuário.
Altera Usuário {Fluxo Alternativo}.
1. Se Administrador logado no sistema.
2. O Administrador escolhe a opção alterar usuário.
3. O Sistema busca os usuários cadastrados e mostra na tela.
4. O Administrador seleciona o usuário, e altera suas informações.
5. O Administrador confirma a alteração.
6. O Sistema salva alterações do usuário selecionado.
Exclui Usuário {Fluxo Alternativo}.
1. Se Administrador logado no sistema.
2. O Administrador escolhe a opção excluir usuário.
3. O Sistema busca os usuários cadastrados e exibe na tela.
4. O Administrador seleciona o usuário.
5. O Administrador confirma a exclusão.
6. O Sistema exclui o usuário selecionado.
UC 02 – Consulta Casos
Consulta Casos {Fluxo Principal}.
79
1. Se Administrador logado no sistema.
2. O Administrador escolhe a opção consulta casos.
3. O Sistema busca os casos e apresenta na tela.
4. O Administrador seleciona o caso que deseja consultar.
UC 03 – Aprova Casos
Aprova Caso Pendente {Fluxo Alternativo}.
1. Se na etapa 4, do UC 02, o status do caso for não resolvido.
2. O Administrador pode escolher entre alterar, excluir ou aprovar o caso pendente.
UC 04 – Cadastra Casos
Cadastra Caso {Fluxo Principal}.
1. Se Administrador logado no sistema.
2. O Administrador seleciona a opção cadastro de casos.
3. O Sistema exibe a tela de cadastro de casos.
4. O Administrador configura o novo caso.
5. O Administrador confirma a inclusão do caso.
6. O Sistema insere o novo caso.
Altera Caso {Fluxo Alternativo}.
1. Se Administrador logado no sistema.
2. O Administrador seleciona a opção cadastro de casos.
3. O Sistema exibe uma lista com os casos.
4. O Administrador seleciona um caso na lista.
5. O Administrador altera as informações do caso.
6. O Administrador confirma a alteração do caso.
7. O Sistema altera o caso selecionado.
Exclui Caso {Fluxo Alternativo}.
1. Se Administrador logado no sistema.
2. O Administrador seleciona a opção cadastro de casos.
3. O Sistema exibe uma lista com os casos.
80
4. O Administrador seleciona um caso na lista.
5. O Administrador confirma a exclusão do caso.
6. O Sistema exclui o caso selecionado.
UC 5 – Cadastra Produtos
Cadastra Novo Produto {Fluxo Principal}.
1. Se Administrador logado no sistema.
2. O Administrador escolhe a opção do menu lista de produtos.
3. O Sistema apresenta uma lista com os produtos cadastrados.
4. O Administrador escolhe a opção cadastrar de produto.
5. O Administrador informa os dados do novo produto.
6. O Administrador confirma a inserção.
7. O Sistema insere um novo produto.
Altera Produtos {Fluxo Alternativo}.
1. Se no passo 3 do fluxo principal, o produto desejado não estiver de acordo.
2. O Administrador seleciona a opção alterar de um produto em da lista.
3. O Administrador altera as informações do produto.
4. O Administrador confirma alteração.
5. O Sistema salva alterações.
Exclui Produto {Fluxo Alternativo}.
1. Se no passo 3 do fluxo principal, o produto desejado não estiver de acordo.
2. O Administrador escolhe o produto na lista e clica sobre o botão excluir.
3. O Administrador confirma a exclusão.
4. O Sistema exclui o produto escolhido.
Cadastra Estrutura do Produto {Fluxo Alternativo}.
1. Se na opção 3 do fluxo principal o Administrador desejar definir a estrutura de um
produto.
2. O Administrador escolhe a opção “Estrut.” De um produto da lista de produtos.
81
3. O Sistema apresenta a tela para definição da estrutura.
4. O Administrador cadastra os dados da estrutura do produto.
UC 06 – Cadastra Conjuntos
Cadastra Novos Conjuntos {Fluxo Principal}.
1. Se no passo 3 do fluxo “Cadastra Estrutura do Produto” do Use Case 6, o conjunto
desejado não estiver listado.
2. O Administrador pode clicar sobre o botão “Cadastro de Conjuntos” ao para abrir a tela
de cadastro.
3. O Sistema abre a tela de cadastro.
4. O Administrador insere a descrição do conjunto.
5 . O Administrador confirma a inclusão.
6. O Sistema insere um novo conjunto.
Altera Conjunto {Fluxo Alternativo}.
1. Se no passo 3 do fluxo “Cadastra Estrutura do Produto” do Use Case 6, o conjunto
desejado não estiver de acordo.
2. O Administrador pode clicar sobre o botão “Altera Conjunto” ao lado do conjunto
desejado, para abrir a tela de alteração.
3. O Sistema abre a tela de alteração.
4. O Administrador insere a nova descrição do conjunto.
5 . O Administrador confirma a operação.
6. O Sistema altera as informações do conjunto.
Exclui Conjunto {Fluxo Alternativo}.
1. Se no passo 3 do fluxo “Cadastra Estrutura do Produto” do Use Case 6, o conjunto
desejado não estiver de acordo.
2. O Administrador pode clicar sobre o botão “Excluir Conjunto”.
3. O Administrador confirma a exclusão.
4. O Sistema exclui o conjunto selecionado.
82
UC 07 – Cadastra Problemas
Cadastra Novos Problemas {Fluxo Principal}.
1. Se no passo 3 do fluxo “Cadastra Estrutura do Produto” do Use Case 6, o problema
desejado não estiver listado.
2. O Administrador pode clicar sobre o botão “Cadastro de problemas”, dentro da área do
conjunto desejado, para abrir a tela de cadastro.
3. O Sistema abre a tela de cadastro.
4. O Administrador insere a descrição do problema.
5 . O Administrador confirma a inclusão.
6. O Sistema insere um novo problema.
Altera Conjunto {Fluxo Alternativo}.
1. Se no passo 3 do fluxo “Cadastra Estrutura do Produto” do Use Case 6, o conjunto
desejado não estiver de acordo.
2. O Administrador pode clicar sobre o botão “Altera Problema” ao lado problema desejado
para abrir a tela de alteração.
3. O Sistema abre a tela de alteração.
4. O Administrador insere as novas informações do problema.
5 . O Administrador confirma a operação.
6. O Sistema altera as informações do problema.
Exclui Conjunto {Fluxo Alternativo}.
1. Se no passo 3 do fluxo “Cadastra Estrutura do Produto” do Use Case 6, o problema
desejado não estiver de acordo.
2. O Administrador pode clicar sobre o botão “Excluir Problema” ao lado problema
desejado.
3. O Administrador confirma a exclusão.
4. O Sistema exclui o problema selecionado.
UC 08 – Cadastra Estados
Cadastra Novos Estados {Fluxo Principal}.
83
1. Se no passo 3 do fluxo “Cadastra Estrutura do Produto” do Use Case 6, o estado desejado
não estiver listado.
2. O Administrador pode clicar sobre o botão “Cadastro de Estados”, dentro da área do
problema desejado, para abrir a tela de cadastro.
3. O Sistema abre a tela de cadastro.
4. O Administrador insere as informações do estado.
5 . O Administrador confirma a inclusão.
6. O Sistema insere um novo estado para o problema.
Altera Estado {Fluxo Alternativo}.
1. Se no passo 3 do fluxo “Cadastra Estrutura do Produto” do Use Case 6, o estado desejado
não estiver de acordo.
2. O Administrador pode clicar sobre o botão “Altera Estado”, ao lodo do estado desejado,
para abrir a tela de alteração.
3. O Sistema abre a tela de alteração.
4. O Administrador insere as novas informações do estado.
6 . O Administrador confirma a operação.
7. O Sistema altera as informações do estado.
Exclui Estado {Fluxo Alternativo}.
1. Se no passo 3 do fluxo “Cadastra Estrutura do Produto” do Use Case 6, o estado desejado
não estiver de acordo.
2. O Administrador pode clicar sobre o botão “Excluir Estado” ao lodo do estado desejado.
3. O Administrador confirma a exclusão.
4. O Sistema exclui o conjunto selecionado.
UC 09 – Consulta Atendimentos
Consulta Atendimentos {Fluxo Principal}.
1. Se Administrador logado no sistema.
2. O Administrador escolhe a opção relatório de atendimentos.
3. O Sistema exibe a tela de definição de consulta.
4. O Administrador define a consulta desejada.
84
5. O Administrador escolhe o modelo de retorno (relatório ou gráfico).
6. O Sistema apresenta o resultado na tela.
UC 10 – Cadastra Grupo Produtos
Cadastra Grupo {Fluxo Principal}.
1. Se Administrador logado no sistema.
2. O Administrador pode clicar na opção do menu “Cadastro de Grupos de Produtos”
3. O Sistema apresenta um alista com os grupos cadastrados.
4. O Administrador escolhe clica sobre o botão “Incluir Grupo”
5. O Sistema apresenta tela de cadastro de grupos.
6. O Administrador informa os dados do novo grupo.
7. O Administrador confirma a inserção.
6. O Sistema insere um novo grupo.
Altera Grupo {Fluxo Alternativo}.
1. Se no passo 5 do fluxo principal, o grupo de produtos desejado não estiver de acordo.
2. O Administrador pode clicar sobre o botão “Altera Grupo”, ao lado do grupo desejado.
3. O Sistema apresenta a tela para alteração do grupo.
4. O Administrador altera as informações.
5. O Administrador confirma a alteração.
6. O Sistema salva alterações.
Exclui Grupo {Fluxo Alternativo}.
1. Se no passo 5 do fluxo principal o grupo de produtos desejado não estiver de acordo.
2. O Administrador pode clicar sobre o botão “Excluir Produto” ao lodo do grupo desejado.
3. O Administrador confirma a exclusão.
4. O Sistema exclui o grupo escolhido.
UC 11 – Consulta Caso
Consulta Caso {Fluxo Principal}.
85
1. O Sistema exibe tela principal.
2. O Usuário informa seu nome e e-mail para prosseguir.
3. O Sistema busca os grupo de produtos e mostra na tela.
4. O Usuário seleciona o grupo de produtos desejado.
5. O Sistema busca os produtos do grupo de produtos selecionado.
6. O Usuário seleciona o produto desejado em uma lista.
7. O Usuário escolhe a opção prosseguir.
8. O Sistema busca a estrutura que um caso para o produto selecionado pode possuir de
acordo com o cadastro de estruturas onde estão cadastrados os conjuntos, os problemas de
cada conjunto e os estados que cada problema pode apresentar e apresenta na tela.
9. O Usuário configura o seu problema da maneira que mais se assemelhe ao problema que
quer solucionar, selecionando as opções na tela.
10. O Usuário seleciona a opção consultar.
11. O Sistema busca os casos mais semelhantes na base de casos e as soluções aplicadas em
tempos passados.
12. Se um dos casos for igual, ou muito semelhante ao problema que o usuário deseja
resolver, o usuário seleciona o caso.
13. O Usuário avalia e adquire conhecimento com o novo caso.
Envia Caso {Fluxo Alternativo}.
1. Se no fluxo principal, no passo 13 do cenário principal, nenhum caso solucionar o
problema apresentado.
2. O Usuário cadastra as informações do problema nos campos na parte inferior da tela.
3. O Usuário confirma o envio de um novo caso.
4. O Sistema envia o caso para avaliação da Assistência Técnica da empresa.
5. Após a configuração do caso, o sistema cadastra um novo atendimento.
A.2 DIAGRAMAS DE SEQUENCIA
Os diagramas de seqüência a seguir exibem uma visão geral sobre a iteração e a troca de
mensagens ocorridas durante uma determinada situação.
86
A Figura 34 mostra o diagrama de seqüência da consulta de casos.
sd DS 01 - ConsultaCasoEA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Cliente
Interface Sistema
«Banco»
Banco de Dados
Obs.: A estrutura do produto é formada pelos conjuntos que o produto possui cadastrado, os problemas de cada conjunto, e os estados de cada problema.
GrupoProdutos:= BuscaGruposShowPrincipal(void)
CadastraNomeEmail(Nome,Email)
SelecionaGrupo(void)
SolicitaProdutos(Cd_Grupo)
Produtos:= BuscaProdutos(Cd_Grupo)ExibeProdutos(Produtos)
SelecionaProduto(void)
SelecionaOpcaoProsseguir(void)
Solici taEstruturaProduto(CD_Produto)
EstruturaProduto:= BuscaEstruturaProduto(CD_Produto)
ExibeEstruturaProduto(EstruturaProduto)
SelecionaOpcoesCaso(void)
SolicitaPossiveisCasos(CD_Grupo,CD_Produto,CD_Problema,Causas,Estados)
Possiveicasos:= BuscaCasos(CD_Grupo,CD_Produto, CD_Problema, Causas, Estados)
CasosSimilares:= CauculaSimilaridade(PossiveisCasos)
ExibeCasosSimilares(CasosSimilares)
[AceitaCaso]: AceitaCaso(CD_Caso)
AvaliaNovoCaso(CD_Caso)AprendeNovoCaso(CD_Caso)
GravaAtendimento(InfAtendimento)[RejeitaCaso]: RejeitaCaso(void)
SolicitaTelaCadastro(void)
ExibeCadastroCaso
CadastraCaso(void)EmviaCaso(InfCaso)
EnviaEmailCaso(InfCaso)
GravaAtendimento(InfAtendimento)
ExibeTelaFinal(void)
Figura 34. Diagrama de Seqüência – Consulta Caso
87
A Figura 35 mostra o diagrama de seqüência de manutenção de usuários.
Figura 35. Diagrama de Seqüência – Manutenção de Usuários
88
A Figura 36 mostra o diagrama de seqüência de manutenção de casos.
Figura 36. Diagrama de Seqüência – Manutenção de Casos
89
A.3 DIAGRAMAS ENTIDADE RELACIONAMENTO
Os diagramas de Entidade Relacionamento a seguir exibem a estrutura geral lógica e física,
planejada para o sistema proposto.
Modelo Lógico
A Figura 37 mostra o modelo lógico do sistema.
Figura 37. Modelo Lógico
90
Modelo Físico
A Figura 38 mostra o modelo físico do sistema.
Figura 38. Modelo Físico
91
A.4 DESCRIÇÃO DAS TABELAS DE DADOS
Tabela 5. Descrição das Tabelas de Dados utilizadas no Sistema.
NOME DA TABELA DESCRIÇÃO
Grupo Tabela armazena os grupos dos produtos.
Produto Tabela que armazena as informações dos produtos.
Conjunto Tabela que armazena os conjuntos.
Problema Tabela que armazena os problemas dos conjuntos.
Estado Tabela que armazena os estados dos problemas
Usuário Tabela que armazena as informações de cada usuário
Prod_Conjunto Tabela que armazena o relacionamento de um produto com um conjunto
Conj_Problema Tabela que armazena o relacionamento entre produtos, conjuntos e os problemas. Também é onde serão cadastrados os pesos de cada problema
Prob_Estado Tabela que armazena o relacionamento entre produtos, conjuntos, problemas e as estados dos problemas.
Caso Tabela que armazena os casos envolvendo os caso, os produtos, e os grupo que fazem parte dos casos, o diagnóstico apurado a solução aplicada e o status do caso.
Caso_Problema Tabela que armazena o relacionamento entre os casos e os conjuntos, problemas e estados dos problemas.
Atendimentos Tabela que armazena o histórico de atendimentos
A.5 DESCRIÇÃO DOS ATRIBUTOS DAS TABELAS
Tabela 6. Dicionário de Dados da Tabela Caso.
NOME DO ATRIBUTO TIPO/TAMANHO DESCRIÇÃO CD_Caso INTEIRO Código do Caso – Chave primária CD_Grupo INTEIRO Código do grupo de produtos – Chave primária CD_Produto VARCHAR(10) Código do Produto – Chave primária Diagnostico VARCHAR(200) Definição do problema encontrado Solucao VARCHAR(200) Solução aplicada para o problema ocorrido Resolvido VARCHAR(1) Status do caso (R=Resolvido, P=Pendente)
92
Tabela 7. Dicionário de Dados da Tabela Caso_Problema.
NOME DO ATRIBUTO TIPO/TAMANHO DESCRIÇÃO CD_Caso INTEIRO Código do Caso – Chave primária CD_Grupo INTEIRO Código do grupo de produtos – Chave primária CD_Produto VARCHAR(10) Código do Produto – Chave primária CD_Conjunto INTEIRO Código do conjunto – Chave primária CD_Problema INTEIRO Código do problema – Chave primária CD_Estado INTEIRO Código do estado – Chave primária
Tabela 8. Dicionário de Dados da Tabela Atendimentos.
NOME DO ATRIBUTO TIPO/TAMANHO DESCRIÇÃO CD_Atendimento INTEIRO Código do atendimento – Chave primária CD_Caso INTEIRO Código do caso a que o atendimento refere-se –
Chave primária Cliente VARCHAR(50) Descrição do nome do cliente Data DATE Data da consulta do caso Hora VARCHAR(5) Hora da consulta do caso
Tabela 9. Dicionário de Dados da Tabela Problema.
NOME DO ATRIBUTO TIPO/TAMANHO DESCRIÇÃO CD_Problema INTEIRO Código do Problema – Chave primária DS_Problema VARCHAR(20) Descrição do Problema
Tabela 10. Dicionário de Dados da Tabela Estado.
NOME DO ATRIBUTO TIPO/TAMANHO DESCRIÇÃO CD_Estado INTEIRO Código do estado – Chave primária DS_Estado VARCHAR(20) Descrição do estado
Tabela 11. Dicionário de Dados da Tabela Grupo.
NOME DO ATRIBUTO TIPO/TAMANHO DESCRIÇÃO CD_Grupo INTEIRO Código do Grupo de Produtos – Chave primária DS_Grupo VARCHAR(20) Descrição do Grupo de Produtos
Tabela 12. Dicionário de Dados da Tabela Conjunto.
NOME DO ATRIBUTO TIPO/TAMANHO DESCRIÇÃO CD_Conjunto INTEIRO Código do Conjunto – Chave primária DS_Conjunto VARCHAR(30) Descrição do Conjunto
93
Tabela 13. Dicionário de Dados da Tabela Prod_Conjunto.
NOME DO ATRIBUTO TIPO/TAMANHO DESCRIÇÃO CD_Grupo INTEIRO Código do Grupo de Produtos – Chave primária CD_Produto VARCHAR(10) Código do Produto – Chave primária CD_Conjunto INTEIRO Código do Conjunto – Chave primária
Tabela 14. Dicionário de Dados da Tabela Conj_Problema.
NOME DO ATRIBUTO TIPO/TAMANHO DESCRIÇÃO CD_Grupo INTEIRO Código do Grupo de Produtos – Chave primária CD_Produto INTEIRO Código do Produto – Chave primária CD_Conjunto INTEIRO Código do Conjunto – Chave primária CD_Problema INTEIRO Código da Problema – Chave primária Peso INTEIRO Peso configurado para o problema
Tabela 15. Dicionário de Dados da Tabela Produto.
NOME DO ATRIBUTO TIPO/TAMANHO DESCRIÇÃO CD_Produto VARCHAR(50) Código do Produto – Chave primária CD_Grupo INTEIRO Código do Grupo de Produtos – Chave primária DS_Produto VARCHAR(50) Descrição do Produto
Tabela 16. Dicionário de Dados da Tabela Usuário.
NOME DO ATRIBUTO TIPO/TAMANHO DESCRIÇÃO CD_User INTEIRO Código do Usuário – Chave primária Nome_User VARCHAR(50) Nome do Usuário Email VARCHAR(50) Email do usuário Senha VARCHAR(6) Senha do usuário Tipo VARCHAR(1) Tipo de usuário (T=Técnico, A=Administrador)
Tabela 17. Dicionário de Dados da Tabela Prob_Estado.
NOME DO ATRIBUTO TIPO/TAMANHO DESCRIÇÃO CD_Grupo INTEIRO Código do Grupo de Produtos – Chave primária CD_Produto INTEIRO Código do Produto – Chave primária CD_Conjunto INTEIRO Código do Conjunto – Chave primária CD_Problema INTEIRO Código do Problema – Chave primária CD_Estado INTEIRO Código do Estado – Chave primária
