Relatório de Estágio/Projectofiles.isec.pt/DOCUMENTOS/SERVICOS/BIBLIO/Teses/Tese_Mest_Hug… ·...

ISEC - Instituto Superior de Engenharia de Coimbra

IPC - Instituto Politécnico de Coimbra

Departamento de Engenharia Informática e de Sistemas

Mestrado em Informática e Sistemas

Estágio/Projecto Industrial

Relatório Final

Ambiente de desenvolvimento de

sistemas CBR

Hugo Antunes

Orientador:

Professor Doutor Viriato Marques

Coimbra, Dezembro, de 2011

“Deus quer, o homem sonha, a obra nasce.”.

Fernando Pessoa

Aos meus pais, Ramiro e Maria, por todo o apoio e paciência ao

longo de toda a minha vida.

Ambiente de desenvolvimento CBR

Hugo Alexandre Bernardo Antunes vii

Agradecimentos

Ao meu orientador do Departamento de Engenharia Informática e Sistemas, Doutor.

Viriato Marques, pela constante disponibilidade e apoio.

A toda a minha família, por todo o sacrifício feito para que eu chegasse a este

ponto da minha vida.

À minha namorada, por sempre me acompanhar nos momentos bons e menos

bons desta etapa final.

Aos meus amigos e colegas, pelo apoio sempre prestado.

A todos os que sempre acreditaram em mim.


Hugo Alexandre Bernardo Antunes ix

Resumo

Este documento descreve o trabalho realizado por Hugo Antunes no âmbito da

disciplina de Estágio / Projecto Industrial do Mestrado em Informática e Sistemas,

Ramo de Desenvolvimento de Software, do Instituto Superior de Engenharia de

Coimbra.

O paradigma Raciocínio Baseado em Casos (RBC) propõe soluções para casos

desconhecidos, de acordo com o conhecimento previamente adquirido. Os sistemas

que se baseiam nesse paradigma variam muitos, desde protótipos até sistemas mais

complexos e de aplicação mais específica.

Neste projecto foi construída uma plataforma de desenvolvimento que permite a

construção de sistemas baseados no paradigma RBC, com recurso apenas à

configuração de alguns parâmetros e à inserção de alguns dados.

A plataforma desenvolvida tem como aspectos inovadores a possibilidade de utilizar

atributos difusos e taxonómicos, a inclusão de um algoritmo de construção de árvores

de decisão (C4.5) integrado com o Nearest Neighbors (NN) numa perspectiva de pré-

classificação seguida de pesquisa local bem como a implementação completa do ciclo

CBR, isto é, incluindo as 4 fases principais que o compõem. Permite, além disso, que

os projectos gerados sejam utilizados na Web.

Dadas as características do sistema, tais soluções podem variar de aplicações de

diagnóstico a comércio electrónico, passando por muitos outros domínios.

Foram realizados alguns testes com o objectivo de verificar a performance do sistema,

tendo-se verificado uma precisão superior à oferecida pelos algoritmos NN e árvores

de decisão quando usados isoladamente.

Palavras Chave (Tema): Inteligência Artificial, Raciocínio Baseado em

Casos, C4.5, Lógica Difusa, Taxonomias

Palavras Chave (Tecnologias): C#, .NET, MS SQL Server


Hugo Alexandre Bernardo Antunes xi

Abstract

This document introduces the work done by Hugo Antunes within the scope of the

Master in Informatics and Systems, Software Development Branch, of the Institute of

Engineering of Coimbra.

The paradigm of Case-Based Reasoning (CBR) offers solutions to unknown cases,

according to previously acquired knowledge. Systems that are based on this paradigm

vary widely, from prototypes to more complex systems and specific application.

This project was built a development platform that allows the construction of systems

based on CBR paradigm, using only the configuration of some parameters and the

inclusion of some data.

The platform has developed innovative features like the possibility of using fuzzy and

taxonomic attributes, including an algorithm to build decision trees (C4.5) integrated

with the Nearest Neighbors (NN) with a view to pre-assessment followed by local

search and the full implementation of the CBR cycle, ie, including four main phases

that compose it. It provides also that the projects generated are used on the Web.

Given the characteristics of the system, such solutions can range from diagnostic

applications to electronic commerce, through many other areas.

Some experiments were performed in order to verify the system performance, and

there has been a superior accuracy to that offered by NN algorithms and decision trees

when used alone.

Keywords (Subject): Artificial Intelligence, Case-Based Reasoning,

C4.5, Fuzzy, Taxonomy

Keywords (Technolgies): C#, .NET, MS SQL Server


xiii

Índice

1 Introdução ........................................................................................................... 27

1.1 Enquadramento ................................................................................................... 27

1.2 Objectivos ............................................................................................................ 28

1.3 Motivação ............................................................................................................. 28

1.4 Organização do relatório .................................................................................... 30

1.5 Plano de trabalho ................................................................................................ 32

2 Raciocínio Baseado em Casos ............................................................................ 35

2.1 Introdução............................................................................................................ 35

2.2 RBC – Princípios Gerais ..................................................................................... 37

2.2.1 Casos ........................................................................................................................... 37

2.2.2 Índices ......................................................................................................................... 37

2.2.3 Memória de casos ........................................................................................................ 38

2.2.4 Modelo de Aamodt & Plaza ......................................................................................... 42

2.3 RBC Aplicações e Ferramentas de Desenvolvimento ....................................... 45

2.3.1 Sistemas RCB desenvolvidos de raiz ........................................................................... 46

2.3.2 Ferramentas de Desenvolvimento ................................................................................ 46

2.4 Resumo ................................................................................................................. 47

3 Árvores de decisão ............................................................................................... 49

3.1 Definição geral ..................................................................................................... 49

3.2 Representação de uma árvore de decisão .......................................................... 50

3.3 Entropia ............................................................................................................... 50

3.4 Algoritmos............................................................................................................ 52

3.4.1 ID3 .............................................................................................................................. 52

3.4.2 Algoritmo C4.5............................................................................................................ 53

3.5 Overfitting / Underfitting e Prunning ................................................................ 54


xiv Hugo Alexandre Bernardo Antunes

3.5.1 Overfitting e Underfitting ............................................................................................ 54

3.6 Prunning .............................................................................................................. 54

4 Análise de Requisitos .......................................................................................... 57

4.1 Requisitos Funcionais da aplicação .................................................................... 58

4.2 Casos de Uso ........................................................................................................ 59

4.2.1 Utilizador .................................................................................................................... 61

4.2.2 Supervisor ................................................................................................................... 61

4.2.3 Administrador ............................................................................................................. 61

4.3 Requisitos não funcionais.................................................................................... 62

5 Ambiente de Desenvolvimento CBR ................................................................... 63

5.1 Introdução............................................................................................................ 63

5.2 Representação dos casos ..................................................................................... 65

5.2.1 Representação atributo-valor ....................................................................................... 65

5.3 Tipo de atributos ................................................................................................. 66

5.3.1 Numérico..................................................................................................................... 67

5.3.2 Inteiro .......................................................................................................................... 71

5.3.3 Booleano ..................................................................................................................... 71

5.3.4 Nominal ...................................................................................................................... 72

5.3.5 Taxonómico ................................................................................................................ 75

5.3.6 Difusos ........................................................................................................................ 75

5.4 Semelhança .......................................................................................................... 76

5.4.1 Atribuição de pesos aos atributos ................................................................................. 77

5.4.2 Semelhança Global ...................................................................................................... 77

5.4.3 Semelhança Local ........................................................................................................ 79

5.5 Árvore de decisão C4.5 ....................................................................................... 86

5.6 Arquitectura ........................................................................................................ 90

5.6.1 Diagrama de classes..................................................................................................... 91

5.6.2 Base de dados .............................................................................................................. 91

6 Tecnologias utilizadas ......................................................................................... 95


Hugo Alexandre Bernardo Antunes xv

7 Testes ................................................................................................................... 97

7.1 Primeiro Teste ................................................................................................... 100

7.2 Segundo Teste .................................................................................................... 101

7.3 Terceiro Teste .................................................................................................... 102

7.4 Quarto teste ....................................................................................................... 104

8 Conclusões ......................................................................................................... 109

8.1 Objectivos realizados ........................................................................................ 110

8.2 Limitações & trabalho futuro ........................................................................... 111

Bibliografia ................................................................................................................ 113

Anexos ....................................................................................................................... 117

Anexo 1 J48 Worker Layer .................................................................................. 119

Anexo 2 Diagrama de classes (CBR) .................................................................. 129

Anexo 3 Diagrama de classes (Data BD) ............................................................ 131

Anexo 4 Diagrama de classes (J48) .................................................................... 135

Anexo 5 Diagrama de classes (Semelhança) ...................................................... 137

Anexo 6 Diagrama de dados (BD Principal) ...................................................... 139

Anexo 7 Diagrama de dados (Domínio) ............................................................. 141

Anexo 8 Diagrama de dados (Temp) ................................................................... 143

Anexo 9 Sistemas de RBC ................................................................................... 145

Anexo 10 Semelhança ........................................................................................... 153

Anexo 11 Manual de Instalação ........................................................................... 159

Anexo 12 Manual do utilizador ............................................................................. 165


xvi Hugo Alexandre Bernardo Antunes


xvii

Índice de Figuras

Figura 1- Esquema RBC ..................................................................................................................... 36

Figura 2 – Espaço “problemas” e espaço “soluções” no paradigma RBC [9] ................................... 37

Figura 3- Estrutura exemplo de uma memória de casos [23] .............................................................. 39

Figura 4- Estrutura de casos e de episódios genéricos [1] .................................................................. 40

Figura 5 - Estrutura de categorias, características e exemplares [1] .................................................. 41

Figura 6- Ciclo dos 4R´s (adaptado de [1]) ........................................................................................ 42

Figura 7 – Representação de uma árvore de decisão [39] .................................................................. 50

Figura 8 – Representação gráfica versus entropia p(x) [30] ............................................................... 51

Figura 9 – Árvore original.................................................................................................................. 55

Figura 10 – Árvore após a poda ......................................................................................................... 55

Figura 11 – Casos de uso ................................................................................................................... 60

Figura 12 - Gráfico Semelhança StepAt .............................................................................................. 67

Figura 13- Gráfico Semelhança Polinomial ........................................................................................ 68

Figura 14- Deltas para a semelhança ................................................................................................. 69

Figura 15- Semelhança numérica, Maior perfeito ............................................................................... 69

Figura 16- Semelhança numérica Menor perfeito ............................................................................... 70

Figura 17 - Atributo nominal circular................................................................................................. 72

Figura 18- Atributo nominal ordinal ................................................................................................... 72

Figura 19- Atributo nominal normal ................................................................................................... 73

Figura 20 – Tabela de Semelhança ..................................................................................................... 73

Figura 21 – Tabela de distância ......................................................................................................... 73

Figura 22 - Representação vertical ..................................................................................................... 75

Figura 23- Representação horizontal .................................................................................................. 75

Figura 24 – Funções de pertença trapezoidais de um atributo difuso .................................................. 76

Figura 25- Taxonómica ...................................................................................................................... 82

Figura 26- Caminho percorrido entre E e L ........................................................................................ 84

Figura 27 – Pontos de pertença .......................................................................................................... 85


xviii Hugo Alexandre Bernardo Antunes

Figura 28 - Interacção da camada J48 ............................................................................................... 88

Figura 29-Parâmetros de configuração J48 ....................................................................................... 89

Figura 30 Parâmetros de configuração .............................................................................................. 89

Figura 31- Camadas do sistema ......................................................................................................... 90

Figura 32 – Tabela de testes RapidMiner ........................................................................................... 99

Figura 33 – Tabela de testes - plataforma desenvolvida neste projecto ............................................... 99

Figura 34 – Área de vendas de prédios ............................................................................................. 105

Figura 35- Funções de pertença para o eixo do x ............................................................................. 105

Figura 36 - Funções de pertença para o eixo do y ............................................................................ 106

Figura 37 – Pedido 1 ........................................................................................................................ 107

Figura 37 – Pedido 1 ........................................................................................................................ 108

Figura 38 – Pedido 2 ........................................................................................................................ 108

Figura 38- Attach database .............................................................................................................. 162

Figura 39 – Escolher a BD ............................................................................................................... 162

Figura 40 – Instalação Windows ...................................................................................................... 163

Figura 41- Interface autenticação Windows ..................................................................................... 168

Figura 42 – Interface Web ................................................................................................................ 168

Figura 43- Ecrã inicial Windows ...................................................................................................... 168

Figura 44-Ecrã inicial web ............................................................................................................... 169

Figura 45-Lista de utilizadores ......................................................................................................... 170

Figura 46 – Adicionar utilizador ...................................................................................................... 170

Figura 47- Pesquisar domínios ......................................................................................................... 171

Figura 48 – Adicionar domínio ......................................................................................................... 172

Figura 49 – Adicionar atributo ......................................................................................................... 173

Figura 50 – Utilizadores do domínio ................................................................................................ 174

Figura 51- Estrutura da solução ....................................................................................................... 174

Figura 52 – Lista de casos aplicação Windows ................................................................................. 175

Figura 53 – Lista de casos aplicação web ......................................................................................... 175

Figura 54 – Adicionar caso, aplicação Windows .............................................................................. 176

Figura 55 – Adicionar caso, aplicação web ...................................................................................... 176


Hugo Alexandre Bernardo Antunes xix

Figura 56 – Testar semelhança Windows .......................................................................................... 177

Figura 57 – Testar semelhança Web ................................................................................................. 178

Figura 58 – Interface Solução web ................................................................................................... 178

Figura 59 – Interface solução Windows ............................................................................................ 179

Figura 60 – Carregar casos .............................................................................................................. 180

Figura 61- Casos recentes ................................................................................................................ 181

Figura 62 – Configurações ............................................................................................................... 182


xx Hugo Alexandre Bernardo Antunes


xxi

Índice de Tabelas

Tabela 1 – Exemplo representação atributo valor ............................................................................... 65

Tabela 2-Apartamentos no sistema ..................................................................................................... 70

Tabela 3- Tabela de semelhança numérica. ........................................................................................ 80

Tabela 4- Entidades da base de dados ................................................................................................ 92

Tabela 5 – Atributos Naturhouse ........................................................................................................ 97

Tabela 6 – Teste com Nearest-Neighbors .......................................................................................... 100

Tabela 7-Teste J48............................................................................................................................ 101

Tabela 8 - Teste misto ....................................................................................................................... 103

Tabela 9 – Atributos de sistema de vendas ........................................................................................ 104

Tabela 10 - Biblioteca de casos, domínio 1 ....................................................................................... 106

Tabela 11 – Biblioteca de casos, domínio 2 ...................................................................................... 106

Tabela 12 - Pedido ao diminio1 ........................................................................................................ 107

Tabela 13 – Pedidos ao domínio 2 .................................................................................................... 107

Tabela 14- comparação das ferramentas .......................................................................................... 152


xxii Hugo Alexandre Bernardo Antunes


xxiii

Notação e Glossário

API Application Programming Interface

CBR Case Based Reasoning

Cm Centímetro

DLL Dynamic-link library

ESA European Space Agency.

GE Episódio genérico

IA Inteligência Artificial

IDE Integrated Development Environment

ID3 Iterative Dichotomizer 3

JAR Java Archive

JDBC Conjunto de classes e interfaces (API) escritas em Java que fazem o

envio de instruções SQL para qualquer base de dados relacional.

Kg Quilograma

LISP List Processing Language

LOOM Ontology Markup Language

MOP Memory Organization Packages

NN Nearest Neighbors

RBC

SGBD

Raciocínio Baseado em Casos

Sistema de Gestão de Base de Dados

SVN Subversion

UML Unified Modeling Language

WEKA Waikato Environment for Knowledge Analysis

XML Extensible Markup Language

= Igual

≠ Diferente

< Menor que

> Maior que

≤ Menor ou igual

≥ Maior ou igual

[a, b] Intervalo de a até b

Σ Somatório

Logaritmo na base 2

∀ Quantificador universal

Quantificação existencial

| | Valor absoluto

Distância local

Distância inter-classe

Distância intra-classe

Distância global

Semelhança local

, Semelhança inter-classe

Semelhança intra-classe

Semelhança global


Hugo Alexandre Bernardo Antunes 27

1 Introdução

Este capítulo faz o enquadramento do projecto, apresentando os objectivos, e a

motivação para a sua realização.

1.1 Enquadramento

Este projecto surge no âmbito da disciplina de Estágio / Projecto Industrial (EPI) do

Mestrado em Informática e Sistemas, Ramo de Desenvolvimento de Software, do

Instituto Superior de Engenharia de Coimbra, tendo como orientador o Professor

Doutor Viriato Marques.

Os classificadores do tipo KNN (K-Nearest-Neighbors) comparam pares (atributo,

valor) de um novo exemplo, com os K exemplos de treino "mais próximos",

avaliando essa proximidade através de uma função de semelhança e classificando o

exemplo de teste de acordo com a classe predominante.

Esta abordagem é de alguma forma semelhante à utilizada no paradigma RBC

(Raciocínio Baseado em Casos), que propõe soluções para um caso desconhecido de

acordo com as previamente conhecidas e válidas para casos anteriores. Os sistemas

baseados neste paradigma variam muito, desde concepções por assim dizer standard,

a protótipos mais ou menos complexos dedicados a aplicações específicas e utilizando

funções de semelhança extremamente variadas.

O paradigma RBC é bem descrito pelo diagrama da Aamodt & Plaza [2], que

compreende 4 fases básicas designadas por Retrieve, Reuse, Revise e Retain.

Sistemas que utilizam o paradigma RBC têm sido utilizados para diagnóstico médico

e de falhas. Contudo, em especial no primeiro caso, os sintomas são muitas vezes

difusos, por natureza. Além disso, em muitas situações existem conceitos de

hierarquia implícitos em alguns tipos de atributos, de forma análoga às vulgares

relações de herança entre classes e objectos. Alguns destes sistemas têm combinado

árvores k-dimensionais (KD.trees) com o paradigma RBC, no sentido de conseguirem

resultados mais rápidos.


28 Hugo Alexandre Bernardo Antunes

1.2 Objectivos

Este projecto tem como objectivo primordial a implementação de um ambiente de

desenvolvimento de sistemas baseados no paradigma RBC, compreendendo as quatro

fases do ciclo de Aamodt & Plaza [2].

Pretende-se que o sistema desenvolvido assente numa arquitectura cliente-servidor de

modo a possibilitar o seu funcionamento, em “Windows apllications” e Web. Além de

conter as vertentes Windows e a Web, pretende-se que o sistema possa ser utilizado

em vários tipos de contextos como, por exemplo, sistemas de diagnóstico ou comércio

electrónico (e-commerce).

A introdução de alguma inovação, de modo a destacar este sistema de outros, é outro

objectivo deste projecto. Uma das inovações é a conjugação do algoritmo de pesquisa,

Nearest Neighbors (NN) com árvores de decisão, integrando assim classificadores

com pesquisa local, de modo a melhorar o tempo de resposta do sistema e a sua

precisão. O uso de atributos difusos e taxonómicos, assim como a implementação das

4 fases do ciclo RBC, é também uma melhoria em relação a outros sistemas do

género, especialmente quando comparado com plataformas gerais de desenvolvimento

de soluções de RBC.

1.3 Motivação

As empresas de desenvolvimento de Software enfrentam hoje em dia numerosos

problemas. Como a dimensão crescente das soluções a implementar, a sua

complexidade e o número de funcionalidades e tecnologias que estão envolvidas.

Nos primórdios a área de engenharia de software propunha, para a resolução deste

problema, a reutilização de software. A ideia passava por reutilizar software

desenvolvido anteriormente para a construção de novas soluções, diminuindo o tempo

de construção de um novo sistema e melhorando a sua qualidade.

O conhecimento adquirido pelas equipas de desenvolvimento de software é um dos

bens mais preciosos que as empresas possuem. Cada engenheiro ou programador

aprende com o seu próprio conhecimento/experiência, que posteriormente

aplica/reutiliza em projectos ou futuras tarefas. Os programadores experientes são



muito importantes para as empresas, uma vez que alguém com a experiência tem

geralmente, maior produtividade e qualidade de trabalho.

Outro aspecto muito importante é a partilha de conhecimento entre programadores

aumentado a produtividade e minimizando as perdas. Os programadores sem grande

experiência beneficiariam com o armazenamento do conhecimento de cada elemento

das equipas de software, podendo atingir altos níveis de qualidade com recurso a esse

conhecimento armazenado.

Ora, conhecimento armazenado dito know-how leva sempre à obtenção de bons

resultados, não só na área de software, mas em muitas outras áreas.

Sob este ponto de vista, o RBC torna possível que o conhecimento adquirido em

situações/cenários anteriores ajude ou leve a tomar decisões mais acertadas em

cenários futuros. Para além disso, o sistema que neste documento se descreve, é uma

plataforma geral de desenvolvimento de sistemas baseados neste paradigma que,

recorrendo apenas a parâmetros de configuração e carregamento de dados, permite a

implementação de soluções deste tipo num curto espaço de tempo, sem necessidade

de recurso a programadores, minimizando assim o esforço e maximizando a produção.



1.4 Organização do relatório

Este relatório está organizado em nove capítulos, onde cada um deles aborda um

assunto específico do projecto.

Capitulo 1 – Neste capítulo é feita uma introdução sobre o âmbito do projecto e os

seus objectivos.

Capitulo 2 – Neste capítulo, é realizada uma breve revisão sobre o paradigma de

RBC, onde são destacados os seus elementos mais importantes.

Capitulo 3 – Apresenta alguns conteúdos teóricos sobre árvores de decisão, com o

objectivo de expor a sua arquitectura geral e as suas vantagens.

Capitulo 4 – Neste capítulo é apresentada a análise de requisitos do projecto.

Capitulo 5 - Neste capítulo são apresentadas todas as tomadas de decisões e os pontos

importantes do projecto. São apresentados em detalhe os tipos de atributos e as

respectivas funções de distância e semelhança. É também apresentada a integração

feita com o sistema WEKA e a arquitectura geral da plataforma.

Capitulo 6 – Este capítulo apresenta as tecnologias usadas no projecto.

Capitulo 7 – Neste capítulo são apresentados os testes efectuados ao sistema.

Capitulo 8 – Este capítulo apresenta as conclusões e algumas sugestões para trabalho

futuro.

Anexo 1 – Código de alguns métodos utilizados na integração com o sistema WEKA.

Anexo 2 e Anexo 3 – Diagramas de classes do sistema.

Anexo 4 – Diagrama de classes da camada construída, que utiliza o sistema WEKA.

Anexo 5 – Diagrama de classes da camada construída, que efectua os cálculos de

semelhança.

Anexos 6, 7 e 8 – Diagramas de dados do sistema.

Anexo 9 – Pequeno estudo sobre alguns sistemas RBC.

Anexo 10 – Código de alguns métodos que permitem calcular a semelhança entre os

casos do sistema.



Anexo 11 – Este anexo contém o manual de instalação do sistema desenvolvido.

Anexo 12 – Este anexo contém o manual de utilizador do sistema desenvolvido.



1.5 Plano de trabalho

Tendo como objectivo o desenvolvimento de uma aplicação de software foi

necessário definir um planeamento faseado e adequado.

De seguida estão esquematizadas as etapas de trabalho realizadas

Etapa 1 – Estudo e compreensão do paradigma RBC e Árvores de Decisão.

Etapa 2 – Revisão bibliográfica.

Etapa 3 – Elaboração de uma análise de requisitos.

Etapa 4 – Elaboração dos casos de uso, diagramas de classes e de dados.

Etapa 5 – Elaboração do sistema.

Interface web

Interface Windows

Processos de negócio

Integração com outros sistemas

Etapa 6 – Testes de carga, utilizado um sistema real.

Etapa 7 – Elaboração do relatório da tese.

A primeira etapa teve como objectivo recolher mais informação sobre o paradigma de

RBC. Desta forma foi possível compreender melhor o funcionamento de RBC e em

que situações pode ser aplicado. Nesta etapa também foram efectuadas pesquisas

sobre aplicações no mercado e casos de empregabilidade deste tipo de sistema.

A segunda etapa passou pela redacção de informação, recolhida sobre RBC que

originou o terceiro capítulo deste relatório. Foram também feitas algumas pesquisas

sobre árvores de decisão.

Na terceira etapa foi feito o levantamento de requisitos tendo em conta o que um

sistema RBC deve, tendo como linha de referência algumas aplicações analisadas.

A quarta etapa teve como objectivo o início da construção dos diagramas de casos de

uso, classes e de dados. Estes diagramas sofreram várias alterações ao longo do

desenvolvimento da aplicação, na medida que foram sofrendo melhorias.

A fase de desenvolvimento, etapa 5, foi a etapa mais trabalhosa. Nesta etapa foi

construído todo o sistema. A construção do sistema inclui a aplicação de todo o



paradigma de RBC, ou seja, a construção das base de dados, a construção o negócio

do sistema, assim como a integração com a WEKA.

A sexta etapa foi realizada no final da fase de desenvolvimento onde foi realizada a

construção da interface de testes do sistema.

A última etapa consistiu na redacção da maior parte deste relatório.



2 Raciocínio Baseado em Casos

Neste capítulo, apresenta-se uma breve revisão, sobre o tópico RBC, como

fundamentação teórica do desenvolvimento do projecto.

Primeiramente é feita a introdução sobre o que é o RBC e como funciona de uma

forma geral.

Seguidamente são também apresentados alguns elementos importantes nos sistemas

de recuperação de casos, que foram tidos em conta na construção do sistema

desenvolvido neste projecto.

Por fim é feito um contexto histórico sobre as aplicações que foram desenvolvidas

com base no paradigma RBC ao longo dos últimos anos.

2.1 Introdução

RBC é uma ferramenta da área da Inteligência Artificial (IA), que utiliza o

conhecimento de experiências passadas para resolver os problemas actuais [21]. O

paradigma que sustenta esta técnica, que em muitos aspectos é fundamentalmente

diferente das outras técnicas de IA, é a capacidade de utilizar o conhecimento

específico de uma experiência anterior para resolver uma situação nova. Outra

diferença importante é que o RBC guarda as novas experiência resolvidas, ficando

estas disponíveis para a resolução de problemas futuros [1].

Com o objectivo de tirar partido de toda a informação adquirida no passado, existe a

necessidade de recorrer a técnicas que recuperem essa informação passada.

Este objectivo pode ser traduzido pela Figura 1:



Figura 1- Esquema RBC

Como se pode ver na Figura 1, o processo de recuperação de casos tem início com a

colocação de um novo problema ao sistema. Este problema determina o início da

pesquisa de casos semelhantes na biblioteca de casos. Por biblioteca de casos entende-

se um conjunto de casos que podem ser consultados, de modo a extrair informação

útil para a resolução de problemas futuros. Depois de encontrado um caso semelhante

ao que se pretende resolver, pode ser necessário proceder a algumas adaptações, de

forma a ajustar a sua solução ao problema actual.

De certa forma é possível afirmar que em RBC existem duas componentes essenciais,

os casos contidos na biblioteca de casos e o método que é utilizado no processo de

pesquisa.

O caso pode ser visto como um elemento que memoriza a informação de uma situação

anteriormente resolvida, ou seja, pode ser considerado como uma lição apreendida,

devidamente contextualizada [21]. De certa forma um caso traduz-se na descrição do

problema e da sua solução.

O processo compreende todas as tarefas que são executadas desde a definição do

problema até à sua resolução. Descrições detalhadas deste processo podem ser

encontradas em Kolodner [21] e Aamodt & Plaza [1].

De uma maneira geral as tarefas principais dos modelos RBC são a recolha, a

adaptação, a revisão e a retenção de casos. A

Figura 2 ilustra a correspondência entre um espaço de descrição dos problemas e o

espaço de descrição das respectivas soluções.

4- Obter solução para o novo problema

3- Adaptar caso anterior ao novo problema

2- Procurar caso anterior

1- Problema

Biblioteca

de Casos



Figura 2 – Espaço “problemas” e espaço “soluções” no paradigma RBC [9]

2.2 RBC – Princípios Gerais

2.2.1 Casos

Antes de abordar o funcionamento do RBC é importante explicitar alguns conceitos

chave, tais como: casos, índices, memória de casos, modelos RBC e as suas várias

fases.

Um caso pode ser definido como um fragmento de conhecimento contextualizado que

regista um episódio em que uma situação/problema foi total ou parcialmente resolvido

[21]. Um caso contém sobretudo experiências concretas passadas em situações

específicas (descrições do problema) e a solução para o mesmo, tendo em conta o

contexto em que esta pode ser aplicada.

2.2.2 Índices

Um índice de um caso é uma etiqueta que lhe está associada e que irá permitir e

lembrá-lo no futuro. Isto permite simplificar a pesquisa uma vez que o algoritmo de

pesquisa utiliza índices em vez de considerar todos os casos armazenados.

Kolodner [21] apresenta o problema de indexação através de duas subáreas:

Definição do vocabulário de indexação;



Atribuição dos índices.

A identificação do vocabulário de indexação consiste em seleccionar dimensões que,

quando atribuídas, preencham as funções dos índices. A atribuição dos índices refere-

se à atribuição de valores para estas dimensões. Segundo Watson [16] os índices

devem:

Ser preditivos, isto é, deve prever a utilização da informação presente nos

casos para diferentes situações de problema;

Endereçar os propósitos onde o caso pode ser usado;

Serem suficientemente abstractos para permitir que um caso seja útil em

diferentes situações;

Serem suficientemente concretos para que possam ser facilmente reconhecidos

em situações futuras.

Para a selecção do vocabulário de indexação são propostas duas abordagens, a

recordação e a funcional.

A abordagem de recordação é intuitiva, porque é a abordagem naturalmente utilizada

pelos peritos quando solicitados para seleccionar um índice. É dada particular atenção

às semelhanças consideradas relevantes pelo perito, entre a nova situação e os casos

recordados.

Por sua vez, na abordagem funcional é examinado um conjunto de casos disponíveis e

as tarefas em causa, com peso para a determinação do papel de cada caso no processo

de resolução de problemas.

2.2.3 Memória de casos

A estrutura que armazena um conjunto de casos de um sistema RBC é designada por

memória de casos (ou biblioteca de casos). A memória de casos pode estar ou não

estruturada.

A estruturação da memória de casos torna o processo de inserção de novos casos mais

lento. No entanto, introduz benefícios na sua pesquisa.



O modelo dos EMOPS [23] e o modelo exemplar-categoria [5,25] são duas formas

hierárquicas de estruturar a memória de casos num sistema RBC.

Na Figura 3 é possível observar um exemplo de uma estrutura de memória de casos de

forma hierárquica.

Figura 3- Estrutura exemplo de uma memória de casos [23]

No modelo EMOPS (também chamado de modelo de memória dinâmica) a memória

de casos é uma estrutura hierárquica de pacotes de episódios, também designados por

episódios genéricos (GE´s),conforme esquematizado na Figura 4. A ideia é organizar

casos específicos com propriedades semelhantes sob uma estrutura mais geral (um

episódio genérico). Um GE contém três tipos de objectos: normas, casos e índices. As

normas são características comuns a todos os casos sob um episódio geral. Os índices

são as características que distinguem os casos num GE.



Figura 4- Estrutura de casos e de episódios genéricos [1]

O modelo exemplar-categoria organiza os casos com base na opinião de que, o mundo

real é traduzido por casos e experiencias referidas como exemplares (Figura 5).

Neste modelo a memória de casos é constituída por uma rede estruturada de

categorias, relações semânticas, casos e ponteiros para índices. Cada caso é associado

a uma categoria e a um índice que pode apontar para um caso ou para uma categoria.

Às diferentes características é atribuída uma importância distinta na descrição de um

caso pertencente a uma categoria. Existem três tipos de índices e cada um pode

apontar para um caso ou para uma categoria:

Ligações para categorias, apontam dos descritores do problema

(características) para um caso ou categoria (também chamados recordações);

Ligações para casos, apontam das categorias para os casos (os exemplares),

que estão ordenados segundo a sua capacidade de tipificar a categoria;

Ligações diferenciais, apontam de casos para os casos vizinhos que diferem

apenas num pequeno número de características.



Na Figura 5 poderemos ver a estrutura do modelo exemplar-categoria com as várias

componentes que o constituem.

Figura 5 - Estrutura de categorias, características e exemplares [1]

Uma vez especificado o problema, as técnicas de RBC aplicam um algoritmo que irá

pesquisar casos semelhantes ao problema actual, na memória de casos. O processo de

pesquisa é normalmente efectuado nos sistemas que possuem os seus casos

estruturados, usando os índices para auxiliar na pesquisa.

A avaliação da semelhança entre casos é realizada com base na utilização de métricas.

Segundo Althoff [3] existem dois momentos de avaliação da semelhança entre casos:

em primeiro lugar efectua-se a avaliação de semelhança entre pares de atributos,

denominada por avaliação local, em segundo lugar realiza-se a avaliação de

semelhanças para a totalidade dos atributos dos dois casos a comparar, designada por

avaliação global. Estes conceitos dão origem às respectivas medidas designadas por

distância local e global (ou, correspondentemente, semelhança local e global).

A adaptação consiste na transformação da solução e pode ser feita de duas formas:

1) Por um método explícito, (por exemplo, regras de adaptação);

2) Pela aplicação de um princípio aprendido e que traduz a forma como se transforma

a solução de um caso anterior na solução para um novo caso.



2.2.4 Modelo de Aamodt & Plaza

O modelo RBC de Aamodt & Plaza [1] está na base de construção do sistema

desenvolvido neste projecto.

Este modelo compreende quatro fases e é conhecido por ciclo dos 4R´s: Recuperação,

Reutilização, Revisão e Retenção, conforme representado na Figura 6.

Figura 6- Ciclo dos 4R´s (adaptado de [1])

2.2.4.1 Fase de Recuperação

A etapa de recuperação tem como objectivo recuperar casos da biblioteca de casos

que sejam mais semelhantes ao problema actual.

Segundo Aamodt & Plaza [1], a tarefa de recuperação de casos inicia-se com a

descrição de um problema e termina quando os casos semelhantes são encontrados De

modo a determinar se um caso é útil para a solução do problema actual é necessário

efectuar um cálculo de semelhança, com as características que descrevem o problema

e as experiências em questão.



A técnica do vizinho mais próximo é, segundo Watson [37], a técnica mais utilizada

para a comparação de semelhanças entre casos.

2.2.4.2 Fase de Reutilização

O modelo de Aamodt & Plaza [1] considera que a solução de um caso recuperado em

relação ao caso actual tem que focar dois aspectos principais:

Diferenças entre o caso anterior e o caso actual;

Que fracção do caso recuperado pode ser transferida para o caso actual.

O objectivo da reutilização é fazer com que o caso obtido na tarefa de recolha se

ajuste ao problema actual. É com base nas diferenças que se efectuam as adaptações

da solução, enquanto as fracções idênticas são copiadas. Assim pode-se dizer que na

fase de reutilização existem duas actividades principais: cópia e se necessário,

adaptação.

2.2.4.2.1 Cópia

A actividade de cópia é responsável por transferir a informação comum aos dois

casos. Em sistemas de classificação simples as diferenças são desprezadas e a solução

recolhida é copiada para o novo caso. No entanto, existem sistemas que consideram as

diferenças. Nestes casos terá de existir um processo de adaptação que tenha em conta

essas diferenças.

2.2.4.2.2 Adaptação

A adaptação tem como objectivo a transformação da solução recolhida, de modo a

que esta se adapte ao novo problema. Existem, segundo Aamodt & Plaza [1], dois

tipos de métodos de adaptação:

Métodos de transformação - transformam a solução do caso anterior

(adaptação transformacional);

Métodos de derivação – utilizam o conhecimento sobre a solução do caso

anterior (adaptação derivacional);



Os métodos de derivação são caracterizados por utilizarem o conhecimento adquirido

na resolução do caso anterior para alcançar uma nova solução. Por sua vez os métodos

de transformação modificam a solução dos casos anteriores tendo em conta as

diferenças encontradas.

2.2.4.3 Fase de Revisão

A solução produzida pela fase de reutilização tem, sempre de ser avaliada, para se

determinar se esta se ajusta ou não ao problema. Esta avaliação é feita por um

processo externo, normalmente um ser humano. Existe assim a oportunidade de

aprender com os erros cometidos para que não se tornem a cometer no futuro. Esta

fase é chamada de Revisão e baseia-se em duas tarefas: avaliação da solução gerada

por reutilização e reparação dessa solução, quando necessário, usando o conhecimento

específico do domínio [1].

2.2.4.4 Fase de Retenção

A fase de retenção é a ultima fase do modelo e tem como objectivo reter o

conhecimento gerado pela resolução do problema actual para que este possa

futuramente ser utilizado na resolução de outros novos problemas. Esta etapa implica

decidir qual o conhecimento/informação do caso a reter, como indexar o caso para

futuras recolhas e como integrar o novo caso na estrutura da biblioteca de casos.

O modelo de Aamodt & Plaza [1] considera as seguintes tarefas na retenção de casos:

extracção, indexação e integração.

2.2.4.4.1 Extracção

Esta tarefa tem como objectivo seleccionar o conhecimento a ser retido e pode ter em

conta, se o problema foi resolvido com a utilização de um caso anterior ou por outro

método (por exemplo, indicação de uma nova solução pelo supervisor externo). De

qualquer forma é necessário decidir qual a fonte de aprendizagem. As novas soluções

são candidatas óbvias a serem retidas.

As falhas e a informação retirada da fase de revisão podem também ser extraídas e

retidas, assim como o contexto em que a falha ocorreu. Ao reter as falhas e a sua



origem é possível relembrar as falhas semelhantes anteriores e usar o caso de falha

para evitar propor soluções inviáveis.

2.2.4.4.2 Indexação

A tarefa de indexação como o nome indica é responsável pela associação de índices

aos casos. Como já foi referido anteriormente um índice é uma etiqueta de um caso

que permitirá relembrá-lo.

2.2.4.4.3 Integração

A tarefa final da retenção é a integração do caso na biblioteca de casos. Esta fase

realiza a inclusão, exclusão ou modificação de casos na memória de casos. A

integração pode realizar um ajuste nos índices existentes e no peso dos mesmos. O

objectivo é que em consultas futuras, a recuperação dos casos venha a ser realizada

numa biblioteca de casos mais actualizada.

2.3 RBC Aplicações e Ferramentas de Desenvolvimento

O paradigma RBC tem sido utilizado com frequência, quer na elaboração de

protótipos - para pura investigação ou de aplicação real - quer em cenários industriais

e de comércio electrónico. Formam comercializadas algumas ferramentas de

desenvolvimento por diversas empresas. No entanto, na sua maioria tais empresas

passaram a incluir esse know-how nas próprias soluções que fornecem, pelo que neste

momento o cenário se modificou bastante relativamente ao inicial.

Nesta secção descrevem-se resumidamente alguns protótipos e ferramentas de

desenvolvimento.



2.3.1 Sistemas RCB desenvolvidos de raiz

PATDEX – Sistema de diagnóstico de problemas em máquinas de produção

[26].

CASEY – Sistema de diagnóstico de problemas cardíacos [21]

PROTOS – Sistema de diagnóstico auditivo [25].

CHEF – Sistema de planeamento de receitas [14]

CLAVIER – Sistema de auxílio na determinação eficiente da carga de um

forno industrial [15].

2.3.2 Ferramentas de Desenvolvimento

São plataformas destinadas a proporcionar a criação de um sistema RBC rapidamente,

sem necessidade de recurso a programação. Muitas soluções industriais foram

desenvolvidas com base em plataformas deste tipo, sendo utilizadas por empresas

como a ESA - European Space Agency, Analog Devices.

Contexto histórico

O CYRUS foi o primeiro sistema considerado como um sistema RBC, tendo sido

desenvolvido por Kolodner na universidade de Yale [24]. Este sistema é baseado na

memória dinâmica e na teoria de MOPS (Memory Organization Packages) de

resolução de problemas e de aprendizagem. Este sistema de memoria de casos esteve

na base do aparecimento de outros sistemas de RBC, como Mediator [33], Persuader

[9], Chef [9],Julia[9],e Casey[9].

Outros sistemas foram surgindo ao logo dos tempos até actualidade. Com o objectivo

de fazer um levantamento de alguns destes sistemas, comerciais e de livre acesso,

foram realizadas algumas pesquisas descritas no Anexo 9. Neste anexo encontram-se

a descrição e análise dos seguintes sistemas: Art Enterprise; Induce-IT;CBR Tools;

CBR works; JColibri;myCBR.

De salientar que o software CBR – Works teve maior preponderância na inspiração da

arquitectura geral do sistema desenvolvido neste projecto.



2.4 Resumo

No centro do ciclo RBC está o conjunto de casos que descrevem experiências

passadas, armazenados na biblioteca de casos e, eventualmente, o conhecimento geral

do domínio.

O conhecimento geral do domínio é aplicado em diferentes etapas do processo RBC.

Um exemplo deste conhecimento geral é a definição da gama em que cada atributo

pode variar (domínio do atributo).

Durante a recuperação é seleccionado o caso mais parecido com o actual, ou o

conjunto de casos da biblioteca de casos, a ele mais semelhante, com base na

descrição do novo problema.

Na reutilização, a informação e conhecimento contida nos casos recuperados é

utilizada para propor uma solução para o novo problema. Existe por vezes a

necessidade da solução do caso proposto ser alterada, de forma a adaptar-se às

necessidades do problema actual.

No final deste processo, a revisão avalia se a solução proposta pode ou não ser

aplicada no contexto do problema actual.

A solução do caso gerado durante a fase de revisão deve ser guardada, para que possa

ser usada na resolução de problemas futuros. Esta é a fase de retenção.



3 Árvores de decisão

Neste capítulo são apresentados alguns conteúdos teóricos sobre árvores de decisão,

tendo como objectivo transmitir o seu funcionamento e as vantagens da sua aplicação.

Como foi referido, a aplicação de um algoritmo de construção de uma árvore de

decisão é um dos objectivos deste projecto.

3.1 Definição geral

As árvores de decisão consistem numa hierarquia de nós ligados por ramos, numa

estrutura em árvore. O nó interno, também conhecido como nó de decisão ou nó

intermediário, é a unidade que avalia, através de testes lógicos, quais serão os

próximos nós descendentes, ou filhos. Em contrapartida, um nó externo (não tem nó

descendente), também conhecido como folha ou nó terminal, está associado a um

rótulo ou a um valor.

Em geral, o procedimento de uma árvore de decisão consiste em apresentar um

conjunto de dados ao nó inicial (ou nó raiz) e, dependendo do resultado do teste

lógico usado pelo nó, “prosseguir” para um determinado nó filho. Este procedimento

é repetido até que um nó terminal seja alcançado. À repetição deste procedimento está

inerente a recursividade sempre presente em estruturas como as árvores.



3.2 Representação de uma árvore de decisão

Na Figura 7 está representada uma árvore de decisão onde cada nó contém um teste

para um dado atributo e cada ramo descendente corresponde à verificação de uma

determinada condição relativa ao valor desse atributo. O conjunto de ramos é distinto,

cada folha está associada a uma classe e cada percurso da raiz até às folhas

corresponde no fundo a uma regra de classificação.

Figura 7 – Representação de uma árvore de decisão [39]

Alguns dos métodos de selecção dos atributos a colocar nos nós, baseiam-se no

conceito de entropia.

3.3 Entropia

A entropia, conceito originário da teoria da Informação de Shannon [32], caracteriza a

(im)pureza dos dados num conjunto, sendo por isso uma medida da sua falta de

homogeneidade em relação à sua classificação. Por exemplo, num classificador

binário (i.e. cujas classes são apenas do tipo positivo ou negativo) a entropia é

máxima (igual a 1) quando o conjunto de dados possui tantos exemplos positivos

como negativos.



Generalizando, dado um conjunto (S) que pode ter c classes distintas, a entropia de S

é dada [22]:

( ) ∑

[1]

onde: é a proporção de dados em S que pertencem à classe i.

Algumas das propriedades da entropia são:

Entropia máxima ( ) se ∀

Entropia (S) = 0 se

Figura 8 – Representação gráfica versus entropia p(x) [32]

Seja P(A) o conjunto dos valores que o atributo A pode assumir; seja x um elemento

deste conjunto e seja Sx o subconjunto de S formado pelos dados em que A = x. A

entropia que se obtém ao particionar S em função do atributo A, i.e., a entropia

representativa da sub-árvore resultante, é dada por:

( ) ∑| |

| | ( )

( ) [2]



O ganho de informação será dado pela diferença entre a entropia do conjunto original,

S, e a resultante da equação [2]:

Ganho (S,A) = Entropia (S) − E (A)

[3]

3.4 Algoritmos

Existem vários critérios e algoritmos para a geração de uma árvore de decisão. O

melhor modelo depende sempre do problema, podendo um algoritmo apresentar maior

ou menor precisão do que outro.

Dos vários algoritmos os mais conhecidos são:

ID3

CART -Classification and Regression Trees

C4.5 (e C5, uma versão melhorada do C4.5)

CHAID (Chi Square Automatic Interaction Detection)

Dos algoritmos acima apresentados apenas foram analisados o ID3 e C4.5 por serem

os que utilizam o conceito de entropia, e em particular o C4.5 por ser reconhecido

como um dos melhores, ou mesmo o melhor. De seguida são apresentadas algumas

noções sobre estes dois algoritmos.

3.4.1 ID3

O algoritmo ID3, Iterative Dichotomizer 3, foi criado por J.R Quinlan [22], umas das

referências dos algoritmos actuais de indução de árvores de decisão.

Neste algoritmo a árvore de decisão é construída de cima para baixo (top-down) de

modo a escolher sempre o melhor atributo em um dos nós de decisão. O atributo

escolhido é aquele a que corresponde um maior Ganho de Informação, conforme dado

pela equação [3].

Depois da escolha do melhor atributo para cada nó, de forma recursiva é aplicado o

algoritmo para os nós descendentes de cada um, até que sejam atingidos os critérios



de paragem que podem ser: ganho de informação mínimo, número de elementos no

nó, entre outros.

Como todos os classificadores, este algoritmo aplica-se a problemas cujas classes de

classificação são valores discretos. Os atributos numéricos têm de ser previamente

discretizados.

O atributo escolhido para os nós de decisão (nó que subdivide um ramo) é calculado

através do ganho de informação. O ganho de informação mede a relevância de um

dado atributo para a predição da classe. A escolha do atributo que mais reduz a

entropia, ou seja, do mais relevante, tende a fazer com que as árvores geradas sejam,

de um modo geral, menos profundas e menos ramificadas.

Uma das grandes vantagens do ID3 é a sua simplicidade. O processo de construção

das árvores de decisão é simples e o seu funcionamento fácil de perceber.

3.4.2 Algoritmo C4.5

O algoritmo C4.5 criado também por, J.R Quinlan [22], vem combater alguns

problemas do ID3, nomeadamente o problema de overfitting e a tentativa de exclusão

de atributos que, por dividirem o conjunto de dados em muitos subconjuntos, podem

ser tomados pelo ID3 como bons preditores, quando na realidade não o são (caso, por

exemplo, de uma chave primária).

Por isso, neste algoritmo o critério de escolha do atributo a usar no teste de cada nó é

o Gain Ratio (em vez do Ganho de informação), conforme equação 4. Este conceito

tem em linha de conta quantos subconjuntos são obtidos ao se utilizar um determinado

atributo para teste. Esta medida é dada pelo Split Information (equação 5).

),(

),(

ASormationSplitInf

ASGainS,A)GainRatio(

[4]



c

1i

2log-S

S

S

S)mation(S,ASplitInfor

ii

[5]

Outro problema que este algoritmo resolve é o de se poder usar atributos com valores

quantitativos, o que o ID3 não permitia.

Este algoritmo utiliza a pós-poda (tpost-prunning, descrito na secção seguinte) de

modo a reduzir as subárvores. Esta redução significa que alguns dos nós

originalmente obtidos, são transformados em folhas. Os cortes são feitos através de

testes que têm em conta o erro de classificação obtido antes e depois do corte. Deste

modo, a poda é feita se o desempenho da árvore não diminuir.

3.5 Overfitting / Underfitting e Prunning

3.5.1 Overfitting e Underfitting

O fenómeno do overfitting ocorre quando a árvore é construída de modo a estar

demasiado adaptada aos exemplos de treino, isto é: se lhe for aplicado o conjunto de

treino, a taxa de erro será baixa; mas se lhe for aplicado um conjunto diferente, ela

apresentará, provavelmente, uma taxa de erro considerável, por não possuir

capacidade de generalização. O fenómeno do underfitting ocorre no caso contrário,

isto é, quando a árvore não está suficientemente ramificada para ter uma taxa de erro

aceitável, mesmo quando lhe for aplicado o conjunto de treino.

3.6 Prunning

Segundo Breiman [6], para prevenir o problema do overfitting e melhorar a

classificação deve-se realizar a poda (prunning) da árvore.

A poda da árvore é aplicada em duas situações diferentes:



Durante a sua construção, chamada pre-prunning ou poda descendente, de

modo a parar o crescimento da árvore;

Com a árvore já completa, chamada post-prunning ou poda ascendente.

O processo de poda pode ser feito da seguinte maneira:

1. Percorrer a árvore em profundidade.

2. Para cada nó de decisão calcular:

a. Erro no nó

b. Soma dos erros nos nós descendentes

3. Se o erro do nó for menor ou igual à soma dos erros dos nós descendentes

então o nó é transformado em folha.

A Figura 9 apresenta um exemplo de poda, que resulta na árvore da Figura 10.

Figura 9 – Árvore original

Figura 10 – Árvore após a poda

Na post-prunning a árvore é gerada no seu tamanho máximo e só depois é podada

aplicando métodos de evolução confiáveis. A subárvore com o melhor desempenho

será a escolhida.

Este processo pode ser computacionalmente ineficiente pelo facto de gerar uma árvore

muito grande e depois esta mesma árvore ser reduzida a uma árvore mínima.



O pre-prunning é mais rápido porém menos eficiente que o post-prunning devido ao

risco de interromper o crescimento da árvore indevidamente, obtendo-se uma árvore

sub-óptima [6].



4 Análise de Requisitos

No desenvolvimento deste projecto foi feito o levantamento de requisitos, seguindo os

parâmetros gerais das metodologias de desenvolvimento de software.

O sistema a desenvolver tratará os seguintes tipos de atributos:

Numéricos

Inteiros

Booleanos

Nominais

Taxonómicos

Difusos

Na implementação da aplicação deve ser usado um algoritmo para a construção de

uma árvore de decisão. A árvore de decisão deve ser integrada no ciclo de

funcionamento da aplicação.

Pretende-se que a árvore de decisão, quando activada, seleccione, em função dos

valores dos atributos de um novo caso, um subconjunto da Biblioteca de Casos,

correspondente ao conteúdo de uma das suas folhas, a que for atingida de acordo com

o valor dos atributos do novo caso.

Depois disso pretende-se que o sistema progrida através de uma pesquisa local, com

base no algoritmo Nearest-Neighbor, ordenando então os casos por semelhança global

e propondo a solução do mais próximo.

O sistema terá de ter duas interfaces, Windows e Web.

Deve ser possível carregar casos de forma massiva para o sistema.

Deve ser possível criar vários domínios de aplicação configuráveis.

O sistema deve possuir três níveis de permissões; Administrador, Supervisor,

Utilizador.



1. O Administrador terá acesso a todas as funcionalidades da aplicação.

2. O Utilizador poderá apenas utilizar o sistema para submeter um caso novo.

3. O Supervisor além das permissões de um utilizador normal poderá também,

ver os casos recentemente inseridos no sistema e decidir se devem ou não ser

incorporados na biblioteca de casos.

4.1 Requisitos Funcionais da aplicação

Neste subcapítulo são apresentadas as principais características da aplicação, no que

diz respeito à sua camada de negócio, detalhando as suas funcionalidades.

A aplicação irá interagir com uma base de dados que será alimentada pela própria

aplicação, tanto através de um interface web como de uma interface Windows.

Os principais requisitos funcionais são apresentados a seguir:

Listar casos

Inserir novo caso

Pesquisar casos semelhantes a um caso actual

Carregar casos para a biblioteca de casos

Listar e ver casos candidatos para entrar na biblioteca de casos

Mover ou eliminar casos candidatos a entrar na biblioteca de casos

Criar um novo domínio, editá-lo e desactivá-lo:

o Adicionar atributos ao domínio, editar e remover

Definir pesos dos atributos

Definir domínio dos atributos

Definir outras características dos atributos

Definir fórmulas de distância / semelhança local

o Adicionar utilizadores ao domínio

o Definir soluções

o Definir tipo de semelhança global

Adicionar utilizadores, editar e eliminar

o Definir tipos de acesso

Utilizador; Supervisor; Administrado.



Seguidamente são descritos todos os requisitos funcionais anteriormente enumerados.

A opção listar casos, visa listar todos os casos guardados da biblioteca de casos.

Na opção inserir caso, o utilizador poderá inserir um novo caso no sistema.

A opção de pesquisa de casos semelhantes visa aplicar o conceito de recuperação e

reutilização do ciclo de vida do RBC, sobretudo com vista ao teste de performance

das fórmulas de semelhança local e global, adoptadas.

A opção de carregar casos para a biblioteca de casos, tem como objectivo carregar

casos de forma massiva através de um ficheiro Excel (ou base de dados), para a

biblioteca de casos.

Na opção de listar casos candidatos para a entrar na biblioteca de casos, é possível ver

os casos que foram recentemente inseridos no sistema e que são candidatos a

incorporar a biblioteca de casos, podendo confirmá-los ou não.

A opção de mover ou eliminar candidatos para entrar na biblioteca de casos, deve

permitir mover os casos que estão na biblioteca de casos recentes (temporária) para a

biblioteca de casos principal. Nesta opção é permitido também eliminar os casos

recentes.

A criação de um novo domínio permite criar um novo domínio de utilização para o

sistema. A plataforma pode, assim, lidar com vários domínios ao mesmo tempo, por

exemplo, um de diagnóstico e outro de comércio electrónico, com diferentes

bibliotecas, atributos e utilizadores. Por isso, esta opção compreende a adição de

atributos, utilizadores e definições das semelhanças a utilizar.

A opção de adicionar, editar e eliminar, utilizadores permite a gestão de utilizadores

do sistema.

4.2 Casos de Uso

Os casos de uso, seguidamente descritos demonstram de uma forma geral, o

funcionamento do sistema.

Na Figura 11 é apresentado um diagrama que esquematiza como os casos de usos

estão ligados com os actores.



Figura 11 – Casos de uso



4.2.1 Utilizador

Um utilizador normal poderá efectuar as seguintes acções no sistema:

Confirmar solução – Quando é apresentada uma solução para um novo caso, o

utilizador poderá confirmar se a solução apresentada soluciona o problema do

caso. Caso exista uma confirmação o novo caso é guardado na biblioteca de

casos temporária.

Pesquisar casos – A pesquisa de casos compreende a inserção dos dados de um

novo caso e a pesquisa de casos semelhantes na biblioteca.

4.2.2 Supervisor

Um utilizador, com privilégios de Supervisor, pode efectuar para além das acções de

um utilizador normal, as seguintes:

Adicionar Caso – Criar um caso e a sua solução e guardar informação na


Confirmar novo caso – Confirmar um caso que esteja na biblioteca de casos

temporária. A confirmação move o caso para a biblioteca de casos.

4.2.3 Administrador

Um utilizador com privilégios de administrador, pode efectuar as acções de um

utilizador normal e de um Supervisor, tendo ainda as seguintes permissões:

Administrar utilizadores do sistema – permite adicionar, eliminar e editar

utilizadores do sistema.

Criar novo domínio – permite criar domínios no sistema, onde é possível

adicionar atributos e utilizadores ao domínio especificar semelhanças locais e

globais. Possibilidade de eliminar ou editar o domínio.



4.3 Requisitos não funcionais

Existem alguns pontos importantes no que diz respeito aos requisitos não funcionais

que são seguidamente mencionados:

Um utilizador terá de estar devidamente autenticado para utilizar o sistema.

Toda a arquitectura assentará em tecnologias Microsoft.

Armazenamento de dados: O Sistema de Gestão de Base de Dados será o

Microsoft Sql Server 2008.

O utilizador terá de possuir um browser ou uma máquina Windows para

aceder ao sistema.



5 Ambiente de Desenvolvimento CBR

Neste capítulo são apresentadas as tomadas de decisão e os pontos importantes para o

desenvolvimento da aplicação desenvolvida. Inicialmente é feito uma

contextualização sobre as tecnologias existentes no mercado, semelhantes ao sistema

construído neste projecto.

Na secção 5.3 são apresentados os tipos de atributos criados para o sistema, incluindo

os seus parâmetros de configuração.

A secção 5.4 apresenta os cálculos de semelhança que o sistema possui, tais como a

semelhança global e a semelhança local.

A secção 5.5 apresenta a forma da utilização de um algoritmo de criação de árvores de

decisão, com o recurso a uma ferramenta externa (WEKA) [35].

A secção 5.6 refere a arquitectura criada para o sistema desenvolvido, explicando

cada uma das camadas de software, assim como o sistema de tabelas da base de

dados.

5.1 Introdução

Este projecto visa não só a implementação de um ambiente de desenvolvimento para

sistemas RCB, mas também a adição de algumas mais-valias relativamente às

aplicações disponíveis até agora.

Um dos pontos fortes e inovador, relativamente a outras aplicações desenvolvidas é a

conjugação de árvores de decisão (C4.5) com um algoritmo de pesquisa local

(nearest-neighbors). Pretende-se com este aperfeiçoamento que a aplicação seja mais

rápida e mais precisa a nível das soluções encontradas para os casos submetidos. Por

outras palavras, pretende-se que o sistema desenvolvido encontre mais soluções

confiáveis para um dado problema.

O algoritmo de construção da árvore de decisão usado foi o C4.5, com o uso da API

(Application Programming Interface) disponibilizado pela WEKA [35]. A escolha

deste algoritmo para a aplicação no sistema passou pela necessidade de usar atributos

numéricos, algo que este algoritmo suporta, além do seu reconhecido valor.



Outra mais-valia desta aplicação, em detrimento de outras, é o uso de atributos

taxonómicos e difusos. Em ambos foram implementadas funções de semelhança

próprias.

Finalmente, a plataforma incorpora a fase de retenção, característica não presente no

ambiente MyCBR nem noutros sistemas comercias anteriormente disponíveis, tais

como o CBR-Works.

Outra característica deste ambiente de desenvolvimento é o de poder ser usado em

vários domínios de aplicação, dado que os atributos são totalmente configuráveis.

Assim sendo, a aplicação poderá ser usada tanto num ambiente de diagnósticos, como

num sistema de vendas. Basta para isto que o administrador configure o domínio

conforme o uso pretendido.

Devido ao sistema ser dinâmico, por permitir a criação de vários domínios e

diferentes atributos para cada um deles, a criação da base de dados é também

dinâmica.

.



5.2 Representação dos casos

A estratégia adaptada para a representação de casos é a representação atributo-valor.

5.2.1 Representação atributo-valor

A representação atributo-valor é uma forma simples de representação de casos, na

qual um item é representado por um par atributo-valor [36].

Tabela 1 – Exemplo representação atributo valor

Atributos Valor

Marca Ford

Cor Azul

Ano 1989

Preço 1000€

A representação de casos atributo-valor pode ser definida por tipos, tais como:

booleanos, datas, símbolos (ordenado, não-ordenado ou taxonómico), números e

texto.

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

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

Fácil implementação de medidas de semelhança;

Fácil armazenamento dos casos;

Recuperação eficiente.

Contudo existem algumas desvantagens como:

Incapacidade de representar informação estrutural;

Incapacidade de representar informação relacional.



5.3 Tipo de atributos

Nesta secção, são apresentados os tipos de atributos e a sua representação. A

representação de um caso pode ser feita através de atributos simples, como por

exemplo: numéricos, inteiros, booleanos e nominais, ou através de atributos

complexos, tais como, taxonómicos e difusos.

Além do valor do atributo, é possível configurar, para alguns atributos, o modo como

a comparação é feita, de modo a corresponder às necessidades do utilizador.

A criação de atributos difusos, tal como já foi referido, foi uma mais-valia para o

sistema desenvolvido. Este tipo de atributos permite representar o conhecimento

impreciso, que não pode ser traduzido simplesmente como verdadeiro ou falso. Isto

permite recolher e tratar informações vagas.

Os atributos difusos utilizados neste projecto têm como base a teoria dos conjuntos

difusos. Esta teoria, criada por Zadeh [38] define conjunto difuso como um conjunto a

que cada elemento pertence num grau variável entre 0 e 1, designado por grau de

pertença. O grau de pertença representa o quanto “é possível” esse elemento pertencer

ao conjunto difuso. Este grau pode ser determinado por uma função de pertença, que

retorna sempre um valor real que varia de 0 a 1: o valor 0 indica que não pertence ao

conjunto, e 1 que pertence totalmente. Como exemplo, a altura de um homem pode

ser representada pelos seguintes três conjuntos difusos: “baixo”, “médio” e “alto”; a

cada um destes conjuntos estariam associados os valores das alturas possíveis para

cada um destes termos linguísticos.

Os atributos taxonómicos são estruturas de organização do conhecimento, esquemas

ordenados em várias áreas, segundo determinadas regras ou normas. Esta abordagem

permite que termos relacionados sejam agrupados e categorizados, o que torna o

processo de recuperação de informação mais simples e transparente. Normalmente

este tipo de atributos está associado à área da biologia para a representação

hierárquica das espécies. Todavia este tipo de atributos também pode ser de

conveniente utilização em sistemas de comércio electrónico.

Nos próximos subcapítulos são apresentados os atributos criados neste projecto de

uma forma pormenorizada.



5.3.1 Numérico

Um atributo numérico tem as seguintes características:

Representa um valor do tipo float;

Pode ter a propriedade de ser mandatório.

Os tipos de valores que podem ser escolhidos são configurados aquando da criação do

atributo. Os valores que o atributo pode ter são escolhidos pelos seguintes parâmetros:

Ilimitado: Pode ser escolhido qualquer valor.

Enumerado: Pode ser escolhido um valor de uma lista predefinida. O

utilizador escolhe um conjunto de valores que podem ser usados no sistema

Menor ou igual a zero: Pode ser escolhido um qualquer valor menor ou igual

a zero.

Maior ou igual a zero: Pode ser escolhido um qualquer valor maior ou igual a

zero.

Intervalo: Pode ser escolhido um qualquer valor compreendido num intervalo.

A semelhança local entre atributos deste tipo pode ser personalizada em relação à sua

simetria, podendo ser simétrica ou assimétrica:

Simétrica – A semelhança numérica, no caso de ser simétrica, terá valores

iguais de semelhança para valores com a mesma distância ao ponto zero.

De modo a possibilitar mais formas de semelhanças para valores simétricos, a

recta que definirá a semelhança para cada ponto poderá ser dois tipos:

o Step at: Neste tipo de recta a semelhança será máxima (igual a 1) num

determinado intervalo e cairá abruptamente para zero fora desse

intervalo como é possível ver na Figura 12.

Figura 12 - Gráfico Semelhança StepAt



A fórmula para o gráfico de um atributo numérico com semelhança simétrica Step At

é a seguinte:

{

[6]

o Polinomial: Neste tipo de recta a semelhança é máxima no ponto zero

e diminui de forma polinomial dentro do intervalo de valores. Quando

o expoente é 1, a semelhança é linear. A Figura 13 mostra

graficamente a semelhança numérica para um atributo com um

intervalo de [-3,3], onde a semelhança é máxima no ponto 0 e decresce

de forma constante.

Figura 13- Gráfico Semelhança Polinomial

A fórmula para a semelhança simétrica polinomial é a seguinte:

{

(

)

(

)

[7]

Tanto no caso da recta Step At como na Polinomial, o intervalo de semelhança é

calculado tendo em conta os piores casos possíveis. Nos casos supracitados (Figura 12

e Figura 13) o cálculo será o seguinte:

Dado um conjunto de valores é determinado o valor máximo e o valor mínimo.

Assim, para

Piores casos:



1. [ ] = -3- 3 = -6

2. [ ] = 3 – (- 3) = 6

Figura 14- Deltas para a semelhança

Assimétrica – A semelhança numérica assimétrica permite definir uma

semelhança constante para um determinado intervalo, enquanto que para o

restante será decrescente/crescente. O ponto de inversão da semelhança será o

ponto x=0. A semelhança assimétrica poderá ser de dois tipos:

o Maior perfeito: Neste tipo a semelhança para os valores acima do

ponto 0 será constante e igual a 1, enquanto que para valores abaixo do

ponto zero a semelhança irá decrescer até zero. A Figura 15 apresenta

um exemplo deste tipo de semelhança.

Figura 15- Semelhança numérica, Maior perfeito

A fórmula do gráfico de um atributo numérico com semelhança

assimétrica do tipo Maior perfeito é a seguinte:

{

(

)

[8]



o Menor Perfeito: Neste tipo a semelhança para os valores abaixo do

ponto 0 será constante e igual a 1, enquanto que para os valores acima

do ponto zero a semelhança irá decrescer até zero. A Figura 16 mostra

um exemplo deste tipo de semelhança.

Figura 16- Semelhança numérica Menor perfeito

A fórmula para a semelhança assimétrica do tipo Menor perfeito é a

seguinte:

{

(

)

[9]

Esta semelhança assimétrica, maior perfeita e menor perfeita, é óptima para os casos

em que se estabelece um mínimo ou máximo sobre um dos parâmetros do resultado

procurado.

Por exemplo, analisando o seguinte caso de um sistema de venda/procura de casa

(imobiliárias):

Pretende-se procurar apartamentos do tipo T2.

O preço máximo de 30.000€.

Tabela 2-Apartamentos no sistema

Tipo Preço

Apartamento1 T2 29.000€






Analisando a Tabela 2 verifica-se que o apartamento 1 preenche na íntegra as

condições impostas. Por outro lado, o apartamento 3 apesar de não ter exactamente as

condições especificadas, dado que é do tipo T3, ou seja, maior que o pretendido,

também preenche as condições apesar de ser por excesso. O apartamento T3 é um

caso, em que apesar das condições especificadas não serem completamente

cumpridas, cumpre as necessidades procuradas.

Um sistema de procura de casas deste tipo poderá ser configurado, com atributos

numéricos, para maior perfeito, de modo a não excluir os casos que ultrapassam as

condições impostas, apesar de cumprirem as necessidades procuradas.

5.3.2 Inteiro

Um atributo inteiro tem as mesmas características do atributo numérico, mas ao

contrário do atributo numérico representa um valor inteiro. Todos os parâmetros de

configuração e semelhança são iguais aos do atributo numérico.

5.3.3 Booleano

Um atributo Booleano tem as seguintes características:

Representa um valor do tipo booleano (0 ou 1);

Pode ter a propriedade de obrigatoriedade;

Pode ter a propriedade de mandatório.

Os atributos booleanos têm um domínio de [0,1], logo a semelhança booleana é

calculada da seguinte forma:

{

[10]



5.3.4 Nominal

Um atributo nominal tem as seguintes características:

Representa um valor do tipo nominal

o Um atributo nominal representa um conjunto de valores, por exemplo

“alto; médio; baixo”.

Pode ter a propriedade de mandatório;

Pode ter a propriedade ordinal;

Pode ter a propriedade circular.

É importante referenciar que a semelhança é calculada de forma diferente para o caso

do ser nominal ordinal ou nominal circular.

A diferente forma de cálculo prende-se com o facto de ser mais fácil fazer a

comparação de valores circulares tendo em conta a distância que se encontram um do

outro. E no caso de não circular é mais fácil fazer a sua comparação tendo em conta a

semelhança que existe entre cada um. A Figura 17 e a Figura 18 mostram um

esquema que ilustra o funcionamento dos dois casos.

Figura 17 - Atributo nominal circular

Figura 18- Atributo nominal ordinal

Nos atributos nominais normais a comparação é feita através da sua semelhança não

respeitando qualquer ordem, ou seja, a semelhança poderá ser configurada sem ordem

Segunda feira

Terça feira

Quarta feira

Quinta feira

Sexta feira

Sábado

Domingo

Alto

Médio

Baixo

Muito Baixo



nenhuma, através de uma tabela de dupla entrada. Um exemplo é o caso das cores,

representado na Figura 19.

Figura 19- Atributo nominal normal

Observando o esquema do atributo nominal circular, apresentado na Figura 17, é

perceptível que a comparação dos dias da semana seja feita de uma forma circular

devido à distância a que cada dia está um do outro. Por exemplo, a terça-feira está à

mesma distância da quinta-feira que o sábado de segunda-feira.

Já no caso de um atributo nominal ordinal, Figura 18, será mais fácil e perceptível

comparar os valores tendo em conta a semelhança entre cada um deles.

A Figura 20 e a Figura 21 apresentam para o mesmo atributo nominal a representação

da semelhança e da distância, entre os vários valores.

Figura 20 – Tabela de Semelhança

Figura 21 – Tabela de distância

Como se pode verificar nas tabelas acima apresentadas, ambos os casos (semelhança e

distancia) são simétricas. Contudo os valores poderão ser alterados manualmente de

acordo com a preferência do utilizador, alterando a simetria das tabelas.

Azul Vermelho

Laranja Preto

Amarelo Branco



O algoritmo de criação da tabela de semelhança, Figura 20, dos valores nominais é o

seguinte:

n = número de valores do atributo nominal.

m = distância do ponto onde x1 = x2

S = semelhança

Início do algoritmo

o Determinar o “passo”

o Aplicar a fórmula a todas as células

{

[11]

A equação 11 representa a equação da semelhança.

Fim do algoritmo

O algoritmo de criação da tabela de distância, Figura 21, dos valores nominais é o

seguinte:

n = numero de valores do atributo nominal.

m = distancia do ponto onde x1 = x2

S = semelhança

Início do algoritmo

o Determinar o “passo”

o Aplicar a fórmula a todas as células

{

[12]

A equação 12 representa a distância.

Fim do algoritmo



5.3.5 Taxonómico

Um atributo taxionómico tem as seguintes características:

Representa uma estrutura taxonómica;


A estrutura de um atributo taxonómico pode assumir várias formas visuais, Figura 22

e Figura 23, representando ambas a mesma estrutura.

Figura 22 - Representação vertical

Figura 23- Representação horizontal

A comparação dos valores deste tipo de atributo é fácil dado que a posição de um

atributo na estrutura determina a distância a que se encontra dos restantes e assim é

possível calcular a sua semelhança.

5.3.6 Difusos

Um atributo difuso tem as seguintes características:

Representa um conjunto de números difuso;


Cada valor pertencente ao atributo difuso é definido por quatro pontos que

determinam a forma da sua função de pertença, considerada sempre trapezoidal.

Trata-se da chamada notação α-cut. A Figura 24 apresenta o gráfico de um atributo

difuso.

A

B

C D

E

F

A B

C

D

E F



Figura 24 – Funções de pertença trapezoidais de um atributo difuso

Como é possível observar existem áreas que são comuns a diferentes valores do

atributo e áreas pertencentes exclusivamente a um valor. A área B por exemplo faz

parte do valor “baixo” e do valor “médio”, o que significa que qualquer valor crespo

nessa região da abcissa poderá pertencer a ambos os termos linguísticos. Por exemplo,

o valor 2,5 será baixo num grau 0,5 e médio num grau também 0,5.

5.4 Semelhança

A avaliação de semelhança entre casos ocorre em dois momentos [3]:primeiro avalia-

se a semelhança entre pares de atributos, designada por semelhança local, cujas

metodologias foram descritas nas secções anterior; depois é realizada a avaliação da

semelhança global entre casos, usando a totalidade dos atributos de ambos os casos.

Estas duas avaliações são articuladas pela seguinte equação de semelhança:

( ) ( ( ) ( ) ( )

( )

[ ] [ ]

[13]

Esta equação representa basicamente a soma das semelhanças entre os pares de

atributos dos casos em análise.



As próximas secções referem-se essencialmente ao cálculo da semelhança global.

5.4.1 Atribuição de pesos aos atributos

A utilização de pesos nos atributos para o cálculo da semelhança tem como objectivo

destacar os atributos mais importantes para a resolução do problema. No sistema

implementado o peso é definido aquando da criação de cada um dos atributos do

domínio.

Os valores destes pesos variam de 0 (menos importante, exclui o atributo do calculo

de semelhança) a 5 (mais importante).

5.4.2 Semelhança Global

A semelhança global mede a semelhança entre dois casos, combinado para isso, a

semelhança de cada um dos atributos através da semelhança local, que compõem cada

um dos casos.

A equação de cálculo da semelhança global é traduzida pela seguinte equação,

eq.[14].

[14]

A distância global pode ser calculada pelas seguintes formas: linear, euclidiana,

máxima e mínima, em que para as duas primeiras são calculadas pela a eq.[16], que

tem como como base a seguinte eq [15].de Minkowski.



rn

k

r

kk yxyxD

1

1

,

[15]

D( ) (∑

( )

∑ )

Onde:

D – Distancia global

c - caso

n = 1 para linear [16]

W - Peso

Nos cálculos da semelhança global é possível o utilizador escolher de entre três tipos

de semelhança, na medida em que a aplicação desenvolvida permite os seguintes tipos

de semelhança global: Linear, Euclidiana, Máxima e Mínima, descritos no Anexo 10.

Os cálculos destas medidas são realizados aquando do cálculo da distância entre dois

casos, eq[16].

A medida de cálculo Linear é a aplicação directa da eq[16], pois esta já faz o cálculo

linear da distância entre os dois casos. O cálculo da medida Euclidiana é a raiz

quadrada, da distância entre os dois casos elevada ao quadrado. Os cálculos para as

medidas Máxima e Mínima, utilizam o cálculo linear entre os dois casos mas este

cálculo é feito apenas para o par de atributos com maior distância ou menor distância

entre eles.



5.4.3 Semelhança Local

A avaliação de semelhanças locais depende do tipo de valores dos atributos, pelo que,

para cada tipo de pares de valores tem de ser ajustada a função de semelhança. De

seguida é apresentada a forma de cálculo de semelhança para cada um dos tipos de

atributos usados na aplicação do projecto desenvolvimento, ponto [5.3].

5.4.3.1 Semelhança numérica

No cálculo da semelhança para os atributos numéricos é necessário proceder à sua

normalização antes de efectuar os cálculos.

A normalização de um atributo numérico é feita através da seguinte expressão eq.[17]:

[17]

O cálculo da semelhança local para os atributos numéricos é feito com os seus valores

normalizados.

A semelhança numérica não é calculada da mesma forma para todos os atributos, a

diferença do cálculo depende da configuração do atributo numérico. A Tabela 3

mostra várias configurações relativas à simetria (simétrica e assimétrica) dos atributos

numéricos, que levam a diferentes cálculos.



Tabela 3- Tabela de semelhança numérica.

Assimétrica

Maior perfeito Menor perfeito

Se valor do caso retido na base de casos

for maior que o do problema actual

então dist = 0, logo a semelhança é 1.

Caso contrário serão aplicadas as

equações normais de cálculo

Se valor do caso retido na base de casos

for menor que o do problema actual

então dist = 0, logo a semelhança é 1.

Caso contrário serão aplicadas as

equações normais de cálculo

Simétrica

Step At Polinomial

-

{

d – distância local entre os atributos do

caso i e j.

} Figura 12

Se for polinomial a normalização dos

atributos em cada caso tem de ser

elevada ao grau do atributo.

5.4.3.2 Semelhança inteira

Um atributo inteiro tem as mesmas características do atributo numérico, deste modo o

cálculo da semelhança de atributos inteiros é igual ao cálculo da semelhança do

atributo numérico descrito anteriormente.

5.4.3.3 Semelhança booleana

O cálculo da semelhança booleana é bastante intuitiva e fácil de calcular, não sendo

necessário a normalização dos valores. A semelhança para os atributos booleanos

pode ser traduzida pela seguinte expressão:



=

[18]

5.4.3.4 Semelhança Nominal

A semelhança nominal é calculada com base nas tabelas de semelhança (para o caso

dos nominais circulares) e da tabela de distância (para os restantes). As tabelas são

construídas pelo utilizador da aplicação quando este cria o atributo nominal, ponto

[5.3.4].

No caso da tabela de semelhança (Figura 20), a semelhança é calculada directamente

através de uma consulta, na referida tabela, pelos índices dos valores do atributo

nominal de cada caso.

No caso da tabela de distância (Figura 21), é igualmente efectuada uma consulta na

referida tabela pelos índices dos valores do atributo nominal de cada caso. Depois de

extraído o valor da tabela é subtraído o valor 1.

5.4.3.5 Semelhança taxonómica

Conforme descrito no capítulo 5.3.5 um atributo semelhança taxonómica assume uma

estrutura de árvore. É com base na posição que os valores ocupam na árvore que a

semelhança entre dois objectos de casos diferentes é calculada.

As fórmulas apresentadas aqui sobre taxonomia foram inspiradas na referência

bibliográfica [34].

A semelhança taxonómica é um assunto bastante discutido, os artigos [28] e [29] são

exemplo disso. Em particular, estes dois artigos descrevem métodos para a avaliação

de dois objectos de uma taxonómica (Figura 25).



Figura 25- Taxonómica

Os nós de uma taxonomia designam-se por classes e não instâncias dessas classes.

Uma classe apenas agrega um conjunto de propriedades comuns a todos os seus

filhos. Acerca das outras propriedades nada é conhecido até que uma seja especificada

por nova subdivisão da classe em questão. Este processo de subdivisão prossegue até

que as folhas sejam atingidas. As folhas representam um objecto concreto para o qual

todas as propriedades têm valores definidos e conhecidos.

Outras noções que é necessário distinguir são semelhança intra-classe e semelhança

inter-classe.

5.4.3.5.1 Semelhança Intra-Classe

Designa-se por Semelhança Intra-Classe [28] [29], SIntra, a semelhança entre dois filhos

do mesmo nó (sejam eles classes ou objectos), representada a vermelho na Figura 25.

A distância entre os objectos C e D, da Figura 25, é possível ser calculada pela média

dos filhos do objecto B, ou seja ½ [34]. No caso geral, para N filhos de um mesmo nó

a distância normalizada média entre eles é representada pela seguinte equação:

[19]

Portanto considerando S= 1-d, a semelhança Intra-Classe será:

A

B

C D

E

F



[20]

5.4.3.5.2 Semelhança Inter-Classe

Designa-se por semelhança Inter-Classe, , a semelhança entre dois nós, onde um

é filho do outro, representado a laranja na Figura 25.

A distância inter-classe [34] obtém-se pela seguinte equação:

(

)

[21]

Portanto considerando S= 1-d, a semelhança Inter-Classe será:

(

)

Onde:

[22]

5.4.3.5.3 Combinação de semelhanças Intra e Inter-Classes

As equações definidas nos capítulos 5.4.3.5.1 e 5.4.3.5.2 são a base para a travessia de

uma árvore de classificação entre quaisquer dois nós. Partindo de um nó A,

pretendendo atingir o nó B, seguindo um caminho específico ao longo do qual a

semelhança entre os nós, vai diminuindo à medida que o caminho percorrido

(distância entre nós) aumenta.

Na Figura 26 é apresentado o caminho percorrido, para o cálculo da semelhança entre

os objectos E e L , .



Figura 26- Caminho percorrido entre E e L

Começando no nó E calcula-se S(E,A) aplicando a fórmula da Semelhança Inter-

Classe dada pela eq.[22]. Como A tem 3 filhos, N=3

778.09

7

3

1.

3

111),(

AES

Entre A e D, tratando-se de filhos do mesmo nó, usa-se a Semelhança Intra-Classe

dada pela eq.[20]. Como R tem 4 filhos, N=4, donde:

75.04

3

4

11, DAS (porque AD)

A semelhança entre E e D é agora calculada como o produto destas duas, conforme

sugerido por Bergmann, [29]:

583.036

21,.,, DASAESDES

Entre D e H aplica-se a semelhança Inter-Classes. O resultado combina-se com

S(E,D) obtido acima. Este procedimento repete-se para se atingir L a partir de H:



75.04

3

2

1.

2

111),(

HDS

4375.0144

63,.,, HDSDESHES

8125.016

13

4

1.

4

111),(

LHS

3555.0256

91,.,, LHSHESLES

Assim sendo a semelhança entre os dois objectos na árvore taxonómica é de 0.3555.

5.4.3.6 Semelhança Difusa

O cálculo de semelhança entre números difusos é feito através dos respectivos valores

de pertença (5.3.6).

A título de exemplo, na Figura 27 é apresentada a configuração de um atributo difuso,

representado por três termos linguísticos. Nesta figura podemos ver que o valor 2,5

corresponde a um valor de pertença de 0,5 para o grupo A (baixo) assim como para o

grupo C (médio), no entanto para o grupo E (alto) o valor de pertença é de 0.

Figura 27 – Pontos de pertença

A expressão que traduz a pertença de um valor a cada um dos termos linguísticos, é a

seguinte:

( )

[23]



( )

onde:

Valor fuzzy do atributo

Depois de calculados os valores de pertença para cada um das áreas, a distância local

entre atributos difusos poderá ser calculada através da seguinte expressão:

∑

[24]

5.5 Árvore de decisão C4.5

O algoritmo de construção de árvores de decisão com recurso ao C4.5 é um algoritmo

muito complexo e de difícil implementação programática. Como a construção do

algoritmo C4.5 em si não era o objectivo deste trabalho, optou-se por recorrer a uma

implementação open-source deste algoritmo.

Foi utilizado o algoritmo disponibilizado pela WEKA (Waikato Environment for

Knowledge Analysis). Este sistema implementa o algoritmo C4.5 dando-lhe o nome

no seu sistema de J48 por ser implementado em Java.

(…) “O pacote de software WEKA começou a ser escrito em 1993, usando Java, na

Universidade de Waikato, Nova Zelândia sendo adquirido posteriormente por uma

empresa no final de 2006. O Weka encontra-se licenciado ao abrigo da General

Public License sendo portanto possível estudar e alterar o respectivo código fonte.

O WEKA tem como objectivo agregar algoritmos provenientes de diferentes

abordagens/paradigmas na sub-área da inteligência artificial dedicada ao estudo da

aprendizagem por parte de máquinas.



Essa sub-área pretende desenvolver algoritmos e técnicas que permitam a um

computador "aprender" (no sentido de obter novo conhecimento) quer indutiva quer

dedutivamente.

O WEKA procede à análise computacional e estatística dos dados fornecidos

recorrendo a técnicas de data-minning tentando, indutivamente, a partir dos padrões

encontrados gerar hipóteses para soluções e nos extremos inclusive teorias sobre os

dados em questão.” (...) [35]

O software WEKA foi criado em java., porém como este projecto foi desenvolvido

em c#, existiu a necessidade de arranjar uma forma de comunicação entre as duas

linguagens.

Para isso recorreu-se à conversão do ficheiro jar (Java Archive) numa dll (Dynamic-

link library) de modo a ser possibilitada a sua utilização no ambiente de

desenvolvimento usado para a construção do sistema (Visual Studio). Esta conversão

foi feita com recurso a várias ferramentas, que estão indicadas no tutorial seguido para

a conversão (em [18]).

A utilização da dll da WEKA (weka.dll) convertida não foi de fácil utilização, devido

a esta só retornar dados em forma texto. Por exemplo ao submeter dados para a

criação da árvore de decisão a weka.dll devolve os dados em forma de texto, como no

exemplo abaixo, obtido com o conjunto de dados bem conhecido, Iris dataset:

petalwidth <= 0.6: Iris-setosa (50.0)

petalwidth > 0.6

| petalwidth <= 1.7

| | petallength <= 4.9: Iris-versicolor (48.0/1.0)

| | petallength > 4.9

| | | petalwidth <= 1.5: Iris-virginica (3.0)

| | | petalwidth > 1.5: Iris-versicolor (3.0/1.0)

| petalwidth > 1.7: Iris-virginica (46.0/1.0)



Assim sendo, teve de ser criada uma camada de software para converter essa

informação, de texto para um objecto c# interpretável e de fácil de manuseamento.

Outra responsabilidade desta camada é a de através da árvore de decisão e de um novo

caso, construir as query´s (i.e., o comando usado para acesso à base de dados), usadas

para retornar os casos da base de dados. A Figura 28 demonstra, de uma forma

simples, a interacção da camada com o resto do sistema:

Figura 28 - Interacção da camada J48

Como é possível observar pela Figura 28 a camada construída (J48 Worker Layer)

tem o seguinte funcionamento.

Ao receber um caso da interface a J48 Worker Layer, comunica com a weka-dll para

esta construir a árvore de decisão (Anexo 1, “TreeJ48”, “BuildDataSet”). O sistema

pode estar configurado para construir a árvore de decisão sempre que seja necessário

usá-la ou usar uma árvore de decisão previamente construída e guardada na base de

dados do domínio respectivo.

Depois de obtida a árvore de decisão, um caso submetido ao sistema é sobreposto às

condições de teste existentes nos nós da árvore, de modo a obter a query respectiva

(Anexo 1, “GetSubQuery”). Por fim a query obtida é aplicada na base de dados e os

casos relevantes são retornados.

BD

Caso

WEKA.DLL

Interface

J48 Worker layer

Query

Casos

Usa os casos para construir a árvore de decisão

Árvore Casos

Casos



O software disponibilizado pela WEKA permite que, para o algoritmo J48, sejam

configurados alguns parâmetros, como demonstrado na Figura 29:

Figura 29-Parâmetros de configuração J48

À imagem do software WEKA, a aplicação desenvolvida neste projecto também

permite a configuração de alguns destes parâmetros. Na Figura 30 é demonstrada a

interface de configuração.

Figura 30 Parâmetros de configuração



5.6 Arquitectura

A tecnologia escolhida para a implementação da aplicação do projecto foi a oferecida

pela Microsoft, Visual Studio, SQL Express. Foi também utilizado uma FrameWork

gráfica (DevExpress) [10], de modo a facilitar e enriquecer a construção do sistema.

A aplicação desenvolvida possui uma alta complexidade, não só devido ao tipo de

sistema em si, mas também pela preocupação em garantir uma alta coesão e baixo

acoplamento da arquitectura. Com este intuito foram tidas as,”Best practices” [20] no

que diz respeito à coesão e acoplamento, assim como na programação do código [8].

Pelos motivos acima citados a arquitectura foi construída em várias camadas de modo

a facilitar a integração de várias interfaces e sistemas externos.

Na Figura 31 estão representadas as camadas construídas no sistema desenvolvido.

Figura 31- Camadas do sistema

Na camada de apresentação foram construídas duas interfaces de utilização do

sistema. Apesar de existirem estas duas interfaces, elas não apresentam as mesmas

funcionalidades. A interface Web tem como principal objectivo a utilização do

sistema, ou seja, a submissão de um caso e procura de casos semelhantes.

A interface Windows, além da utilização do sistema também permite a configuração

do mesmo e a criação de um novo ambiente.

A camada de negócio como o próprio nome indica, é responsável pelo controlo do

negócio do sistema e dos seus processos. É nesta camada que estão todos os processos



fulcrais, que permitem o funcionamento do paradigma de RBC. É também nesta

camada que estão os processos de cálculo de semelhança entre os casos e a utilização

da árvore de decisão.

5.6.1 Diagrama de classes

De modo a permitir o bom funcionamento do sistema e maximizar a simplicidade de

todo o código foram criadas para cada uma das camadas, várias classes. Nos anexos

de 2 a 5, são apresentados os diagramas de classes do sistema.

O Anexo 2 apresenta o diagrama de classes do módulo CBR, que representa o negócio

de um domínio do sistema. Estão aqui representadas as classes dos vários tipos de

atributos [5.3], assim como as classes que representam o domínio, o caso e a solução

do mesmo.

No Anexo 3 é apresentado o diagrama das classes usadas para comunicar com a base

de dados. Estas classes apenas contêm os métodos de comunicação com a base de

dados, ou seja, comunicam com o SGBD (Sistema de Gestão de Base de Dados).

O Anexo 4 apresenta o diagrama de classes que são usadas para comunicar com o

sistema WEKA, e para trabalhar com as árvores de decisão.

No Anexo 5 é apresentado o diagrama de classes usadas para os cálculos de

semelhança entre os vários tipos de atributos. Neste anexo estão representadas as

classes da semelhança linear, euclidiana, máxima e mínima.

5.6.2 Base de dados

Com o objectivo armazenar os dados de todo o sistema, durante a fase de análise foi

realizado o projecto do schema da base de dados,

Foi identificada a necessidade de criar três grupos de tabelas, com o objectivo de

guardar tipos de dados de diferentes origens. Estes três grupos de tabelas originam

assim três bases de dados diferentes.

Esta necessidade surge devido ao facto do sistema ter a necessidade de ser dinâmico,

de modo a possibilitar a criação de vários domínios e cada um deles ter a sua base de

dados.



O facto de cada domínio ter uma base de dados distinta de todas os outros, leva a

outra necessidade, a necessidade de centrar a informação comum a todos os domínios,

como por exemplo, as tabelas de dados dos utilizadores e grupos.

No Anexo 6 é apresentado o diagrama de tabelas da base de dados comum a todos os

domínios.

Quando é criado um novo domínio são criadas duas bases de dados. Uma delas

armazena os dados principais do domínio, enquanto a outra armazena apenas os novos

casos e soluções inseridas no domínio.

Como já foi referido, pretende-se que o sistema seja dinâmico, e daí existir uma base

de dados principal para cada domínio (e outra temporária, onde são armazenados os

novos casos até confirmação ou rejeição pelo Supervisor). Por motivo, existe também

a necessidade da criação de algumas tabelas flexíveis, devido ao facto de os diferentes

domínios terem diferentes atributos. Assim sendo o script de criação de cada base de

dados é diferente para cada domínio, dependendo da configuração do mesmo.

No Anexo 7 e no Anexo 8 são apresentados os diagramas de dados das tabelas de um

domínio. As tabelas, “Case_Library” e “Solução” são tabelas criadas dinamicamente,

pois representam os casos e soluções de um domínio que são configurados on the run,

em virtude das características do sistema que se pretende construir.

5.6.2.1 Descrição das entidades existentes na base de dados

De seguida é apresentado uma tabela (Tabela 4) com uma descrição muito superficial

de cada uma das entidades da base de dados.

Tabela 4- Entidades da base de dados

Entidade Descrição

GRUPO Registo dos grupos do sistema

UTILIZADOR Registo de utilizadores do sistema

DOMINIO Registo de domínios do sistema

SOLUCAO Registo das soluções dos casos

CASE_LIBRAY Registo dos casos do domínio



Entidade Descrição

ATRIBUTO_DOMINIO Dados que representam um atributo

ATRIBDOMINIO_VALORES Valores que um atributo poderá ter

SEMELHANCA_NOMINAL Configuração da semelhança nominal

SEMELHANCA_NUMERICA Configuração da semelhança numérica

TREE_J48 Registo da árvore de decisão

CONFIGS Configurações da árvore de decisão



6 Tecnologias utilizadas

Como já referido anteriormente, no desenvolvimento do sistema, usaram-se

tecnologias Microsoft. O Microsoft Visual Studio 2010 foi o IDE (Integrated

Development Environment) usado na construção do sistema.

O Microsoft SQL Server2008 foi o SGDB usado para suporte das bases de dados.

Para a administração da base de dados foi usado o Microsoft SQL Management

Studio2008.

Foi utilizada a ferramenta Power Designer para a criação das tabelas de base de

dados. Esta ferramenta auxiliou na criação das tabelas e geração do script para a

criação da base de dados.

A framework disponibilizada pela DevExpress [10] foi utilizada para auxiliar a

construção dos interfaces Windows e Web (http://www.devexpress.com/).

Na construção dos diagramas de casos de uso, foi utilizada a ferramenta, Star Uml.

Esta ferramenta está disponível em, http://staruml.sourceforge.net/en/.

Os diagramas de classes foram criados com o auxílio da ferramenta, Visual Paradigm

for UML, disponível em, http://www.visual-paradigm.com.

Com o objectivo de existir um maior controlo e segurança sobre o código da aplicação

foi utilizado um sistema de controlo de versões, SVN (Subversion). O servidor

utilizado foi o ProjectLocker (https://portal.projectlocker.com/). Como cliente para

aceder ao servidor e gerir as alterações dos ficheiros foi usado o programa,

TortoiseSVN (http://tortoisesvn.net/).

http://www.devexpress.com/

http://staruml.sourceforge.net/en/

http://www.visual-paradigm.com/

http://tortoisesvn.net/



7 Testes

A aplicação desenvolvida, descrita neste relatório, pode ser aplicada em casos reais.

Com o objectivo de testar o sucesso do sistema implementado na pesquisa e

apresentação de soluções correctas para os casos submetidos, foram realizados alguns

testes.

Foi criado um domínio, representativo de um negócio real de aconselhamento de

dietas. Este domínio foi carregado posteriormente com 2595 casos representativos de

situações reais.

Cada caso deste domínio é composto pelos atributos representados na Tabela 5:

Tabela 5 – Atributos Naturhouse

Atributo Descrição

Tamanho Tamanho da pessoa em cm

Constitucional Assume valores: R,M,D

Peso Peso da pessoa em Kg

PesoObjectivo Peso a alcançar em Kg

Cintura Cintura em cm

Quadril Quadril em cm

Contorno Contorno em cm

IMC Índice de massa muscular

Hipertensao Assume valores: normal, hipertenso, hipertensa, irregular

IMC Assume valores: Acima, Baixo, Normal, Obeso

ActFisica Assume valores: Normal, Sedentária, Vigorosa

PatRenal Possui Patologia renal: sim, não

PatEstomago Possui Patologia no estômago: sim, não

PatCirculacao Possui Patologia circulação: sim, não

PatDiabetes Possui Patologia diabetes: sim, não



Atributo Descrição

PatOssos Possui Patologia ossos: sim, não

PatColestrol Possui Patologia colesterol: sim, não

PatDepressao Possui Patologia depressão: sim, não

PatAnemia Possui Patologia anemia: sim, não

Enxaquecas Possui enxaquecas: sim, não

Solucao Identificação da solução

Com o objectivo de verificar a fiabilidade dos resultados dos testes obtidos foi

utilizada a ferramenta RapidMiner como meio de comparação.

Esta aplicação tal como o sistema desenvolvido neste projecto permite carregar um

conjunto de casos e “correr” sobre eles alguns algoritmos. Um dos algoritmos

suportados é o NearestNeighbors, utilizado também na aplicação desenvolvida nas

semelhanças entre os casos. O algoritmo J48 utilizado no sistema desenvolvido,

também está disponível no RapidMiner, sendo possível comparar os resultados.

Uma vez que o RapidMiner apresenta os resultados na forma de tabela, Figura 32, foi

necessário criar uma interface semelhante, Figura 33, na aplicação desenvolvida para

comparação de resultados.



Figura 32 – Tabela de testes RapidMiner

Figura 33 – Tabela de testes - plataforma desenvolvida neste projecto



Uma parte dos casos que existem na biblioteca de casos é utilizada como casos

problema (query cases), enquanto os restantes são utilizados como biblioteca de

casos.

Os testes realizam cinco ciclos, em cross-validation, onde para cada ciclo são

utilizados quinhentos casos problema diferentes. Cada um dos casos é submetido ao

sistema e é verificado se foi obtida a solução correcta. Este funcionamento foi

aplicado aos testes do sistema desenvolvido. O RapidMiner processa este algoritmo

por simples configuração de parâmetros nos operadores usados.

De seguida são descritos alguns testes efectuados em ambas as aplicações e

apresentados os resultados obtidos.

Os resultados obtidos em cada teste são apresentados em forma de tabela. Na tabela é

possível verificar, para cada caso, quantas vezes a aplicação chegou à solução

correcta e quantas vezes errou.

7.1 Primeiro Teste

O primeiro teste teve como objectivo perceber como funcionam ambas as aplicações

sem utilizar o algoritmo de criação da árvore de decisão. Com este objectivo cada

uma das aplicações apenas utilizou o Nearest-Neighbors.

Na Tabela 6 são apresentados os resultados obtidos para cada uma das aplicações.

Tabela 6 – Teste com Nearest-Neighbors

Aplicação RapidMiner

Solução Acertou Falhou Precision Acertou Falhou Precision

13 0 38 0,00% 0 41 0,00%

14 15 7 68,18% 0 22 0,00%

15 4 7 36,36% 0 11 0,00%

18 3 5 37,50% 1 7 12,50%

25 6 6 50,00% 0 65 0,00%

47 13 6 68,42% 5 14 26,32%

50 0 5 0,00% 0 5 0,00%

55 26 190 12,04% 14 202 6,48%

56 61 4 93,85% 34 31 52,31%

65 525 5 99,06% 472 58 89,06%





80 1 77 1,28% 0 86 0,00%

82 24 41 36,92% 44 21 67,69%

91 326 193 62,81% 381 138 73,41%

101 166 37 81,77% 154 67 69,68%

102 53 10 84,13% 25 46 35,21%

103 434 5 98,86% 417 22 94,99%

111 25 3 89,29% 18 11 62,07%

124 41 15 73,21% 8 52 13,33%

126 82 13 86,32% 45 50 47,37%

133 26 2 92,86% 14 14 50,00%

Analisando a Tabela 6 é possível verificar que na maioria das situações a aplicação

desenvolvida tem maior percentagem de soluções encontradas correctas do que o

RapidMiner. Existem algumas situações onde o RapidMiner não acerta em nenhuma

das soluções e a aplicação desenvolvida chega a acertar entre 30% a 60%. No entanto

existe uma minoria de situações com resultado igual ou inferior.

Em suma a aplicação desenvolvida obtém resultados superiores ao RapidMiner. No

entanto salienta-se que o RapidMiner é mais rápido nos cálculos dos testes que a

aplicação desenvolvida.

7.2 Segundo Teste

O segundo teste teve como objectivo perceber como funcionam ambas as aplicações

quando é utilizado o algoritmo de criação da árvore de decisão (J48) em conjugação

com o Nearest-Neighbor para pesquisa local.

A Tabela 7 apresenta os resultados obtidos para cada uma das aplicações.

Tabela 7-Teste J48



13 35 0 100,00% 0 41 0,00%

14 22 0 100,00% 7 15 31,82%

15 11 0 100,00% 10 1 90,91%

18 8 0 100,00% 0 8 0,00%

25 11 0 100,00% 0 65 0,00%





47 17 0 100,00% 13 6 68,42%

50 5 0 100,00% 3 2 60,00%

55 212 2 99,07% 1 215 0,46%

56 65 0 100,00% 65 0 100,00%

65 530 0 100,00% 530 0 100,00%

80 73 0 100,00% 0 86 0,00%

82 65 0 100,00% 25 40 38,46%

91 519 0 100,00% 292 227 56,26%

101 197 0 100,00% 220 1 99,55%

102 59 0 100,00% 58 13 81,69%

103 436 0 100,00% 439 0 100,00%

111 27 0 100,00% 27 2 93,10%

124 53 0 100,00% 40 20 66,67%

126 92 0 100,00% 94 1 98,95%

133 28 0 100,00% 28 0 100,00%

Analisando os resultados da Tabela 7 é perceptível que a aplicação desenvolvida

acerta em 100% das soluções para todos os casos, apenas falhando em 0.93% para

uma solução. Por seu turno o RapidMiner apenas consegue acertar na solução para os

casos com uma percentagem de 100% em algumas situações. Apesar disso a sua

média de soluções encontradas correctas é bastante mais alta que no teste anterior. No

entanto existem quatro situações em que não acerta em nenhuma solução.

Mais uma vez a aplicação desenvolvida neste projecto consegue destacar-se em

relação ao RapidMiner apesar de continuar a ser mais lenta nos cálculos.

7.3 Terceiro Teste

Da análise dos dois testes anteriores, verificou-se que a aplicação desenvolvida obtém

resultados superiores em ambos os testes. Outra constatação dos testes anteriores foi

que ambas as aplicações melhoraram os resultados quando utilizam o algoritmo J48.

Assim sendo o terceiro teste tem o objectivo comparar as aplicações, quando apenas

o RapidMiner tem o J48 activado. Este teste visa perceber se a aplicação

desenvolvida consegue alcançar melhores resultados apenas com o NearestNeighbors

do que o RapidMiner utilizando o J48.



Tabela 8 - Teste misto



13 0 38 0,00% 0 41 0,00%

14 15 7 68,18% 7 15 31,82%

15 4 7 36,36% 10 1 90,91%

18 3 5 37,50% 0 8 0,00%

25 6 6 50,00% 0 65 0,00%

47 13 6 68,42% 13 6 68,42%

50 0 5 0,00% 3 2 60,00%

55 26 190 12,04% 1 215 0,46%

56 61 4 93,85% 65 0 100,00%

65 525 5 99,06% 530 0 100,00%

80 1 77 1,28% 0 86 0,00%

82 24 41 36,92% 25 40 38,46%

91 326 193 62,81% 292 227 56,26%

101 166 37 81,77% 220 1 99,55%

102 53 10 84,13% 58 13 81,69%

103 434 5 98,86% 439 0 100,00%

111 25 3 89,29% 27 2 93,10%

124 41 15 73,21% 40 20 66,67%

126 82 13 86,32% 94 1 98,95%

133 26 2 92,86% 28 0 100,00%

Analisando os resultados da Tabela 8 pode verificar-se que existem algumas

situações em que a aplicação desenvolvida consegue alcançar melhores resultados.

No entanto na maioria das situações o RapidMiner consegue alcançar melhores

resultados, apesar da percentagem de acerto não ser significativamente superior.

Numa análise geral pode-se afirmar que nestas condições a aplicação desenvolvida

consegue alcançar quase os mesmos resultados que o RapidMiner, sendo a sua

inferioridade pouco destacável.



7.4 Quarto teste

Este terceiro teste foi efectuado com o objectivo de testar a aplicabilidade dos

atributos difusos em situações particulares, mostrando as suas vantagens.

De modo a testar a aplicação deste tipo de atributos, foram construídos dois domínios

representativos de um sistema de vendas de prédios imobiliários (aplicação ao e-

commerce). Cada um dos domínios possui os atributos representados na Tabela 9

(cada solução, neste domínio, consistirá na identificação do prédio, por número de

processo ou morada).

Tabela 9 – Atributos de sistema de vendas

Atributo Tipo Valores admitidos

Tipologia Nominal T1;T2;T3

Preço Numérico Valor de 100 a 500

Garagem Booleano Sim; Não

Local

Nominal (Domínio 1, Crespo)

Difuso (Domínio 2, Difuso))

A;B;C;D

Na Figura 34 estão representados os prédios (T1,T2,T3) para venda, nas áreas

limitadas e identificadas por A,B,C e D.



Figura 34 – Área de vendas de prédios

Para testar a influência dos atributos difusos, a configuração dos domínios foi

diferente para o atributo “Local”. No domínio 1 o atributo “Local” foi configurado

como um atributo nominal que aceita os valores “A, B, C, D” e para o segundo

domínio este atributo é do tipo difuso, aceitando valores que representam o grau de

pertença de cada prédio a cada uma das zonas A, B, C e D.

Estes valores foram obtidos segundo os eixos, x e y, de acordo com as áreas da Figura

34 e as funções de pertença representada na Figura 35 e na Figura 36.

Figura 35- Funções de pertença para o eixo do x



Figura 36 - Funções de pertença para o eixo do y

A biblioteca de casos foi carregada com os seguintes casos para cada um dos

domínios, como demonstrado na Tabela 10 e na Tabela 11.

Tabela 10 - Biblioteca de casos, domínio 1

Domínio 1

Caso Tipologia Preço Garagem Local

1 T3 100 Não B

2 T2 100 Não A

3 T1 100 Não D

Tabela 11 – Biblioteca de casos, domínio 2

Domínio 2

Caso Tipologia Preço Garagem

Local (Grau pertença)

A B C D

1 T3 100 Não 0,4 0,6 0 0,7

2 T2 100 Não 0,5 0 0,5 0,5

3 T1 100 Não 0 0,8 0,8 0



Suponhamos que se pretende encontrar neste sistema de vendas, no domínio 1,

prédios com as seguintes características.

Tabela 12 - Pedido ao diminio1

Tipologia Preço Garagem Local

Pedido 1 T2 100 Não A

Ao submeter o pedido ao sistema os resultados obtidos foram os seguintes.

Figura 37 – Pedido 1

Como se pode verificar, o caso 2 (T2) é o caso proposto como primeira opção, dado

situar-se na zona A.

Suponhamos que se pretende encontrar neste sistema de vendas, no domínio 2

(difuso), prédios com as seguintes características.

Tabela 13 – Pedidos ao domínio 2

Tipologia Preço Garagem

Local

x y

Pedido 1 T2 100 Não 8 15

Pedido 2 T2 100 Não 3 15

Ao submeter os pedidos ao sistema os resultados obtidos foram os seguintes.





Como se pode verificar pelos resultados, no caso do pedido 2 o sistema indica a

solução 2 como a melhor. Mas já para o pedido 1 a solução que é apresentada como a

melhor é a 1, que se situa na zona B, apesar da localização pedida ser zona A. Mas,

“por acaso” este prédio custa o mesmo que o T2 pedido mas é um T3. Ou seja, a

abordagem difusa permitiu sugerir uma solução aparentemente muito vantajosa, por

ser mais próxima do pretendido, ao mesmo preço e maior.

Comparando os dois domínios criados, é possível perceber que para o domínio 1 o

sistema irá muitas vezes indicar como melhores soluções os casos onde o local (zona)

de procura seja igual ao local de um prédio da biblioteca de casos. Já no caso do

domínio 2 os resultados retornados dependem, de uma forma mais humanizada, do

factor localização, graças à intervenção do sistema de fuzificação.



8 Conclusões

Neste projecto foi construído um sistema de desenvolvimento inspirado no paradigma

Raciocínio Baseado em Casos. O projecto não passou apenas pela aplicação directa

do paradigma RBC, mas também por adicionar algo de novo. O sistema

implementado permite a construção de um sistema baseado em RBC, sendo

necessário apenas a configuração de alguns parâmetros, tudo isto sem grande esforço

e perda de tempo.

A inclusão de atributos difusos e taxonómicos é também uma mais-valia que este

sistema possui, pois a maioria dos sistemas deste género não possui este tipo de

atributos.

Um dos pontos fortes do sistema implementado foi a associação de árvores de

decisão com o NN. Foi esta combinação que culminou nos bons resultados dos testes

efectuados, apesar do algoritmo de NN também obter por si só bons resultados.

A implementação do algoritmo, C4.5 foi trabalhosa e complexa, apesar de utilizado o

J48 da WEKA. Os temas abordados no projecto revelaram-se bastante interessantes e

contribuíram claramente para o desenvolvimento do meu interesse pela área a IA.

As medidas de semelhança implementadas foram também um sucesso, pelo facto de,

como já foi acima referido, levarem a que o NN alcance bons resultados.

Nem tudo correu “às mil maravilhas”: de facto existiram alguns problemas de

performance, algo muito comum em sistemas que utilizam algoritmos de pesquisa,

recursividade ou mesmo cálculos avançados. Nos testes iniciais o comportamento do

sistema não foi o melhor, apesar dos bons resultados finais. Revelou-se muito lento

na obtenção dos casos semelhantes, e foram necessários alguns minutos até serem

obtidos todos os resultados. Esta lentidão devia-se aos acessos à base de dados e à

conversão dos casos da biblioteca de casos em objecto C#. Este problema foi

rapidamente identificado e corrigido, passando a aplicação a retornar todos os

resultados quase de forma instantânea. Os interfaces desenvolvidos foram também

uma mais-valia para este projecto. À primeira vista, mesmo não sendo evidente, os

interfaces Web, Windows foram implementados para serem criados client side,

levando a que sejam dinâmicos. Deste modo ambos são automaticamente adaptados a

todos os domínios que venham a ser criados na plataforma.



O facto de os interfaces serem dinâmicos tornou este projecto muito mais trabalhoso,

no entanto permite que a plataforma seja adaptável.

O facto da arquitectura do sistema ter sido desenvolvido em camadas e com o

cuidado de possibilitar novas adições de atributos assim como medidas de

semelhança, leva a que futuramente seja muito fácil e perceptível a adição de novos

componentes. Isto implica que alterações futuras do sistema causem um baixo

impacto no custo de implementação. Como é sabido, no mundo do software os custos

determinam o sucesso ou insucesso de um negócio.

A título de conclusão posso dizer que o projecto desenvolvido foi positivo e o seu

desenvolvimento tonou-se bastante interessante.

Com o desenvolvimento deste projecto enriqueci substancialmente a minha formação

e, como já referi, surgiram mais algumas ideias para adicionar ao sistema agora

implementado (referidas no ponto 8.2), quem sabe se num futuro académico - que

também já passou pela minha ideia.

8.1 Objectivos realizados

Do ponto de vista do projecto pode-se dizer que os objectivos inicialmente propostos

foram alcançados.

A implementação de uma plataforma flexível foi implementada com sucesso, e a sua

arquitectura está pronta para receber facilmente novas funcionalidades.

Foram construídas os dois interfaces para a utilização do sistema, automaticamente

adaptáveis a novos tipos de atributos.

Foram incluídos os atributos difusos e taxonómicos.

Foi utilizado o algoritmo de criação de árvores de decisão C4.5, existindo a

flexibilidade de conjugação com o NN.

O sistema implementado funciona como um sistema completo cumprindo as etapas

do paradigma de RBC.

Os testes efectuados revelam excelente desempenho.



8.2 Limitações & trabalho futuro

Não sendo objectivo do projecto, e dadas as limitações de tempo, optou-se por não

implementar a fase de adaptação de casos por regras. Este é um tópico para possível

futura implementação.

Como já foi referido anteriormente existiram alguns problemas de performance que

foram ultrapassados. O investimento de mais algum tempo em testes de carga e

melhoria de performance seria um ponto a ter em conta, também como trabalho

futuro.

O sistema implementado é, como já foi referenciado, uma plataforma de RBC e,

como plataforma que é, seria benéfica a criação de web-services para comunicação

com outras aplicações.

Vivendo nós numa era “móvel“, a disponibilização do sistema para as várias

plataformas móveis existentes seria uma mais-valia. Atrevo-me a dizer que seria um

ponto crucial a desenvolver no futuro, mas não seria de fácil implementação. O facto

de a plataforma requerer que o interface seja dinâmico, poderá ser de difícil

implementação nas aplicações móveis, assim como a gestão do número itens

mostrados no visor dos dispositivos móveis.

Em suma, como trabalho futuro … há muitas possibilidades. E, para além disso, o

mundo da IA está em constante desenvolvimento…



Bibliografia

1. Aamodt, E. Plaza.(1994) Case-Based Reasoning: Foundational Issues,

Methodological Variationsand System Approaches. AI Communications, 17(1).

2. Agnar Aamodt , Enric Plaza – Case-Based Reasoning , foundational Issues,

Methodological Variations, and System Approaches

3. Althoff, K.-D. (1995). Evaluating Case-Based Reasoning Systems. In: Proc.

Workshopon Case-Based Reasoning: A New Force In Advanced Systems

Development, S.48-61, published by Unicom Seminars Ltd., Brunel Science

Park, Cleveland Road,Uxbridge, Middlesex UB8 3P, UK.

4. Art-Enterprise – Disponivel em: http://www.ai-cbr.org/tools/brightware.html

(Acedido em 14 de Maio de 2011).

5. Bareiss, R. 1989. Exemplar-Based Knowledge Aquisition - A Unified Approach

to Concept Representation Classification, and learning. Academic Press

6. Breiman, L. (1998). Arcing classifiers. The Annals of Statistics

7. CBR Tools – Disponível em: http://www-sop.inria.fr/axis/cbrtools/manual/

(Acedido em 15 de Maio de 2011)

8. C# Coding Standards and Best Programming Practices - Disponível em:

http://www.dotnetspider.com/tutorials/BestPractices.aspx (Acedido em 20 de

Maio de 2011)

9. David B. Leake (1996) Case-Based Reasoning , Experiences, Lessons & Future

Directions

10. DevExpress – Disponível em - http://www.devexpress.com (Acedido em 15

Março de 2011)

11. Empolis (2008), Technical White Paper Empolis: Dynamic Decision Trees

12. Esteem: Case-based Reasoning Shell – Disponível em:

http://www.stottlerhenke.com/solutions/decision_support/esteem.htm (Acedido

em 15 de Maio de 2011)

13. Friedrich Gebhardt, Angi Vob, Wolfgang Gräther, Barbara Schmidt-Belz (1997)

Reasoning With Complex Cases

14. Hammond,K., 1986, CHEF: A model of case-based planning, Proceedings of

AAAI-86

http://www.ai-cbr.org/tools/brightware.html

http://www-sop.inria.fr/axis/cbrtools/manual/

http://www.dotnetspider.com/tutorials/BestPractices.aspx

http://www.devexpress.com/

http://www.stottlerhenke.com/solutions/decision_support/esteem.htm



15. Hinkle,D., Toomey,C., 1994, Clavier: Applying Case-Based Reasoning to

Composite Part Fabrication, Innovative Applications of Artificial Intelligence

6, AAAI Press / MIT Press

16. Ian Watson (1997) Applying Case-Based Reasoning

17. Induc-IT Disponível em http://www.inductive.com/download.htm (Acedido em

14 de Maio de 2011)

18. IKVM whith Weka Tuturial – Disponivel em:

http://weka.wikispaces.com/IKVM+with+Weka+tutorial (Acedido em 30 Julho

de 2011)

19. jCOLIBRI – Disponível em: http://gaia.fdi.ucm.es/research/colibri/jcolibri

(Acedido em 25 de Maio de 2011)

20. Jeremy Miller, Coesão e acoplamento – Disponível em :

http://msdn.microsoft.com/pt-br/magazine/cc947917.aspx (Acedido em 20

Junho de 2011)

21. J. L. Kolodner.(1993) Case-Based Reasoning. Morgan Kaufmann, San

Francisco, California

22. J. R. Quinlan (1986) Induction of Decision Trees

23. Kolodner, J. 1983b. Reconstrutive Memory: A Computer Model. Cognitive

Science, 7,

24. Kolodner, J. L.1983, Case-Based Reasoning. San Mateo:Morgan Kaufmann

25. Porter, B. W., Bareiss, R., e Holte, R. C. 1990. Concept Learning and Heuristic

Classification in Weak-Theory Domains. Artificial Intelligence Journal, 45(1-2),

229–264.

26. Michael M. Richter, Stefan Wess, University of Kaiserslautern , Similarity,

Uncertainty and Case-Based Reasoning

27. MYCBR – Disponível em: http://mycbr-project.net/ (Acedido em 19 de Maio de

2011)

28. Ralph Bergmann and Armin Stahl (paper), Similarity Measures for Object-

Oriented Case Representations

29. Ralph Bergmann (paper), On the use of Taxonomies for Representing Case

Features and Local Similarity Measures.

30. Remco R. Bouckaert, Eibe Frank Mark Hall, Richard Kirkby, Peter Reutemann,

Alex Seewald, David Scuse, “WEKA Manual for Version 3-6-0” (December 18,

http://www.inductive.com/download.htm

http://weka.wikispaces.com/IKVM+with+Weka+tutorial

http://gaia.fdi.ucm.es/research/colibri/jcolibri

http://msdn.microsoft.com/pt-br/magazine/cc947917.aspx

http://mycbr-project.net/



2008). Disponivel em:

http://switch.dl.sourceforge.net/project/weka/documentation/3.6.x/WekaManual

-3.6.0.pdf (Acedido em 26 de julho de 2011)

31. Riesbeck, C. K., e Schank, R. C. 1989. Inside Case-Based Reasoning. Lawrence

Erlbaum Associates

32. Shannon (1948), C.E.SHANNON ; A Mathematical Theory of communication

33. Simpson,R,L (1985) A computer modelo f case-based reasoning in problema

solving: An investigation in domain of dispute mediation.

34. Marques, V., “Diagnóstico de Falhas em Equipamento Baseado em Informação

Difusa oriunda dos Técnicos de Manutenção”, Tese de Doutoramento, FEUP –

Faculdade de Engenharia da Universidade do Porto, 1982

35. Waikato Environment for Knowledge Analysis – Disponível em:

http://pt.wikipedia.org/wiki/Weka (Acedido em 25 de Julho de 2011)

36. Wangenheim. (2003). Raciocínio Baseado em Casos. Barueri: Manole.

37. Watson and Marir,(1994) Ian Watson and Farhi Marir. Case-based reasoning: a

review. The knowledge Engineering Review.

38. Zadeh (1965), L.A.Zadeh,Fuzzy Sets , Departement of Electrical Engineering

and Electronics Research Laboratory, University of California, Berkeley,

California

39. http://www.liaad.up.pt/~jgama/Bdc/arv.pdf (Acedido em 14 de Junho de 2011)

http://switch.dl.sourceforge.net/project/weka/documentation/3.6.x/WekaManual-3.6.0.pdf

http://switch.dl.sourceforge.net/project/weka/documentation/3.6.x/WekaManual-3.6.0.pdf

http://pt.wikipedia.org/wiki/Weka

http://www.liaad.up.pt/~jgama/Bdc/arv.pdf



Anexos



Anexo 1 J48 Worker Layer

Neste anexo são apresentados alguns métodos e classes usados para a criação da

árvore de decisão.

TreeJ48

O método “TreeJ48” é responsável por comunicar com a weka.dll e obter a árvore de

decisão em forma de texto. Este método recebe os casos da biblioteca de caso, as

respectivas soluções para os mesmos e as configurações a aplicar no algoritmo C4.5

usadas no J48. Neste método é utilizado o método “BuildDataSet” para construir o

DataSet enviado para a weka.dll.

public TreeJ48(List<Caso> lCasos, DataTable solucoes, string[] configsJ48) { try { Instances insts = BuildDataSet(lCasos, solucoes); //// train classifier string[] options = { "-C", "0.25", "-M", "2", "", "", "", "", "", "", "", "", "", "" }; if (!configsJ48.Equals(string.Empty)) { options = configsJ48; } var cls = new weka.classifiers.trees.J48(); cls.setOptions(options); cls.buildClassifier(insts); TreeInString = cls.graph(); String[] list = TreeInString.Split('\n'); treeNodeRoot = TreeJ48.ConstroiTree(list); } catch (Exception) { treeNodeRoot = null; TreeInString = string.Empty; } }



BuildDataSet

Método responsável por construir o dataSet.

private Instances BuildDataSet(List<Caso> lCasos, DataTable solucoes) { try { #region cria os atributos Instances dataset = null; int i = 0; Attribute atr = null; FastVector attrs = new FastVector(lCasos[0].AtributosCaso.Count + 1); foreach (Atributo atributo in lCasos[0].AtributosCaso) { if (atributo.Tipo != AtributoType.Fuzzy) { if (atributo.Tipo == AtributoType.Inteiro || atributo.Tipo == AtributoType.Numérico) { atr = new Attribute(atributo.NomeColunaBd, i); } else { if (atributo.Tipo == AtributoType.Nominal) { var atrNominal = (AtributoNominal)atributo; FastVector attrsValues = attrsValues = ConvertListToFastVector(atrNominal.ValoresNominais); atr = new Attribute(atributo.NomeColunaBd, attrsValues, i); } if (atributo.Tipo == AtributoType.Booleano) { FastVector atrV = new FastVector(2); atrV.addElement("True"); atrV.addElement("False"); atr = new Attribute(atributo.NomeColunaBd, atrV, i); } if (atributo.Tipo == AtributoType.Taxonomico) { var atrTax = (AtributoTaxonomico)atributo; FastVector attrsValues = ConvertListToFastVector(atrTax.GetNodesNamesList(atrTax.ListNodes[0])); atr = new Attribute(atributo.NomeColunaBd, attrsValues, i); } } attrs.addElement(atr); i++; }



} // preenche as opções para as soluçoes FastVector attrsSolu = ConvertDatatableSolucoesToFastVector(solucoes); atr = new Attribute("SOL_SO_SOLUCAO_ID", attrsSolu, i); attrs.addElement(atr); #endregion dataset = new Instances("CaseLibrary", attrs, lCasos.Count); foreach (Caso caso in lCasos) { var inst = new Instance(i + 1); for (int j = 3; j < caso.NomeColuna.Count; j++) { if (caso.AtributosCaso[j - 3].Tipo != AtributoType.Fuzzy) { if (caso.AtributosCaso[j - 3].Tipo == AtributoType.Numérico || caso.AtributosCaso[j - 3].Tipo == AtributoType.Inteiro) { inst.setValue((Attribute)attrs.elementAt(j - 3), Double.Parse(caso.Valores[j].ToString())); } else { inst.setValue((Attribute)attrs.elementAt(j - 3), caso.Valores[j].ToString()); } } } inst.setValue((Attribute)attrs.elementAt(i), caso.Solucao.IdSolucao.ToString()); dataset.add(inst); } dataset.setClassIndex(dataset.numAttributes() - 1); return dataset; } catch (Exception ex) { } return null; }



TreeJ48 e ConstroiTree

Métodos responsáveis por construir um objecto representativo da árvore de decisão.

public TreeJ48(String treeJ48String) { try { TreeInString = treeJ48String; String[] list = TreeInString.Split('\n'); treeNodeRoot = ConstroiTree(list); } catch (Exception) { treeNodeRoot = null; TreeInString = string.Empty; } }

private static TreeNodeJ48 ConstroiTree(String[] list) { try { #region vars Condition conditionTemp = null; List<TreeNodeJ48> mTreeList = new List<TreeNodeJ48>(); string temp = string.Empty; String[] listTemp = null; #endregion for (int i = 0; i < list.Count(); i++) { temp = list[i]; if (temp.Contains("N")) { listTemp = temp.Split(' '); if (listTemp[0].Contains("->")) { #region preenche condicao e e cria o filho temp = listTemp[0].Split('-')[0].Replace('N', ' '); // Get Id father int position = GetPositionFather(int.Parse(temp), mTreeList); // Get father position un array TreeNodeJ48 node = mTreeList[position]; TreeNodeJ48 nodeFilho = new TreeNodeJ48(); conditionTemp = new Condition(); conditionTemp.AtributeName = node.Label; conditionTemp.Condicao = listTemp[1].Split('\"')[1]; //condição conditionTemp.Value = listTemp[2].Split('\"')[0]; // valor nodeFilho.Condition = conditionTemp; nodeFilho.IdNode = int.Parse(listTemp[0].Split('>')[1].Replace('N', ' ')); // Get Id son);



nodeFilho.ParenteIdNode = int.Parse(temp); mTreeList.Add(nodeFilho); #endregion } else { TreeNodeJ48 node = null; temp = listTemp[1].Split('\"')[1].Split(' ')[0]; int id = int.Parse(listTemp[0].Replace('N', ' ')); int position = GetPositionFather(id, mTreeList); // Get father position un array if (position.Equals(-1)) { #region é o root node = new TreeNodeJ48(); node.IsClass = true; node.IsLeaf = false; node.IdNode = id; node.Label = temp; mTreeList.Add(node); #endregion } else { #region n é o root node = mTreeList[position]; node.Label = temp; node.IsLeaf = false; node.IsClass = false; if (listTemp.Contains("shape=box")) node.IsLeaf = true; else node.IsClass = true; #endregion } } } } ConstroiOrdenaTree(mTreeList); return mTreeList[0]; } catch (Exception ex) { } return null; }



TreeNodeJ48 e Condition

Classe que representa um nó da árvore.

public class TreeNodeJ48 { #region vars public String Label { set; get; } public int IdNode { set; get; } public int ParenteIdNode { set; get; } public List<TreeNodeJ48> Nodes { set; get; } public Condition Condition { set; get; } public Boolean IsClass { set; get; } public Boolean IsLeaf { set; get; } public Boolean RigthOfather { set; get; } #endregion public TreeNodeJ48() { Nodes = new List<TreeNodeJ48>(); ParenteIdNode = -1; IdNode = -1; Condition = null; IsClass = false; IsLeaf = false; Label = string.Empty; } }

Classe que representa a condição num nó.

public class Condition { public String AtributeName { set; get; } public String Value { set; get; } public String Condicao { set; get; } }

OptionsJ48

Classe que representa as opções de configuração que podem ser usadas na weka.dll.

public class OptionsJ48 { public static float FACTOR_CONFIANCA { get; set; } public static float MINIMO_OBJ { get; set; } public static Boolean BINARY_SPLITS { get; set; } public static Boolean SAVE_INSTANCE_DATA { get; set; } public static Boolean REDUCE_ERROR_PRUNING { get; set; } public static float N_FOLDS { get; set; } public static float SEED { get; set; } public static Boolean J48_ACTIVE { get; set; }



public OptionsJ48(String bdName, float factorConfianca, float minimoObjs, bool binarySplits, bool savaInstData, bool reducePruning, float nFolds, float seed, bool j48Active) { try { FACTOR_CONFIANCA = factorConfianca; MINIMO_OBJ = minimoObjs; BINARY_SPLITS = binarySplits; SAVE_INSTANCE_DATA = savaInstData; REDUCE_ERROR_PRUNING = reducePruning; N_FOLDS = nFolds; SEED = seed; J48_ACTIVE = j48Active; } catch (Exception) { } } public OptionsJ48(DataTable Configs) { try { if (Configs != null && Configs.Rows.Count > 0) { FACTOR_CONFIANCA = float.Parse(Configs.Rows[0]["CFS_FACTOR_CONFIANCA"].ToString()); MINIMO_OBJ = float.Parse(Configs.Rows[0]["CFS_MINIMO_OBJ"].ToString()); BINARY_SPLITS = IntToBool(Configs.Rows[0]["CFS_BINARY_SPLITS"].ToString()); SAVE_INSTANCE_DATA = IntToBool(Configs.Rows[0]["CFS_SAVE_INSTANCE_DATA"].ToString()); REDUCE_ERROR_PRUNING = IntToBool(Configs.Rows[0]["CFS_REDUCE_ERROR_PRUNING"].ToString()); N_FOLDS = float.Parse(Configs.Rows[0]["CFS_N_FOLDS"].ToString()); SEED = float.Parse(Configs.Rows[0]["CFS_SEED"].ToString()); J48_ACTIVE = IntToBool(Configs.Rows[0]["CFS_J48_ACTIVE"].ToString()); } } catch (Exception) { } } private static Boolean IntToBool(string value) { if (value.Equals("True") || value.Equals("TRUE") || value.Equals("1")) { return true; // true } return false; // false } public String[] GetOptions() {



try { int i = 0; string[] options = { "", "", "", "", "", "", "", "", "", "", "", "", "", "" }; if (SAVE_INSTANCE_DATA) { options[i] = "-L"; i++; } if (REDUCE_ERROR_PRUNING) { options[i] = "-R"; i++; options[i] = "-N"; i++; options[i] = N_FOLDS.ToString().Replace(',', '.'); i++; options[i] = "-Q"; i++; options[i] = SEED.ToString().Replace(',', '.'); i++; } else { options[i] = "-C"; i++; options[i] = FACTOR_CONFIANCA.ToString().Replace(',', '.'); i++; } if (BINARY_SPLITS) { options[i] = "-B"; i++; } options[i] = "-M"; i++; options[i] = MINIMO_OBJ.ToString().Replace(',', '.'); i++; return options; } catch (Exception) { } return null; } }



GetSubQuery

Método responsável por obter a query representativa da aplicação de um caso à árvore

de decisão.

private List<String> GetSubQuery(List<TreeNodeJ48> nodes, DataCase dadosCaso) { List<String> querys = new List<string>(); try { foreach (TreeNodeJ48 node in nodes) { String mQuery = string.Empty; string nomeAtr = node.Condition.AtributeName; string valorBaseCaso = node.Condition.Value; string and = " and "; // obtem o valor do caso a testar para a condicao do node actual string valorCaso = string.Empty; Boolean emptyFild = false; if (dadosCaso.FieldsEmpty != null) emptyFild = dadosCaso.FieldsEmpty.Contains(nomeAtr.Split('_')[0]); if(!emptyFild) valorCaso = dadosCaso.DataCaso[nomeAtr].ToString(); Boolean vCondicao = verificaCondicao(valorCaso, valorBaseCaso, node.Condition.Condicao); if (node.Condition != null && vCondicao) { #region and if (mQuery.Equals(string.Empty)) { and = string.Empty; } else { and = " and "; } #endregion if (valorCaso.Equals("True")) valorCaso = "1"; if (valorCaso.Equals("False")) valorCaso = "0"; if (node.Condition.AtributeName.Contains("Numérico")) valorCaso = valorCaso.Replace(',', '.'); mQuery = string.Concat(mQuery, and, String.Empty, node.Condition.AtributeName, String.Empty, node.Condition.Condicao, String.Empty, "'" + valorCaso + "'"); }



if (node.Nodes.Count != 0 && ( vCondicao || emptyFild)) { List<String> querysTemp = GetSubQuery(node.Nodes, dadosCaso); for (int i = 0; i < querysTemp.Count; i++) { #region and if ((querysTemp[i].Equals(string.Empty) || mQuery.Equals(string.Empty))) { and = string.Empty; } else { and = " and "; } #endregion querysTemp[i] = string.Concat(mQuery, and, String.Empty, querysTemp[i]); querys.Add(querysTemp[i]); } } else // já chegou à folha { if (vCondicao || emptyFild) { #region and if (mQuery.Equals(string.Empty)) { and = string.Empty; } else { and = " and "; } #endregion //mQuery = string.Concat(mQuery, and, String.Empty, "SOL_SO_SOLUCAO_ID", " = ", "'" + node.Label + "'"); querys.Add(mQuery); } } } } catch (Exception ex) { } return querys; }



Anexo 2 Diagrama de classes (CBR)



Anexo 3 Diagrama de classes (Data BD)



utilizad



Anexo 4 Diagrama de classes (J48)



Anexo 5 Diagrama de classes (Semelhança)



Anexo 6 Diagrama de dados (BD

Principal)



Anexo 7 Diagrama de dados (Domínio)



Anexo 8 Diagrama de dados (Temp)

Este diagrama representa as tabelas da base de dados temporária de um domínio.



Anexo 9 Sistemas de RBC

1 Sistemas de RBC

Durante a realização deste projecto foram realizadas pesquisas com o objectivo saber

que ferramentas de RBC existem e qual o seu modo de funcionamento e aplicação.

Muitas das afirmações apresentadas neste anexo foram baseadas no livro de Ian

Watson [16].

Existem algumas ferramentas, de livre uso ou comerciais, com o objectivo de

construir sistemas de RBC, que são dirigidos ao tipo de problema para o qual foram

construídos. Nas secções seguintes são apresentadas breves descrições das

características e funcionalidades das seguintes ferramentas: Art Enterprise; Induce-

IT; CBR Tools; CBR works; JColibri;myCBR.

1.1 Art Enterprise

Art Enterprise[4] foi criada pela empresa Brightware´s da Califórnia que desenvolve

aplicações com base na IA (Inteligência Artificial) .

Este ambiente de desenvolvimento é utilizado em técnicas de IA baseadas em casos e

regras. Esta ferramenta é dirigida principalmente para as empresas que pretendam

optimizar as suas práticas empresariais, podendo ser utilizadas com grande volume de

dados.

As principais características desta ferramenta são:

Interface XML (Extensible Markup Language) de modo a poder partilhar

informação com sistemas externos;

Interoperabilidade Java;

Distribuição de dados de modo a poder utilizar grandes bibliotecas de casos.

Esta é uma ferramenta que é comercializada e não é possível descarregar uma versão

de demonstração, o que levou à impossibilidade de realizar uma análise mais

detalhada.



1.2 Induce-IT

Esta ferramenta disponível para download gratuitamente para estudantes, no site do

distribuidor [17] tem como base o Microsoft Excel.

O objectivo desta ferramenta é o utilizador poder localizar os casos mais semelhantes

ao problema actual, e adaptar o melhor caso a partir das respostas obtidas, podendo

também indicar a resposta para o problema actual [17]. Esta ferramenta permite

também que o problema actual do utilizador seja guardado no sistema como um novo

caso.

As questões de cálculos de semelhança desta ferramenta podem ser realizadas com o

recurso ao ambiente Excel ou então pode ser utilizada a linguagem C com recurso às

bibliotecas dinâmicas, utilizando para isso um interface personalizado [17].

A figura 1 apresenta a interface desta ferramenta, onde é possível observar que é

utilizado o Microsoft Excel.

Figura 1 - Inteface Induce – IT



1.3 Esteem

A ferramenta Esteem [12] é para uso comercial, que possibilita ao utilizador

desenvolver aplicações utilizando o RBC sem necessitar de nenhuma programação.

Esta ferramenta oferece uma interface gráfica que possibilita a definição da estrutura

da aplicação, assim como os índices e adaptação dos casos. A figura 2 apresenta a

interface desta ferramenta.

Figura 2 – Interface do Esteem

Esta ferramenta permite configurar várias opções de combinação (regras), adaptando-

se aos tipos de características.

No que se refere aos cálculos de semelhança esta ferramenta permite ao utilizador

definir pesos relativos às características de maior importância.



1.4 CBR Tools

O CBR Tools [7] é uma framework, desenvolvida pelo INRIA (Institut National de

Recherche) e é dirigida ao desenvolvimento de sistemas de Raciocínio Baseado em

Casos. Esta framework foi desenvolvida em Java e utiliza como base o software

Rational Rose (figura 3), que é necessário para a utilização do CBR Tools.

Figura 3- Interface CBR Tools

Nesta framework é possível encontrar um conjunto de classes que vão ao encontro do

paradigma de RBC (casos, índices, métricas). São também fornecidas classes que

implementam os métodos de semelhança.

Esta ferramenta dá também a possibilidade de efectuar a reutilização dos casos,

indexados através de um esquema de situações ao nível do comportamento.

1.5 CBR Works

O CBR-Works é um software também dirigido para o desenvolvimento de aplicações

RBC, tendo como objectivo a resolução de problemas através de problemas

resolvidos no passado. Este software de entre todos os softwares abordados neste

anexo foi o mais inspirador para construção do sistema desenvolvido neste projecto.

Na seguinte figura 4 é apresentado um interface deste software, de notar que este

software já possui a interface bastante amigável.



Figura 4 – Interface CBR- Works

Este software permite ao utilizador desenvolver um sistema partindo do zero,

configurando os tipos de atributos, definindo as semelhanças e regras. Ou caso se

deseje pode-se utilizar um sistema base para a construção de um novo.

1.6 MYCBR

O MYCBR [27] é uma ferramenta Open Source desenvolvida pelo DFKI (Centro de

pesquisa Alemão de inteligência Artificial). Esta ferramenta foi desenvolvida devido

à necessidade de existir uma ferramenta flexível e fácil de usar, na construção de

protótipos para aplicações RBC, tanto ao nível de sistema de pesquisa ou sistemas

industriais.

O desaparecimento do CBR-Works serviu de inspiração para a criação desta

ferramenta. Na figura 5 é apresentada a interface principal desta ferramenta.



Figura 5- Interface MYCBR

Esta ferramenta tem como principal objectivo minimizar o esforço do utilizador em

construir aplicações RBC que implicam grande complexidade cognitiva nas medidas

de semelhança. Com este objectivo é apresentado ao utilizador uma interface gráfica

que permite configurar vários tipos de atributos e medidas de semelhança. É também

possível verificar a qualidade da recuperação dos casos.

Um dos pontos negativos é a utilização de XML para armazenar a informação do

sistema, não suportando outros tipos de formatos.

1.7 jCOLIBRI

A ferramenta jColibri [19] é uma framework orientada a objectos, construída em

JAVA, com o objectivo de facilitar a construção de sistemas de RBC.

Esta ferramenta pode ser utilizada em ambiente onde existam tecnologias como XML

ou JDBC (conjunto de classes e interfaces (API) escritas em Java que fazem o envio

de instruções SQL para qualquer base de dados relacional).

jColibri é uma evolução do sistema denominado de Colibri que utilizava uma

ontologia de concepção de RBC, o CBROnto. Este facto leva a seja permitido



resolver tarefas comuns em RBC sem a necessidade de possuir conhecimento

específico sobre o domínio.

O Colibri foi desenvolvido em LISP (List Processing Language)e utilizava LOOM

(Ontology Markup Language) como tecnologia para representar o conhecimento.

O jColibri é uma framework que foi desenvolvida à base de tarefas, sendo cada uma

delas associada a uma técnica de RBC:

Recuperação dos casos semelhantes (CBR Retrive Task)

Reutilização de casos para resolver o problema (CBR Reuse Task)

Revisão do caso proposto para a solução (CBR Revise Task)

Retenção do conhecimento obtido (CBR Retain Task)

Estas tarefas são guardas em ficheiros XML, sendo possível adicionar novas tarefas.

Figura 6 – Interface jColibri



1.8 Comparação entre as ferramentas

Visando uma análise comparativa entre as ferramentas pesquisadas, na Tabela 14

estão alguns pontos comparativos entre elas.

Tabela 14- comparação das ferramentas

Licença Métricas Armazenagem

Art enterprise Comercial BD Documentos

Induce-IT Comercial MS Excel

Esteem Comercial Vizinho mais próximo.

Contagem de

características.

BD

Arquivos Texto ASCII

CBR Tools Comercial Vizinho mais próximo.

BD

CBR Works Comercial Média Mínima

Máxima

Euclidiana

BD

MYCBR Livre Soma dos pesos. Mínima

Máxima Euclidiana

XML

jCOLIBRI Livre Média BD Documentos Texto



Anexo 10 Semelhança

Neste anexo são presentados os métodos que permitem os cálculos de semelhança

entre os casos. Os métodos aqui apresentados apenas mostram como é possível fazer

os cálculos utilizando as medidas de cálculo, Linear, Euclidiana, Máxima e Mínima,

com base na distância entre os dois casos.

GetSemelhanca

Este método permite o cálculo da semelhança entre dois casos, utilizando a distância

entre ambos.

public double GetSemelhanca(Caso problema, Caso solucao, String dbName) { try { Double semelhanca = 1 - GetDistancia(problema, solucao, dbName); return semelhanca; } catch (Exception ex) { Parameters.Log.Error("GetSemelhanca (SemelhancaMax)", ex); } return 0; }

GetDistancia (Max)

Este método permite o cálculo da distância entre dois casos utilizando a medida de

cálculo, Máxima.

public double GetDistancia(Caso problema, Caso solucao, String dbName) { Double totalDist = 0; Double distMax = double.MinValue; Double pesoMax = 0; try { for (int k = 0; k < problema.AtributosCaso.Count; k++) { int ii = k; #region ignora os atributos pertencas da tabela de casos if (problema.AtributosCaso[ii].Tipo == AtributoType.Fuzzy) { String origFuzzy = problema.AtributosCaso[ii].Nome.Split('_')[0];



for (int j = ii + 1; j < problema.AtributosCaso.Count; j++) { String origSec = problema.AtributosCaso[j].Nome.Split('_')[0]; if (problema.AtributosCaso[j].Tipo == AtributoType.Fuzzy && origFuzzy.Equals(origSec)) { ii++; } else { break; } } } #endregion Double dist = SemelhancaCalculos.CalcularDistancia(problema.AtributosCaso[ii], problema.Valores[ii], solucao.AtributosCaso[ii], solucao.Valores[ii],dbName); dist = dist * problema.AtributosCaso[ii].Peso; if (dist > distMax) { distMax = dist; pesoMax = problema.AtributosCaso[ii].Peso; } } totalDist = distMax / pesoMax; } catch (Exception ex) { Parameters.Log.Error("GetDistancia (SemelhancaMax)", ex); } return totalDist; }

GetDistancia (Mínima)

Este método permite o cálculo da distância entre dois casos, utilizando a medida de

cálculo Mínima.

public double GetDistancia(Caso problema, Caso solucao, String dbName) { Double totalDist = 0; Double distMin = double.MaxValue; Double pesoMin = 0; try { for (int k = 0; k < problema.AtributosCaso.Count; k++) { int ii = k; #region ignora os atributos pertencas da tabela de casos if (problema.AtributosCaso[ii].Tipo == AtributoType.Fuzzy)



{ String origFuzzy = problema.AtributosCaso[ii].Nome.Split('_')[0]; for (int j = ii + 1; j < problema.AtributosCaso.Count; j++) { String origSec = problema.AtributosCaso[j].Nome.Split('_')[0]; if (problema.AtributosCaso[j].Tipo == AtributoType.Fuzzy && origFuzzy.Equals(origSec)) { ii++; } else { break; } } } #endregion Double dist = SemelhancaCalculos.CalcularDistancia(problema.AtributosCaso[ii],problema.Valores[ii], solucao.AtributosCaso[ii],solucao.Valores[ii], dbName); dist = dist * problema.AtributosCaso[ii].Peso; if (dist < distMin) { distMin = dist; pesoMin = problema.AtributosCaso[ii].Peso; } } totalDist = distMin / pesoMin; } catch (Exception ex) { Parameters.Log.Error("GetDistancia (SemelhancaMin)", ex); } return totalDist; }

GetDistancia (Linear)


cálculo linear.

public double GetDistancia(Caso problema, Caso solucao, String dbName) { Double totalDist = 0; Double pesoDistSum = 0; Double pesoSum = 0; try { for (int k = 0; k < problema.AtributosCaso.Count; k++) {



int ii = k; #region ignora os atributos pertencas da tabela de casos if (problema.AtributosCaso[ii].Tipo == AtributoType.Fuzzy) { String origFuzzy = problema.AtributosCaso[ii].Nome.Split('_')[0]; for (int j = ii + 1; j < problema.AtributosCaso.Count; j++) { String origSec = problema.AtributosCaso[j].Nome.Split('_')[0]; if (problema.AtributosCaso[j].Tipo == AtributoType.Fuzzy && origFuzzy.Equals(origSec)) { ii++; } else { break; } } } #endregion // Double dist = SemelhancaCalculos.CalcularDistancia(problema.AtributosCaso[ii], solucao.AtributosCaso[ii], dbName); Double dist = SemelhancaCalculos.CalcularDistancia(problema.AtributosCaso[ii], problema.Valores[ii], solucao.AtributosCaso[ii], solucao.Valores[ii], dbName); dist = dist * problema.AtributosCaso[ii].Peso; pesoDistSum += dist; pesoSum += problema.AtributosCaso[ii].Peso; } totalDist = pesoDistSum / pesoSum; } catch (Exception ex) { Parameters.Log.Error("GetDistancia (SemelhancaLinear)", ex); } return totalDist; }



GetDistancia (Euclidiana)


cálculo Euclidiana.

public double GetDistancia(Caso problema, Caso solucao, String dbName) { Double totalDist = 0; Double pesoDistSum = 0; Double pesoSum = 0; try { for (int k = 0; k < problema.AtributosCaso.Count; k++) { int ii = k; #region ignora os atributos pertencas da tabela de casos if (problema.AtributosCaso[ii].Tipo == AtributoType.Fuzzy) { String origFuzzy = problema.AtributosCaso[ii].Nome.Split('_')[0]; for (int j = ii + 1; j < problema.AtributosCaso.Count; j++) { String origSec = problema.AtributosCaso[j].Nome.Split('_')[0]; if (problema.AtributosCaso[j].Tipo == AtributoType.Fuzzy && origFuzzy.Equals(origSec)) { ii++; } else { break; } } } #endregion Double dist = SemelhancaCalculos.CalcularDistancia(problema.AtributosCaso[ii], problema.Valores[ii], solucao.AtributosCaso[ii],solucao.Valores[ii] ,dbName); dist = dist * problema.AtributosCaso[ii].Peso; pesoDistSum += dist; pesoSum += problema.AtributosCaso[ii].Peso; } Double distSumP = Math.Pow(pesoDistSum, 2); Double pesoSumP = Math.Pow(pesoSum, 2); distSumP = Math.Sqrt(distSumP); pesoSumP = Math.Sqrt(pesoSumP); totalDist = distSumP / pesoSumP; } catch (Exception ex) {



Parameters.Log.Error("GetDistancia (SemelhancaEuclideana)", ex); } return totalDist; }



Anexo 11 Manual de Instalação



1 Introdução

Este documento descreve todos passos a serem realizados para instalar o sistema

“Ambiente de desenvolvimento CBR”:

1.1 Meio de distribuição

O sistema desenvolvido é distribuído em cd, onde está disponível a aplicação Web e a

aplicação Windows assim como a base de dados necessária para utilizar o sistema.

1.2 Informação específica por plataforma

O sistema desenvolvido é apenas direccionado para a plataforma Windows.

1.3 Pré-requisitos

A instalação deste sistema tem como pré-requisitos uma máquina Windows, com o

Microsoft SQL Server 2008, IIS 6 ou superior, DevExpress 10.2, Microsoft

Framework 4.

2 Instalação

Antes de proceder à instalação propriamente dita é necessário adicionar a base de

dados “Dominios”, disponível no cd de instalação, ao SGBD (Sistema de Gestão de

Base de Dados). Os passos para esta instalação serão descritos seguidamente:

1. No MS SQL Server Management Studio , ir a DatabasesAttach , como se

pode observar na figura seguinte.



Figura 40- Attach database

2. No ecrã apresentado adicionar a base de dado “Dominios” como se apresenta

na seguinte figura.

Figura 41 – Escolher a BD



Depois de adicionar a base de dados “Dominios” no SGBD, o sistema está pronto

para ser instalado.

A aplicação Windows pode ser instalada como um programa normal, usando o setup

disponível no cd de instalação. O setup disponibiliza uma interface amigável de modo

a facilitar a instalação do programa, como se pode ver na seguinte imagem.

Figura 42 – Instalação Windows

Depois de instalada a aplicação apenas será necessário configurar o ficheiro

“CBR_Monitor.exe.config” que se encontra na pasta onde a aplicação foi instalada.

Neste ficheiro é necessário configurar os seguintes parâmetros:

“UserDB” Utilizador com acesso ao SGBD

“UserPwd” Password do utilizador “UserDB”

“ServerDB”Endereço do SDGB

“DataContextDB_DominioConnectionString” Indicar o utilizador,

password, e endereço da base de dado “Dominios”.

“MyDbConnSQLServer” Indicar o utilizador, password, e endereço da

base de dado “Dominios”.

Neste ponto já será possível utilizar o sistema com sucesso.



A instalação da aplicação Web do sistema é feita adicionando a pasta “CBR_WEB”

disponível no cd, ao IIS do servidor. A aplicação web necessita que seja configurado

no ficheiro os seguintes parâmetros:

“DataContextDB_DominioConnectionString” Indicar o utilizador,

password, e endereço da base de dado “Dominios”.

“MyDbConnSQLServer” Indicar o utilizador, password, e endereço da

base de dado “Dominios”.

Neste ponto a aplicação web está instalada e pronta a ser utilizada.



Anexo 12 Manual do utilizador



1 Introdução

Tratando-se de um sistema de interacção com o utilizador serão detalhadamente

apresentadas todas as interfaces gráficas de utilização, assim como explicitados os

respectivos conceitos de funcionamento.

1.1 Estrutura do sistema

O sistema é composto por duas aplicações, uma Web e outra Windows.

Seguidamente são listadas as funcionalidades do sistema construído.

Autenticação

Gestão de utilizadores

Gestão de domínios

Gestão de casos

Carregar casos

Consultar casos recentes

Configuração do sistema

2 Descrição do sistema

2.1 Autenticação

Ao iniciar a aplicação Windows ou Web é mostrador ao utilizador uma interface onde

é necessário inserir as credenciais, como se pode ver na Figura 43 e Figura 44.

É necessário inserir credenciais válidas do sistema apara aceder ao sistema, no caso

se a primeira vez que se está a utilizar o sistema as credenciais de administrador são:

Login: admin

Password : admin



Figura 43- Interface autenticação

Windows

Figura 44 – Interface Web

Depois da autenticação feita com sucesso o utilizador é redireccionado para o ecrã

principal da aplicação.

No caso de estar a utilizar a aplicação Windows é surge o seguinte ecrã.

Figura 45- Ecrã inicial Windows



Na parte superior do ecrã é possível ao utilizador aceder às funcionalidades da

aplicação. Na parte inferior do ecrã é mostrado, qual o utilizador ligado e a qual

domínio.

Caso esteja a usar a aplicação Web para aceder ao sistema, o ecrã principal mostrado

ao utilizador é o seguinte.

Figura 46-Ecrã inicial web

Na parte superior do ecrã principal web é possível aceder a algumas funcionalidades

do sistema.

2.2 Gestão de Utilizadores

A gestão de utilizadores está apenas disponível na aplicação Windows do sistema.

2.2.1 Pesquisar utilizadores

A pesquisa de utilizadores pode ser feita no menu de utilizadores escolhendo a opção

de “Pesquisar”, como demonstrado na figura seguinte.



Figura 47-Lista de utilizadores

Nesta opção é mostrada a lista de utilizadores que estão registados no sistema. Ao

seleccionar um dos utilizadores será possível editar os dados do mesmo ou eliminá-lo

do sistema.

2.2.2 Adicionar utilizador

A adição de um novo utilizador ao sistema pode ser feita no menu de utilizadores na

opção “Adicionar”, como demonstrado na seguinte figura.

Figura 48 – Adicionar utilizador

Nesta opção é possível definir os dados do novo utilizador assim como as suas

credenciais de acesso ao sistema.



2.2.3 Editar utilizador

Editar os dados de um utilizador pode ser feito no menu de utilizadores na opção

“Editar”. Esta opção mostra um ecrã igual ao apresentado na Figura 48, com os dados

do utilizador preenchidos, sendo possível altera-los e guardar as alterações.

2.2.4 Eliminar utilizador

A eliminação de um utilizador pode ser feita no menu de utilizadores na opção

“Eliminar”. Esta opção só está disponível quando um utilizador da lista de

utilizadores estiver seleccionado.

Ao eliminar o utilizador este deixará de ter acesso ao sistema.

2.3 Gestão de domínios

A gestão de domínios está apenas disponível na aplicação Windows do sistema.

2.3.1 Pesquisar domínios

Na opção “Pesquisar” é possível ter uma listagem de todos os domínios do sistema,

como se pode verificar na Figura 49.

Figura 49- Pesquisar domínios



Ao seleccionar um domínio as opções, “Alterar” e “Eliminar” ficam activas podendo

estas ser acedidas.

2.3.2 Eliminar domínio

A eliminação pode ser feita através da opção “Eliminar” no menu de domínios. Ao

eliminar um domínio este fica desactivado não sendo possível ao utilizador aceder-

lhe.

2.3.3 Adicionar domínio

A adição de um domínio pode ser feita no menu de domínios, na opção de

“Adicionar”, como se pode observar na seguinte figura.

Figura 50 – Adicionar domínio

Como pode verificar, na Figura 50, é possível efectuar várias configurações no ecrã

de adição de um domínio.

Na parte superior é possível definir, entre outras, o título do domínio e o nome para a

sua base de dados.

É possível também adicionar novos atributos ao domínio, ao seleccionar a opção

“Adicionar atributo”. Ao seleccionar esta opção será mostrado um novo ecrã onde o



utilizador poderá criar um novo atributo para o domínio, como demonstrado na

seguinte figura.

Figura 51 – Adicionar atributo

Neste ecrã o utilizador pode escolher o tipo de atributo que quer criar e configurar os

dados de semelhança do atributo.

O ecrã da Figura 51 é o mesmo a ser mostrado ao utilizador no caso da edição de um

atributo do domínio. Este ecrã no caso de edição será mostrado ao utilizador, com os

dados do atributo que poderão ser alterados.

No domínio também podem ser associados utilizadores, para isso é necessário

seleccionar o separador “Utilizadores”. Neste separador o utilizador poderá adicionar

utilizadores ao domínio ou mesmo remover, como se pode ver na seguinte figura.



Figura 52 – Utilizadores do domínio

Também é possível definir a estrutura da solução para um domínio, configurável no

separador “Definição da Solução.”, como demonstrado na seguinte figura.

Figura 53- Estrutura da solução

Neste separador podem ser adicionados ou removidos, componentes disponíveis,

“Texto, Hyperlink, Imagem, Numérico”, para a estrutura da solução.

2.3.4 Editar domínio

A edição do domínio está acessível no menu de domínios na opção de “Alterar”,

Figura 50, que mostra um ecrã com as configurações do domínio podendo estas ser

alteradas.



2.4 Gestão de Casos

Na gestão de casos, algumas das opções estão também disponíveis na aplicação web.

Na aplicação web é possível ao utilizador listar os casos do sistema, adicionar novos

casos e testar a semelhança entre casos, demonstrado na, Figura 46.

2.4.1 Pesquisar casos

Nesta opção o utilizador poderá consultar os casos inseridos no sistema, como

evidenciado nas seguintes figuras.

Figura 54 – Lista de casos aplicação Windows

Figura 55 – Lista de casos aplicação web

Ao listar os casos o utilizador pode consultar a informação de cada um dos casos. Ao

consultar um caso é apresentado um ecrã com a informação do caso, igual ao ecrã de

adição de um novo caso.



2.4.2 Adicionar caso

A adição de um novo caso pode ser feita no menu de casos na opção de “Adicionar”.

Ao seleccionar esta opção surge um ecrã onde o utilizador poderá inserir a

informação do novo caso, como é possível ver nas seguintes figuras.

Figura 56 – Adicionar caso, aplicação Windows

Figura 57 – Adicionar caso, aplicação web



2.4.3 Alterar caso

A alteração de um caso existente pode ser feita no menu de casos na opção “Alterar”.

Nesta opção será mostrada a informação do caso seleccionado, num ecrã igual ao da

Figura 56, no caso da aplicação Windows ou igual ao da Figura 57 no caso da

aplicação web.

2.4.4 Eliminar caso

A eliminação de um caso pode ser feita no menu de casos na opção “Eliminar”. Ao

eliminar um caso este será desactivado deixando de ser visível para o utilizador.

2.4.5 Testar semelhança

Esta opção permite submeter um novo caso no sistema e consultar os casos

semelhantes existentes. É também permitido através desta opção consultar a solução

de cada um dos casos semelhantes do sistema.

Os passos de utilização desta opção são igual na aplicação web e Windows.

Para realizar o teste de semelhança é necessário preencher os dados do caso, Figura

58 e Figura 59 e efectuar a pesquisa.

Figura 58 – Testar semelhança Windows



Figura 59 – Testar semelhança Web

Ao efectuar a pesquisa são apresentados os casos semelhantes existentes no domínio.

O utilizador pode consultar a solução que cada um dos casos sugere ou então criar

uma nova.

Ao seleccionar um caso e consultar a sua solução é mostrado o seguinte ecrã, com a

informação da solução.

Figura 60 – Interface Solução web



Figura 61 – Interface solução Windows

Ao consultar a solução de um caso o utilizador pode associar a solução ao caso

actual. A associação da solução ao caso irá guardar o caso e a solução na biblioteca

de casos recentes.

2.5 Carregar Casos

A carga de casos de forma massiva pode ser feita no menu de casos, na opção

“Carregar Casos”, apenas na aplicação Windows.

Ao seleccionar esta opção é mostrado uma interface, Figura 62, onde será possível ao

utilizador carregar casos para o domínio através de um ficheiro Excel. Na pasta de

instalação deste sistema, encontra-se um ficheiro Excel modelo que pode ser usado

para carregar casos.



Figura 62 – Carregar casos

Para carregar os casos o utilizador tem de escolher o ficheiro Excel do qual pretende

carregar os casos e efectuar a sincronização através da opção “Guardar Casos”.



2.6 Consultar casos recentes

Os casos que foram inseridos recentemente no domínio poderão ser consultados na

opção “Casos Recentes” no menu de casos. Esta opção apenas está disponível na

aplicação Windows.

Ao seleccionar esta opção é mostrado uma lista de casos inseridos recentemente no

sistema, como demonstrado na seguinte figura.

Figura 63- Casos recentes

No ecrã apresentado o utilizador pode consultar a informação de cada um dos casos

recentes, na opção “Ver Casos”.

Os casos podem ser eliminados ou desactivados utilizando as opções “Eliminar” e

“Desactivar todos”.

A opção “Eliminar” elimina definitivamente o caso da biblioteca de casos recentes.

A opção “Desactivar todos” desactiva todos os casos listados, não os eliminando da


2.7 Configuração do sistema

Existem algumas configurações que podem ser feitas no sistema, para isso basta

aceder no menu configurações à opção “Parâmetros”, conforme demonstrado na

Figura 64.



Figura 64 – Configurações

No ecrã de configurações o utilizador tem a opção de activar o algoritmo de criação

da árvore de decisão e configurar os parâmetros do mesmo.

É também possível ao utilizador criar a árvore de decisão neste ecrã, escolhendo para

isso a opção “Criar arvore agora”

Relatório de Estágio/Projectofiles.isec.pt/DOCUMENTOS/SERVICOS/BIBLIO/Teses/Tese_Mest_Hug… ·...

Documents

Transcript of Relatório de Estágio/Projectofiles.isec.pt/DOCUMENTOS/SERVICOS/BIBLIO/Teses/Tese_Mest_Hug… ·...