UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

INSTITUTO DE INFORMTICA
PROGRAMA DE PS-GRADUAO EM COMPUTAO

Raciocnio Baseado em Casos

Aplicado ao Gerenciamento de Falhas
em Redes de Computadores

por
CRISTINA MELCHIORS

Dissertao submetida avaliao, como requisito parcial para

a obteno do grau de Mestre em
Cincia da Computao

Profa. Liane Margarida Rockenbach Tarouco

Orientadora

Porto Alegre, agosto de 1999

CIP - CATALOGAO NA PUBLICAO

Melchiors, Cristina
Raciocnio Baseado em Casos Aplicado ao Gerenciamento de
Falhas em Redes de Computadores / por Cristina Melchiors. Porto
Alegre: PPGC da UFRGS, 1999.
151f. : il.
Dissertao (mestrado) Universidade Federal do Rio Grande do
Sul. Programa de Ps-Graduao em Computao, Porto Alegre, BR-RS,
1999. Orientadora: Tarouco, Liane Margarida Rockenbach.
1. Gerenciamento de falhas 2. Sistemas de registro de problemas
3. Raciocnio baseado em casos 4. Gerenciamento de redes I. Tarouco,
Liane Margarida Rockenbach. II. Ttulo.

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

Reitora: Profa. Wrana Panizzi
Pr-Reitor de Ps-Graduao: Prof. Franz Rainner Semmelmahn
Diretor do Instituto de Informtica: Prof. Philippe Olivier Alexandre Navaux
Coordenadora do PPGC: Profa. Carla Maria Dal Sasso Freitas
Bibliotecria-Chefe do Instituto de Informtica: Beatriz Regina Bastos Haro

Agradecimentos

Gostaria de agradecer, em primeiro lugar, minha orientadora, profa. Liane

Tarouco, pelos seus valiosos conselhos, ensinamentos e ateno recebidos desde os
tempos de auxiliar de pesquisa.
Um enorme agradecimento aos meus pais, pelo inesgotvel e constante apoio e
incentivo recebidos durante todo este perodo, e pela incrvel pacincia e ateno que
sempre tiveram. Agradeo, tambm, s minhas irms, Lcia e Paula, e meus cunhados,
pelo carinho e compreenso.
Um agradecimento, tambm enorme e muito especial, ao Mauro, que tanto me
incentivou e apoiou durante todo este trabalho, pelo enorme e constante carinho,
pacincia, compreenso, companheirismo.
Aos gerentes de redes, meus agradecimentos pela pacincia e auxlio prestados
nas diversas entrevistas e consultas, em especial Cristina Nunes, Fernando Krahe e
Margareth Schaffer. Aos meus colegas do CPGCC, pelo apoio e sugestes.
Agradeo, tambm, aos funcionrios do CPGCC, sempre atenciosa equipe da
biblioteca, Eliane, equipe da administrao da rede.
Por fim, meu agradecimento ao CNPq pelo auxlio financeiro que possibilitou a
realizao deste trabalho, UFRGS e aos professores do curso pelos conhecimentos,
auxlio e incentivo recebidos.

Sumrio
Lista de Abreviaturas ................................................................ 7
Lista de Figuras.......................................................................... 8
Lista de Tabelas ....................................................................... 10
Resumo...................................................................................... 11
Abstract .................................................................................... 12
1 Introduo ............................................................................. 13
2 Raciocnio Baseado em Casos .............................................. 15
2.1 Histrico............................................................................................. 16
2.2 O Ciclo CBR ...................................................................................... 17
2.3 A Memria de Casos .......................................................................... 18
2.4 Base de Casos..................................................................................... 18
2.4.1 Representao dos Casos ................................................................................. 19
2.4.2 Indexao.......................................................................................................... 21

2.5 Recuperao ....................................................................................... 22

2.5.1 Estruturas de organizaes da base de casos e algoritmos de recuperao ... 24
2.5.1.1 Memria linear com busca serial ...................................................................... 24
2.5.1.2 Rede de caractersticas compartilhadas ............................................................ 25
2.5.1.3 Redes de discriminao.................................................................................... 25
2.5.1.4 Redes de discriminao redundante.................................................................. 26
2.5.2 Casamento e Classificao ............................................................................... 26
2.5.3 Consideraes sobre a indexao e a recuperao.......................................... 29

2.6 Reutilizao (adaptao)..................................................................... 29

2.7 Reviso............................................................................................... 32
2.8 Armazenamento (aprendizado)............................................................ 34
2.9 Exemplos de Aplicaes CBR ............................................................ 35
2.9.1 Sistema CASCADE .......................................................................................... 35
2.9.2 Sistema Smart .................................................................................................. 37

2.10 Consideraes Finais ........................................................................ 39

3 Gerncia de Redes................................................................. 40
3.1 Introduo .......................................................................................... 40
3.2 reas Funcionais da Gerncia de Redes.............................................. 41
3.3 Sistemas de Registro de Problemas ..................................................... 43
3.4 Sistemas Especialistas para Gerncia de Redes................................... 45

3.5 Raciocnio Baseado em Casos em Gerncia de Redes......................... 48

3.5.1 Sistema NETTRAC.......................................................................................... 49
3.5.2 Sistema ExSim.................................................................................................. 52
3.5.3 Sistema CRITTER ........................................................................................... 54

3.6 Consideraes Finais .......................................................................... 58

4 Raciocnio Baseado em Casos Aplicado a um Sistema de

Registro de Problemas: Sistema DUMBO.............................. 59
4.1 Motivao........................................................................................... 59
4.2 Aquisio do Conhecimento................................................................ 60
4.3 Problemas Tpicos das Redes Pesquisadas .......................................... 61
4.3.1 Camada Interface de Rede............................................................................... 63
4.3.1.1 Ethernet .......................................................................................................... 65
4.3.1.2 Linhas Seriais .................................................................................................. 67
4.3.2 Camada Internet .............................................................................................. 68
4.3.3 Camada de Transporte .................................................................................... 70
4.3.4 Camada de Aplicao ...................................................................................... 71

4.4 Consideraes sobre os Problemas do Domnio .................................. 72

5 Sistema DUMBO: Modelagem ............................................. 74

5.1 Sistema DUMBO - Uma Viso Geral das Tcnicas Adotadas ............. 74
5.2 Representao dos Tipos de Problemas............................................... 78
5.3 Estrutura do Sistema ........................................................................... 81
5.4 Base de Conhecimento........................................................................ 83
5.4.1 Representao dos Casos ................................................................................. 83
5.4.2 Base de Casos: Organizao e Indexao........................................................ 88
5.4.3 Base de Conhecimento Geral do Domnio....................................................... 88

5.5 Modelagem dos Processos CBR ......................................................... 89

5.5.1 Definio do Contexto...................................................................................... 90
5.5.1.1 Elaborao dos Provveis Componentes com Falha Fsica ............................... 91
5.5.1.2 Elaborao dos Tipos de Problema Relacionados............................................. 93
5.5.2 Recuperao: Busca e Classificao ................................................................ 95
5.5.2.1 Algoritmo de Busca......................................................................................... 95
5.5.2.2 Classificao: Similaridade entre Caractersticas .............................................. 96
5.5.2.3 Classificao: Relevncia das Caractersticas ................................................... 99
5.5.2.4 Classificao e Ordenamento ..........................................................................102
5.5.3 Reutilizao e Reviso.....................................................................................104
5.5.3.1 Redefinindo o Contexto..................................................................................105
5.5.4 Aprendizado ....................................................................................................107

5.6 Consideraes Finais ........................................................................ 108

6 Prottipo do Sistema........................................................... 109

6.1 Implementao.................................................................................. 109
6.1.1 Arquitetura do sistema ...................................................................................109
6.1.2 Interao com o sistema..................................................................................117

6.2 Avaliao do Prottipo ..................................................................... 120

7 Consideraes finais ........................................................... 128

7.1 Trabalhos Futuros ............................................................................. 129

Anexo 1 Rede Semntica dos Tipos de Problemas .............. 131

Anexo 2 Caractersticas de um Caso .................................... 135
Anexo 3 Alguns Casos do Sistema ........................................ 141
Anexo 4 Especificao SDL do Sistema................................ 143
Bibliografia............................................................................. 146

Lista de Abreviaturas
CBR

Case-Based Reasoning (raciocnio baseado em casos)

CMIP

Common Management Information Protocol

CMIS

Common Management Information Services

CNPq

Conselho Nacional de Desenvolvimento Cientfico e Tecnolgico

CPGCC

Curso de Ps-Graduao em Cincia da Computao

CPU

Central Processing Unit

IA

Inteligncia Artificial

IAD

Inteligncia Artificial Distribuda

IP

Internet Protocol

ISO

International Organization for Standardization

MBR

Model-Based Resoning (raciocnio baseado em modelos)

MOP

Memory Organization Packets

OSI

Open Systems Interconnection

RBR

Rule-Based Reasoning (raciocnio baseado em regras)

SDL

Specification and Description Language

SNMP

Simple Network Management Protocol

TCP

Transmission Control Protocol

UFRGS

Universidade Federal do Rio Grande do Sul

Lista de Figuras
FIGURA 2.1 - Ciclo CBR ........................................................................................... 17
FIGURA 2.2 - Esquema do processo de recuperao na base de casos ........................ 23
FIGURA 2.3 - Esquema do processo de reviso.......................................................... 33
FIGURA 2.4 - Exemplo de um caso do sistema CASCADE ........................................ 36
FIGURA 2.5 - Arquitetura do sistema CASCADE ..................................................... 36
FIGURA 2.6 - Esquema de uma consulta de um caso no sistema Smart..................... 38
FIGURA 3.1 - Arquitetura do sistema NETTRAC ...................................................... 51
FIGURA 3.2 - Estrutura do ExSim ............................................................................. 52
FIGURA 3.3 - Funo de similaridade utilizada no sistema ExSim............................... 53
FIGURA 3.4 - Exemplo de um registro de problema ................................................... 55
FIGURA 3.5 - Exemplo de um determinador .............................................................. 55
FIGURA 3.6 - Exemplo de adaptao parametrizada................................................... 56
FIGURA 3.7 - Exemplo de adaptao por abstrao ................................................... 57
FIGURA 3.8 - Arquitetura do sistema CRITTER........................................................ 57
FIGURA 5.1 - Rede semntica dos tipos de problemas................................................ 79
FIGURA 5.2 - Rede semntica dos tipos de problemas (parte 2) ................................. 80
FIGURA 5.3 - Rede semntica da localizao dos problemas ...................................... 81
FIGURA 5.4 - Estrutura do sistema proposto.............................................................. 82
FIGURA 5.5 - Componentes de um caso..................................................................... 87
FIGURA 5.6 - Hierarquia da base de casos ................................................................. 88
FIGURA 5.7 - Possveis componentes envolvidos em falhas fsicas e de configurao do
HW ...................................................................................................................... 92
FIGURA 5.8 - Funo para clculo da probabilidade final de cada tipo de problema.... 95
FIGURA 5.9 - Algoritmo para recuperao na base de casos....................................... 96
FIGURA 5.10 - Funo de avaliao numrica utilizada para a classificao dos casos
recuperados .........................................................................................................103
FIGURA 5.11 - Funo para clculo da confiabilidade do casamento entre dois casos 103

FIGURA 5.12 - Funo para clculo do fator de ordenamento ...................................104

FIGURA 5.13 - Esquema do processo de reutilizao e reviso do sistema ................105
FIGURA 6.1 - Diagrama do sistema Dumbo ..............................................................110
FIGURA 6.2 - Diagrama do bloco cliente...................................................................110
FIGURA 6.3 - Diagrama do bloco servidor ................................................................112
FIGURA 6.4 - Definio do Servidor .........................................................................113
FIGURA 6.5 - Definio do CBR...............................................................................115
FIGURA 6.6 - Tela inicial no registro do caso corrente ..............................................117
FIGURA 6.7 - Tela de coleta de caractersticas adicionais para linhas seriais ..............118
FIGURA 6.8 - Tela com casos recuperados................................................................119
FIGURA A1.1 - Rede semntica da localizao dos problemas (parte 1) ....................130
FIGURA A1.2 - Rede semntica da localizao dos problemas (parte 2) ....................131
FIGURA A1.3 - Rede semntica da localizao dos problemas (parte 3) ....................132
FIGURA A1.4 - Rede semntica da localizao dos problemas (parte 4) ....................133
FIGURA A4.1 - Definio do InterpretaDados...........................................................142
FIGURA A4.2 - Definio do MostraTela..................................................................142
FIGURA A4.3 - Definio do ProcessaOperaes......................................................143
FIGURA A4.4 - Definio do ComunicaoCliente....................................................143
FIGURA A4.5 - Definio do InterfaceBD.................................................................144
FIGURA A4.6 - Definio do ComunicaoServidor .................................................144

10

Lista de Tabelas
TABELA 2.1 - Tcnicas de adaptao ........................................................................ 32
TABELA 4.1 - Alguns problemas da camada interface de rede.................................... 64
TABELA 4.2 - Alguns problemas tpicos de redes Ethernet......................................... 65
TABELA 4.3 - Alguns problemas tpicos de linhas seriais............................................ 67
TABELA 4.4 - Alguns problemas tpicos da camada internet....................................... 68
TABELA 4.5 - Alguns exemplos de problemas na camada de transporte ..................... 71
TABELA 4.6 - Alguns exemplos de problemas na camada de aplicao....................... 72
TABELA 5.1 - Tipos de similaridades das caractersticas do sistema ........................... 99
TABELA 5.2 - Relevncia de algumas caractersticas.................................................101
TABELA 6.1 - Tabelas do banco de dados do sistema DUMBO ................................114
TABELA 6.2 - Distribuio dos casos do prottipo por tipo de problema ..................120
TABELA A2.1 - Similaridade das caractersticas adicionais implementadas ................136
TABELA A2.2 - Algumas caractersticas adicionais propostas ...................................138
TABELA A2.3 - Grupo estados das interfaces ...........................................................139
TABELA A2.4 - Grupo produtos...............................................................................138
TABELA A2.5 - Algumas caractersticas especficas do prottipo..............................139
TABELA A3.1 - Lista dos casos presentes no prottipo.............................................140

11

Resumo
Com o crescimento do nmero e da heterogeneidade dos equipamentos presentes
nas atuais redes de computadores, o gerenciamento eficaz destes recursos torna-se
crtico. Esta atividade exige dos gerentes de redes a disponibilidade de uma grande
quantidade de informaes sobre os seus equipamentos, as tecnologias envolvidas e os
problemas associados a elas. Sistemas de registro de problemas (trouble ticket systems)
tm sido utilizados para armazenar os incidentes ocorridos, servindo como uma memria
histrica da rede e acumulando o conhecimento derivado do processo de diagnose e
resoluo de problemas. Todavia, o crescente nmero de registros armazenados torna a
busca manual nestes sistemas por situaes similares ocorridas anteriormente muito
morosa e imprecisa. Assim, uma soluo apropriada para consolidar a memria histrica
das redes o desenvolvimento de um sistema especialista que utilize o conhecimento
armazenado nos sistemas de registro de problemas para propor solues para um
problema corrente.
Uma abordagem da Inteligncia Artificial que tem atrado enorme ateno nos
ltimos anos e que pode ser utilizada para tal fim o raciocnio baseado em casos (casebased reasoning). Este paradigma de raciocnio visa propor solues para novos
problemas atravs da recuperao de um caso similar ocorrido no passado, cuja soluo
pode ser reutilizada na nova situao. Alm disso, os benefcios deste paradigma incluem
a capacidade de aprendizado com a experincia, permitindo que novos problemas sejam
incorporados e se tornem disponveis para uso em situaes futuras, aumentando com
isso o conhecimento presente no sistema.
Este trabalho apresenta um sistema que utiliza o paradigma de raciocnio baseado
em casos aplicado a um sistema de registro de problemas para propor solues para um
novo problema. Esse sistema foi desenvolvido com o propsito de auxiliar no
diagnstico e resoluo dos problemas em redes. Os problemas tpicos deste domnio, a
abordagem adotada e os resultados obtidos com o prottipo construdo so descritos.

Palavras-Chave: gerenciamento de falhas; sistemas de registro de problemas;

raciocnio baseado em casos; gerenciamento de redes.

12

TITLE: CASE-BASED REASONING APPLIED

MANAGEMENT IN COMPUTER NETWORKS

TO

FAULT

Abstract
With the increasing number of computer equipments and their increasing
heterogeneity, the efficient management of those resources has become a hard job. This
activity demands from the network manager a big amount of expertise on network
equipments, technologies involved, and eventual problems that may arise. So far, trouble
ticket systems (TTS) have been used to store network problems, working like a network
historical memory and accumulating the knowledge derived from the diagnosis and
troubleshooting of such problems. However, the increasing number of stored tickets
makes the manual search of similar situations very slow and inaccurate in these kind of
systems. So, an adequate approach to consolidate the network historic memory is the
development of an expert system that uses the knowledge stored in the trouble ticket
systems to propose a solution for a current problem.
Case-based reasoning (CBR), an approach borrowed from Artificial Intelligence
that recently had attracted many researchers attention, may be applied to help diagnosing
and troubleshooting networking management problems. This reasoning paradigm
proposes solution to new problems by retrieving a similar case occurred in the past,
whose solution can be reused in the new situation. Furthermore, the benefits of this
paradigm include the experience learning capability, allowing new problems being added
and becoming available to use in future situations, expanding the knowledge of the
system.
This work presents a system that uses case-based reasoning applied to a trouble
ticket system to propose solutions for a new problem in the network. This system was
developed with the aim of helping the diagnostic and troubleshooting of network
problems. It describes the typical problems of this domain, the adopted approach and the
results obtained with the prototype built.

Keywords: fault management; trouble ticket systems; case-based reasoning; network

management.

13

1 Introduo
As redes de computadores manipulam de modo rpido e eficiente grandes
quantidades de informaes, sendo utilizadas naturalmente no dia a dia das pessoas. Em
virtude de sua importncia, a interrupo de seus servios pode gerar diversas
complicaes para seus usurios, causando perda de rendimentos, atraso no recebimento
de dados crticos, etc.
Entretanto, com o crescimento do nmero e heterogeneidade dos equipamentos e
tecnologias envolvidas nas redes, o nmero de problemas possveis nessas e a
complexidade envolvida no seu diagnstico tornam-se crticos. Assim, as redes so
controladas usualmente por tcnicos especialistas, que so encarregados de manter a
disponibilidade e a qualidade dos seus servios, efetuando o gerenciamento das mesmas.
A fim de auxiliar no gerenciamento das falhas ocorridas na rede, sistemas de
registro de problemas tm sido utilizados. Tais sistemas auxiliam os gerentes na
monitorao dos problemas correntes, mantendo um registro do ciclo de vida do
problema e armazenando, com isso, a memria histrica das falhas de uma rede.
Em virtude do conhecimento acumulado nos sistemas de registro derivado dos
processos de diagnstico e resoluo de incidentes anteriores, esses sistemas podem ser
utilizados para auxiliar na investigao de um novo problema. Entretanto, se o nmero
de registros crescer muito, a busca de solues em situaes anteriores para tentar as
mesmas aes corretivas acaba por se tornar muito morosa e imprecisa quando feita com
base em mera inspeo manual dos registros. Assim, uma soluo apropriada para
consolidar a memria histrica da rede a criao de um sistema especialista que utilize
o conhecimento acumulado nos sistemas de registro de problemas para auxiliar os
gerentes no diagnstico de uma nova situao similar, propondo solues a partir dos
registros armazenados.
Nesse contexto, uma abordagem da Inteligncia Artificial que tem despertado
grande ateno nos ltimos anos e que pode ser utilizada nesses sistemas o raciocnio
baseado em casos. Sistemas com esse paradigma de raciocnio propem solues para
uma ocorrncia corrente pela recuperao de situaes similares ocorridas no passado,
denominadas casos, que podem contribuir para a resoluo do problema corrente. Esses
sistemas tm tambm como caracterstica o aprendizado com a experincia, possuindo a
capacidade de armazenar novas situaes solucionadas, que se tornam disponveis para
futuras consultas e aumentam naturalmente o conhecimento presente no sistema.
O domnio de gerenciamento de redes envolve uma grande complexidade e
variedade de problemas. Alm disso, incorpora novas tecnologias muito rapidamente,
gerando uma evoluo e mudana nas redes muito acentuada. Por estas especificidades,
o uso de raciocnio baseado em casos, em sistemas especialistas do domnio de
gerenciamento de redes, traz inmeras vantagens, entre as quais se destacam: a
diminuio da fragilidade de outros paradigmas de raciocnio, pela sua capacidade de
incorporar novos casos e, assim, suportar mais facilmente as mudanas do domnio; a
possibilidade de um processo de aquisio de conhecimento mais natural.
Este trabalho apresenta um sistema que incorpora o paradigma de raciocnio
baseado em casos em um sistema de registro de problemas tradicional, visando utilizar o
conhecimento armazenado nestes registros para propor solues para um novo problema

14

corrente. Esse sistema, que objetiva manter a memria histrica da rede, denominado
sistema DUMBO.
O captulo 2, que d seqncia a esta introduo, apresenta o paradigma de
raciocnio baseado em casos, fornecendo uma viso geral do mesmo e como ele pode ser
utilizado para desenvolvimento de um sistema. Inicialmente, sero abordadas as questes
referentes base de casos, comentando a representao dos casos e a sua indexao. Em
seguida, sero explicitados os processos envolvidos no ciclo de raciocnio do sistema,
que compreendem a recuperao das situaes similares da base de casos, a reutilizao
da soluo presente nesses casos, a reviso da soluo quando necessrio e, por fim, o
armazenamento da experincia obtida no processo de modo que o caso corrente possa
ser til para a resoluo de problemas futuros. Como ltimo aspecto, so descritos dois
sistemas que utilizam este paradigma e que contriburam para o desenvolvimento de
particularidades dos processos ou da base de conhecimento do sistema DUMBO.
O captulo 3 discorre sobre a gerncia de redes, enfocando o gerenciamento de
falhas e o desenvolvimento de sistemas especialistas para o domnio. Conceitos e
principais tpicos da rea so comentados, e os sistemas de registro de problemas so
apresentados. O uso de sistemas especialistas e suas abordagens so ento discutidos, e,
por fim, alguns sistemas do domnio de gerncia de redes que fazem uso de raciocnio
baseado em casos so citados.
Na seqncia, o captulo 4 introduz o sistema DUMBO, apresentando a
motivao para desenvolvimento de tal sistema. O estudo efetuado sobre os problemas
do domnio ento comentado, sendo apresentados alguns dos problemas tpicos das
redes pesquisadas e algumas consideraes resultantes deste estudo que foram utilizadas
para a modelagem do sistema.
A modelagem do sistema apresentada no captulo 5. Aps uma viso geral da
abordagem utilizada, a representao dos problema usando o formalismo em redes
semnticas apresentada, de modo a fornecer uma viso da hierarquia e dos atributos
dos tipos de problemas identificados na etapa da aquisio do conhecimento e utilizados
no sistema. Em seguida, a estrutura do sistema e os aspectos da base de conhecimento
so abordados, incluindo o modo como os casos foram representados no sistema, como
a base de casos est organizada e que informaes gerais sobre o domnio so mantidas
pelo sistema. Por fim, comentada a forma como cada um dos processos do ciclo de
raciocnio apresentado no captulo 2 foi desenvolvido no sistema.
O captulo 6 apresenta, ento, o prottipo implementado. Aspectos da sua
implementao so abordados e a especificao do prottipo utilizando a linguagem de
especificao SDL (Specification and Description Language) apresentada. Por fim, a
avaliao do prottipo comentada.
Encerrando o texto, uma anlise crtica do trabalho apresentada no captulo
final, enfocando os principais pontos positivos e negativos do sistema modelado, e uma
lista de metas traada como trabalho futuro.

15

2 Raciocnio Baseado em Casos

Sistemas especialistas so aplicaes capazes de representar e raciocinar sobre
algum domnio de conhecimento, a fim de auxiliar na resoluo de problemas ou fornecer
conselhos [JAC 86]. Esses sistemas capturam as estratgias de resoluo de problemas
dos especialistas do domnio e aplicam-nas em circunstncias especficas, de modo
seletivo. O conhecimento dos especialistas, entretanto, no pode ser obtido simplesmente
a partir do conhecimento bsico do domnio isoladamente ele precisa representar a
experincia obtida por estes especialistas, experincia que os capacita a concentrarem-se
nas causas mais provveis de um problema e adaptarem respostas para problemas
especficos [GOY 91].
Os sistemas especialistas utilizam diversos paradigmas, sendo o baseado em
regras o mais utilizado [HAR 89]. Outras importantes abordagens dentro da Inteligncia
Artificial (IA), que podem fornecer meios poderosos para tais sistemas, esto tambm
sendo pesquisadas atualmente, tais como a Inteligncia Artificial Distribuda e o
Aprendizado Automtico [GOY 91]. Mas alm destas, nos ltimos anos tem atrado
ateno uma abordagem da IA que pode ser utilizada para o raciocnio na resoluo de
problemas: a abordagem Case-based Reasoning (CBR Raciocnio Baseado em
Casos).
Sistemas com esse paradigma de resoluo de problemas propem solues para
novos problemas pela recuperao de um caso similar ocorrido no passado, que
reutilizado na nova situao. Alm disso, esses sistemas possuem a capacidade de
aprendizado, uma vez que um novo problema pode ser armazenado aps ter sido
solucionado, tornado-se disponvel para futuros problemas e aumentando com isso o
conhecimento presente no sistema.
Conforme demostram os resultados de pesquisas da psicologia cognitiva, o
raciocnio atravs da reutilizao de experincias passadas um poderoso e freqente
meio para resoluo de problemas por seres humanos [AAM 94]. Quando, por exemplo,
um gerente de rede se depara com um problema a ser solucionado, ele utiliza
primeiramente sua memria de incidentes passados (podendo fazer uso de arquivos de
registros dos problemas anteriores da rede, por exemplo) para propor e justificar a sua
deciso [CAU 95].
Assim, um caso representa na terminologia CBR uma situao ocorrida
anteriormente denominada caso anterior ou do passado que capturada e
aprendida de modo a ser utilizada na soluo de problemas futuros denominados
casos correntes ou novos [AAM 94]. Os casos, que podem ser representados em
diferentes formatos e tamanhos, reproduzem o conhecimento especfico para um
determinando contexto, registrando o conhecimento a nvel operacional. Um caso
registra uma experincia que tem o potencial de ser til para atingir um objetivo ou
conjunto de objetivos mais facilmente no futuro ou de alertar para a possibilidade de
falhas imprevistas em um problema [KOL 93].
Apresentaremos, neste captulo, uma breve reviso da abordagem de raciocnio
baseado em casos. Leituras adicionais sobre a abordagem podem ser obtidas em
[AAM 94][KOL 93][ABE 96][WAT 94][WAT 97][MAR 94][MEL 99],
alm
de

16

referncias de aplicaes desenvolvidas [ABE 95][ACO 92][SMI 92][BRA 91]

[DRE 95][LEW 93][CAU 95][STA 93][MAT 95][LEA 96], entre outras.

2.1 Histrico
Em 1977, Schank e Abelson Apud [WAT 97] propuseram que o conhecimento
geral das pessoas sobre as situaes est armazenado em scripts, permitindo que elas
criem expectativas sobre o que ouvem, e assim, construam inferncias sobre as relaes
entre as coisas das quais ouviram. Os scripts foram propostos como uma estrutura de
memria conceitual, descrevendo informao sobre eventos estereotipados, como ir a
um restaurante ou a uma consulta a um mdico. Experimentos com scripts mostraram,
entretanto, que eles no representam uma teoria completa de representao de memria,
j que as pessoas confundem eventos que tem scripts similares [WAT 94]. Os scripts
fornecem apenas um tipo de conhecimento que as pessoas utilizam para o entendimento:
elas se valem tambm outros tipos de conhecimento, como o conhecimento sobre
objetivos, planos, relaes interpessoais e papeis efetuados pelas pessoas [KOL 93].
Representaes sobre estes tipos de conhecimento tm sido propostas e sistemas de
computadores que usam estes tipos de conhecimento para o entendimento tm sido
desenvolvidos.
Em 1982, Roger Schank Apud [AAM 94] props a teoria da Dinamic Memory
(memria dinmica) e o papel central que a lembrana de situaes anteriores (episdios,
casos) e modelos de situaes (scripts, MOPs pacotes de organizao de memria)
desempenham na resoluo de problemas. Este trabalho, segundo Aamodt e Plaza,
apresenta as razes do uso de raciocnio baseado em casos na Inteligncia Artificial.
Outras caractersticas do campo CBR tm sido originadas do estudo de raciocnio
analgico proposto por Gentner Apud [AAM 94] e das teorias de formao de
conceitos, resoluo de problemas e aprendizado experimental dentro da filosofia e
psicologia [AAM 94].
O primeiro sistema CBR, denominado CYRUS, foi desenvolvido por Janet
Kolodner [AAM 94]. Este sistema, baseado no modelo de memria dinmica de Schank
e na teoria MOP de resoluo de problemas e aprendizado, foi basicamente um sistema
de questes e respostas com conhecimento de vrias viagens e encontros do primeiro
secretrio do estado americano, Cyrus Vance. O modelo de memria de casos
desenvolvido por este sistema serviu de base para outros diversos sistemas
CBR [WAT 94], como MEDIATOR, PERSUADER, CHEF, JULIA e CASEY.
Outra base de CBR e conjunto de modelos foi desenvolvida por Bruce Porter e
seu grupo na University of Texas, em Austin. Inicialmente trabalhando com o problema
de aprendizado automtico para classificao de tarefas, o grupo desenvolveu o sistema
PROTOS [AAM 94]. Esse sistema enfatiza a integrao do conhecimento geral do
domnio e do conhecimento especfico de casos em uma estrutura de representao
unificada um modelo de memria de casos. Alm dessa, outra contribuio
importante para a rea foi o trabalho do grupo de Edwina Rissland na University of
Massachussetts, em Amherst, que desenvolveram o sistema HYPO, aplicado para o
domnio do Direito.
Atualmente, as pesquisas em CBR tm estendido-se rapidamente, sendo
percebidos um crescente nmero de artigos envolvendo CBR em peridicos de IA e um

17

aumento de aplicaes comercias de sucesso [WAT 94], alm de pesquisas em

desenvolvimento em diversos pases.

2.2 O Ciclo CBR

Alm da base de conhecimento composta por casos que representam situaes
anteriores, os sistemas de raciocnio baseado em casos requerem mecanismos para
recuper-los da base de conhecimento, adapt-los para o caso corrente, validar a soluo
proposta e armazenar o conhecimento obtido durante o processo. Conforme apresentado
por Aamodt e Plaza [AAM 94] e Watson e Mahir [WAT 94], os mecanismos envolvidos
no raciocnio baseado em casos podem ser representados de modo geral por um ciclo
formado por quatro processos:
1. Recuperao do caso ou casos mais similares;
2. Reutilizao da informao e conhecimento presente no caso para solucionar
o problema corrente;
3. Reviso da soluo proposta se necessrio;
4. Armazenamento de parte da experincia obtida nos processos de modo a ser
til na soluo de problemas futuros.
Problema Corrente
Novo Caso

Caso Aprendido
RECUPERAO

ARMAZENAMENTO
Novo Caso
Casos
Recuperados

Base de
Conhecimento
Caso Avaliado

REUTILIZAO

REVISO
Caso Proposto

Soluo Proposta

FIGURA 2.1 - Ciclo CBR

A figura 2.1, adaptada de [AAM 94] e [WAT 94], representa o ciclo de
processos CBR. A descrio de um problema corrente gera um novo caso, que usado
para recuperar da base de casos um ou mais casos similares ao problema corrente. A
soluo apresentada pelos casos recuperados ento combinada com o novo caso
atravs da reutilizao, gerando uma soluo proposta para o problema inicial. Com o

18

processo de reviso, esta soluo testada (sendo aplicada ao ambiente no mundo real
ou avaliada por um especialista) e revisada se necessrio, produzindo um novo caso, que
ser armazenado como um novo caso aprendido ou como uma modificao de alguns
casos existentes. O uso de conhecimento geral do domnio geralmente faz parte do ciclo
sendo suportado pelos processos CBR [AAM 94]. Este suporte varia nos diversos
mtodos utilizados pelos sistemas CBR existentes, sendo algumas vezes muito fraco ou
mesmo nulo e em outras fornecendo um suporte muito forte.
O ciclo apresentado raramente ocorre sem interveno humana [WAT 94].
Muitas aplicaes CBR agem primordialmente como sistemas recuperadores de casos,
sendo a adaptao freqentemente realizada por gerentes da base de casos.
Alm dos processos do ciclo apresentado, faz parte das pesquisas em raciocnio
baseado em casos o estudo da representao do conhecimento na base de casos,
envolvendo a representao dos casos e a escolha dos ndices para a base [KOL 93]. Nas
sees a seguir, enfocaremos a base de casos e cada um dos processos envolvidos no
ciclo CBR.

2.3 A Memria de Casos

Um sistema de raciocnio baseado em casos altamente dependente da estrutura
de sua coleo de casos. Como a resoluo de problemas efetuada pela recuperao de
uma experincia anterior aplicvel para a soluo do novo problema, os processos de
busca e casamento precisam ser eficientes e ter um tempo de execuo razovel. Alm
disso, como a experincia obtida durante a resoluo de um problema armazenada para
uso futuro, so necessrios mecanismos para integrar o novo conhecimento na base de
casos. Assim, necessrio obter um balano entre os mtodos de armazenamento que
preservem a riqueza semntica dos casos e ndices e os mtodos que efetuem e
simplifiquem o acesso e recuperao de casos relevantes. Estes mtodos so usualmente
referenciados como modelos de memria de casos [WAT 94].
A memria de casos formada pela base de casos, que serve como repositrio
dos casos, e pelos procedimentos de acesso base [KOL 93]. Juntos, a base de casos e
os procedimentos disponibilizam os casos para a consulta e incorporam novos casos,
mantendo a acessibilidade dos itens j presentes na base de casos.
Os dois modelos de memria de casos considerados mais influentes nos estudos
de CBR so [AAM 94][WAT 94][ABE 96] o modelo de memria dinmica, proposto
por Roger Schank e o modelo de categoria e exemplar, proposto por Ray Barreis e
Bruce Porter. Informaes sobre estes modelos podem ser obtidas em
[AAM 94][KOL 93][ABE 96][MEL 99].

2.4 Base de Casos

O desenvolvimento de uma base de casos envolve o estudo sobre como os casos
sero representados abrangendo questes como o que armazenar em um caso e qual
estrutura utilizar para descrever os seus contedos e como sero indexados de
modo a serem recuperados no momento apropriado [AAM 94].

19

Na seo seguinte, abordaremos a representao e indexao de casos. Nas

sees subseqentes, apresentaremos os procedimentos de acesso a base de casos,
anteriormente identificados no ciclo CBR.

2.4.1 Representao dos Casos

Conforme descrevemos no incio deste captulo, os casos representam um
conhecimento especfico relacionado a um contexto, armazenando conhecimento em
nvel operacional. Devem ser armazenados, entretanto, apenas os casos que possuem
diferenas dos demais, de modo que possam acrescentar algum conhecimento til para o
sistema. Os casos podem apresentar diferentes tamanhos e modelos, assim como podem
representar um pequeno ou grande intervalo de tempo. Janet Kolodner define a partir
dessas observaes que um caso um pedao de conhecimento contextualizado
representando uma experincia que ensina uma lio fundamental para atingir os
objetivos do raciocinador [KOL 93],p.13.
Os casos so formados por duas partes maiores: as lies que ele ensina
contidas no contedo dos casos e o contexto em que pode ensinar tais lies
representado pelos ndices. Tipicamente, o contedo de um caso formado por trs
partes principais [WAT 94][KOL 93][ABE 96]:

descrio do problema ou situao, apresentando as condies do ambiente

no momento que o caso ocorreu e as restries associadas;

soluo, que expressa a soluo derivada para o problema, podendo ser

formada por uma ao, um conjunto de procedimentos, um diagnstico, uma
classificao, um projeto, etc., variando conforme o tipo de problema que o
sistema se prope a resolver;

resultado, que descreve o estado no ambiente real aps o caso ter ocorrido e
a soluo ter sido, assim, aplicada.
A descrio do problema ou situao representa o problema que precisa ser
solucionado ou a situao que precisar ser interpretada, classificada ou entendida. Como,
de modo geral, um sistema CBR utiliza as similaridades entre a descrio do caso
corrente e do caso armazenado para decidir se um caso armazenado deve ser
recuperado, a descrio deve ser suficientemente detalhada para que o sistema seja
capaz de julgar a aplicabilidade do caso na nova situao.
A descrio do problema formada por trs componentes maiores [KOL 93]:
pelos objetivos a serem atingidos na resoluo de um problema, pelas restries
relacionadas a estes objetivos e pelas caractersticas do problema e relaes entre as
partes.
Os objetivos na descrio do problema se referem as intenes ou propsitos a
serem atingidos na situao. Estas intenes podem ser concretas ou abstratas,
dependendo de que lies o caso almeja fornecer. Se o caso deseja diagnosticar um
conjunto de sintomas, ento o objetivo ser diagnstico. J se o caso pretende criar
uma soluo para uma questo, seu objetivo ser criao. As restries, por sua vez,
envolvem as condies relacionadas aos objetivos almejados que precisam ser
consideradas no processo, como, por exemplo, no incluir um certo ingrediente na
criao de uma receita culinria ou no causar determinada reao em um paciente que
possui alergia a um medicamento.

20

Por fim, as caractersticas da situao envolvem todas as outras informaes

descritivas sobre a situao que so relevantes para a obteno dos seus objetivos. Em
uma aplicao de diagnstico mdico, por exemplo, sintomas e resultados de exames do
paciente so descritores necessrios para construir a soluo, enquanto outras
caractersticas podem tambm ser consideradas para a busca do objetivo. Do mesmo
modo, alguns sintomas ou particularidades observados em uma rede de computadores
devem necessariamente ser usados para solucionar um problema, enquanto outros
podem ser usados para a soluo desejada.
Dependendo da aplicao sendo desenvolvida, diferente ateno exigida para
cada um dos componentes da descrio do problema algumas enfatizam os trs
componentes da descrio, outras enfatizam somente um ou dois. As situaes que
exigem uma soluo explcita, como um projeto ou planejamento de tarefas, enfatizam,
de modo geral, os objetivos e as restries em suas representaes do problema. Aquelas
que requerem entendimento ou interpretao, por sua vez, tendem a ter um nico
objetivo simples, como diagnstico ou entendimento, e enfatizam os descritores da
situao problema. Assim, conforme sugere Janet Kolodner, h dois princpios gerais que
devem ser seguidos na deciso de que informaes devem pertencer descrio do
problema:

incluir toda a informao descritiva que deve ser explicitamente levada em

conta na busca do objetivo do caso;

incluir todos os tipos de informao descritiva que so normalmente usados

para descrever os casos desta espcie.
O primeiro princpio permite que o sistema ignore caractersticas que so
relevantes, mas implcitas, por nunca variarem. O segundo, necessrio para a
acessibilidade do caso. Ao menos algumas pores da descrio do caso so usadas em
um sistema para a indexao e julgamento da similaridade, sendo melhores para a
recuperao aqueles que so semelhantes nas dimenses que se sabe serem relevantes
para a soluo do problema. Porm, como existe muita informao que no conhecida
quando um novo caso descrito, necessrio alternar o modo de determinar os
melhores casamentos [KOL 93].
A parte componente soluo de um caso representa os conceitos ou objetos que
atingiram os objetivos descritos na descrio do problema, levando em considerao as
restries e as caractersticas especificadas. Existem diferentes tipos de solues em
um problema de projeto a soluo o artefato elaborado, enquanto que em um problema
de interpretao de uma situao ela a interpretao apresentada para o caso. Alm da
soluo de um caso recuperado ser usada para derivar uma soluo para o caso corrente,
ela pode tambm possuir componentes que acrescentem adaptao e reviso da soluo
proposta. Entre as partes componentes da soluo que podem ser teis para essas
funes esto, alm da soluo propriamente dita, o conjunto de passos usados no
raciocnio para resolver o problema, o conjunto de justificativas para as decises que
foram tomadas, as solues aceitveis que no foram escolhidas e suas as justificativas,
as solues inaceitveis que foram eliminadas e suas justificativas e as expectativas frente
aos resultados aps a soluo ser efetuada.
Por fim, a parte componente resultado de um caso identifica o que ocorreu
como conseqncia da soluo efetuada e como ela foi realizada. Este componente inclui
tanto o feedback do ambiente real como as interpretaes para este feedback, de modo

21

que o sistema possa antecipar problemas em potencial e predizer resultados de uma

soluo proposta. Alm disso, o resultado pode tambm incluir a explicao do porqu
uma soluo ou expectativas frente a uma soluo falharam e o que foi feito para reparar
estas falhas.
Os casos podem ser representados em uma grande variedade de formas usando
praticamente que todos os formalismos de representao da Inteligncia Artificial
[WAT 94], incluindo frames, objetos, predicados, redes semnticas e regras, alm de
estruturas menos ricas semanticamente, como os modelos de banco de dados comerciais.
Muitos sistemas usam mais de um dos formalismos acima combinados [ABE 96].

2.4.2 Indexao
Os ndices so utilizados para facilitar a recuperao dos casos armazenados na
base, sendo os responsveis por tornar um caso acessvel no momento e condio
apropriado isto , quando ele possuir um potencial para contribuir para a soluo do
problema corrente. So combinaes dos descritores importantes de um caso, isto ,
daqueles descritores que distinguem um caso dos outros.
O esquema de indexao envolve vrias partes. Primeiramente, devem ser
designados rtulos para os casos no momento em que estes so armazenados na base, de
modo a garantir que eles possam ser recuperados no momento apropriado. Tais rtulos
so usados no momento de recuperao para julgar se o caso armazenado deve ser
selecionado. Uma segunda questo envolvendo a indexao a definio da
organizao dos casos, de modo que a busca atravs da base de casos seja eficiente e
precisa. Relacionada a estas questes est a definio dos algoritmos de recuperao a
serem utilizados.
A atribuio de ndices aos casos depende da compreenso do contedo e das
informaes que um caso pode fornecer. Ela deve permitir que sejam reconhecidas as
similaridades entre a situao corrente e os casos armazenados que podem contribuir
para atingir os objetivos do caso corrente. Assim, para a escolha de um bom ndice,
necessrio uma grande compreenso da situao problema, de forma que essas
similaridades possam ser corretamente identificadas. Considere-se, por exemplo, a
resoluo de um problema ocorrido em uma rede de computadores. Informaes como a
aplicao utilizada e o usurio que identificou o problema no so importantes quando o
problema envolve o acesso fsico de um equipamento por problemas em sua placa de
rede ou no cabeamento. Por outro lado, se o problema envolver a no autenticao do
usurio por uma aplicao, a aplicao utilizada e o usurio so dados importantes.
Como apontado em [ABE 96], a similaridade que se busca em sistemas de raciocnio
baseado em casos muitas vezes diferente daquelas semelhanas superficiais, obtidas
pela comparao de dados descritivos. um estilo de similaridade mais abstrata, que
permite reconhecer em diferentes contextos solues que possam ser aplicadas a novos
casos.
Atravs da experincia com a construo de sistemas CBR, a comunidade CBR
prope alguns princpios que devem ser seguidos para a escolha de ndices apropriados
[KOL 93][ABE 96][WAT 94]:

eles devem ser preditivos, isto , devem prever a utilizao da informao

presente nos casos para diferentes situaes problema;

22

devem enderear os propsitos em que o caso pode ser usado;

devem ser abstratos o suficiente para permitir que um caso seja til em uma
variedade de diferentes situaes;

devem ser concretos o suficiente para que possam ser facilmente reconhecidos
em situaes futuras.
Os ndices podem ser escolhidos atravs de mtodos manuais, onde a escolha
comea com a anlise dos casos para a identificao da utilidade que poderia ter o caso,
e sob que circunstncias. Essas informaes devem ser ento traduzidas para
representaes que o sistema pode usar, definindo um conjunto de descritores, que so
ento trabalhados de modo a garantir que os ndices sejam aplicveis em mbito geral e
que possam ser reconhecidos no mximo de situaes possveis [KOL 93].
Alm dos mtodos manuais, existem, tambm, mtodos de indexao
automticos, que so disponibilizados por muitas das ferramentas de CBR disponveis no
mercado. Entre os mtodos automticos referenciados na bibliografia, podemos citar o
mtodo baseado em uma checklist, o mtodo baseado em diferenas e o mtodo baseado
em explicao [WAT 94][ABE 96] [KOL 93]. Entretanto, apesar do sucesso de muitos
mtodos automticos [WAT 94], Janet Kolodner alerta que os ndices tendem a ser
melhor escolhidos pelo modo manual, e em aplicaes prticas devem ser escolhidos
desta forma.

2.5 Recuperao
Um algoritmo de recuperao de casos o responsvel por encontrar, a partir da
descrio de um problema ou situao, um pequeno conjunto de casos similares ao
problema corrente que seja til para a identificao da sua soluo. A busca pelos casos
similares no deve considerar, porm, apenas a descoberta de algumas dimenses da
descrio do problema similares situao. Na identificao da similaridade entre os
casos, alguns atributos so mais importantes que outros no julgamento da mesma e esta
valorao pode variar de acordo com os objetivos almejados pelo sistema. Assim, a
recuperao de casos similares envolve considerar que os casos similares ao problema
corrente so aqueles que so similares nas dimenses que auxiliam o sistema a realizar
suas tarefas ou atingir os objetivos desejados [KOL 93].
A recuperao dos casos teis situao corrente envolve vrias etapas, cada
uma possuindo diferentes pontos que devem ser analisados. Inicialmente, precisam ser
identificadas quais as caractersticas ou dimenses do caso corrente que devem ser
utilizadas para julgar a similaridade dos casos armazenados. Isso determinado levandose em conta os propsitos para os quais os casos esto sendo recuperados e as
dimenses que foram relevantes no passado para determinar o resultado do ambiente
para as solues aplicadas. Essas caractersticas sero ento utilizadas pelos
procedimentos de casamento e classificao para identificar quais dos casos armazenados
tm o potencial de serem mais teis.
Como os ndices de um caso indicam quais das suas dimenses so mais
importantes para julgar a similaridade, os algoritmos de casamento utilizam os ndices
para auxiliar no processo de identificao de que caractersticas devem ser consideradas
para a similaridade entre os casos. Esses algoritmos devem, contudo, estar habilitados

23

para distinguir, dentre os vrios ndices existentes, quais focalizar para um dado
momento quando os casos estiverem indexados em muitas formas [KOL 93].
Uma outra questo relevante no processo de recuperao so os algoritmos de
busca propriamente ditos. Estes algoritmos so os processos que viabilizam encontrar na
base aqueles casos que potencialmente podem ter um bom casamento com a situao
corrente. A partir dos casos identificados pelos algoritmos de busca empregados, os
procedimentos de casamento so aplicados.
Os algoritmos de busca so relacionados diretamente s estruturas utilizadas nas
bases de casos para organiz-las. Uma estrutura em lista , por exemplo, consultada pelo
algoritmo de modo diferente de uma estrutura em rvore complexa. Assim, diferentes
organizaes dos casos na base ocasionam diferentes algoritmos para recuperar seus
casos.
Um esquema dos processos envolvidos na recuperao de um caso pode ser visto
na figura abaixo, adaptada de [KOL 93]. Conforme mostra o nvel superior da figura,
inicialmente feita uma avaliao da situao e so identificadas as caractersticas que
sero usadas para a busca na base de casos, sendo freqentemente necessrio que
algumas dessas caractersticas sejam elaboradas pelo sistema. Os algoritmos de
recuperao, atravs da descrio do problema e dos ndices selecionados para a
consulta na base, buscam os casos com potencial de serem similares e utilizam os
mecanismos de casamento, seja para calcular o grau de casamento entre a situao
corrente e os casos encontrados, seja para calcular o casamento de uma dimenso
individual. Os algoritmos de recuperao retornam, ento, uma lista dos casos
parcialmente casados, cada qual com no mnimo algum potencial de ser til para o
sistema. Os casos so, por fim, analisados pelos procedimentos de classificao e aqueles
que possuem mais potencial de serem teis so retornados.
Recuperao
Avaliao da situao
Elaborao da descrio do caso
Calculo dos ndices hipotticos para a
nova situao (caso corrente)

Busca na estrutura organizacional da

memria para identificar casos
parcialmente casados

Seleo do(s)
melhor(es) caso(s)

FIGURA 2.2 - Esquema do processo de recuperao na base de casos

Na seo a seguir, apresentaremos algumas possveis estruturas de organizao
da base de casos e discutiremos os algoritmos de recuperao utilizados para a busca
nessas organizaes. Na seo subseqente, discutiremos alguns procedimentos para
casamento e classificao e, por fim, apresentaremos, na seo 2.5.3, consideraes

24

sobre o processo de avaliao da situao e sobre algumas relaes entre os processos

de indexao e recuperao.

2.5.1 Estruturas de organizaes da base de casos e algoritmos de

recuperao
Uma base de casos pode ser vista como um tipo especial de banco de dados. Ela
deve ser, assim como os sistemas de banco de dados, percorrida em uma quantidade de
tempo razovel pelos seus algoritmos de recuperao, mesmo quando manusear centenas
ou milhares de casos.
Um dos grandes focos dos estudos em CBR tem sido a busca para tornar a
recuperao eficiente, pois s sero possveis abordar problemas em larga escala quando
os algoritmos de recuperao forem suficientemente robustos e eficazes para manusear
milhares de casos. Diferentes dos bancos de dados que recuperam registros a partir de
campos idnticos, as bases de casos exigem a recuperao a partir de um casamento
parcial, porm os algoritmos de recuperao parcial so dispendiosos. Assim, a
recuperao de casos deve ser efetuada de modo que o casamento seja feito apenas nos
casos com algum potencial de relevncia para a nova situao.
Como o casamento parcial importante para a recuperao dos casos, mas
dispendioso, devem ser encontrados meios de particionar o espao de busca, de modo
que o casamento parcial total seja realizado apenas em um pequeno nmero de casos.
Assim, os algoritmos de recuperao devem fazer uma primeira seleo para distinguir
quais os casos tm relevncia para o caso corrente.
Os ndices tm um importante papel nos algoritmos de busca e nas estruturas de
organizaes utilizadas nas bases de casos, sendo usados em muitos algoritmos para
organizar os casos e direcionar a busca ao longo das estruturas organizacionais. Se, por
exemplo, o casamento de uma caracterstica importante, os casos so indexados por
essa caracterstica em alguma estrutura organizacional e, no processo de busca, ela ser
considerada. J se o casamento parcial da caracterstica importante, ento o ndice deve
ser familiar com os valores que indicam similaridade para a caracterstica, permitindo aos
algoritmos de recuperao reconhecer dois itens como potenciais para casamento,
mesmo que os valores de suas caractersticas no sejam exatamente os mesmos. De
modo alternativo, os algoritmos de busca podem utilizar os procedimentos de casamento
para determinar quo similares so dois valores diferentes em casos sendo comparados.
A seguir, apresentamos algumas diferentes organizaes de casos e os algoritmos
utilizados para recuperao e insero de casos nestes estruturas. Informaes adicionais
sobre estas organizaes, assim como sobre outras organizaes aqui no comentadas,
tais como o uso de memria linear com busca paralela e memria hierrquica com busca
paralela, podem ser obtidos em [KOL 93][MEL 99].
2.5.1.1 Memria linear com busca serial
Numa memria horizontal, os casos so armazenados seqencialmente em uma
lista simples, um vetor ou um arquivo, e so recuperados pela aplicao de funes de
casamento, em seqncia, para cada caso, calculando o grau de casamento de cada um e
retornando os casos que melhor casaram. No h organizao no topo desses casos e o
algoritmo de recuperao que utilizado bastante simples. So na verdade as
heursticas do procedimento de casamento as responsveis pela recuperao.

25

O algoritmo de busca serial nesta estrutura de fcil implementao e efetua uma

busca completa na base de casos. Ele tem, porm, a desvantagem de se tornar muito
lento quando o nmero de casos na base cresce.
2.5.1.2 Rede de caractersticas compartilhadas
Quando a base de casos trabalhada grande, devem ser utilizados meios para
particionar a base de casos, de modo que apenas um subconjunto de casos seja avaliado
durante a recuperao, subconjunto este que deve conter os casos mais teis para a
situao corrente. Existem vrios mtodos de agrupamento indutivo que podem ser
usados para a identificao desses subconjuntos, que procuram geralmente por
similaridades sobre um grupo de instncias e formam categorias baseadas nessas
similaridades. Um modo de determinar os subconjuntos corretos , por exemplo,
agrupar os conjuntos de caractersticas que so compartilhadas em um grande nmero de
itens. Outra forma agrupar as caractersticas individuais que dividem o conjunto em
agrupamentos de mesmo tamanho. Um terceiro modo seria ainda agrupar as
caractersticas individuais que diferenciam um pequeno grupo de itens dos outros. Cada
um destes mtodos resulta em diferentes agrupamentos.
Nas redes de caractersticas compartilhadas, os casos que compartem muitas
caractersticas so agrupados juntos. Cada nodo interno de uma estrutura deste tipo
mantm as caractersticas partilhadas com casos abaixo dele, sendo os casos mantidos
pelos nodos folha. Na recuperao de um caso, a situao corrente relacionada e
casada para cada um dos contedos dos nodos no mais alto nvel da rede de modo a ser
escolhido o nodo com melhor casamento. Se este nodo for um caso, ele retornado. Do
contrrio, o processo repetido para o prprio nodo interno retornado, at que seja
retornado no um nodo interno, mas um caso.
A recuperao numa estrutura em rede de caractersticas compartilhadas mais
eficiente que em uma busca serial. Ela permite, entretanto, que casos com bom
casamento sejam perdidos se a hierarquia dos nodos da rede no corresponder
importncia das caractersticas do caso corrente. Alm disso, a insero de casos uma
operao complexa e, com o crescimento da base, difcil manter a rede numa estrutura
tima, o que pode tornar a busca ineficiente.
2.5.1.3 Redes de discriminao
A estrutura organizacional rede de discriminao similar s redes de
caractersticas compartilhadas. Nessa estrutura, cada nodo interno representado por
uma questo ou pergunta que subdivide o conjunto de casos armazenados em hierarquia
inferior a dele. Os nodos filhos representam as diferentes respostas para a questo
formulada pelo nodo pai, e agrupam os casos que possuem a sua resposta. Assim como
nas redes de caractersticas compartilhadas, as questes mais importantes devem ser
colocadas numa hierarquia superior para evitar que casos com importantes caractersticas
similares no sejam consultados.
As redes de discriminao so, assim como as redes de caractersticas
compartilhadas, mais eficientes que organizaes em lista para a busca dos casos, mas
tm a desvantagem de requererem tambm um espao adicional para representar a
prpria rede. Em ambos os esquemas, porm, a estrutura no fornece nenhum
mecanismo para continuar a busca quando uma questo sendo solicitada no pode ser
respondida. Opes para resolver o problema incluem finalizar a busca, continuar a busca

26

procurando em todos os nodos filhos e escolher o caminho mais provvel, porm

nenhuma das opes amplamente satisfatria. Em relao s redes de caractersticas
compartilhadas, elas so mais eficientes, pois a busca seguindo apenas a resposta
questo mais eficiente que a comparao do conjunto das caractersticas do nodo.
2.5.1.4 Redes de discriminao redundante
Esta forma de organizao dispe os casos em vrias redes de discriminao
redundante, resolvendo o problema de como continuar uma busca quando uma questo
que no pode ser respondida encontrada. A busca realizada em paralelo, seguindo as
diversas redes existentes, e quando uma questo nessas condies encontrada, a busca
suspensa naquela rede de discriminao, mas continua nas outras redes. Com a
redundncia existente, geralmente ao menos uma das redes ir encontrar um caso similar.

2.5.2 Casamento e Classificao

Conforme j foi visto, o processo de recuperao dos casos similares da base
envolve a definio dos ndices a serem utilizados, a busca dos casos com potencial de
serem teis para a situao corrente, o casamento desses casos com o caso corrente e a
classificao dos casos recuperados, de modo a selecionar o melhor ou os melhores
casos. Esses processos no so, porm, isolados uns dos outros: eles dependem e so
algumas vezes altamente integrados entre si.
Muitos dos procedimentos de recuperao para as estruturas discutidas acima
so exemplos disso, agregando funes de casamento na prpria busca. Algoritmos para
busca em memria linear, por exemplo, fazem o casamento de cada caso com o caso
corrente, computam o valor de casamento e escolhem o caso de maior valor. J os
algoritmos de busca em redes de caractersticas compartilhadas agregam funes de
casamento no momento de busca, utilizando relaes que fazem o casamento parcial das
caractersticas do nodo. Os procedimentos de casamento de casos, assim, podem ocorrer
no apenas aps a busca na base de casos, mas tambm serem utilizados para esta busca.
Para a definio dos procedimentos de casamento necessrio que algumas
questes sejam consideradas. Uma dessas questes envolve a identificao da
correspondncia entre os campos do caso corrente e os casos armazenados. Isso pode
ser feito por meio da associao de campos com nomes iguais, contudo nem sempre esta
associao to simples: os casos podem possuir nmero de caractersticas diferentes,
estar representados em diferentes pontos de vista, variando com os objetivos almejados
pela situao descrita, etc. Nessas situaes, o uso de heursticas de senso comum pode
contribuir para a identificao da correspondncia. Em [KOL 93], cinco heursticas que
podem ser utilizadas nesse processo so apresentadas:
1. campos com mesmo nome devem ser mapeados diretamente, mesmo
considerando que uma estrutura possua subdivises e outra no;
2. preferir o mapeamento entre as caractersticas que possuem o mesmo papel
funcional;
3. preferir o mapeamento das caractersticas que satisfazem as mesmas
restries;
4. preferir o mapeamento das caractersticas que possuem os mesmos valores ou
valores similares;

27

5. mltiplas caractersticas do problema podem ser mapeadas para uma

caracterstica simples mais geral ou vice versa.
Quando um modelo causal para o domnio est disponvel, isso pode tambm ser
utilizado para a definio dessa correspondncia. O sistema CASEY, desenvolvido por
Koton Apud [KOL 93], aplicado ao domnio da medicina, um exemplo de como um
modelo causal pode ser usado para determinar a correspondncia entre caractersticas.
Neste modelo, so utilizadas regras de evidncia para determinar como dois campos
podem ou no serem considerados iguais. utilizado um modelo que define que
caractersticas e resultados correspondentes a outras caractersticas e outros resultados,
que caractersticas levam a outras, que valores entre os possveis para uma dimenso
pertencem ao mesmo intervalo e so assim considerados similares.
Outra questo necessria para os procedimentos de casamento a definio de
como ser calculado o grau de similaridade entre as caractersticas correspondentes.
Entre os mtodos disponveis [KOL 93] esto:

distncia qualitativa e quantitativa. Este mtodo utiliza vrias formas,

dependendo do tipo de valor da dimenso: (i) dividir em regies, atribuindo
casamento exato para aqueles valores que esto na mesma e os valores uma
regio, duas regies, etc. para aqueles que no se encontrarem na mesma. Para
resolver problemas gerados por valores muito prximos dos limites dos
intervalos, podem ser criadas regies que se sobrepem, (ii) medir a diferena
numrica e atribuir classificao qualitativa, (iii) fazer a enumerao de
valores qualitativos quando no h nmeros e medir como casamento exato,
casamento com uma regio distante, duas regies distantes, etc. Pode tambm
ser atribudo um valor numrico para cada valor qualitativo e compar-los,
(iv) comparar os atributos de cada valor utilizando uma estrutura de
comparao que aponta as similaridades e diferenas ou tambm utilizando
representaes com frames, (v) comparar numericamente os valores
numricos, atribuindo um casamento pior para valores mais distantes.

julgar o grau de similaridade baseado na eficincia da funo. Para isso pode

ser utilizado um modelo causal. Se dois valores diferentes qualitativamente
(como, por exemplo, uma cadeira e uma pedra utilizada para uma pessoa
sentar-se) so mostrados correspondentes por um modelo causal, ento elas
casam. Neste mtodo no comparado o grau de casamento, apenas se eles
casam ou no.

hierarquia de abstrao. Neste mtodo, a similaridade entre dois valores

medida pela utilizao da abstrao com valor comum a estes valores mais
especfica, sendo que quanto mais especfica a abstrao comum, maior a
similaridade.
Por fim, necessrio atribuir valores de importncia para as dimenses da
representao, de modo a apontar as informaes mais relevantes para a similaridade
dos casos sendo comparados. Para isso, devem ser atribudos pesos para cada campo, o
que pode ser feito de forma global, para um grande nmero de casos, ou atribudo de
modo mais local, apenas para um pequeno conjunto. Esta importncia entre as
dimenses pode ser identificada com a ajuda de um especialista ou atravs de uma
avaliao estatstica para determinar quais campos resultam em diferentes resultados ou

28

solues. Pode tambm ser interessante atribuir diferentes valores de importncia para
cada objetivo da situao, o que pode ser feito de forma dinmica [KOL 93].
Uma vez que alguns casos tenham sido recuperados e os procedimentos de
casamento tenham sido efetuados sobre eles, estes devem passar por mtodos de
classificao a fim de sejam escolhidos os casos mais similares a situao corrente. Como
j foi dito, muitas vezes esses procedimentos so feitos de modo integrado, em uma
nica etapa.
Existem vrios mtodos envolvendo os procedimentos de casamento e
classificao que so utilizados no processo de recuperao dos casos. Entre estes
apresentamos:
1. algoritmo de vizinhana (nearest-neighbor matching). Este algoritmo um
procedimento numrico em que utilizada uma funo de avaliao numrica
para cada caracterstica. Para cada caracterstica do caso corrente
encontrada a caracterstica correspondente no caso recuperado, os valores so
comparados, o grau de casamento calculado e multiplicado pelo grau de
importncia da caracterstica;
2. excluso dos casos que no possuem caractersticas ou relaes que os
tornam diferentes ou no teis em relao ao caso atual, como no caso de
objetivos diferentes, por exemplo. Aps este processo, realizada uma
avaliao numrica.
Existem tambm mtodos que levam em conta o contexto da situao, que esto
presentes em sistemas que tratam diferentes propsitos ou contextos e, assim, precisam
utilizar meios de avaliar seus graus de casamentos parciais tambm diferentes. Isso pode
ser feito:
1. utilizando-se mltiplas associaes de importncia, em uma classificao
dinmica. Neste mtodo so utilizados vrios conjuntos de critrios de
importncia, cada um associado com as condies relacionadas s
circunstncias sobre as quais eles deveriam ser usados. Isso pode ser feito
atravs (i) do fracionamento da base de casos sendo relacionado um diferente
conjunto de critrios de importncia para cada partio, (ii) da associao de
diferentes critrios de importncia para cada diferente objetivo de raciocnio
ou (iii) da associao de um ou mais conjuntos de critrios de importncia
para cada caso, cada um associado com uma diferente tarefa para qual o caso
pode ser usado. Quando somente um objetivo de raciocnio ser usado na base
de casos, mas o que importante varia com o tipo da nova situao, a
biblioteca de casos pode ser seccionada de acordo com o tipo e para cada
partio indicado um conjunto de valores de importncia para as dimenses
dos casos (caso i). Quando mltiplos objetivos so suportados pela base de
casos, entretanto, o particionamento por tipo no suficiente e os casos em
cada partio devem ser avaliados diferentemente dependendo do objetivo do
raciocnio para o qual ele deve servir (caso ii). Para acomodar diferentes
objetivos de raciocnio, diferentes funes de avaliao podem ser associadas
para cada diferente objetivo de raciocnio. Por fim, quando critrios para
julgar a similaridade variam tanto em relao ao objetivo sendo buscado como
em relao ao tipo de caso, valores de importncia devem ser assinalados,
levando ambos em conta (caso iii). Podem ainda existir, porm, casos

29

altamente particulares. Nessa situao, devem ser associados um ou mais

conjuntos de critrios de importncia para cada caso. Cada conjunto de
valores designado para um objetivo e enfatiza as dimenses do caso que, se
casarem bem, indicam que ele pode servir para o objetivo.
2. usando preferncias para implementar um esquema de classificao
relativa. utilizado para fazer um corte aps os casos terem sido
selecionados, passando-os por filtros se existem muitos casos aps o
casamento. Esses filtros podem ser relacionados ao objetivo de raciocnio, ao
grau de especificidade e facilidade de adaptao, e freqncia e ocorrncia
recente.

2.5.3 Consideraes sobre a indexao e a recuperao

Para fazer a indexao de um caso, deve ser estabelecido um equilbrio entre os
parmetros profticos e os parmetros observveis. Existem alguns sistemas, como o
modelo causal do CASEY, que derivam parmetros profticos a partir de outros
observveis. Mas esse processo, conhecido como elaborao, pode ter dois pesos: (i)
alguns parmetros so difceis de serem elaborados, exigindo tempo e fora
computacional, e (ii) podem haver muitas possveis elaboraes a serem feitas, cada uma
consumindo alguma fora e tempo. Assim, quando a elaborao cara, ou
potencialmente cara, ela deve ser controlada de modo inteligente.
A deciso de quais elaboraes devem ser realizadas conhecida como o
problema de controle da avaliao da situao [KOL 93]. Quando poucas elaboraes
so necessrias e estas so de baixo custo, todas podem ser efetuadas. Nos demais
sistemas, porm, necessrio um controle sobre esse processo, que pode ocorrer em
uma ou vrias das trs fases abaixo:

estabelecimento do contexto: processo ocorrido antes de efetuar a busca,

quando elaborado o conjunto de dimenses que se sabe ser necessrio para
uma boa recuperao. As dimenses a serem elaboradas so geralmente
definidas por uma catalogao;

refinamento do contexto: processo ocorrido durante a busca, em que a

elaborao feita quando necessria, usando a base de casos para definir as
dimenses que so indispensveis elaborar para que o sistema possa
discriminar entre vrios itens na memria. O sistema CASCADE [SIM 92] e
vrios programas que usam rede de discriminao apresentam esse processo;

redefinio do contexto: processo ocorrido aps a busca, em que o conjunto

de itens recuperados examinado para verificar se eles so realmente to
teis como deveriam ser.

2.6 Reutilizao (adaptao)

Aps os casos similares terem sido recuperados da base e o melhor caso ter sido
selecionado, a soluo deste caso deve ser reutilizada, podendo ser adaptada para as
necessidades do problema corrente. Este processo envolve a identificao das diferenas
entre o caso recuperado e o caso corrente e a anlise das partes do caso recuperado que
podem ser transferidas para o caso corrente, aplicando frmulas e regras que consideram
estas diferenas e sugerem uma soluo [WAT 94].

30

Uma soluo pode ser reutilizada de modo direto, sendo aplicada a soluo
recuperada sem ser adaptada. Essa tcnica, denominada por alguns de adaptao
nula [WAT 94] ou identificada simplesmente como cpia [AAM 94], til em
problemas que envolvem um complexo raciocnio, mas uma soluo simples, e utilizada
nos sistemas em que as diferenas no so consideradas relevantes, ao passo que as
similaridades entre os casos o so. Entretanto, em sistemas que levam essas diferenas
em conta, um processo de adaptao necessrio, podendo ser feito atravs da simples
substituio de componentes da situao recuperada por componentes da situao
corrente, por meio da transformao da antiga soluo para uma soluo que seja
aplicada ao novo problema e por meio da derivao de uma nova soluo, utilizando
mtodos para derivar a soluo ou pedaos da soluo do caso armazenado. Entre os
mtodos ou tcnicas que tm sido usados para adaptao podem ser citados:

reinstanciao: usada para instanciar caractersticas da antiga soluo com

caractersticas da nova. utilizada, por exemplo, pelo sistema CHEF para
propor a substituio de um prato por outro na elaborao de um cardpio de
uma refeio [WAT 94][KOL 93].

adaptao parametrizada: usada para o ajuste de parmetros da antiga

soluo atravs do uso de heursticas especializadas que identificam as
relaes entre as especificaes de entrada e as diferentes solues. Esta
tcnica freqentemente usada quando as variveis relevantes do caso so
numricas, sendo um exemplo de sua aplicao o clculo da quantidade de
ingredientes pela relao do nmero de pessoas. Uma das dificuldades em
aplicar esta tcnica o conhecimento da funo que relaciona as variveis
descritivas do problema e a soluo [LEW 95].

busca local: fornece um meio de buscar em uma estrutura de conhecimento

auxiliar um substituto para um valor ou estrutura do caso recuperado que no
apropriado para a situao corrente. Um exemplo seria a busca em uma rede
semntica por frutas que pudessem substituir a fruta laranja em um prato de
sobremesa sendo elaborado [KOL 93].

consulta a memria: procura em estruturas de conhecimento auxiliares ou na

memria de casos por algo com uma dada descrio.

substituio baseada em casos: utiliza, para a substituio de um parmetro,

casos da base.

transformao de senso comum: utiliza heursticas de senso comum para

inserir, remover ou modificar componentes em uma soluo.

reparo guiado ao modelo: efetua transformaes na soluo do caso anterior

guiadas por um modelo causal. indicada especialmente em sistemas que
envolvem raciocnio sobre equipamentos, seja envolvendo diagnstico ou
projeto.

adaptao ou reparo de propsitos especiais: utiliza heursticas de

propsitos especiais para modificar estruturas ou adaptaes especficas ao
domnio no fornecidas pelos demais mtodos acima. Essas heursticas so
indexadas pelas situaes em que so aplicveis. Podem ser utilizadas para,
por exemplo, inserir um passo extra em um procedimento de soluo, se
determinado componente fizer parte do problema.

31

adaptao por derivao: utiliza o mtodo usado para encontrar a soluo

do caso recuperado para derivar a soluo da situao corrente. Usando este
raciocnio, um problema pode ser resolvido pela mesma seqncia de passos
que foi previamente utilizada para solucionar o caso recuperado. Em manuais
de resoluo de problemas de gerncia de redes, por exemplo, possvel
encontrar procedimentos ou fluxos de tarefas que apontam como localizar a
causa do problema e as possveis solues. Alm disso, gerentes
freqentemente planejam seus prprios procedimentos que iro divulgar para
os usurios de uma rede quando um problema ocorre. Estes procedimentos
podem ser considerados como rvores de deciso ou checklists que guiam a
investigao das causas e possveis solues para o problema, podendo ser
freqentemente implementados como scripts em Unix. Um exemplo de um
procedimento geral para uma estao com mal funcionamento : Checar todos
os cabos. Determinar se mudanas ocorreram no hardware. Determinar se
mudanas foram feitas na configurao da rede. Contatar e conversar com o
ltimo usurio da estao. [LEW 95] importante observar que
procedimentos no so solues do problema, mas instrues que devem guiar
para a causa do problema e solues potenciais. Com essa forma de
adaptao, o sistema oferece (ou mesmo executa) os procedimentos que
funcionaram em casos passados para chegar soluo do problema corrente.
Para utilizar este mtodo, necessrio haver um repositrio dos
procedimentos e um modo de mapear tipos de problemas para procedimentos
que mais regularmente levam a uma soluo. Essa adaptao tambm
denominada adaptao procedural. [LEW 95]

adaptao baseada em crtica: nesta tcnica, o usurio observa a soluo

proposta no caso recuperado e manualmente adapta a soluo para o caso
corrente. usada quando o sistema recupera solues que o usurio sabe que
no funcionar, sabendo porque no funcionar e como fazer funcionar.
Nessas situaes, o usurio deve adaptar o caso por si mesmo, j que o caso
sugerido como uma possvel soluo pode solucionar a situao com uma
pequena modificao. Deve ser, entretanto, documentado o modo que o caso
foi adaptado para que ele possa ser usado no futuro [LEW 95].
As tcnicas acima so alguns exemplos de mtodos usados para efetuar
adaptaes na soluo de um caso recuperado de modo que esta seja reutilizada para o
caso corrente. Elas podem ser utilizadas combinadas ou de modo isolado. Um resumo
das tcnicas usadas para adaptao pode ser visto na tabela abaixo.

32

TABELA 2.1 - Tcnicas de adaptao

Tcnica

Orientao

Tarefa

Opera com

Reinstanciao

estrutural

substituio

valores

Parametrizada

senso comum

substituio

valores

Busca local

especializada,
senso comum

substituio

valores,
estruturas

Consulta memria

especializada

substituio

valores,
estruturas

Substituio baseada
em casos

casos

substituio

valores

Transformao de
senso comum

senso comum

transformao

valores,
estruturas

Reparo guiado ao
modelo

modelo causal

transformao,
substituio

valores,
estruturas

Adaptao ou
reparo de propsitos
especiais

especializada,
senso comum,
modelo causal

transformao,
substituio

valores,
estruturas

Adaptao por
derivao

casos

transformao,
substituio

valores,
estruturas

Adaptao baseada
em crtica

senso comum

transformao,
substituio

valores,
estruturas

2.7 Reviso
Aps um caso ter sido recuperado da base e sua soluo ter sido adaptada para o
caso corrente, necessrio que (i) a soluo proposta seja avaliada. Se esta soluo
no produzir resultado satisfatrio, (ii) ela deve ser reparada, e uma nova soluo deve
ser gerada. Uma vez que a soluo encontrada for correta, a experincia obtida deve ser
aprendida, sendo armazenada para uso futuro. Esses processos (i, ii e armazenamento)
podem ser vistos como obteno de experincia, ao passo que o processo de
recuperao e de adaptao visto como uma aplicao da experincia armazenada.
A avaliao da soluo (i) resultado da aplicao da soluo proposta em um
ambiente e avaliao dos resultados ocorridos. O ambiente pode ser representado por um
ambiente de simulao apto a gerar os resultados corretos a uma soluo. Um exemplo
o sistema CHEF, em que a soluo proposta (um prato culinrio) aplicada a um
modelo interno, que considerado eficiente para fornecer a avaliao necessria
soluo fornecida [AAM 94]. De modo geral, porm, essa etapa avaliada no ambiente
real, para o problema real. Os resultados da execuo da soluo podem variar desde
alguns segundos, quando aplicada, por exemplo, para corrigir automaticamente uma
configurao em uma rede, at vrios meses, quando aplicada, por exemplo, a um
tratamento mdico. Durante o perodo de execuo, um caso pode ser aprendido, sendo

33

j mantido armazenado na base, porm a informao de que o caso no foi ainda

avaliado deve ser marcada a este [AAM 94].
caso corrente
soluo proposta
aplicao da soluo proposta
avaliao dos resultados

caso corrente com

soluo satisfatria

caso corrente com

soluo com falhas

deteco dos erros da

soluo corrente
modificao das falhas na
soluo proposta

armazenamento da experincia obtida

(processo de aprendizado)

FIGURA 2.3 - Esquema do processo de reviso

Conforme apresentado por Lundy Lewis em [LEW 95], existem, de modo geral,
trs modelos de execuo para uma soluo: execuo manual, execuo sem
superviso e execuo supervisionada. Na execuo manual, o usurio do sistema
responsvel por interpretar a soluo proposta e decidir se ela deve ou no ser
executada. Ocorre na maior parte dos sistemas CBR [LEW 95], em que o sistema
somente sugere, com base na sua experincia, no processo de recuperao e no processo
de adaptao, uma boa soluo para o problema, que executada pelo usurio.
Em alguns domnios, porm, quando uma soluo expressa em um programa de
computador, um sistema CBR pode ter a capacidade de executar a soluo que ele
prope, realizando-a automaticamente sem interveno ou controle humano. Quando
isso ocorre, formado um ciclo fechado de soluo de problemas sem interveno
humana, em que o problema submetido ao sistema, um caso similar recuperado e sua
soluo adaptada para a situao corrente, a soluo executada pelo sistema e os
resultados so inseridos na base de casos. Esse tipo de execuo envolve, contudo, um
alto risco, pois delega muita responsabilidade ao sistema [LEW 95]. Um modo
intermedirio a execuo da soluo proposta de modo automtico com o controle do
usurio. Nessa modalidade, o usurio pode permitir ou proibir a execuo de uma
soluo que sugerida pelo sistema, que a executa automaticamente se for autorizado.
Aps uma soluo ter sido avaliada, se o seu resultado for satisfatrio, a
experincia que foi obtida durante o processo de resoluo do problema corrente deve
ser armazenada no sistema. Isso feito atravs do processo de aprendizado, que ser
visto na prxima seo. Se, entretanto, o resultado da avaliao mostrou que a soluo
proposta no produziu um resultado adequado, o caso deve ser reparado. A reparao
do caso envolve a deteco dos erros da soluo corrente e a recuperao ou gerao da
explicao para a ocorrncia destes erros. Um exemplo de um sistema em que isso
realizado o sistema CHEF, desenvolvido por Hammond Apud [AAM 94], que utiliza

34

um conhecimento causal para gerar explicaes do porqu certos objetivos almejados no

caso corrente no foram atendidos, e armazena as situaes gerais que produziram falhas
usando uma tcnica de aprendizado baseada em explicao [AAM 94]. Um segundo
passo no processo de reparao utiliza, ento, as explicaes das falhas para modificar a
soluo corrente de modo que os erros no mais ocorram. A reparao de falhas pode
ser executada diretamente (quando for garantido que est correta) ou pode ser avaliada e
reparada novamente se necessrio. O esquema do processo de reviso pode ser visto na
figura 2.3.

2.8 Armazenamento (aprendizado)

O armazenamento dos casos o processo de incorporao ao sistema da
experincia obtida durante a resoluo do problema. Como foi visto, esse aprendizado
do sucesso ou falha da soluo proposta proporcionado pelo resultado da fase de
avaliao e possvel reparo da soluo. O armazenamento envolve a seleo de que
informaes do caso devem ser retidas, em que formas estas informaes devem ser
retidas, como indexar o caso para posterior recuperao em problemas similares futuros
e como integrar o novo caso na memria de casos [AAM 94].
Quando um caso foi resolvido pelo uso de um caso recuperado, um novo caso
pode ser construdo ou o caso recuperado pode ser generalizado para incluir o caso
corrente. J quando o problema foi resolvido por outros mtodos, como por consultas ao
usurio, um novo caso inteiro deve ser construdo. Informaes como descritores
relevantes do problema e soluo para a situao so dados geralmente utilizados para
armazenamento do conhecimento, assim como explicaes e outras formas de
justificativa do porqu a soluo utilizada foi proposta para o problema. No sistema
CASEY, por exemplo, explicaes so retidas nos casos e reutilizadas futuramente na
modificao da soluo. Informaes obtidas da tarefa de reparo da soluo podem
tambm ser extradas e retidas no sistema, seja como casos separados que falharam, seja
dentro de casos problema totais.
Por fim, o sistema CBR deve integrar o conhecimento aprendido base de casos.
Isso pode ser feito com a modificao do esquema de indexao dos casos existentes, em
que o sistema pode aprender o modo de ajust-los para que a similaridade possa ser
melhor identificada. Os pesos ou importncia dos ndices de um caso ou soluo em
particular podem ser ajustados pelo sucesso ou falha do uso do caso na soluo do
problema corrente. As caractersticas que foram julgadas relevantes na recuperao do
caso com sucesso tm ento sua importncia de associaes aumentada, ao passo que as
associaes das caractersticas que levaram a casos no similares serem recuperados so
enfraquecidas. Com esse processo, a estrutura de ndices tem a funo de canalizar e
adaptar a memria de casos para seu uso.
O aprendizado pode ocorrer tambm dentro de um modelo de conhecimento
conceitual geral, por exemplo utilizando outros mtodos de aprendizado automtico ou
atravs de interao com o usurio [AAM 94]. Assim, com uma interface apropriada ao
usurio, o modelo de conhecimento geral do sistema pode ser incrementado e refinado
naturalmente ao longo da resoluo de problemas, do mesmo modo como feito com a
memria de casos.

35

2.9 Exemplos de Aplicaes CBR

A seguir, apresentamos dois exemplos de aplicaes que usam raciocnio baseado
em casos. Estes exemplos foram escolhidos por terem contribudo para o
desenvolvimento de algumas particularidades dos processos do sistema proposto,
embora no sejam sistemas aplicados ao gerenciamento de redes.

2.9.1 Sistema CASCADE

O sistema CASCADE [SIM 92] foi desenvolvido para auxiliar engenheiros de
suporte a resolver falhas ocorridas em device drivers que afetam o sistema operacional
VMS da Digital. Esse sistema foi projetado utilizando um algoritmo de recuperao
denominado validated retrieval (recuperao validada), que envolve duas fases distintas.
A primeira fase do algoritmo envolve a busca na base de todos os casos que
parecem ser relevantes ao problema corrente, baseando-se nas caractersticas fornecidas
inicialmente sobre o problema. Essas caractersticas, denominadas caractersticas
superficiais, j so conhecidas pelos usurios no gerando, assim, nenhum custo para
serem obtidas ou podem ser obtidas a baixo custo. Exemplos dessas caractersticas
so o tipo de CPU e a verso do sistema operacional, que podem ser obtidas em um
simples comando.
A segunda fase do processo denominada model-based validation (validao
baseada no modelo): nessa etapa, baseando-se no contedo dos casos recuperados,
caractersticas adicionais so escolhidas. Essas caractersticas derivadas, que so mais
discriminantes para a situao corrente, no so de fcil obteno: elas so extradas
mediante um mecanismo complexo e dispendioso. As caractersticas derivadas ajudam a
eliminar os casos recuperados que no so apropriados, a identificar os casos
recuperados mais adequados e a recuperar casos relevantes adicionais que no foram
identificados atravs do uso das caractersticas superficiais. Um caso recuperado e
fornecido ao usurio somente depois que todas as caractersticas superficiais e derivadas
casaram com o problema corrente.
As caractersticas superficiais e derivadas so descritas atravs de pares
atributo/valor. Os casos so indexados por um subconjunto das suas caractersticas
superficiais e todas as suas caractersticas derivadas. As caractersticas derivadas so
geradas e obtidas por meio de probes objetos formados por aes que requerem
dados sobre o problema e por um conhecimento especfico ao domnio que gera as
caractersticas derivadas a partir dos dados obtidos. Os casos armazenados no sistema
so compostos de trs partes:

caractersticas superficiais com informaes sobre a falha e o ambiente em que

a falha ocorreu;

caractersticas derivadas relevantes e ponteiros para as probes relacionadas;

ao ou grupo de aes de reparo que soluciona o problema.

36

(Case 1
(Surface-Features
(Bugcheck invexceptn)
(Exception access-violation)
(CPU VAX-8800)
(VMS-Release 4.6)
(Module ioc$iopost)
(Offset 277)
(Instruction movz)))
(Derived-Features
((UCB-Status-TimeoutBit set)(Check-Timeout-Bit))
((IRP-Status invalid)(Check-IRP-Status)))
(Repair-Action Install VMS version 5.0 ))

FIGURA 2.4 - Exemplo de um caso do sistema CASCADE

Como uma probe pode gerar diversas caractersticas derivadas de um particular
atributo, elas podem ser utilizadas por muitos casos. Alm disso, dependendo do
domnio, as probes podem ser tambm inter-relacionadas: dados obtidos por uma probe
pode ser condies para aes de outra, dados gerados por uma probe podem disparar
outras probes relevantes, dados gerados por uma probe podem inibir outras probes que
estavam sendo executadas.
O algoritmo de recuperao do sistema utiliza uma estrutura denominada
validation model (modelo de validao), que contm as definies das probes, as interrelaes entre elas e outras informaes tal como o seu custo de execuo. O modelo
baseado em validao considera o custo total para estabelecer as caractersticas
derivadas do caso, e sempre leva em conta primeiro o caso com menor custo. A
arquitetura do sistema pode ser visto na figura abaixo [SIM 92].

engenheiro de front-line

comandos do analisador de dump

do sistema para a mquina do
cliente

Interface Usurio
Caractersticas

Casos

mdulo validated-retrieval
base de conhecimento
caractersticas
superficiais

recuperador de
caractersticas
superficiais

Casos

validador
baseado no
modelo

modelo de
validao

base de casos

FIGURA 2.5 - Arquitetura do sistema CASCADE

O processo de raciocnio inicia quando o usurio descreve o problema, usando
um conjunto das caractersticas superficiais. O sistema faz o casamento dessas
caractersticas com os ndices das caractersticas superficiais, utilizando o conhecimento
armazenado em uma base de conhecimento para efetuar o casamento de valores no

37

idnticos. As probes associadas s caractersticas derivadas dos casos extrados so

acessadas, e estabelecido o custo total para validar cada caso recuperado em relao ao
custo de suas probes. Os casos so ordenados em relao ao seu custo e o caso com
menor custo considerado.
A probe correspondente primeira caracterstica derivada que ainda no tenha
sido gerada executada e a caracterstica derivada gerada. O sistema tenta fazer o
casamento da caracterstica correspondente do caso recuperado. Quando a caracterstica
no casa, ele rejeita o caso e utiliza os ndices das caractersticas derivadas para tambm
rejeitar os outros casos que possuem valores diferentes do obtido para o atributo da
caracterstica derivada. O sistema recupera ento outros casos que incluem a
caracterstica obtida mas que no haviam sido inicialmente recuperados. Quando todas as
caractersticas derivadas do caso so estabelecidas, o caso selecionado e apresentado
ao usurio.
A base de conhecimento das caractersticas superficiais utilizada pelo sistema
contm dois tipos de conhecimento do domnio:

conhecimento sobre similaridade entre valores das caractersticas superficiais.

Indica, por exemplo, a similaridade entre duas CPU que pertencem a mesma
famlia;

conhecimento sobre inter-relaes entre as diversas caractersticas de

superfcie, implementadas atravs de um conjunto de regras se-ento.
Identificam, por exemplo, que os multiprocessadores VAX 8840 e 6230 so
similares se a falha ocorreu no mdulo SMP do sistema operacional e
releases da verso 5.0 de VMS estavam sendo utilizadas.
O sistema no utiliza conhecimento sobre similaridades entre caractersticas
derivadas. As probes do sistema, implementadas atravs de funes, so executadas
sobre um arquivo de dump da falha e geram as caractersticas derivadas sobre o estado
das estruturas de dados, podendo ser executadas muitas probes sobre cada estrutura de
dados.
O algoritmo validated retrieval um dos aspectos desse sistema que influenciou
o desenvolvimento da abordagem proposta no sistema DUMBO. No DUMBO, h
tambm uma recuperao dividida em duas etapas distintas, uma responsvel por uma
recuperao inicial baseada em informaes preliminares, outra responsvel por uma
avaliao da similaridade com o problema corrente mais especfica, que faz uso de
caractersticas extradas dos casos recuperados na primeira etapa. Alm disso, o uso de
inter-relaes entre as diversas caractersticas foi tambm aplicado no sistema DUMBO,
sendo estas inter-relaes utilizadas, contudo, para modificar a relevncia de
caractersticas, ao contrrio de modificar o clculo da similaridade.

2.9.2 Sistema Smart

O sistema Smart [ACO 92] um sistema assistente para resoluo de problemas
integrado ao servio telefnico de suporte ao cliente da empresa Compaq Computer
Corporation, desenvolvido pela empresa Compaq em conjuno com a Inference
Corporation. Este servio oferece suporte tcnico a consultas que vo desde requisio
de informaes sobre produtos da empresa at pedidos de resoluo de problemas em

38

um complexo ambiente de rede com uma vasta quantidade de produtos envolvidos, no

possuindo assim consultas tpicas.
Inicialmente, quando o engenheiro de suporte recebe uma chamada, ele tenta
resolv-la baseada na descrio textual da requisio ou problema. Se, entretanto, ele
no consegue solucionar o problema, ele aciona o sistema Smart, que recebe a descrio
do problema fornecida pelo usurio. O sistema Smart realiza, ento, uma busca inicial de
casos que casem com a descrio do problema corrente. Essa busca realizada
utilizando para o casamento uma anlise da descrio a nvel de subpalavras que faz uso
de um algoritmo de casamento denominado trigram [ACO 92], comparando a descrio
do problema corrente com a descrio do problema dos casos armazenados.
Aps a busca inicial, o sistema apresenta uma lista dos casos que apresentaram
maior similaridade ao problema corrente e uma lista de questes associadas a estes casos,
que visam obter informaes adicionais sobre o problema, de modo a melhor definido.
medida que as respostas a essas questes vo sendo fornecidas, o sistema aciona uma
nova busca, sendo que quanto mais informaes forem fornecidas, mais o sistema
aumenta sua acurcia do conjunto de casos relevantes ao problema corrente e das
questes associadas.
Para cada caso recuperado pelo sistema, informado um valor que representa
seu grau de similaridade com relao ao caso corrente. Este valor calculado com base
no valor resultante do casamento das descries, no peso das questes respondidas que
casaram ou no com o caso recuperado e na quantidade de questes no respondidas. A
figura 2.6 representa um esquema dos dados da consulta de um caso no sistema, extrada
de uma imagem em [ACO 92].
Description:
Experiencing spurious problems in a compaq file server resulting in a lockup situation, ethernet
topology, high traffic contention.
Questions about this Problem:
How do you categorize the problem (pick the first that applies)??
What Network Operating system are you using??
What major release of Banyan Vines are you using??
Are you using Vines SMP??
Wich family of Compaq maquine is it??
Are ther any interrupt conflicts??..
What is the Topology of the Network??

Networking proble...
Banyan Vines
4.10
Yes
Systempro
No
Ethernet

Matching Cases:
73 [KG] Banyan & Systempro W/ multiple server panics & locks-up #2
65 [KG] Banyan, Vines 4.10 Systempro server and PCs locking up.
50 [KG] Banyan, SMP Server sees 1 out of 3 NI3210 Ethernet Cards #2
46 [KG] Banyan, SMP Server sees 1 out of 3 NI3210 Ethernet Cards #1
42 [KG] Banyan, Server hanging when EtherLink II card cable is removed
40 [KG] Banyan, Vines PC program within PATH receives Command error

FIGURA 2.6 - Esquema de uma consulta de um caso no sistema Smart

Quando um registro de problema no resolvido pelo sistema, ele armazenado
na base de casos com o formato de um caso e o seu estado de caso no resolvido.
Quando esses casos so ento resolvidos, eles so aprendidos pelo sistema e
transformados em casos reais por engenheiros de suporte snior treinados para a
insero de casos na base.

39

A base de casos est contida em um banco de dados relacional simples. Para

garantir a consistncia e alto uso entre os casos foram estabelecidas questes que so
utilizadas em todos os casos em que se aplicam, tais como sistema operacional da rede,
processador da mquina, famlia de produtos Compaq em uso, ambiente de operao. O
sistema Smart tem se mostrado eficiente em 87% dos casos em que ele foi
consultado [ACO 92].
Entre os aspectos desse sistema que influenciaram o desenvolvimento do sistema
DUMBO, podemos citar o uso aes para aprimorar a recuperao, representadas por
perguntas em texto livre, e o fornecimento ao usurio do grau de casamento de cada
caso, a fim de permitir que este avalie o grau de segurana do sistema quanto
similaridade deste caso com o problema corrente.

2.10 Consideraes Finais

Este captulo procurou fornecer uma viso dos principais aspectos do paradigma
de raciocnio baseado em casos, com enfoque nos tpicos relacionados aos propsitos
desta dissertao. Este estudo foi realizado com o intuito de
identificar as
particularidades deste paradigma de modo a possibilitar sua correta utilizao para a
modelagem do sistema DUMBO.
O captulo a seguir discorre sobre a gerncia de redes. Neste captulo so
comentados seus principais conceitos, os sistemas de registro de problemas e o uso de
sistemas especialistas para a rea, com enfoque no uso de raciocnio baseado em casos.

40

3 Gerncia de Redes
As redes de computadores, hoje em dia, manipulam de modo rpido e eficiente
grandes quantidades de informao. Utilizadas normalmente no dia a dia das pessoas,
podem gerar, com a interrupo de seu funcionamento, a suspenso de diversos servios
de empresas e da vida diria, provocando enormes complicaes, tais como atraso no
recebimento de dados crticos, perda de rendimentos, impossibilidade de obter fundos
fora de horrio bancrio.
Em virtude da importncia de seus servios, as redes tm sido usualmente
controladas por tcnicos especialistas que possuem a responsabilidade de instalar, manter
e resolver seus problemas. Esses problemas podem abranger desde uma simples resposta
a uma dvida de um usurio at a identificao e substituio de um equipamento com
mal funcionamento ou a ativao de procedimentos de recuperao de falhas aps a
ocorrncia de um evento catastrfico.
Com o crescimento do nmero e da heterogeneidade dos equipamentos
envolvidos nas redes, o nmero de problemas potenciais e a complexidade envolvidas
nestes problemas tornam-se crticos, e exigem que os gerentes de rede possuam uma
vasta quantidade de informao sobre as redes manuseadas e os problema destas. Assim,
o gerenciamento de redes destina-se a auxiliar os gerentes a trabalhar com a
complexidade dos dados envolvidos, de modo a garantir a mxima eficincia e
transparncia da rede para os seus usurios.
Este captulo apresenta os principais conceitos de gerncia de redes, os sistemas
de registro de problemas e o uso de sistemas especialistas no domnio, destacando o uso
de raciocnio baseado em casos e as aplicaes da rea que utilizam esta abordagem.

3.1 Introduo
O gerenciamento de redes pode ser definido como a prtica de monitorar e
controlar uma rede, de modo que ela corresponda s expectativas de seus usurios; o
planejamento de ampliaes ou modificaes na rede, a fim de aumentar a demanda nas
operaes da rede e a incorporao de novos elementos na rede sem interferir nas
operaes existentes [LEW 95]. Possui diversos objetivos [UDU 96]: garantir sua
disponibilidade, reduzir seus custos operacionais, aumentar a flexibilidade de operao e
integrao das redes, aumentar a eficincia das redes, permitir facilidades de uso,
garantir caractersticas de segurana.
Gerenciar redes de computadores uma tarefa complexa, envolvendo a
monitorao e o controle de diferentes componentes de hardware e software, tais
como equipamentos
de
nvel
fsico
e
de
enlace,
componentes
de
computadores (processadores, impressoras, etc.), componentes de interconexo
(bridges, roteadores, switches, etc.), hardware de telecomunicaes (modens,
multiplexadores, etc.), sistemas operacionais, aplicaes e ferramentas de software,
softwares de interconexo (presentes nas bridges, roteadores, etc.), aplicaes clienteservidor (servidores de banco de dados, servidores de arquivos, servidores de impresso,
etc.), software de comunicao de dados [UDU 96].
Um importante fator no gerenciamento a habilidade de adquirir informaes
sobre os equipamentos envolvidos e as mudanas ocorridas nestes [LEI 96]. At alguns

41

anos atrs, a coleta de informaes nos diferentes dispositivos de rede era feita atravs
de mtodos distintos, proprietrios [NUN 97]. Com o passar do tempo, porm, foram
desenvolvidos protocolos de gerenciamento padronizados especficos para o
gerenciamento de redes, que fornecem mtodos para monitorar e configurar os diversos
equipamentos na rede. Atualmente, os dois protocolos mais comuns so o protocolo
SNMP (Simple Network Management Protocol), desenvolvido pela comunidade
Internet, e o CMIS/CMIP (Common Management Information Services/Commom
Management Information Protocol), padro da ISO [LEI 96].

3.2 reas Funcionais da Gerncia de Redes

Para melhor definir o seu escopo, o gerenciamento de redes foi dividido em cinco
reas funcionais pela ISO, cada uma com uma responsabilidade especfica:
gerenciamento de configurao, gerenciamento de segurana, gerenciamento de
performance, gerenciamento de contabilizao e gerenciamento de falhas
[LEI 96][UDU 96] [CAR 93][LEW 95].
O gerenciamento de configurao fornece facilidades para a obteno dos
dados sobre a rede e utilizao destes dados para gerenciar a configurao de todos os
equipamentos da rede, de modo a aumentar o controle dos gerentes atravs do acesso
rpido aos dados de configurao. Ele deve incluir facilidades como capacidade de
descobrir uma rede, manter o inventrio dos tipos de equipamentos de uma rede e
detalhes sobre eles, detectar mudanas ocorridas e executar mudanas. O gerenciamento
de configurao consiste de trs etapas[LEI 96]: obteno das informaes sobre o
ambiente de rede corrente, de modo que problemas gerados por simples erros de
configurao sejam rapidamente descobertos, utilizao dos dados obtidos para
modificar a configurao dos equipamentos de rede necessrios, o que precisa ser feito
em tempo real em virtude da contnua modificao dos dados no ambiente da rede, e
armazenamento dos dados, mantendo uma relao atualizada de todos os componentes
de rede e produzindo diversos relatrios. Estas etapas podem ser efetuadas atravs de
mtodos manuais ou automticos.
O gerenciamento de segurana envolve o controle de pontos de acesso s
informaes sensveis em uma rede as informaes armazenadas nos equipamentos de
rede que a organizao deseja manter em segurana e no devem estar disponveis para
todos os usurios. O gerenciamento de segurana responsvel pela proteo destas
informaes e deteco e relato das tentativas de intruso na rede ocorridas com sucesso
ou no, incluindo facilidades para procedimentos de controle, tais como estabelecer
polticas para o uso da rede, estabelecer e manter chaves criptografadas e cdigos de
autorizao, manter um registro (log) do acesso rede, prevenir e relatar acessos no
autorizados, iniciar procedimentos de investigao em resposta a acessos no
autorizados, detectar e prevenir vrus de computadores [LEW 95]. O gerenciamento de
segurana envolve quatro etapas: identificar as informaes sensveis, encontrar os
pontos de acesso (que podem incluir servios de software, componentes de hardware, o
meio de comunicao da rede), tornar os pontos de acesso seguros e manter a
segurana destes pontos [LEI 96].
O gerenciamento de performance envolve a medida da performance do
hardware, software e meios de comunicao da rede de modo que a rede permanea
acessvel e sem congestionamentos, ofereendo um nvel de servio consistente para os

42

usurios. Utilizando o gerenciamento de performance, possvel monitorar a utilizao

dos enlaces e equipamentos da rede e, em posse dessas informaes, determinar
tendncias de utilizao, isolar problemas de performance e resolv-los mesmo antes que
eles causem impacto na performance da rede. As etapas envolvidas nesse processo so
coletar os dados de utilizao dos equipamentos e enlaces de rede, analisar os dados
relevantes, de modo a identificar tendncias de utilizao elevadas, estabelecer limiares
de utilizao e usar procedimentos de simulao para identificar como a rede pode ser
alterada para maximizar sua performance [LEI 96].
O gerenciamento de contabilizao diz respeito anlise de como os recursos
disponveis so utilizados e os custos envolvidos no uso desses recursos. Envolve o
rastreamento e gerao de relatrios da utilizao dos recursos da rede por cada usurio
ou grupo de usurios, a fim de estabelecer mtricas, verificar cotas, determinar custos e
cobrar usurios. Permite um aumento do entendimento da utilizao da rede que pode
auxiliar tambm no desenvolvimento de uma rede mais produtiva. O gerenciamento de
contabilizao envolve os processos de [LEI 96]: obter dados sobre a utilizao da
rede, estabelecer quotas de utilizao utilizando mtricas e cobrar os usurios pelo
uso da rede.
Por fim, o gerenciamento de falhas envolve a localizao e correo dos
problemas ocorridos nas redes. Prov meios para o reconhecimento dos problemas da
rede, relatrio e registro desses problemas, correlao e avaliao destes, identificao
das causas dos problemas, inicializao dos procedimentos de correo das falhas,
verificao da correo [LEW 95]. O gerenciamento de falhas contribui para o aumento
da confiabilidade da rede, em virtude de suas ferramentas permitirem uma rpida
deteco de problemas e inicializao de procedimentos de recuperao: com elas, so
fornecidas as informaes necessrias sobre o estado corrente da rede, e os gerentes
podem trabalhar na resoluo de sua falha mesmo antes desta ser detectada pelos
usurios. Conforme aponta Allan Leinwand [LEI 96], o gerenciamento de falhas
compreensivo uma das tarefas mais importantes envolvidas no gerenciamento de redes.
O gerenciamento de falhas consiste primeiramente da deteco e aviso do
problema, que pode ser efetuado atravs de alarmes e eventos. O filtro e a correlao de
alarmes so funes importantes, alm do registro (log) das falhas e erros ocorridos. A
etapa seguinte consiste em isolar a causa do problema, utilizando procedimentos de
diagnstico e testes. Quando um problema ocorre, importante identificar a sua causa
correta. A anlise do problema requer, alm dos registros de log, detalhes das provveis
causas e as aes de diagnstico recomendadas, que devem estar disponveis
imediatamente para os gerentes envolvidos na resoluo do problema. Como os
problemas podem ser resultantes de diversas causas, ou um problema pode ser
responsvel por diferentes alarmes sendo gerados, estes devem ser correlacionados em
uma causa simples se h chances de mltiplas mensagens estarem sendo geradas. Por
fim, o problema corrigido, atravs de mtodos manuais ou automticos [UDU 96].
Um rastro de todo o ciclo de vida do problema deve ser mantido, sendo usualmente
utilizados para isso trouble tickets (registros de problemas).
A seguir apresentamos algumas consideraes sobre os sistemas de registro de
problemas e seu uso para o armazenamento do ciclo de vida de um problema.

43

3.3 Sistemas de Registro de Problemas

Os trouble ticket systems (TTS - sistemas de registro de problemas) so
utilizados para monitorar os problemas de uma rede, mantendo um rastro do ciclo de
vida de um problema, e tm sido amplamente discutidos na bibliografia [JOH
92][LEI 96][UDU 96][MAD 94]. Eles podem, tambm, ser utilizados para manter o
registro de outros aspectos da rede que no apenas digam respeito ao gerenciamento de
falhas, tais como modificaes de configurao, modificaes de segurana, requisies
e melhoramentos de performance. [LEI 96].
So atribudos para esses sistemas muitas funes ou propsitos [JOH 92]:

servir como uma memria dos problemas especficos ocorridos no domnio de

gerncia, mantendo a histria completa do problema. Com isso, possvel a
comunicao entre os gerentes envolvidos na resoluo do problema, de modo
que os problemas que se estendem por diversos turnos de trabalho possam ser
analisados e trabalhados imediatamente por um novo gerente quando
necessrio;

servir como um visualizador da lista de problemas correntes em um domnio,

que deve preferencialmente ser fornecida em ordem de prioridade. Eles
auxiliam, assim, o escalonamento do fluxo de trabalho dos diversos gerentes
de um domnio;

enviar atribuies de tarefas ou consultas atravs de sistemas de correio

eletrnico que estejam integrados ao sistema;

atribuir temporizadores para cada registro de problema, que quando

decorridos gerem um alerta para o registro associado, lembrando sobre o
problema;

enviar relatrios eletronicamente para os representantes de cada rede

controlada pelo domnio de gerncia, com resumos dos problemas associados
a essa rede, de modo a informar sobre o estado corrente de cada ocorrncia
ainda no solucionada;

permitir a anlise estatstica dos equipamentos da rede e da produtividade do

domnio de gerncia, atravs do processamento dos campos fixos dos
registros. Permitem que sejam gerados relatrios de Tempo Mdio entre
Falhas e Tempo Mdio de Reparo, alm de relatrios estatsticos de controle
de qualidade, que propiciam a deteco de equipamentos defeituosos antes de
uma falha efetiva;

atuar como filtro dos alertas que sejam relacionados a um registro de

problema em aberto;

permitir aos usurios e administradores da rede a visualizao das atividades

desenvolvidas pelo centro de operaes de gerncia para a resoluo de
falhas, indicando assim os esforos empregados para a resoluo destes.
Alm destes propsitos, os sistemas de registro de problemas servem tambm
para a interao entre diversos domnios envolvidos em um problema. Cabe lembrar que
a gerncia de redes no ambiente de processamento distribudo admite o surgimento de
ilhas de gerncia, nas quais a responsabilidade pela administrao da rede alocada ao
pessoal local. Essa modalidade de segmentao, referida na bibliografia especializada

44

como domnio de gerncia, costuma surgir de forma quase natural em redes complexas,
heterogneas e com mltiplos locais de concentrao [MAD 94], como no caso da rede
desta universidade, de redes regionais ou nacionais. Porm, se de um lado a diviso da
responsabilidade facilita o diagnstico, uma vez que os administradores locais tm
grande conhecimento daquela parte da rede, por outro lado, a possibilidade dos
problemas em sub-rede surgirem em funo de anomalias de outra sub-rede leva
necessidade de estabelecer algum mecanismo de apoio interao e cooperao entre os
administradores das diversas sub-redes. Assim, sistemas de registro de problemas podem
ser usados para compartilhar as informaes sobre a resoluo do problema, desde que
possam ser acessados de modo distribudo com os controles e restries adequadas,
permitindo a colaborao dos especialistas dos diversos domnios envolvidos no
diagnstico do problema.
Um sistema de registro de problemas cria para cada problema informado um
novo registro, atribuindo para este um nmero nico, e registra os dados sobre o
problema e aes efetuadas ao longo deste, desde a sua criao at o seu encerramento.
Os registros podem ser criados automaticamente, a partir de alarmes, ou manualmente,
por usurios ou gerentes da rede. Uma vez que o problema registrado, o sistema
interage com sua base de dados ou com bancos de dados da topologia, de modo a
preencher automaticamente as informaes solicitadas pelo registro que ele tem
condies de responder.
Cada problema registrado deve ter uma categoria assinalada automaticamente
pelo sistema ou manualmente pelo gerente encarregado do problema, o que pode auxiliar
no futuro a identificar os problemas que ocorrem mais freqentemente. Algumas
classificaes comuns, apontadas em [LEI 96], seriam: falha no enlace, falha em
equipamento da rede, brecha na segurana, erro de configurao, problema de
performance e questo de contabilizao. Podem existir diferentes tipos de registro para
os diferentes problemas encontrados em um rede, variando o formato dos registros
principalmente nos campos fixos.
As informaes podem ser solicitadas atravs de campos fixos ou de texto de
forma livre [JOH 92]. Os campos fixos tm a vantagem de serem utilizados mais
facilmente para busca e ter sua consistncia verificada com mais exatido. Alm disso,
estes campos so apropriados para dados que so fornecidos automaticamente pelo
sistema. Eles so, porm, mais apropriados para ambientes de resoluo de problemas
bem compreendidos e estveis, sendo utilizados para problemas especficos. Isso
acontece porque embora tendam a tornar os dados mais consistentes e confiveis, os
campos fixos tm a desvantagem de forar os usurios a escolherem entre os valores
preparados e permitidos que nem sempre representam a situao com preciso.
A estrutura de um registro de problema sugerida por [JOH 92] consiste de trs
partes: cabealho, atualizaes e dados da resoluo. O cabealho responsvel pelas
informaes de abertura do problema, que incluem [JOH 92]:

hora e data do incio do problema;

identificao do usurio que abriu o registro;
severidade do problema;
descrio do problema;
quem relatou o problema;

45

quais os equipamentos envolvidos;

qual a rede envolvida (quando o centro de operaes responsvel por vrias
redes);

endereo da mquina do usurio;

endereo da mquina destino;
prxima ao;
hora e data para o alarme associado ao problema;
para quem enviar o registro;

responsvel pelo registro.

Os quatro primeiros itens apresentados so sugeridos para todos os sistemas. Os
demais so apresentados como opes para coleta de informaes com propsitos
especficos ou informaes associadas a diferentes tipos de problemas.
As informaes de atualizao representam as aes e diagnsticos realizados
ao longo do ciclo de vida do problema. A primeira atualizao pode representar uma
descrio do problema, j que quando o problema aberto geralmente sua natureza
exata no conhecida e a descrio fornecida pode ser imprecisa e demasiado complexa.
sugerido que ao menos um campo de texto livre seja fornecido nesse estgio do
problema, para esse tipo de informao. Os campos de atualizao seguintes podem ser
bastante simples, tais como o exemplificado em [JOH 92] Site chamado; sem
resposta, e podem ser armazenados em campos fixos ou campos de texto livre,
variando conforme a implementao. sugerido ainda que haja sempre uma indicao da
prxima ao associada ao registro, que, mais uma vez, pode ser implementada como um
campo fixo especial ou como um campo de texto livre.
Por fim, os dados da resoluo representam as informaes que resumem o
problema para futuras anlises estatsticas, e tambm para uso em problemas similares.
Os campos apontados em [JOH 92] que seriam teis para esta etapa so:

hora e data da resoluo do problema;

durao;
descrio da resoluo do problema;
componentes afetados;
quem verificou o problema depois que este foi resolvido;
quem foi consultado para auxilio na resoluo do problema;

campo temporrio para armazenar informaes temporrias utilizadas para

investigaes estatsticas.
Outras informaes que poderiam ser solicitadas so ainda sugeridas na
bibliografia consultada. Entre estas, esto o estado corrente do problema, os usurios
afetados e as provveis causas para o problema [UDU 96][LEW 95].

3.4 Sistemas Especialistas para Gerncia de Redes

O processo de tomada de deciso em um ambiente, incluindo o gerenciamento de
redes, consiste em obter informaes, analis-las e tomar decises baseadas nestas

46

informaes. Esse um processo freqentemente decisivo para determinar o sucesso ou

a falha de um ambiente, de modo que grandes esforos so investidos nos estudos desse
processo. Exemplos de processos de tomada de deciso dentro da gerncia de redes
incluem gerenciamento da deteco e correlao de falhas na rede, do roteamento das
redes, do planejamento de configurao e controle de configurao on-line, da anlise e
otimizao da performance dos sistemas de comunicao, da anlise da segurana da
rede, da deteco de intruso na rede [ERI 89].
O processo pode ser feito de modo automtico. Com a automao dessas
atividades, a produtividade da equipe dos especialistas envolvidos aumentada e mais
servios podem ser oferecidos pela equipe, que pode concentrar-se tambm em outras
atividades em que requisitada. A automatizao de tais sistemas envolve a construo
de sistemas que imitem as atividades de tomada de deciso por especialistas humanos.
Tcnicas da IA podem ser usadas para o desenvolvimento destes sistemas os sistemas
especialistas.
As redes de computadores e telecomunicaes esto se tornando maiores e mais
heterogneas, possuindo cada vez mais diferentes caractersticas que precisam ser
consideradas no processo de gerenciamento de redes. So, assim, um domnio em que o
uso de IA traz inmeros benefcios. Aliado a isso, a gerncia de redes uma rea que se
beneficia com a presena de especialistas que, via de regra, possuem um considervel
domnio tcnico em computao. Com isso, expressam mais facilmente seu
conhecimento na forma adequada para a representao do conhecimento [STA 93].
Os sistemas especialistas podem ser aplicados na gerncia de redes para diversas
reas. No gerenciamento de configurao, eles podem ser utilizados para auxiliar no
planejamento de redes. Esses sistemas devem possuir informaes sobre a topologia
fsica da rede, mapas de roteamento e a topologia lgica-virtual.
O gerenciamento de falhas foi a rea que teve os primeiros sistemas
especialistas. Nesta rea, eles podem ser utilizados para o diagnstico e manuteno das
redes. Os sistemas de diagnstico efetuam a anlise das falhas da rede e seus efeitos, a
fim de determinar as provveis causas e definir os reparos e manuteno necessrios para
resolver o problema. Os benefcios dos sistemas especialistas de diagnstico incluem
[ERI 89]: diminuir o tempo para detectar as causas do problema; sugerir aos gerentes da
rede aes para resolver o problema; e automatizar a resoluo de problemas pela
interveno direta, resultando em comandos corretivos para uma rede inteligente.
Uma outra aplicao de sistemas especialistas para gerenciamento de falhas
envolve o controle da rede, sendo utilizados para estender as capacidades dos
operadores da rede, e no substitu-los. Os benefcios de tais sistemas so aumentar a
preciso e eficincia da interveno do operador, facilitar seu processo de tomada de
deciso e reduzir a quantidade de tempo necessria para restaurar ou alterar a
rede [ERI 89]. Alm de diagnstico e controle, sistemas especialistas podem ser
aplicados tambm para a interpretao de eventos, fornecendo mensagens de acordo
com a ordem e os cdigos de prioridade associados.
Sistemas especialistas podem ser tambm aplicados para o gerenciamento de
performance, gerenciamento de contabilizao e gerenciamento de segurana. Uma
aplicao desenvolvida para o ltimo, por exemplo, combina o conhecimento sobre o
sistema alvo, o perfil da histria das atividades passadas dos usurios e heursticas de

47

deteco de intruso, a fim de detectar violaes especficas que ocorrem no computador

alvo [ERI 89].
Existem diversos exemplos de sistemas especialistas desenvolvidos para a rea de
gerncia de redes de computadores e de telecomunicaes [ERI 89][KRI 91]
[CRO 88][TAR 90][NUN 97][HAR 97]. Os sistemas especialistas de diagnstico so as
aplicaes mais populares. Na rea de telecomunicaes, a manuteno de switches,
tipicamente para a tecnologia dos antigos switches, uma aplicao comum. Para a
administrao de redes em telecomunicaes, a aplicao mais comum para roteamento
de trfego ou gerenciamento de trfego [GOY 91].
Nas diversas aplicaes existentes, o paradigma de representao do
conhecimento
e
raciocnio
baseado
em
regras
(RBR - rule
based
reasoning) [JAC 86][HAR 89] [CRO 88] tem sido a tecnologia bsica utilizada, e tem
sido aplicado com sucesso para uma ampla variedade de problemas do mundo
real [GOY 91]. Um sistema baseado em regras consiste basicamente em uma memria de
trabalho, uma base de regras e procedimentos de controle. Em aplicaes no domnio de
redes, a memria de trabalho consiste tipicamente ma representao das caractersticas
da rede, incluindo informaes topolgicas e do estado da rede, enquanto que a base de
regras representa o conhecimento sobre as operaes que devem ser efetuadas quando a
rede entra num estado indesejvel. As regras podem efetuar diversas aes, tais como
testes na rede, consultas em um banco de dados, invocao de um outro sistema
especialista, envio de avisos e criao de registros de problemas. Quando a rede entra
num estado indesejvel, os procedimentos de controle selecionam as regras aplicveis
para a situao corrente, e uma estratgia de controle pr-determinada seleciona dentre
as regras aplicveis a que ser de fato executada [LEW 93].
Os sistemas baseados em regras possuem, porm, algumas limitaes,
especialmente considerando o uso de sistemas especialistas na gerncia de redes. Uma
destas limitaes o gargalo apresentado na aquisio de conhecimento. Isto
especialmente aplicado para a gerncia de redes, em que os esquemas de representao
do conhecimento so freqentemente inadequados para seu conhecimento um
exemplo o tipo de conhecimento utilizado em gerentes de trfego, que amplamente
baseado na experincia, ao invs de em heursticas pr-compiladas ou modelos de
domnios bem conhecidos. O domnio de gerncia requer a combinao da avaliao da
situao, resoluo de problemas e controle em tempo prximo ao real, quase de modo
contnuo, num domnio em que o modelo formal no existe e o conhecimento especialista
freqentemente irregular e sem coordenao. Alm disso, a velocidade na mudana
tecnolgica muito alta, com mudanas na arquitetura de vrios elementos da rede e
novos servios sendo integrados constantemente [GOY 91].
Uma outra caracterstica das operaes na rede a restrio de tempo para
tomada de decises tem como efeito a necessidade de resposta em tempo real em
muitas aplicaes do gerenciamento e a valorizao de sistemas que apresentam funes
com ciclo fechado, j que o tempo de reao humana muito longo para algumas
operaes da rede e a tarefa dos especialistas deve ser idealmente apenas de
superviso [GOY 91]. Contudo, j que os sistemas automticos apresentam um ciclo
fechado de execuo, a performance da rede se torna dependente da confiabilidade de
tais sistemas, que requerem tcnicas de verificao e validao precisas.

48

Novas tecnologias de conhecimento tm sido assim estudadas pela comunidade

da IA, freqentemente apelidando os sistemas em sistemas especialistas de segunda
gerao. Entre estas, citamos a Inteligncia Artificial Distribuda (IAD)
[LEW 95a][GOY 91][KRI 91], voltada para compartilhar o conhecimento e melhor
coordenar a resoluo de problemas, e o Aprendizado Automtico [GOY 91], que
prov a habilidade de obteno automtica de conhecimento em um ambiente dinmico.
Informaes adicionais e exemplos de sistemas baseados em regras e nas demais
tecnologias da IA para gerncia de redes podem ser obtidas em [ERI 89][KRI 91]
[CRO 88][TAR 90][NUN 97][HAR 97]. Alm destes, estudos sobre a representao do
conhecimento tem sido tambm desenvolvidos, a fim de identificar modos melhores e
mais robustos de utilizao do conhecimento do especialista [GOY 91].
A representao do conhecimento o modo de codificar o conhecimento do
especialista sobre o domnio, de modo que seja possvel armazenar, processar e utilizar o
conhecimento codificado. Existem muitos esquemas de representao desenvolvidos,
sendo que a maior parte dos sistemas utiliza para a representao regras de produo ou
frames [GOY 91]. Os paradigmas baseados em regras tm sido, como foi dito
anteriormente, amplamente utilizados no domnio de gerncia de redes, mas apresentam
algumas limitaes quando aplicado gerncia de redes.
Um paradigma que , segundo [GOY 91], adequado para o diagnstico e
resoluo e de problemas o raciocnio baseado em modelos (MBR - model-based
reasoning). O MBR trabalha atravs da interao da observao do elemento (o
comportamento de um equipamento, por exemplo) e da previso baseada no modelo.
Esta abordagem pode ser utilizada quando o equipamento ou sistema pode ser
formalmente modelado e o domnio do problema no contm interaes entre muitos
equipamentos. , entretanto, difcil modelar em uma aplicao uma rede completa e suas
interaes.
Um outro paradigma que pode ser utilizado para o raciocnio em sistemas
especialistas em gerncia de redes o raciocnio baseado em casos (CBR- case-based
reasoning), abordado no captulo anterior. Sua aplicao no gerenciamento de redes traz
diversos benefcios, tais como: possibilidade de incorporar novos conhecimentos;
diminuio da fragilidade dos sistemas, j que no precisam casar um conjunto preciso de
condies, e sim identificar situaes similares; adequabilidade representao do
conhecimento adquirido a partir de experincias passadas.
Cabe comentar que as diferentes representaes de conhecimento existentes so
apropriadas para pores especficas do conhecimento, que so, por sua vez, necessrias
em uma operao mais complexa. Assim, o uso de representaes hbridas contribui para
o aumento da robustez do sistema especialista, diminuindo a sua fragilidade quando este
no est apto para uma situao [GOY 91].
Comentaremos, a seguir, algumas aplicaes de gerenciamento de redes que
fazem uso do paradigma de raciocnio baseado em casos.

3.5 Raciocnio Baseado em Casos em Gerncia de Redes

Existem, ainda hoje, poucas aplicaes para gerncia de redes que fazem uso de
raciocnio baseado em casos. As aplicaes encontradas so utilizadas para suporte

49

deciso, algumas apresentando execuo automtica, outras sugerindo aes. Essas

aplicaes so aplicadas ao domnio das telecomunicaes e de redes de computadores.
No domnio das telecomunicaes, citamos os sistemas NETTRAC
[KOP 88][BRA 91], o sistema NEMS [MAT 95] e o sistema apresentado em [CAU 95],
aplicados ao gerenciamento de trfego, alm do sistema ACS [PEN 99], aplicado para
diagnstico e correo de falhas. No domnio de redes de computadores, destacamos o
sistema ExSim [STA 93], o sistema CRITTER [LEW 93][LEW 95] e o sistema
MASTER [DRE 95].
A seguir, apresentamos os sistemas NETTRAC, ExSim e CRITTER. Esses
sistemas representam um exemplo do uso de raciocnio baseado em casos nos diferentes
domnios de gerenciamento em que foram encontradas aplicaes: gerenciamento em
telecomunicaes, roteamento e gerenciamento de falhas em redes de computadores,
respectivamente. Os aspectos e particularidades em cada abordagem que contriburam
para o desenvolvimento do sistema DUMBO, proposto neste trabalho, so tambm
apresentados.

3.5.1 Sistema NETTRAC

O sistema NETTRAC [KOP 88][BRA 91] aplicado para o gerenciamento do
fluxo de trfego em uma rede telefnica pblica comutada. O controle de trfego nestas
redes realizado pela alocao de um conjunto varivel de recursos da rede, de modo a
satisfazer as demandas de uma amostra flutuante de chamadas telefnicas. Esse controle
exercido por um grupo de gerentes de trfego experientes, localizado em um ponto
central, que so responsveis pelas modificaes no processamento das chamadas
telefnicas para melhor atender s necessidades. Os problemas apresentados nesse
domnio so problemas de controle contnuo um quadro de dados analisado para
fornecer o diagnstico da situao, um conjunto de aes de controle efetuado para
tratar a situao e os efeitos destas aes so continuamente monitorados e
ajustados. [KOP 88]
Os nodos distribudos de uma rede telefnica so sistemas de comutao
telefnica automtica (os switches) fontes dos dados da rede e mquinas que
executam os controles de trfego , cada um capaz de manusear milhares de conexes
simultaneamente. Estes switches, assim como os grupos de troncos que os
interconectam, so os recursos da rede com capacidade finita sendo gerenciados.
Quando um switch falha, parcialmente ou completamente, ou o tronco rompido, a
capacidade de processamento total da rede reduzida e os gerentes de trfego buscam o
melhor modo de completar as chamadas. Da mesma forma, mesmo quando a capacidade
da rede total, a demanda pode exced-la por exemplo, em horrios crticos, em dias
especiais como dia de Natal, em chamadas de rdio e, tambm nessas situaes, os
gerentes procuram encontrar modos de satisfazer a demanda local utilizando os recursos
disponveis do resto da rede. Esses sistemas apresentam aspectos relativos a diagnstico
e planejamento, que so, como aponta Kopeikina et al, domnios clssicos para uso de
IA, e funes de planejamento tm sido amplamente desenvolvidas utilizando CBR, que
tm diversas vantagens de serem aplicados para sistemas de tal tipo [KOP 88].
Uma dessas vantagens diz respeito ao tipo de conhecimento utilizado pelos
gerentes de trfego. A partir das entrevistas com os gerentes de trfego, Kopeikina et al
descobriram que grande parte do seu conhecimento episdico, isto , o especialista

50

resolve um problema corrente pela lembrana de uma experincia anterior similar, que
pode ser tanto uma situao real especfica como uma generalizao de uma classe de
situaes similares ocorridas. Quando um gerente de trfego est passando seus
conhecimentos para um novo gerente, ele utiliza essas experincias/casos para transmitir
seu conhecimento especialista, o que indica a adequao de utilizar casos para
representar o conhecimento envolvido nesse domnio. Assim, a aquisio de
conhecimento naturalmente resulta em casos de gerenciamento de trfego [KOP 88].
Alm disso, Kopeikina et al apontam que a partir do entendimento do domnio
adquirido pelo grupo, a utilizao de experincias passadas parece ser o melhor guia
disponvel para tomada de deciso pois, embora exista algum conhecimento de relaes
gerais causais entre as aes de controle e respostas da rede a estas, nenhum modelo
completo do domnio existe. Assim, os gerentes de rede freqentemente agem de acordo
com situaes anteriores bem sucedidas, mantendo um entendimento incompleto das
razes do sucesso ocorrido. Como comentam Kopeikina et al, isso compreensvel,
dada a intratvel escala da dinamicidade da rede e das restries de tempo para
resposta [KOP 88]p.251. Assim, o raciocnio baseado em casos oferece um meio
adequado para levar vantagem deste conhecimento episdico.
Uma outra questo diz respeito continua e gradual mudana sofrida no domnio
do gerenciamento de trfego mudanas ocorrem quando a companhia telefnica
aumenta o nmero de switches sobre gerenciamento de trfego, quando a companhia
adiciona novos tipos de switch ou novos componentes de hardware ou software que
gradualmente modificam o comportamento da rede. Essas mudanas passam, porm,
freqentemente desapercebidas pelos especialistas humanos envolvidos neste domnio,
que vo adaptando o seu conhecimento gradualmente e aplicando verses modificadas
de situaes anteriores para resolver novas situaes. Assim, sistemas utilizando CBR
podem criar novos casos para resolver as situaes em que o conhecimento dos casos
armazenados insuficiente, ao passo que a utilizao de sistemas especialistas
convencionais que no utilizem CBR iriam demonstrar uma contnua degradao de
performance com estas mudanas [KOP 88].
Portanto, o uso de raciocnio baseado em casos muito adequado para domnios
como o de gerenciamento de trfego: ele permite a utilizao de experincias anteriores
casos para resoluo de novas situaes e permite que novos casos sejam criados
para incorporar as situaes em que os casos existentes no so aplicveis
adequadamente [KOP 88]. Essas vantagens so compartilhadas pelos sistemas aplicados
ao domnio de gerenciamento de falhas em redes de computadores, como o sistema
proposto neste trabalho. Nesse domnio, pode ser tambm identificado nos gerentes de
rede uma grande ocorrncia de conhecimento episdico, que vai sendo adaptado para as
diversas modificaes e evoluo sofrida pelas redes atuais.
O processo envolvido no sistema NETTRAC inicia com o Pr-processador, que
interpreta as informaes da rede e forma a representao do problema, denominada
Problem Statement (PS - Descrio do Problema). O Pr-processador escolhe o
esqueleto de PS a ser utilizado, entre os diferentes esqueletos existentes, de acordo com
o tipo de problema corrente, e avalia se o problema antigo e j est sendo tratado pelo
sistema ou se um problema novo. No primeiro caso, os dados sobre o problema so
enviados ao Monitor, responsvel por relacionar os dados correntes sobre o estado do
problema com o estado esperado (as expectativas para as aes j efetuadas), relatado

51

no caso armazenado. Quando os efeitos esperados no foram atingidos, o Monitor deve

propor ajustes ou modificaes no tratamento.
J no segundo caso, isto , quando o Pr-processador identifica um novo
problema, a descrio (PS) transferida para o Indexador/Casador que recupera entre
os casos armazenados na base os casos mais relevantes para o problema corrente. O
Seletor escolhe, ento, entre os casos selecionados, o que possui maior potencial de ser
til para a situao, e a experincia armazenada nesse caso aplicada para a situao
corrente pelo Modificador, sendo alterada quando necessrio.
O caso modificado proposto ao Criticador, que utiliza procedimentos
especficos ao domnio para determinar se o tratamento proposto parece levar a algum
efeito danoso. Se o caso proposto for vetado, o Modificador pode efetuar as
modificaes necessrias no caso armazenado, o Seletor pode escolher um novo caso
entre os casos selecionados ou ainda o Indexador/Casador pode realizar uma nova busca
para recuperar outros casos candidatos. Se o caso for aprovado pelo Criticador, ele
proposto para o usurio. Uma vez que tambm o usurio tenha aceito o plano de
tratamento do caso, ele , ento, implementado pela Interface de Rede na forma de
controles nos processamentos das chamadas dos switches. Esse plano ainda registrado
na Histria do Tratamento e comunicado ao Pr-processador, a fim de que uma nova
entrada de problema associada com um tratamento sendo efetuado seja reconhecida. A
figura abaixo [KOP 88] apresenta a arquitetura do sistema.
Interface
de Rede

Monitor

Histria
Tratamento

Indexador /
Casador

Pr-Processador

Aprendiz

Casos Recuperados

Seletor
de Casos
ndices
Modificador
Casos
Controles

Criticador

Fluxo de Controle e Dados

Fluxo de Dados

Usurio

FIGURA 3.1 - Arquitetura do sistema NETTRAC

A estrutura de indexao dos casos, utilizada pelo mdulo Indexador/Casador
para recuperar os casos similares ao problema corrente, foi escolhida considerando-se
que o domnio no suporta um conjunto simples de atributos que seja sempre
discriminante entre as diversas possveis situaes problema ao contrrio, a relevncia
dos atributos definida localmente. Essa abordagem foi tambm utilizada no sistema
DUMBO, em que os problemas do domnio apresentam grande diversidade. Dessa
forma, tornou-se necessrio utilizar um conjunto de atributos discriminantes varivel
conforme a situao sendo tratada, como ser visto no captulo 5.

52

3.5.2 Sistema ExSim

O ExSim Prototype [STA 93] foi desenvolvido para o domnio de gerenciamento
de redes automtico, enfocando o processo de roteamento. Esse sistema utiliza um
programa de simulao que simula a rede WAN sendo gerenciada, composta de
gateways que trocam mensagens utilizando tcnicas de roteamento esttico. Em virtude
dessa estratgia de roteamento simples, uma sobrecarga local pode ocorrer se as
informaes de roteamento no forem trocadas de modo adequado pelo gerenciamento,
diminuindo a performance da rede. Assim, a tarefa do mdulo de raciocnio baseado em
casos detectar os gargalos e mau funcionamento, atravs da classificao dos estados
da rede e comparao desses estados com os problemas ocorridos anteriormente,
armazenados na base como casos.
Por ser um sistema sem interveno do usurio, essa abordagem apresenta
aspectos como a deciso automtica quanto aplicao ou no da soluo de um caso e
a avaliao automtica de que procedimentos realizar se o sistema no foi capaz de
recuperar uma situao similar. O sistema ExSim ilustra, assim, como o uso de
procedimentos sem interveno humana bastante complexo num domnio como o
gerenciamento de redes. Quando aplicado em um sistema cujo objetivo tratar uma
vasta gama de problemas, como o sistema proposto neste trabalho, esses procedimentos
se tornam ainda mais complexos pela dificuldade de avaliar a soluo recuperada e
simular uma situao similar. O sistema DUMBO engloba, assim, a interveno e
avaliao do usurio na sua arquitetura, como ser visto no captulo 5. Porm, o uso de
procedimentos automticos com a rede suportado pelo DUMBO em alguns processos,
tal como a obteno de informaes diretamente dos equipamentos da rede.
A figura a seguir [STA 93] apresenta a estrutura do sistema ExSim, onde podem
ser identificadas as suas trs partes componentes (simulador, rede gerenciada e
raciocinador baseado em casos).
Mdulo de raciocnio baseado em casos
Simulador

Base de
Casos

Casamento
Aplicao Aprendizado
Comunicao

Redes de Comunicao Simuladas

FIGURA 3.2 - Estrutura do ExSim

Os casos contidos no sistema representam situaes de falha, sendo formados
pela descrio do problema, descrio da soluo, um nome nico e por dois valores de
limiares e . A descrio do problema e da soluo realizada atravs de um conjunto
de pares atributo/valor, em que cada atributo (caracterstica) descreve um aspecto de um
possvel estado dos componentes da rede.
A descrio do problema consiste em um conjunto de tabelas de roteamento dos
gateways combinadas em um atributo, a informao da carga em todos os enlaces da
rede, a tabela da topologia da rede e o estado dos gateways. O atributo correspondente
tabela de roteamento representado por um conjunto de matrizes inteiras, enquanto o

53

correspondente a carga da rede formado por um conjunto de nmeros positivos em

ponto flutuante. Os atributos correspondentes ao estado do nodo so identificados com
o estado up ou down. A descrio da soluo, por sua vez, consiste em um conjunto
de tabelas de roteamento para os gateways da rede gerenciada, que tambm
representado por um nico atributo, como na descrio do problema.
O valor de limiar utilizado para decidir se um caso candidato para a soluo
do problema, enquanto que o valor de limiar utilizado para decidir se a soluo do
caso deve ser aplicada para o problema corrente. O sistema assegura sempre que
0 < < < 1. Quando a similaridade do caso para o problema corrente excede o seu
limiar , o caso acrescentado para os casos candidatos ao problema corrente; quando a
similaridade excede o limiar , a soluo deve ser aplicada para o problema corrente.
Com isso, possvel, atravs do ajuste de e , influenciar a probabilidade dos casos
serem escolhidos. Estes valores so obtidos atravs do mtodo de tentativas, e na verso
do prottipo relatado na referncia consultada [STA 93] os melhores resultados foram
obtidos utilizando os valores 0,6 para e 0,8 para .
O casamento dos casos recuperados com as descries do estado da rede
realizado utilizando uma medida de similaridade calculada pela razo entre os indcios
indicando similaridade e todos os indcios registrados, conforme apresenta a funo sim
na figura 3.3 [STA 93]. Na figura, common representa o nmero de atributos que esto
presentes tanto na descrio do caso recuperado como na descrio do estado da rede e
cujos valores so considerados similares, e different representa o nmero de atributos
que esto tambm em ambas as descries, mas cujos valores no so classificados como
similares. A similaridade entre dois valores considerada verdadeira quando a
similaridade entre eles exceder um limiar global t.
sim(state, case) =

a . common

[0, 1].

a . common + b . different
FIGURA 3.3 - Funo de similaridade utilizada no sistema ExSim
Cada tipo de atributo dos casos possui uma funo de similaridade prpria. Os
valores correspondentes ao estado do nodo possuem similaridade 1 se ambos possuem o
valor igual (seja ele up ou down), e similaridade 0 caso sejam diferentes. Os valores
descrevendo a topologia tm similaridade 1 quando so idnticos, e 0 quando no o so.
A similaridade entre as tabelas de roteamento calculada pela razo do nmero de
entradas que coincidem em relao ao nmero total de entradas na tabela. Por fim, a
similaridade entre os valores da carga do enlace considerada verdadeira se ambos os
enlaces excedem um limiar C, que representa enlaces com carga crtica. Este limiar C
ajustado de acordo com a carga mnima e mxima ocorrida no estado da rede, para que
se garanta que a medida de similaridade seja especfica e no seja tratada de modo
independente pelo mdulo responsvel pelo casamento.
Como o sistema opera em modo de ciclo fechado, isto , as tarefas de
monitorao, raciocnio e controle devem ser feitas sem interveno humana durante
operaes normais, os autores consideraram importante que ele operasse em modo
pessimista as aes de controle devem ser assim verificadas em caso de incerteza
antes de que elas sejam aplicadas na rede gerenciada, seja utilizando simulaes para
verificar os resultados das operaes corretivas seja comunicando as aes pretendidas
para os operadores humanos a fim de obter uma verificao. Assim, a fim de

54

implementar uma estratgia pessimista, o sistema definiu o coeficiente a como 1, e o

coeficiente b como 2.
O processo de recuperao inicia quando estados crticos na rede so
reconhecidos pelo raciocinador. Isso identificado atravs de um alarme recebido da
rede, indicando uma sobrecarga de um dos gateways e informando o estado da rede, ou
atravs de um pooling explcito no estado da rede. As informaes sobre o estado da
rede consistem em um conjunto de tabelas de roteamento dos gateways, na carga nos
enlaces da rede, na topologia e no estado do gateway. As informaes recebidas so
comparadas s partes problemas dos casos armazenados utilizando-se medidas de
similaridades. Quando um caso selecionado como o melhor caso, a sua soluo
enviada para os componentes ativos da rede a fim de que a situao crtica seja aliviada.
Essa soluo consiste de um novo conjunto de tabelas de roteamento para os gateways
atingidos pela sobrecarga ou que so origem dela.
Quando nenhum caso similar selecionado, diferentes aes so tomadas,
dependendo do problema ter sido identificado atravs de um alarme da rede ou no. Se
o problema no foi identificado atravs de um alarme, ento significa que em termos do
conhecimento do sistema a rede est operando corretamente e nenhuma ao precisa ser
tomada. Se, entretanto, o problema foi identificado atravs de um alarme da rede,
identificado que para um problema da rede existente no h soluo no sistema e assim
novos conhecimentos devem ser adquiridos. As informaes sobre o estado da rede so
ento passadas para o programa simulador, que simula uma rede similar rede
gerenciada, com a diferena que na rede simulada utilizada uma estratgia de
roteamento dinmica dependente da carga. Assim, quando a simulao termina, o seu
resultado representa um conjunto de tabelas de roteamento timo aplicvel para a rede
sendo gerenciada, dando origem a um novo caso, que armazenado na memria de
casos, sendo sua soluo repassada para a rede gerenciada [STA 93].
O prottipo deste sistema foi implementado em linguagem C++.

3.5.3 Sistema CRITTER

O sistema CRITTER [LEW 93][LEW 95] baseado na adio de um
componente de resoluo de problemas que utiliza o paradigma de raciocnio baseado
em casos sobre um sistema de registro de problemas simples. O contexto para o qual este
sistema foi desenvolvido similar ao do sistema DUMBO, enfocando falhas em redes de
computadores e o uso de raciocnio baseado em casos associado a sistemas de registros
de problemas. Alm disso, a abordagem utilizada nesse sistema apresenta diversos
aspectos que influenciaram o sistema DUMBO, tais como o uso de uma linguagem
estruturada para o registro de problema e o uso de atributos relevantes distintos,
variando conforme o tipo de problema sendo tratado, que so comentados a seguir.
Um exemplo de um registro do CRITTER [LEW 93] apresentado na figura 3.4.
Alguns campos do registro so usados apenas para propsitos de gerenciamento, tais
como a prioridade ou o estado do registro, enquanto outros descrevem a natureza do
problema (tais como o nome e o tipo do equipamento). Os registros podem ser formados
de modo mais ou menos estruturados, com linguagem estruturada ou livre. No exemplo
da figura, por exemplo, o campo Additional Data contm uma lista de dados que o
gerente pode estar interessado em conhecer antes de comear a tentar solucionar o
problema. Esse campo descrito usando uma linguagem estruturada. Isso ocorre

55

porque, como aponta Lundy Lewis [LEW 93], aconselhvel desenvolver uma
linguagem descritiva estruturada para a informao para os campos como Trouble,
Additional Data e Resolution. importante ressaltar, porm, que, embora essa
abordagem evite algumas difceis questes referentes ao processamento de linguagem
natural, ela tem a desvantagem de impor limites para a quantidade de aprendizado que o
sistema pode atingir [LEW 93].
Entry-ID

Submitter

00000000116

Alarm ID

SPECTRUM

Create-date

57

07/24/92 08:51:08

Alarm Date/Time 07/24/92 08:51:07

Condition
oRed oOrange oYellow
Device Name
Ethernet-Randy

Notify-method

Device Type

Last-modified-by SPECTRUM
Modified-date
07/24/92 08:51:08

Ethernet

IP Address

oNone oNotifier oE-mail

Assigned-Priority oLow oMedium oHigh

Assigned-to

Trouble

file_transfer_throughput=slow

Additional Data

network_load=20, collision_rate=15,deferment_rate=20,users=31

History of Trouble
Probable Cause
Resolution
Resolution Status
Ticket Status

o Good

No Good

In Progress

New

Assigned

Reject

Closed

FIGURA 3.4 - Exemplo de um registro de problema

O clculo da similaridade entre dois registros do sistema foi concebido de modo a
dar importncia para o nmero de casamentos entre atributos que so relevantes para
um particular tipo de problema. Para isso, Lewis aponta que a base de registros deve ser
acrescentada com um conjunto de determinadores que registrem informaes de
relevncia entre as classes de problemas da rede e os conjuntos de atributos dos
registros [LEW 93]. A figura a seguir, extrada de [LEW 93], apresenta um exemplo de
um determinador, onde so indicados os atributos relevantes para os problemas do tipo
vazo_da_transferncia_de_arquivo. Os determinadores, assim, permitem que o
sistema focalize os registros de problemas mais provveis de conterem estratgias que
levem resoluo do problema corrente.
Exemplo de um determinador:
A soluo para o problema vazo da transferncia de
arquivos est lenta determinado observando a largura de banda,
carga da rede, taxa de colises e taxa de retardo dos pacotes.

FIGURA 3.5 - Exemplo de um determinador

Como aponta Lewis, existem diversas abordagens para a criao dos
determinadores. A primeira delas se baseia na observao de que os gerentes de rede
aplicam determinadores conceituais quando vo inspecionar uma base de dados de
registros de problemas em busca de registros teis. Tipicamente, recuperado um
conjunto de registros que case com o campo problema da situao corrente, e este
conjunto , ento, podado, atravs do casamento de outros atributos. Assim, com o

56

uso de sistemas de registro de problemas, possvel armazenar as aes efetuadas pelos

gerentes durante o processo de seleo e definir estes processos como macros, que se
tornam os determinadores, podendo ser usados novamente em problemas similares
[LEW 93].
Uma segunda abordagem estabelece que os especialistas do domnio definam um
pequeno, mesmo que imperfeito, conjunto de determinadores. Essas regras podem ser
ento refinadas automaticamente com o aprendizado do sistema e ser modificadas com
as mudanas da rede. Com isso, a obstruo da aquisio de conhecimento, que ocorre
em domnios de rpidas mudanas, torna-se menos problemtica. Por fim, uma terceira
alternativa seria aplicar um algoritmo de informao terico para a base de dados dos
registros de problemas, que indicaria uma lista de determinadores que casam com os
atributos do registro para os procedimentos de resoluo de falhas [LEW 93]. O sistema
CRITTER foi desenvolvido utilizando a segunda abordagem citada.
Aps a recuperao ser efetuada e o registro com maior similaridade ser
escolhido, um estratgia de resoluo deve ser proposta ao usurio (ou executada
automaticamente), o que realizado pelo mapeamento da soluo do registro
recuperado para o registro da situao corrente.
Quando a resoluo do registro selecionado no pode ser diretamente aplicada
para o problema, o sistema CRITTER aplica sobre ela uma estratgia de adaptao,
possuindo trs estratgias utilizveis [LEW 93]. Uma primeira estratgia a adaptao
parametrizada, descrita no captulo 2. Com esse mtodo, a varivel da soluo do
registro corrente ajustada de modo relativo s variveis do problema, usando para isso
a relao entre a varivel soluo e as variveis do problema do caso recuperado.
Observando o exemplo da figura 3.6, com as demais variveis sendo iguais, para um
problema corrente vazo_transferncia_arquivo=F, seria proposto a resoluo
ajustar_carga_rede=A (b), onde F e A teriam a mesma relao que F e A do
problema recuperado (a). Nesse exemplo, h vrios modos de representar a funo f. O
modo mais simples seria uma tabela em que os valores de F que no esto na tabela
seriam calculados por interpolao. Um outro modo seria representar a funo utilizando
inferncias de lgica fuzzi [LEW 92]. Outros tipos de problema poderiam utilizar uma
seqncia de passos ou uma rvore de deciso [LEW 93].
Caso Recuperado:
problema: vazo_transferncia_arquivo=F
dados adicionais: nenhum
soluo: A=f(F), ajustar_carga_rede=A
estado da soluo: bom
(a)

Situao corrente:
problema: vazo_transferncia_arquivo=F
dados adicionais: nenhum
soluo: A=f(F), ajustar_carga_rede=A
estado da soluo: bom
(b)

FIGURA 3.6 - Exemplo de adaptao parametrizada

Uma segunda estratgia que utilizada para a adaptao o mtodo da abstrao
ou reinstanciao. Com essa tcnica, se h uma restrio proibitiva em uma soluo
proposta, o sistema abstrai o registro que contm a soluo e se volta para um registro
que contm uma soluo alternativa. Um exemplo dessa estratgia pode ser visto
considerando-se novamente o problema da figura anterior (3.6 b), e supondo-se que
tenham sido recuperados dois casos igualmente similares para o problema o caso
exemplificado na figura anterior (3.6 a) e o caso exemplificado na figura a seguir (3.7 a).
Se uma restrio para uma possvel resoluo de um registro corrente

57

no_ajustar_carga_rede, ou se a execuo desta funo no resolve o problema, ento

o sistema prope aumentar_largura_de_banda e acrescenta um novo registro a base
conforme mostrado na figura a seguir (3.7 b) [LEW 93].
Caso aprendido:
Caso Recuperado:
problema: vazo_transferncia_arquivo=F
problema: vazo_transferncia_arquivo=F
dados adicionais: ajustar_carga_rede=no
dados adicionais: nenhum
soluo: B=g(F), aumentar_largura_de_banda=B soluo: A=f(F), ajustar_carga_rede=A
estado da soluo: no bom
estado da soluo: bom
(a)
(b)

FIGURA 3.7 - Exemplo de adaptao por abstrao

Por fim, o sistema pode utilizar tambm a adaptao baseada em crtica, que
corresponde adaptao realizada quando um especialista repara a soluo recuperada,
de modo que esta seja aplicada ao caso corrente. Exemplos dessa forma de adaptao
so adicionar, remover, reordenar e substituir passos na soluo recuperada. Os registros
cuja soluo sofreram essa forma de adaptao devem ser, ento, armazenados na base
de casos, de forma que seu conhecimento seja incorporado.
O sistema CRITTER est envolvido em uma arquitetura conforme apresentado
na figura 3.8 [LEW 93]. O sistema SPECTRUM prov as funes de gerenciamento de
configurao e deteco de falhas, enquanto que o AR System prov as funes de
gerenciamento de falhas [CAB 97]. O sistema CRITTER resultado da adio do
componente de resoluo de falhas CBR para o sistema de gerenciamento de falhas (AR
System).
Rede
SPECTRUM
Gerenciamento
Configurao
Deteco
Falhas
CRITTER
(AR System + CBR)
Gerenciamento de Falhas
Resoluo de Falhas

Entra

Biblioteca
Trouble Tickets

Recupera

Adapta

Prope

Determinadores

Tcnicas
Adaptao

Adaptao
baseada Usurio

Processa

Usurio

FIGURA 3.8 - Arquitetura do sistema CRITTER

58

O processo inicial envolvido no sistema CRITTER obtm informaes sobre o

problema corrente na forma de um registro de problema, atravs do mdulo Entra. Essas
informaes podem ser obtidas de modo manual por um usurio ou automaticamente por
uma aplicao que una o sistema CRITTER ao SPECTRUM. A recuperao realizada
pelo mdulo Recupera de modo transparente ao usurio, fazendo uso dos
determinadores para recuperar o conjunto de registros armazenados que so similares ao
problema corrente. O conjunto inicial das regras de determinao do sistema podem ser
fornecidos por especialistas do domnio ou serem extrados de um documento de
diagnstico. Estas regras no so, porm, perfeitas, sendo melhoradas com o uso do
sistema.
Uma vez que os registros similares foram recuperados, o registro com maior
similaridade selecionado pelo mdulo de Adaptao. Se este registro possui um
casamento total com todos os campos relevantes, ento a resoluo mantida igual.
Caso contrrio, o mdulo aplica a tcnica de adaptao parametrizada ou a adaptao
por abstrao, comentadas anteriormente. As solues potenciais encontradas pelo
sistema so apresentadas ao usurio pelo mdulo Prope, e o usurio pode inspecionar e
manualmente adaptar as solues. Por fim, o registro armazenado na base de casos
pelo mdulo Processa. Alm disso, esse mdulo pode enviar instrues ao sistema
SPECTRUM, tornando o gerenciamento um ciclo fechado e fazendo o gerenciamento de
falhas de modo completamente automatizado.
Como pode ser visto na figura, o usurio pode interagir em trs pontos da
arquitetura: pode filtrar os registros de problemas que so submetidos ao sistema
CRITTER, pode adaptar as solues propostas atravs do mdulo Prope e pode
regular as instrues que sero enviadas para o sistema SPECTRUM.

3.6 Consideraes Finais

Este captulo apresentou os principais tpicos de gerncia de redes e comentou
alguns exemplos do uso de raciocnio baseado em casos j apresentado no captulo 2
neste domnio.
Apresentaremos, a seguir, o modelo proposto neste trabalho um modelo que
utiliza raciocnio baseado em casos sobre um sistema de registro de problemas para
diagnstico de falhas ocorridas em uma rede . O modelo ser introduzido no captulo 4 e
descrito no captulo 5, sendo o seu prottipo comentado no captulo 6.

59

4 Raciocnio Baseado em Casos Aplicado a um Sistema

de Registro de Problemas: Sistema DUMBO
4.1 Motivao
Comentamos, no captulo anterior, a ampla utilizao dos sistemas de registro de
problemas no gerenciamento de falhas em redes de computadores [JOH 92][MAD 94].
Esses sistemas mantm o rastro do ciclo de vida dos problemas enfrentados,
armazenando, assim, uma memria histrica dos problemas do domnio de gerncia.
Como grande parte dos problemas que ocorrem em uma rede constituem
repetio de uma situao similar j ocorrida no passado, tais sistemas so muito
utilizados para acumular o conhecimento derivado do processo de diagnstico e
resoluo dos problemas anteriores. Todavia, a consulta manual por uma soluo de uma
situao similar em sistemas de registro com nmero grande de ocorrncias acaba por se
tornar muito morosa e imprecisa.
Assim, uma soluo apropriada para consolidar a memria histrica de um
domnio de gerncia a criao de um sistema especialista que faa uso do
conhecimento armazenado nestes sistemas para propor solues na ocorrncia de um
novo incidente. Como foi comentado no captulo anterior, existem diversos paradigmas
que tm sido utilizados no desenvolvimento de sistemas especialistas na rea de gerncia
de redes em geral.
O raciocnio baseado em regras tem sido a tecnologia mais utilizada [GOY 91].
Os sistemas com este paradigma possuem, porm, algumas limitaes, especialmente
quando utilizados em domnios com alta taxa de mudanas e evoluo [LEW 93]. Uma
destas limitaes diz respeito ao gargalo apresentado na aquisio do conhecimento
[GOY 91][LEW 93]. Esse problema pode ocorrer quando um engenheiro de
conhecimento tenta identificar regras e procedimentos de controle que iro abranger
situaes imprevisveis e o sistema acaba por se tornar imprevisvel, difcil de manejar e
de manter [LEW 93]. Razes para tal problema ocorrer incluem dificuldade dos
especialistas em articular o raciocnio que utilizaram, dificuldade dos especialistas em
lembrar de detalhes de como solucionar um problema em particular at que o tenham
feito, dificuldade em prever os problemas que podem ocorrer [LEW 95].
Outra limitao de tais sistemas se relaciona sua fragilidade quando uma
situao nova apresentada. Essa limitao est relacionada falta de habilidade desses
sistemas em adaptar o conhecimento existente para novas situaes e de aprender com a
experincia [LEW 93]. Como aponta Lewis, os seres humanos aumentam claramente
suas habilidades de diagnstico com a experincia [LEW 95]. Sistemas especialistas
tradicionais so, entretanto, difceis de serem projetados para aprender novas solues.
Aqueles sistemas especialistas tradicionais que so desenvolvidos com o cuidado de
tratar de uma situao bem compreendida e relativamente constante, em um domnio que
apresenta poucas surpresas e que o conhecimento necessrio para resolver os problemas
na maior parte rgido e fixo, so bem sucedidos e provem um servio til. Mas, como
comenta Lewis, infelizmente, muito poucas tarefas no gerenciamento das redes de hoje
so assim [LEW 95]p.34. Nas redes de hoje, novas aplicaes e usurios so
introduzidos naturalmente, os componentes so atualizados rotineiramente para insero

60

de novas funcionalidades, novas tecnologias so adicionadas s redes existentes. E essas

evoluo e mudanas nas redes impem uma grande sobrecarga aos gerentes de redes e
aumenta a dificuldade de construir um sistema especialista para auxlio das tarefas de
diagnstico [LEW 95]. Assim, em domnios com rpidas mudanas, como ocorre em
muitas tarefas do gerenciamento de redes, esses sistemas podem acabar por se tornarem
obsoletos rapidamente [LEW 93].
Outro paradigma que pode ser utilizado para o diagnstico de problemas o
raciocnio baseado em modelos, tambm comentado anteriormente. Sua aplicao para o
domnio de gerncia de redes sofre, entretanto, pela dificuldade de modelar uma rede
completa, com suas interaes, em uma aplicao [GOY 91].
Assim, uma abordagem alternativa para sistemas especialistas em gerncia de
redes o raciocnio baseado em casos, apresentado no captulo 2. Esse paradigma traz
benefcios como a capacidade de aprender com a experincia naturalmente com a
utilizao do sistema e evitar a manuteno excessiva [LEW 93].
Quando, porm, utilizado junto a sistemas de registro de problemas, em que a
estrutura de um registro j semelhante de um caso, soma-se a essas vantagens o fato
de tais sistemas j representarem tecnologia consolidada na rea. Isso proporciona uma
utilizao e aprendizado mais natural da aplicao CBR, j que esta se integra s
facilidades colaborativas inerentes aos sistemas de registro aceitos e utilizados
normalmente nos centros de gerncia. Assim, o uso de raciocnio baseado em casos junto
a um sistema de registro de problemas um meio bastante adequado para utilizar o
conhecimento armazenado nestes sistemas.
A partir do estudo dos sistemas de registro apresentado na seo 3.3 e do estudo
de raciocnio baseado em casos comentado no captulo 2, fcil conceber um registro de
problema como um caso, e a base de registros de problemas como a base de casos do
sistema. Portanto, a fim de desenvolver uma aplicao de raciocnio baseado em casos
sobre um sistema de registro de problemas tradicionais, necessrio acrescentar
arquitetura destes sistemas os processos de raciocnio e acrescentar sobre os registros de
problemas as informaes adicionais necessrias para que esses processos possam ser
executados.
Este trabalho apresenta um sistema de raciocnio baseado em casos que foi
desenvolvido a partir da arquitetura e tecnologia de sistemas de registro de problemas,
denominado sistema DUMBO. Neste captulo, abordaremos o processo de aquisio de
conhecimento efetuado para o desenvolvimento deste sistema. No captulo 5,
abordaremos a modelagem do sistema, apresentando como a representao do
conhecimento e os processos de raciocnio foram abordados. Por fim, no captulo 6,
apresentaremos o prottipo do sistema implementado.

4.2 Aquisio do Conhecimento

O processo de aquisio do conhecimento para a modelagem do sistema foi
realizado utilizando-se entrevistas com especialistas, anlise dos registros de problemas
armazenado no sistema de registro de problemas CINEMA [TAR 96][TAR 96a]
desenvolvido e utilizado pelo grupo do centro de gerncia do POP-RS e por anlise
da bibliografia. Essa anlise bibliogrfica compreendeu estudo de referncias tericas e
de situaes problemas relatadas por livros de troubleshooting [MIL 96]

61

[MIL 95][NAS 94], por manuais de troubleshooting de fabricantes de equipamentos de

rede [CIS 97][CIS 97a][CIS 97b][CIS 97c], de casos problemas fornecidos por
fabricantes [CAB 97a][CAB 97b], de referncias tericas de redes de computadores e
gerncia de redes [HUN 98][NEM 95][SIN 96][STA 97] e de projetos de sistemas
especialistas desenvolvidos na rea [NUN 97][HAR 97].
As entrevistas foram realizadas com especialistas do centro de gerncia do POPRS e do centro de gerncia da rede do Instituto de Informtica/UFRGS. O ambiente e
tecnologias das redes gerenciadas por esses centros caracterizam o ambiente para o qual
o modelo foi concebido e onde ser validado redes TCP/IP em ambiente Unix, com
presena de redes Ethernet e de linhas seriais.
Este estudo foi realizado enfocando de modo especial, portanto, ambientes com
as tecnologias presentes nessas redes. Entretanto, ele foi concebido objetivando facilitar
sua adaptao e portabilidade para redes com outras tecnologias, variando a facilidade
desta tarefa de acordo com as caractersticas do ambiente adotado. Assim, existem
algumas novas tecnologias, como tecnologias de hardware e acesso ao meio e novos
tipos de equipamentos de interconexo, que podem ser acrescentadas automaticamente
com o uso do sistema.
Do estudo realizado, foram identificados os tipos de problemas tpicos que
podem ser encontrados em redes TCP/IP. Esses problemas abrangem falhas na
comunicao entre nodos, em aplicaes e nos demais servios fornecidos pelas redes,
podendo se manifestar com a total interrupo do servio ou na qualidade oferecida por
este. O estudo enfocou a identificao dos sintomas gerados pelos diversos problemas,
ambiente e contexto em que podem acontecer e que outros problemas poderiam fornecer
informaes que auxiliassem no diagnstico daqueles problemas.
Na seo a seguir, comentaremos brevemente sobre a atividade de diagnstico de
problemas e apresentaremos algumas situaes de problemas tpicos que podem ser
encontrados nas redes TCP/IP. Para uma anlise mais aprofundada dos problemas
citados, remetemos o leitor bibliografia referenciada anteriormente.

4.3 Problemas Tpicos das Redes Pesquisadas

As tarefas de gerenciamento de falhas so fundamentais para manter um servio
de rede confivel e estvel. Entretanto, os problemas em redes so freqentemente
difceis de serem solucionados. O diagnstico efetivo de problemas requer uma
abordagem metdica do problema, alm de um entendimento de como a rede funciona
incluindo como os dados so roteados atravs da rede entre estaes individuais e
entre os nveis da pilha de protocolos [HUN 98].
Como aponta Craig Hunt, os problemas no so todos iguais e no podem,
portanto, ser abordados da mesma maneira [HUN 98]. Mas o entendimento de qual
problema est ocorrendo a chave para sua soluo. Um problema superficial algumas
vezes enganoso e o problema real pode estar obscurecido por muitos nveis de software.
Assim, uma vez que a natureza real do problema for identificada, a soluo para ele se
torna freqentemente bvia.
O primeiro passo para uma atividade de diagnstico de um problema a
obteno de informaes detalhadas sobre o que est exatamente ocorrendo, a fim de
identificar e eliminar causas potenciais do problema. Exemplos de tais informaes

62

incluem a identificao da aplicao que est com falha, o nome e endereo IP da

estao remota, o nome e endereo IP da estao do usurio (local), as mensagens
informadas [HUN 98]. O correto e amplo entendimento do problema tambm auxilia a
determinar quais testes e dados adicionais sero necessrios para o diagnstico [SIN 96].
Alguns sintomas que devem ser observados no problema corrente so [HUN 98]
[SIN 96]:

O problema ocorre em apenas uma aplicao na estao do usurio? Se for

apenas uma aplicao, a aplicao pode estar mal configurada ou desabilitada
na estao remota.

O problema ocorre somente com uma estao remota, todas as estaes

remotas, ou somente certos grupos de estaes remotas? Se somente uma
estao remota est envolvida, o problema pode facilmente estar nesta
estao. Se todas as estaes esto envolvidas, o problema provavelmente
est no sistema do usurio (particularmente se nenhuma outra estao na sua
rede local est experimentando o mesmo problema). Se somente estaes em
certas sub-redes ou redes externas esto envolvidas, o problema pode estar
relacionado a roteamento.

O problema ocorre em outras estaes da mesma sub-rede? Se ele ocorre

somente na estao do usurio, os testes devem ser concentrados nesta
estao, no cabeamento e nos concentrados aos quais a estao est ligada. Se
ele afeta todos as estaes na sub-rede, a ateno deve ser concentrada no
roteador da sub-rede, no servidor, nos equipamentos de interconexo ao longo
caminho para o servidor ou estao destino.

O problema impede totalmente os servios da rede ou um problema de

performance que est causando atrasos e interrupes?

H algum trfego nos canais de comunicao? Pouco ou nenhum trfego

podem indicar um componente maior com falha. O tipo de trfego inexistente
pode tambm auxiliar na identificao da causa do problema.

H mensagens de erro? As mensagens de erros devem ser observadas com

ateno, pois podem conter informaes importantes para a resoluo da
situao.

Houve modificaes na rede? Muitas falhas em redes ocorrem aps

modificaes ou mudanas na topologia, na configurao, aplicaes e
usurios. Novos componentes inseridos, novas verses de aplicaes e
sistemas de gerenciamento, reconfigurao de componentes de conexo como
roteadores, bridges (pontes) e gateways so exemplos de mudanas que
podem ser relacionadas ao problema.
Existem, ainda, alguns procedimentos que podem auxiliar na correta abordagem
da situao. Entre eles, destacamos [HUN 98]:

Os problemas devem ser trabalhados cuidadosamente, sendo divididos em

partes gerenciveis. Cada parte deve ser testada antes de ser abordada a
prxima. A diviso da rede em segmentos LAN, MAN ou WAN, por

63

exemplo, essencial para tornar um problema gerencivel [SIN 96]. Nessa

abordagem, cada segmento pode ento ser examinado e pode ser excludo ou
identificado como causador do problema raro dois segmentos falharem
simultaneamente [SIN 96][MIL 96].

Devem ser mantidos bons registros de testes que foram executados e seus
resultados. Registros histricos de problemas devem tambm ser mantidos
para ocorrncias que se repetem.
Muitas falhas em redes so diretamente relacionadas aos seus componentes.
Exemplos de componentes que podem estar envolvidos so [SIN 96]:

cabeamento, conectores, concentradores, adaptadores de rede, placas de rede;

pontes, switches, roteadores e gateways;
servidores, estaes de trabalho.
As diversas funes exercidas por estes componentes, assim como os diversos
protocolos associados, so enquadrados nas diversas camadas da Arquitetura
TCP/IP [COM 91] que compem a arquitetura do ambiente. Quando h, por exemplo,
problemas na comunicao de uma estao para outra numa rede, a causa do problema
pode estar em qualquer ponto no caminho da comunicao entre as estaes, podendo
envolver equipamentos que tratam os dados apenas fisicamente, como repetidores e
concentradores; equipamentos que tratam os dados segundo o hardware de rede, como
pontes e placas de rede; equipamentos encarregados do roteamento dos pacotes, como
roteadores; equipamentos que tratam os dados tambm no nvel de aplicao, como
estaes de trabalho e servidores. Esses problemas podem envolver falhas fsicas nos
diversos componentes, como falhas no hardware de placas de rede e cabeamento, e
falhas nas diversos protocolos e softwares envolvidos, como incompatibilidade de
protocolos, roteamento, controle de fluxo, etc., que se enquadram nos diversos nveis do
modelo.
Para permitir a melhor apresentao e anlise dos problemas, iremos abord-los
examinando cada uma das camadas do modelo. Assim, comentaremos brevemente a
seguir cada um dos problemas tpicos e suas caractersticas nas camadas do modelo
TCP/IP [COM 91]: camada interface de rede, camada internet, camada de transporte e
camada de aplicao.

4.3.1 Camada Interface de Rede

A camada interface de rede conecta a estao local ao hardware da rede local,
fazendo a conexo fsica ao cabeamento do sistema, acessando o cabeamento no
momento apropriado e transmitindo os dados em um frame no formato do hardware de
rede [MIL 96]. A configurao do hardware sobre o qual os protocolos TCP/IP podem
operar incluem opes para LAN, MANs e WANs. Como aponta Mark Miller [MIL 96],
a resoluo de problemas de hardware isto , no nvel de Interface de Rede
consome tanto tempo, se no mais, que os problemas nos nveis superiores.
As falhas na camada interface de rede so, juntamente com as falhas na camada
internet, responsveis pelos problemas com a conectividade da rede. O comando ping
exemplo de uma funo que pode ser usada para testar a conexo da rede, permitindo

64

que seja determinado se o diagnstico da falta de conectividade em uma aplicao deve

ser direcionado para a prpria conexo da rede, englobando os nveis inferiores, ou se
deve enfocar a aplicao em que o problema foi detectado, nos nveis superiores.
Na camada interface de rede, o diagnstico pode ser auxiliado, por exemplo, com
a verificao da configurao do estado da interface (comando ifconfig, por exemplo),
que permite identificar interfaces desabilitadas que no puderam ser ativadas por
problemas fsicos na interface. Outras informaes que podem auxiliar nesta etapa so o
nmero de pacotes enviados e recebidos, erros de entrada e de sada e taxa de coliso,
entre outras, que podem ser verificadas, em sistemas Unix, atravs do comando netstat.
Alguns exemplos de problemas que podem ser detectados atravs de comandos como
este so mostrados na tabela abaixo.
TABELA 4.1 - Alguns problemas da camada interface de rede
Causas

Possveis Sintomas

cabeamento partido estado interface up e running mas o sistema

no envia pacotes para a rede (ocorrncia de
interface defeituosa
pacotes na fila da interface).
m conexo fsica, alta taxa de erros de sada e
problemas fsicos na alta taxa de erros de entrada
rede
meio saturado
alta taxa de erros de sada na interface
alta taxa de erros de entrada na interface
alta taxa de colises (Ethernet)
estao local
alta taxa de erros de entrada
saturada

Referncias
[HUN 98]

[HUN 98]

[HUN 98]
[MIL 96]
[HUN 98]

Nos problemas dessa camada, porm, importante enfocar a tecnologia de rede

envolvida, j que a topologia de cada tipo de rede tem seu prprio conjunto de
erros [NAS 94]. O prprio tipo de cabeamento utilizado pode trazer diferentes tipos de
problemas. Apresentaremos, a seguir, alguns exemplos de erros freqentes presentes em
algumas tecnologias de rede, enfocando as redes selecionadas para a validao do
sistema Ethernet, para rede local, e linhas seriais que so as tecnologias de rede
presentes na rede da UFRGS onde o sistema ser validado.
Como na tabela anterior, a primeira coluna de cada uma das tabelas indica
algumas causas de problemas em redes, enquanto a segunda coluna apresenta alguns
possveis sintomas para os problemas. Nem todos os sintomas abordados, entretanto,
ocorrem sempre para os problemas apresentados. Exemplo uma falha em uma placa de
interface de rede, que pode ser responsvel por um grupo de diferentes tipos de
erros [NAS 94]. Maiores informaes sobre cada problema podem ser obtidas nas
referncias correspondentes, indicadas na ltima coluna. Caractersticas adicionais aos
sintomas apresentados que podem auxiliar no diagnstico do problema so a sua
classificao em constante ou intermitente, se componentes ou softwares foram
modificados ou inseridos e a abrangncia do problema na sub-rede e no
segmento [NAS 94].

65

4.3.1.1 Ethernet
As causas de problemas em redes Ethernet incluem problemas de projeto do
cabeamento, configurao do nodo, componentes defeituosos e configurao dos
equipamentos de interconexo envolvidos, que podem atingir apenas um nodo ou todos
os nodos da rede. A tabela a seguir exemplifica alguns destes problemas.
TABELA 4.2 - Alguns problemas tpicos de redes Ethernet
Causas

Possveis Sintomas

Referncias

cabos Ethernet sem

terminao

alta taxa de colises

[CIS 97a]

cabos Ethernet com

comprimento excessivo
nmero excessivo de
repetidores na rede

colises tardias

[CIS 97a]

uso de cabeamento
incorreto: 100BaseT4 com
somente 2 pares de fios
disponveis, erro em
10BaseT, 100BaseT4 e
100BaseTx (por exemplo,
placa de rede diferente da
porta em um hub)

ausncia de integridade no enlace [CIS 97a]

em 10BaseT, 100BaseT4 ou
100BaseTX

incompatibilidade entre
IEEE 802.3 e Ethernet

ausncia de acesso para nodos [MIL 96]

configurados diferentes, estaes
[SIN 96]
recm configuradas

software defeituoso na
placa de rede

taxa
excessiva
de
frames [CIS 97a]
pequenos, sem alta taxa de
colises simultnea

cabeamento defeituoso
associado a um nodo
Ethernet (falhas na placa de
rede, transceiver,
conectores)

ocorrncia de falha em um nico [NAS 94]

nodo Ethernet
[MIL 96]
alta taxa de colises locais
(transceiver, cabeamento)
colises remotas (placa de rede
ou transceiver de segmento
remoto)
pacotes longos e curtos (placa de
rede, transceiver)
jabber (placa de rede, transceiver)
alta taxa de CRC (conectores,
transceiver, placa de rede)

alta taxa de colises

taxa
excessiva
pequenos

de

frames [CIS 97a]

66

Causas

Possveis Sintomas

Referncias

rudo excessivo no meio,

causado por cabeamento
defeituoso, pancadas
espaadas causando
reflexes

muitos erros de CRC com baixa [CIS 97a]

taxa de colises
o tipo de cabeamento utilizado
pode ser relevante para a soluo:
por exemplo, em 100BaseTX,
verificar a utilizao de UTP Cat.
5

porta de repetidor ou hub

com falha

ocorrncia de falha associada a [NAS 94]

uma
porta
especfica
do
equipamento no segmento
especfico, nodos no operam ou
congelam e penduram durante
operao

repetidor ou hub com falha

ocorrncia de falha em mltiplas [NAS 94]

portas ou com toda a rede
Ethernet nodos no operam ou
congelam durante operao
trfego pode no ser transmitido
de um lado para o outro do
equipamento
alta taxa de colises e CRC de
mltiplos nodos da rede

configurao de hardware
ou software de uma ponte
incorreto

nenhum trfego atravessa a ponte [NAS 94]

ou dados so corrompidos
intermitentemente
quando
atravessam o equipamento

configurao de parmetros
que controlam a quantidade
de trfego a ser enviada na
ponte incorretos

trfego excessivo presente em um [NAS 94]

certo segmento
broadcast storms excessivas
vindo da ponte

equipamentos conectados a
um nodo Ethernet (como
modens e impressoras sem
sua prpria placa de rede)
ou nodo Ethernet ao qual
so ligados com hardware
ou software mal
configurados
cabeamento defeituoso
entre o nodo Ethernet e o
equipamento sem placa de
rede

equipamento conectado ao nodo [NAS 94]

Ethernet no pode ser acessado

67

4.3.1.2 Linhas Seriais

As linhas seriais podem apresentar diversas falhas na conexo. A tabela abaixo
apresenta alguns dos problemas que podem ocorrer nestes enlaces. Alm dos sintomas
apresentados, uma caracterstica que pode auxiliar no diagnstico desses incidentes o
estado da interface. Testes de loop local e remoto so tambm ferramentas poderosas
para isolar a origem do problema.
TABELA 4.3 - Alguns problemas tpicos de linhas seriais
Causas

Possveis Sintomas

equipamentos da
companhia telefnica
defeituosos
linha serial com rudo
cabos incorretos ou longos
demais

conectividade intermitente
[CIS 97c]
erros de entrada de CRC,
framming e aborts na transmisso

trfego de entrada na
interface serial excede a
largura de banda disponvel

descartes de
crescente

trfego na entrada excede a

capacidade do roteador
filas de entrada excedem o
tamanho das filas de sada

descartes na entrada em nmero [CIS 97c]

crescente
ocorre, geralmente, quando o
trfego est sendo roteado entre
interfaces rpidas (Ethernet,
FDDI, Token Ring) e interfaces
seriais, e h presena de taxa de
trfego elevada

congestionamento no
enlace

conectividade
intermitente, [CIS 97c]
falhando nos perodos de pico
[CIS 97a]
taxa de erros de entrada baixa
ocorrncia de resets na interface
em nmero crescente

problemas de hardware no
CSU/DSU, ou no enlace

conectividade intermitente
[CIS 97a]
ocorrncia de resets na interface [CIS 97c]
em nmero crescente
alta taxa de erros de entrada

interrupes na linha
causadas por origem
externa (separao fsica do
cabeamento, relmpagos
em algum ponto da rede)

contador das transies

portadora crescente

pacotes keepalive no
sendo recebidos

ausncia de conectividade

sada

Referncias

em

taxa [CIS 97c]

na [CIS 97a]

[CIS 97a]

68

4.3.2 Camada Internet

A camada internet do modelo TCP/IP anloga camada de rede do modelo
OSI, sendo responsvel pela entrega dos dados de sua origem ao seu destino atravs de
uma rede internet. Esta rede pode incluir a Internet, uma rede corporativa ou os meios de
transmisso de LANs e WANs.
Uma das principais funes da camada internet o roteamento. O roteamento
possibilita a conectividade entre duas estaes atravs de uma internet, utilizando o
endereo lgico da estao que a identifica unicamente dentro da internet o endereo
IP. Para isso, so utilizados roteadores que guiam os pacotes ao destino, identificando a
rota apropriada para os pacotes, atravs da comparao das informaes de
endereamento dentro dos pacotes com as informaes que eles possuem sobre a
topologia da rede. As informaes de endereamento da topologia de rede so trocadas
entre os roteadores, atravs de protocolos de roteamento, como o RIP, OSPF, etc.
Associado ao roteamento, esto questes de endereamento, definio de sub-redes e
mscaras [MIL 96], entre outros. Protocolos como ARP/RARP, BOOTP esto tambm
associados camada.
Um protocolo que auxilia o diagnstico de problemas de conectividade o
ICMP. Uma das mensagens desse protocolo a utilizada pelo comando ping, a
mensagem ICMP Echo, que pode ser usada de modo seqencial para isolar um
problema. Outra ferramenta que pode ser tambm utilizada o traceroute, que utiliza
mensagens ICMP para verificar cada sub-rede ao longo de uma rota para uma estao
distante.
Assim, se problemas de conectividade em uma internet no so causados por
problemas no hardware e sua configurao (camada interface de rede), as falhas devem
ser buscadas na camada internet. O processo de identificao de um endereo, atribuio
de endereos, comunicao entre roteadores e notificaes de erros dos roteadores
podem oferecer indcios sobre a causa do problema na entrega dos datagramas [MIL 96].
TABELA 4.4 - Alguns problemas tpicos da camada internet
Causas

Possveis Sintomas

Referncias

rota default no
especificada ou incorreta
gateway default no
especificado ou incorreto
em estao local ou remota

ausncia de conectividade para

estaes remotas
ausncia de conectividade para
estaes de sub-redes remotas
pode haver conectividade para
algumas
sub-redes
remotas,
enquanto para outras no h acesso
rotas so perdidas de uma tabela de
roteamento
estaes em uma rede no podem
acessar estaes em outra

[CIS 97a]

mtricas incorretas
ausncia de conectividade

[MIL 96]

m configurao no
roteador, com comandos
ausentes ou incorretos (tais
como identificador e
endereo IP para uma
interface do roteador)
tabelas de roteamento em
roteadores corrompidas

[CIS 97a]
[CIS 97c]

[CIS 97a]

69

listas de acesso ou outros

filtros mal configurados

conectividade
em
algumas [CIS 97a]
aplicaes ou protocolos, enquanto
[CIS 97c]
outros falham
conectividade para algumas subredes remotas, enquanto outras
falham (com listas de acesso
atingindo
informaes
de
roteamento para algumas rotas,
mas no para outras)
conectividade
para
algumas
estaes remotas, enquanto para
outras h falha
em rede com mltiplas rotas performance ruim, um dos canais [CIS 97c]
de uma sub-rede a outra h
no
parece
conter
trfego.
listas de acesso mal
Caracteriza, na verdade, um
configuradas, que
problema de conectividade
bloqueiam o acesso a uma
das rotas, ou problemas
com balanceamento de
carga
endereos IP duplicados
perda de conexo de uma das [MIL 96]
numa mesma sub-rede
estaes, enquanto uma outra
estao possui acesso
roteador v atualizaes de perda de conexo sbita e [CIS 97c]
roteamento duplicadas em
performance extremamente ruim
duas interfaces, causada
por ponte em paralelo com
roteador, que faz com que
atualizaes e trfego sejam
vistos em ambos os lados
de uma interface
em um roteador que est
trfego no enviado pelo [CIS 97c]
redistribuindo rotas em
roteador que est redistribuindo
diferentes domnios de
rotas em diferentes domnios de
roteamento (tipicamente,
roteamento
RIP e IGRP) h ausncia da
mtrica default, problemas
com a distncia
administrativa default,
ausncia de outros
comandos necessrios
(como redistribute,
distribute-list)

70

mscara da sub-rede
incorreta

pacotes
no
so
roteados
corretamente
dependendo da topologia da rede,
um roteador com mscara incorreta
poderia enviar datagramas para um
estao destino incorreta, para uma
interface incorreta ou descart-los.
uma estao com mscara incorreta
poderia ter, dependendo da
topologia,
retardo
no
estabelecimento de conexo para
estaes de sua prpria sub-rede,
ou poderia no ter conectividade
poderia
haver
ausncia
de
conectividade para estaes em
sub-redes remotas (enquanto, em
certas situaes, outras estaes
poderiam ser acessadas)
em uma nova interface em
ausncia de conectividade na nova
um roteador, h ausncia de
interface
comandos necessrios
configurao do roteador

[CIS 97a]
[CIS 97c]
[MIL 96]

[CIS 97c]

4.3.3 Camada de Transporte

A camada de transporte tem como principal objetivo prover a transferncia
confivel de dados entre processos de diferentes estaes pertencentes ou no mesma
rede [CAR 94]. Essa camada a responsvel por garantir que os dados sejam entregues
livres de erro e em seqncia, sem perdas ou duplicao, liberando as camadas
superiores da arquitetura TCP/IP da tarefa de gerenciar a infra-estrutura de comunicao
utilizadas pelas aplicaes.
A camada de transporte da Arquitetura TCP/IP possui dois tipos de protocolos:
o protocolo TCP (Transmission Control Protocol), que garante a transferncia confivel
dos dados, e o UDP (User Datagram Protocol), que considerado uma simples
extenso do protocolo IP da camada Internet e que no oferece garantia de entrega de
dados. A utilizao do protocolo TCP ou UDP depende das necessidades da aplicao,
tais como qualidade de servio, throughput, tipo de dados [CAR 94].
Para o diagnstico de problemas ocorridos na conectividade fim-a-fim (ou hostto-host), o primeiro passo consiste em determinar qual o protocolo de transporte
utilizado. Se o protocolo for o UDP, deve ser verificado se o servio sem conexo
adequado para a aplicao, e, se for, ento problemas como mltiplas retransmisses
devem ser resultantes dos protocolos da camada superior condizentes com o mecanismo
de transporte. Se o protocolo utilizado for o TCP, o diagnstico mais complexo. Alm
de verificar o nmero da porta de servio, eventos significativos na conexo TCP devem
ser analisados, tais como o mecanismo three-way handshake e o encerramento da
conexo [MIL 96].

71

Enfim, de modo geral, deve ser determinado se os dados transmitidos esto

atingindo o seu destino. Se no estiverem, problemas na camada internet devem ser
analisados. Se estiverem, o problema pode ser atribudo para a camada de transporte.
Um analisador de protocolos pode tambm auxiliar nesse processo com a anlise dos
cabealhos TCP e UDP. A seguir, apresentamos alguns exemplos de problemas que
podem ocorrer na camada de transporte, ou que podem ser aparentemente atribudos a
camada de transporte.
TABELA 4.5 - Alguns exemplos de problemas na camada de transporte
Causas

Possveis Sintomas

condio half-open TCP ausncia de resposta na aplicao

connection e reset da
conexo
devido
a interrupo da conexo TCP
problemas intermitentes da
comunicao (causa real
nas camadas inferiores, por
exemplo, placa de rede com
falhas intermitentes)

Referncias
[MIL 96]

mdulo
TCP
de falha sbita em aplicao com [MIL 96]
equipamento incorreto, que
grande transferncia de dados
interpreta delay solicitado
por equipamento remoto interrupo sbita da conexo TCP
como fim da conexo
buffers de entrada e sada estaes comunicam com outras no [MIL 96]
com tamanho inadequado e
mesmo segmento sem problema,
com parmetro limiar de
enquanto a comunicao com
descartes (nmero mximo
estaes em segmentos remotos
de frames que podem ser
ocorre com delays excessivos e
armazenados
na
fila)
interrupes em sesses FTP
inferior ao necessrio em
equipamentos
de fim abrupto da conexo em
conexes FTP
interconexo entre estaes
(por exemplo, em pontes)

4.3.4 Camada de Aplicao

A camada de aplicao situa-se no topo da Arquitetura TCP/IP. Diferente das
demais camadas, que so transparentes para os usurios, a camada de aplicao
acessada pelos usurios diretamente via sistema operacional da estao [MIL 96].
Aplicaes padronizadas da Arquitetura TCP/IP incluem correio eletrnico
(implementado atravs do protocolo SMTP - Simple Mail Transfer Protocol), FTP (File
Transfer Protocol), TELNET (Terminal Virtual), NFS (Network File System), DNS
(Domain Name System) e SNMP (Simple Network Management Protocol) [CAR 94].
O diagnstico de problemas na camada de aplicao comea com a verificao
das funes de conectividade fim-a-fim, que devem estar transmitindo os dados para o
destino solicitado; se no estiverem, falhas nas camadas inferiores camada de aplicao

72

devem ser consideradas. Se, entretanto, os dados esto atingindo o destino, ento
problemas na camada superior podem existir [MIL 96].
Uma questo que deve ser lembrada que os dados recebidos no so,
necessariamente, interpretados corretamente (por exemplo, se um terminal est
transmitindo caracteres ASCII e o outro est esperando caracteres EBCDIC). Assim,
uma questo a ser analisada se a aplicao est sendo utilizada adequadamente. Outra
possibilidade que os dois processos de aplicaes no estejam aptos a comunicarem
devido a diferenas de implementao internas [MIL 96].
A seguir, apresentamos alguns exemplos de problemas na camada de aplicao.
TABELA 4.6 - Alguns exemplos de problemas na camada de aplicao
Causas

Possveis Sintomas

Referncias

utilizado um modo de transferncia de dados com erro, [MIL 96]

com
arquivo
transferido
transferncia de dados
corrompido
incorreto em FTP ou TFTP
erro de configurao na uma estao pode enviar e-mails [MIL 96]
estao de trabalho, tais
corretamente para outra (com
como erro no nome do
configurao incorreta), que no
servidor
consegue,
entretanto,
enviar
resposta para a estao original
incompatibilidade
entre interrupo da
formatos do tipo de
estabelecida
terminal em TELNET

conexo

sendo [MIL 96]

alguns registros sendo servidores de nomes secundrios [HUN 98]

recuperados do servidor de
no podem resolver um hostname
nomes
primrio
pelos
do domnio em que seu servidor
secundrios
esto
um secundrio. O nome resolvido
corrompidos, devido a
pelo servidor primrio.
problemas na configurao
do servidor primrio

4.4 Consideraes sobre os Problemas do Domnio

Como pode ser visto pela relao de problemas citados, o domnio de gerncia de
redes mesmo considerando a limitao para o ambiente de redes TCP/IP possui
uma ampla gama de problemas possveis de serem encontrados. Algumas dessas falhas
so facilmente diagnosticadas e solucionadas, outras podem envolver uma srie de aes
at a correta compreenso do problema, cujos sintomas podem muitas vezes estar
mascarando a problema real e apontando para um outro tipo de problema.
Os problemas podem atingir a prpria conexo da rede, com interrupo ou m
qualidade do acesso a nodos ou sub-redes remotas, ou podem atingir as aplicaes ou
servios da rede que utilizam a conexo rede proporcionada pelas camadas inferiores.
Alm disso, podem ser identificados problemas no trfego presentes nos canais de

73

comunicao da rede, mesmo que ainda no tenham ocasionado problemas na conexo

perceptveis aos usurios em geral.
Assim, atravs do estudo dos problemas realizados, os problemas do domnio
foram caracterizados como problemas de conectividade, performance da comunicao
e alto trfego nos canais, para os problemas na conexo das redes, alm dos problemas
de aplicaes e servios, sendo identificados de modo especial trs servios: resoluo
de nomes, autenticao de usurios e servidor de arquivos. Em virtude das diferentes
situaes de problemas de conectividade, foram ainda reconhecidos dois subtipos
distintos: problemas de conectividade fsicos e de configurao do hardware
(englobando os problemas na camada interface de rede) e problemas de endereamento
e roteamento (englobando as funes na camada internet).
Esses problemas no so mutuamente exclusivos: alguns problemas que ocorrem
nas redes podem ser detectados como fazendo parte de mais de um dos tipos
apresentados. Exemplo disso seria uma situao de conectividade intermitente, que
poderia ser detectada como uma situao de alto tempo de resposta ou interrupo da
comunicao (performance), e que poderia apresentar ainda alto trfego nos canais.
Modos de diviso dos problemas em tipos que no sejam relacionados e que possam ser
identificados na viso dos problemas disponvel aos usurios no foram identificados.
Alm disso, as falhas reais podem estar mascaradas como outros tipos de
problemas. Exemplos so uma ocorrncia de performance ruim ou alto trfego num
canal causada pela interrupo de um canal de comunicao paralelo, problemas com um
servio de autenticao causado por falhas na resoluo de nomes, problemas em uma
aplicao ou servio causada por falhas na conectividade.
Assim, como um problema pode ser enquadrado e informado em diferentes tipos,
meios de relacionar estes problemas em sistemas so necessrios, a fim de que uma
situao vista de diferentes formas possa ser tratada corretamente. Os procedimentos
concebidos para esse tratamento no sistema DUMBO sero apresentados no captulo a
seguir.
O estudo dos problemas permitiu, tambm, a identificao de informaes
relevantes para o diagnstico de uma situao: algumas esto presentes em todos os
incidentes enfrentados, tais como a abrangncia do problema e sua localizao; outras
esto presentes em apenas um conjunto de incidentes, tais como a aplicao sendo
utilizada, a tecnologia de rede, os protocolos envolvidos. Existem outras, ainda, que
esto presentes apenas em casos particulares, como o uso de um determinado protocolo
ou tecnologia na rede gerenciada, o resultado de um teste em particular, etc. Portanto,
para a utilizao destas informaes na recuperao de situaes similares anteriores, a
identificao de uma listagem dessas informaes necessria, assim como meios de
organiz-la e compar-la.
Apresentaremos, a seguir, o modelo proposto para o uso de raciocnio baseado
em casos integrado a um sistema de registro de problemas. Enfocaremos, como j foi
comentado, o ambiente de redes TCP/IP com sistemas Unix.

74

5 Sistema DUMBO: Modelagem

Como foi abordado no captulo anterior, o conhecimento armazenado nos
sistemas de registro de problemas pode ser reutilizado aplicando-se sobre ele tcnicas de
raciocnio baseado em casos. Desta forma, s funes dos sistemas de registro
tradicionais tais como manter a listagem dos problemas correntes do centro de
gerncia, enviar mensagens aos especialistas envolvidos, permitir a anlise estatstica da
produtividade do domnio so agregadas facilidades que auxiliam a resoluo dos
problemas correntes na insero de um novo registro, atravs da recuperao de
situaes similares anteriores.
A fim de se tornarem amigveis, esses sistemas devem manter a estrutura
utilizada nos sistemas de registro de problemas tradicionais j consolidada em centros
de gerncia, sendo nela adicionados os demais procedimentos de raciocnio baseado em
casos. Assim, na insero de um novo registro, alm das informaes tradicionais
solicitadas aos usurios tais como a prioridade do problema, quem o relatou e o
responsvel , o sistema deve obter as informaes adicionais necessrias para o
processo de recuperao tais como detalhes dos sintomas identificados e do ambiente
em que o problema ocorreu. Com essas informaes, mecanismos de raciocnio inseridos
no sistema selecionam os registros das situaes similares ocorridas no passado que
podem contribuir para a soluo do problema enfrentado e apresentam-nos ao usurio.
Procedimentos adicionais responsveis pelo aprendizado do caso ocorrido e j
solucionado devem tambm ser acrescidos ao processo de encerramento de um problema
dos sistemas tradicionais.
Este captulo discorre sobre o modelo concebido para o sistema DUMBO. A
representao do conhecimento, os procedimentos de raciocnio utilizados e a base de
conhecimento do sistema so apresentados.

5.1 Sistema DUMBO - Uma Viso Geral das Tcnicas Adotadas

Como foi visto, o uso de CBR em um sistema de registro de problemas exige
mecanismos para decidir quais informaes sobre o problema devem ser obtidas, quais
procedimentos para recuperar registros similares armazenados devem ser utilizados e
quais instrumentos para aprender um novo caso podem ser usados.
Inicialmente, necessrio preparar o registro para o diagnstico, sendo obtidas
informaes acerca da situao incluindo sintomas identificados (problema
encontrado, taxa de erros da rede, abrangncia do problema, equipamentos e redes
afetadas, etc.) e ambiente da rede afetada (topologia da rede, protocolos utilizados, etc.),
alm das demais informaes j utilizadas nos sistemas de registro de problemas
tradicionais (apresentadas na seo 3.3). As informaes acerca de um problema podem
ser obtidas atravs de mtodos automticos diretamente da rede, de informaes
cadastradas, de uma plataforma de gerncia associada ou diretamente do usurio.
Uma importante deciso nessa etapa a definio da linguagem a ser utilizada
nos registros. Como apontam Lewis e Dreo [LEW 93a], a linguagem utilizada deve
levar em considerao que existem diferentes modos de expressar um problema. Isso visa
evitar que duas descries expressando de diferentes modos o mesmo problema no
sejam relacionadas, como, por exemplo, com mltiplos registros dizendo em diferentes

75

palavras FTP no possibilitado. Assim, para propsitos prticos, uma descrio em

linguagem natural deve ser evitada, devendo ser utilizada uma linguagem descritiva
formal, bem estruturada [LEW 93a][LEW 95][LEW 93]. Podem ser utilizados para isto
menus em cascata ou campos independentes para informaes, tais como problema,
equipamento [LEW 93], etc., sendo utilizado um campo adicional, em texto livre, para
outras informaes relevantes [LEW 95].
possvel, porm, utilizar de modo complementar a breve descrio do
problema, presente nos sistemas de registro tradicionais, para o clculo da similaridade
do caso. Essa utilizao j feita em algumas aplicaes CBR, seja auxiliando numa
busca inicial para recuperar alguns casos e as caractersticas relevantes destes [ACO 92],
seja auxiliando na recuperao principal [RAM 95][CHA 96]. Para isso, a descrio do
caso corrente passa por um tratamento em que os principais termos so selecionados e
feito um casamento desses termos com as descries dos casos armazenados
[ACO 92][CHA 96]. Neste trabalho, considerada tambm, de modo complementar s
demais caractersticas, a similaridade das descries no clculo da similaridade entre
casos, utilizando uma abordagem anloga utilizada em [CHA 96].
O gerenciamento em redes de computadores envolve, entretanto, a anlise e
resoluo de uma ampla variedade de problemas. Os problemas podem abranger tanto
falhas nas camadas inferiores do modelo TCP/IP, englobando desde problemas fsicos
nos meios e equipamentos de transmisso at problemas de roteamento de pacotes,
como podem envolver problemas em aplicaes e nos servios oferecidos pela
rede [MIL 96] [NAS 94][CIS 97][HUN 98][TAR 96]. No basta, portanto, para
diagnosticar uma ocorrncia, obter informaes que sejam referentes a todos os
problemas que podem ser encontrados em gerenciamento. Embora algumas informaes
digam respeito a todos os tipos de ocorrncias, outras referem-se e so relevantes apenas
para um determinado grupo ou tipo de problema, e devem ser elaboradas para que
ocorrncias similares possam ser recuperadas.
Lewis aponta que, para o desenvolvimento de um sistema CBR de registro de
problemas de redes, deve ser elaborada uma lista dos principais tipos de problemas, a
qual deve ser implementada no registro como um campo com uma lista de termos
fixa [LEW 95]. Tipos de problemas no previstos deveriam ser tambm permitidos,
devendo nesse caso o usurio informar o novo tipo de problema da situao corrente.
Essa informao (tipo de problema), que representa o principal sintoma, j solicitada
em alguns sistemas de registro de problemas tradicionais, a exemplo do ambiente
CINEMA [TAR 96], embora nesses sistemas a identificao dos problemas no necessite
ser to completa.
Uma vez que os tipos de incidentes provveis para o domnio so identificados,
para cada tipo de problema devem ser analisadas quais informaes adicionais
contribuiriam para determinar a soluo da situao, e as informaes relevantes devem
ser obtidas [LEW 95]. Estas questes, assim como os meios de obteno destas
informaes sero discutidos nas sees 5.4.1 e 5.5.1.
Esta abordagem apresenta, entretanto, algumas dificuldades, especialmente
quando aplicada a sistemas de registro de problemas que no estejam ligados a uma
estrutura de gerenciamento de falhas, e, por conseguinte, a criao de registros no seja
feita de maneira automtica, mas sim diretamente pelo usurio. Uma estrutura de
gerenciamento de falhas (tal como a apresentada anteriormente na figura 3.8, por

76

exemplo) pode integrar diversos componentes, incluindo uma plataforma de

gerenciamento de redes, um gerador automtico de registros de problemas e um sistema
de registro de problemas [LEW 95]. Nesse contexto, os registros presentes no sistema
de registro podem ser criados pelo gerador automtico de registros, a partir dos alarmes
detectados na rede pela plataforma de gerncia. Estes registros so criados pelo sistema
aps a aplicao de filtros de alarmes, que evitam mltiplas ocorrncias relacionadas a
um mesmo problema (como, por exemplo, quando se evita a criao de mltiplos
registros para um mesmo problema intermitente) [LEW 95].
Essa criao automtica acarreta algumas caractersticas nestes registros, que
apresentaro uma certa padronizao, j que so reflexos da configurao da plataforma
geradora dos alarmes e do gerador automtico de registros. Assim, incidentes similares
sero provavelmente detectados de modo similar e daro origem a registros tambm
similares, com tipo de problema similar. Alm disso, a plataforma muito provavelmente
identificar um problema j no seu ponto de origem por exemplo, comunicar de
imediato que um determinado enlace apresenta falha na comunicao, e no que a
comunicao entre duas estaes que possuem este enlace entre elas est interrompida.
Assim, a comparao da similaridade entre dois registros gerados automaticamente
mais simplificada, apresentando menos variaes que os registros informados por
especialistas humanos.
No presente trabalho se pretende, porm, atender problemas informados por
especialistas humanos, e no gerados automaticamente. Como comentado anteriormente,
foi utilizado neste trabalho uma estrutura baseada no sistema de registro de problemas
CINEMA, desenvolvido e utilizado pelo grupo no centro de gerncia do POP-RS,
acrescida das modificaes necessrias para a implantao do raciocnio baseado em
casos. Tambm o CINEMA [TAR 96] trata principalmente de registros criados
manualmente por usurios. Assim, mecanismos adicionais para assegurar a identificao
da similaridade entre casos desejvel. Neste trabalho, foram, ento, definidos alguns
mecanismos para tratamento destas questes.
Em primeiro lugar, como j foi comentado, utilizada uma linguagem
estruturada para com o usurio, e um mecanismo desenvolvido para clculo da
similaridade da descrio em texto livre implementado para que esta descrio
contribua tambm para a similaridade. Mas, alm disso, foi tambm identificada a
necessidade de realizar algum tratamento sobre o tipo de problema a ser consultado.
O tipo de problema um dos principais ndices para a recuperao dos casos
ele funciona como um filtro para os casos recuperados, impondo uma hierarquia virtual
na base de casos onde s os casos dos tipos desejados so consultados. O estudo
efetuado sobre os problemas em redes e a anlise dos registros cadastrados no sistema
estudado (CINEMA) demonstraram, porm, que os problemas em redes so algumas
vezes extremamente complexos, e uma ocorrncia que detectada inicialmente como de
um tipo pode ser causada, na realidade, por um outro tipo de problema correlato. Isso
causa, assim, algumas dificuldades. Dependendo do estgio de desenvolvimento da
situao quando o registro foi criado, este pode ser informado como de diferentes tipos,
o que impediria a sua recuperao na base de um caso semelhante cadastrado em etapas
diferentes. Alm disso, foi percebido que um mesmo problema pode levar a falhas em
diferentes nveis e aplicaes, e, mais uma vez, problemas com a mesma falha poderiam
no ser recuperados como similares. Esta situao agravada ainda pelo sistema

77

proposto ser baseado na criao manual de registros, que traz uma maior variao entre
os registros criados.
Para minimizar essa situao, percebeu-se a necessidade de relacionar no apenas
o tipo de problema usado na criao, mas de considerar, tambm, o tipo de problema
identificado aps o encerramento do problema, alm de desenvolver um mecanismo de
tratamento para essa caracterstica. O mecanismo proposto efetua ento, para cada caso,
um tratamento para identificar outros tipos de problemas relacionados e provveis
causadores. Este tratamento faz uso de uma relao histrica entre os tipos de problemas
cadastrados inicialmente e o tipo de problema real causador indicado na soluo, alm de
utilizar informaes especficas da descrio do problema, que podem redirecionar de um
tipo de problema para outro. Este mecanismo apresentado na seo 5.5.1.2.
Na etapa seguinte, em posse das caractersticas da situao e dos provveis tipos
de problema, realizada uma busca na biblioteca de casos, e os casos recuperados so
classificados de acordo com o seu grau de similaridade com o caso corrente. Essa
classificao foi elaborada levando-se em conta que se percebeu que as informaes dos
diversos problemas possuem um grau de relevncia diferente para a identificao da
similaridade entre eles.
Presente em diversas reas em que os sistemas CBR so aplicados, essa
particularidade pode ser tratada atribuindo-se diferentes pesos para cada caracterstica no
clculo da similaridade [KOL 93][WAT 97] ou separando caractersticas que so
essenciais para um problema de outras que podem contribuir para este, mas no so
obrigatrias, tal como em [KOP 88]. Na abordagem proposta pelo presente trabalho,
sero consideradas caractersticas essenciais algumas informaes tais como a
representada pelos provveis tipo de problema , que so usadas como ndices para a
recuperao inicial na base, enquanto as demais recebero diferentes graus de
importncia, sendo representadas por um peso diferente no algoritmo para clculo da
similaridade entre dois casos. Este tpico ser visto no item 5.5.2.2.
Uma vez que os casos recuperados so classificados, os melhores casos so
apresentados ao usurio, ou o usurio pode solicitar um processo de refino. Esse
processo foi incorporado ao sistema porque o estudo efetuado sobre os incidentes do
domnio demonstrou que algumas caractersticas extremamente importantes acerca dos
problemas no fazem parte do conjunto de caratersticas de um tipo de problema que
serve a todos os problemas desse tipo, porm esto presentes em diversos casos desse
tipo, formando um subgrupo dentro do tipo.
Assim, optou-se por uma abordagem que se baseia no contedo dos casos
recuperados para obter caractersticas mais discriminantes para a nova situao. Cada
caso pode conter uma ou mais informaes relevantes para o problema em particular,
denominadas caractersticas especficas. Quando feita a recuperao, as caractersticas
especficas dos casos selecionados so solicitadas ao usurio e utilizadas posteriormente
para o refino da recuperao, podendo modificar a ordem de casamento, selecionar
novos casos ou eliminar casos j selecionados.
Essas caractersticas permitem que aes de diagnstico atividades essenciais
para a identificao da soluo em problemas de gerenciamento de redes sejam
propostas pelo sistema e que seus resultados sejam utilizados para a recuperao. Outra
contribuio dessa abordagem o aumento do conhecimento do sistema, j que permite
que, no momento de encerramento de um registro que ser aprendido, caractersticas

78

especficas sejam informadas, seja selecionando-as entre as j cadastradas, seja

cadastrando uma nova caracterstica, e permitindo, assim, que um problema com facetas
diferentes dos j armazenados seja aprendido adequadamente pelo sistema. Este
processo ser comentado na seo 5.5.3.
Os tpicos aqui comentados permitiram uma viso geral da modelagem de
raciocnio utilizada no sistema proposto neste trabalho sistema DUMBO.
Apresentaremos, a seguir, a representao dos problemas, utilizando como formalismo
redes semnticas. Nas sees posteriores abordaremos os processos de raciocnio
utilizados e a base de conhecimento, que foram comentados brevemente nesta seo.

5.2 Representao dos Tipos de Problemas

Existem diversas formas de representar o conhecimento quando se utiliza um
sistema especialista, tais como redes semnticas, sistemas de produo, frames
[STE 95][TUR 92]. A representao por redes semnticas uma forma grfica de
representar o conhecimento, composta por nodos e arcos, sendo basicamente uma
descrio grfica do conhecimento que mostra relaes hierrquicas entre objetos. Uma
das caractersticas mais interessantes e teis das redes semnticas sua capacidade de
mostrar herana. Assim, uma idia comum em tais representaes que as informaes
gerais devem ser armazenadas o mais alto na hierarquia em que for aplicvel e herdadas
pelos nodos abaixo durante o processo [STE 95].
A representao por redes semnticas foi utilizada neste trabalho para permitir a
visualizao dos atributos e da hierarquia dos tipos de problemas identificados para o
ambiente de redes, atravs da aquisio do conhecimento, e que so utilizados no
sistema, permitindo identificar quais as informaes o sistema considera relevantes no
tratamento de uma situao. Estas informaes, como pode ser visto pelas figuras,
variam conforme os principais sintomas e o contexto da rede em que o problema se
desenvolve, e representam sintomas que podem ser encontrados nas situaes, topologia
da rede, etc. Em virtude da complexidade e ampla gama de problemas encontrados,
optou-se por dar uma nfase maior para as falhas na comunicao, realizando um
tratamento mais simplificado nas falhas dos nveis superiores.
Inicialmente, na figura 5.1, apresentada a viso global dos tipos de problemas,
que podem ser problemas na comunicao e problemas nas camadas superiores. Nesta
figura e na figura 5.2, os tipos de problemas, seus atributos e valores que podem assumir
so indicados. Como pode ser visto, um dos atributos dos problemas de comunicao a
localizao do problema, que pode ser entre uma mesma sub-rede IP, entre outras subredes IP, em uma linha serial, etc. (figura 5.3). Essas especializaes conduzem a
diversos outros atributos especficos para a localizao do problema em questo, que so
apresentados no anexo 1.
Nessa rede, nem todas as especializaes de um atributo herdado so
obrigatoriamente
assumidas
em
uma
situao.
Um
problema
de
roteamento/endereamento, por exemplo, no assumir a especializao canal de
comunicao de uma LAN para a localizao do problema. Da mesma forma, o atributo
interface de rede tambm no ser relevante para esta situao. Alm disso, existem
atributos que podem ser, em algumas situaes, relacionados a outros da hierarquia
superior de modo que podem ser identificados automaticamente, recebendo o mesmo
valor do outro atributo. Um exemplo quando um problema de conectividade para uma

79

outra sub-rede IP aponta que o primeiro roteador na rota para esta sub-rede j no
atingido neste caso, a abrangncia do problema da sub-rede afetada ter o mesmo
valor que a abrangncia do problema na sub-rede origem, pois a sub-rede afetada a
prpria sub-rede origem.
mensagem
erro
_caracterizado_por
houve
alterao
_caracterizado_por
provveis
causas

tipo problema
_caracterizado_por
_um

_um

problemas nas
camadas
superiores

problemas na
comunicao

_caracterizado_por
problemas na
comunicao

localizao do
problema

_um

_um
_um

conectividade
genrico

_um

_um

alto trfego
conectividade fsico
e config/HW

roteamento /
endereamento

performance

problemas nas
camadas
superiores

_um

_um
_um

_um

_um

aplicao
servios
resoluo de nomes

outros
servios
autenticao

servios
servidor arquivos

FIGURA 5.1 - Rede semntica dos tipos de problemas

80

falta de acesso

falta de acesso
_caracterizado_por

_caracterizado_por
conectividade
genrico

_caracterizado_por

_caracterizado_por

modo de falta
de acesso

roteamento
endereamento

_caracterizado_por

_caracterizado_por

problema
mantm usando
IP

modo de falta
de acesso

problema
mantm usando
IP

falta de acesso
conectividade fsico
e config HW
_caracterizado_por

ocorrncia de
alta taxa de
erros
_caracterizado_por
ocorrncia de
alto tempo de
resposta

ocorrncia de
alta taxa de
erros

_caracterizado_por
performance
_caracterizado_por
_caracterizado_por

ocorrncia de
alto trfego

performance
ruim como

_caracterizado_por

_caracterizado_por

ocorrncia de
alto tempo de
resposta
falta de acesso

alto trfego

_caracterizado_por

_caracterizado_por
falta de acesso
_caracterizado_por

qual tipo de
trfego com
taxa elevada

ocorrncia de
alta taxa de
erros
_um

no h alta
taxa de erros

_um

h alta taxa de
erros

_caracterizado_por

quais tipos de
erros

ocorrncia de
alto tempo de
resposta
_um
no h alto
tempo de
resposta

_um

h alto tempo
de resposta

em que h alto
tempo de
_caracterizado_por
resposta

FIGURA 5.2 - Rede semntica dos tipos de problemas (parte 2)

81

localizao do
problema

_um

_um
_um

_um

_um

linha serial
entre mesma
sub-rede IP

canal de diversas
sub-redes IP
entre sub-redes IP

canal de uma LAN

FIGURA 5.3 - Rede semntica da localizao dos problemas

5.3 Estrutura do Sistema

O sistema DUMBO foi estruturado de modo a manter as funes dos sistemas de
registro de problemas tradicionais, inserindo os procedimentos de raciocnio na etapa de
criao de um registro, de encerramento de um registro e na criao de notas. A
estrutura do processo de raciocnio pode ser visto na figura a seguir.
No momento de criao de um registro, o mdulo avaliador da situao definio do contexto ativado e o responsvel pela obteno das informaes
referentes descrio do problema. O tipo de problema informado utilizado ento para
identificar as informaes adicionais que devem ser obtidas. Em alguns problemas,
situao anloga ocorre para a localizao do problema. As informaes que puderem
ser obtidas de modo automtico so processadas, enquanto que as demais so solicitadas
ao usurio.
O mdulo efetua o tratamento sobre o tipo de problema, identificando os demais
tipos de problemas relacionados segundo a experincia do sistema e fazendo uso das
regras redirecionadoras, que so aplicadas sobre algumas caractersticas, para verificar
se um outro tipo de problema deve tambm ser consultado e se as probabilidades de cada
tipo de problema devem ser alteradas. Essas regras constituem regras simples, aplicadas
sobre algumas caractersticas pr-definidas que contribuem para isolar o tipo de
problema.
O registro de problema/caso ento conduzido ao mdulo recuperador inicial,
que recupera na biblioteca os casos cujo tipo corresponda a algum dos tipos de
problemas selecionados para busca os tipos de problema avaliados como provveis
pelo mdulo anterior. Em alguns tipos de problema, filtros podem ser tambm aplicados.
Os casos recuperados so classificados pelo mdulo seletor segundo as suas
caractersticas, utilizando para o clculo da similaridade entre os casos o grau de
relevncia de cada caracterstica, que influenciado pelo tipo de problema final do caso
recuperado, e os melhores casos so selecionados e apresentados ao usurio.
O usurio pode aceitar diretamente esses casos ou solicitar um processo de refino
da recuperao. Para isso, informa todas ou algumas das caractersticas especficas
solicitadas, que foram recuperadas pelo mdulo reutilizador-revisor dos casos
recuperados, e o processo de recuperao reiniciado utilizando agora tambm as
caractersticas especficas.

82

Situaes em que o sistema no foi capaz de propor casos similares so

aprendidas pelo sistema no momento de encerramento do registro, a fim de que o
conhecimento adquirido pelo grupo na experincia possa ser utilizado novamente. Nas
demais situaes, o caso armazenado apenas com fins de gerenciamento. Esses
procedimentos so controlados pelo mdulo aprendiz.
Avaliador
da Situao Definio do
Contexto
descrio do problema
informao das caractersticas
relevantes situao

Criao Registro

- consulta das caractersticas adicionais

por tipo_de_problema
- relao histrica entre tipos de
problema
- caractersticas redirecionadoras

Recuperador
Recuperador
Inicial

ndices/filtro do
problema
Interface
Usurio

Seletor

ndices/relevncia
do problema

adaptao baseada em crtica

avaliao do problema
reviso do problema quando
necessrio

Encerramento Registro

Reutilizador
Revisor

insero similaridades
definio ndices especiais problema
definio de novo caso

- insero similaridades
- alterao relao % tipo de
problemas
Aprendiz

FIGURA 5.4 - Estrutura do sistema proposto

Essa seqncia de processos no precisa ser efetuada ao mesmo tempo pelo
usurio a estrutura apresentada diz respeito seqncia de raciocnio do sistema, e
no necessariamente o desenvolvimento do problema e seu registro seguiro essa mesma
seqncia de etapas diretamente (criao do registro, visualizao dos similares,
reutilizao de uma soluo proposta com sucesso e encerramento do registro). Aps a
recuperao dos casos, quando solues so oferecidas, atravs dos casos, e atividades
de diagnstico so sugeridas, atravs destes e das caractersticas especficas, o usurio
pode interromper o processo, a fim de realizar alguma atividade de diagnstico ou testar
alguma soluo proposta. Aps esse perodo, pode fornecer novas informaes e
solicitar a recuperao de novos casos, pode inserir uma nota ao registro ou pode
encerrar o registro, caso a soluo proposta tenha surtido o efeito desejado.

83

Ao inserir uma nota, os casos recuperados a partir das informaes j disponveis

sobre o problema so fornecidos ao usurio, assim como as caractersticas especficas
so solicitadas, e o processo de recuperao pode ser reiniciado.
A seguir, apresentamos cada um dos componentes da estrutura: a base de
conhecimento e os processos envolvidos no raciocnio.

5.4 Base de Conhecimento

Conforme comentado no captulo 2, a base de conhecimento de um sistema CBR
responsvel por armazenar os seus casos. Diz respeito a ela, portanto, decidir o que
armazenar em um caso, qual a estrutura apropriada para descrever o contedo dos casos
e como organizar e indexar a base de casos para que os processos de recuperao e
reutilizao se tornem eficientes [AAM 94]. Uma questo adicional envolve a deciso de
como integrar a estrutura da base de casos em um modelo de conhecimento geral do
domnio, de modo que este conhecimento seja incorporado.
Comentaremos, a seguir, a representao dos casos, a organizao da base e o
conhecimento geral do domnio do modelo proposto.

5.4.1 Representao dos Casos

A partir das discusses acerca de sistemas de registro de problemas, apresentadas
na seo 3.3, e de representao dos casos, comentadas na seo 2.4.1, torna-se simples
relacionar um registro de problema como um caso. Resta, assim, determinar quais
informaes adicionais so necessrias para transformar um registro de problema em um
caso que possa ser utilizado de modo eficiente nos processos de acesso base de casos.
Antes disso, porm, necessrio avaliarmos como ser a linguagem de um caso,
a fim de determinar as transformaes da linguagem do registro muitas vezes uma
linguagem em texto livre, sem restries para a linguagem de um caso. Conforme
aponta Lewis [LEW 95], quanto mais liberal se na definio da linguagem para
descrever as experincias nos problemas das redes, mais provvel se de ser mal
interpretada a natureza do problema. Assim, a melhor abordagem impor restries para
a linguagem do caso de modo que o usurio deva ser preciso sobre a experincia
representada no caso.
Deve-se cuidar, entretanto, para que a linguagem no se torne excessivamente
precisa e restritiva, de modo que no existam formas de expressar pedaos importantes
de informao na linguagem. Assim, necessrio estabelecer inicialmente um meio termo
entre uma linguagem sem restries e outra excessivamente restrita, e fornecer modos
para que a linguagem evolua a partir de novas experincias.
Neste trabalho, a fim de minimizar os problemas que envolvem as linguagens
estruturadas necessrias para o melhor entendimento da natureza do problema ser
usado um campo para descrio em texto livre, que ser utilizado de modo
complementar para o clculo da similaridade entre os casos, e se possibilitar que novas
caractersticas sejam inseridas, atravs das caractersticas especficas, permitindo uma
flexibilizao da linguagem. Estes tpicos sero abordados novamente em sees
subseqentes. Resta agora definir as modificaes de um registro tradicional para um

84

caso, a fim de que os diversos processos envolvidos no raciocnio possam ser

incorporados de modo eficiente no sistema.
Como apresentado no captulo 2, em um caso de um sistema CBR, a descrio
de um caso representa as informaes acerca do problema e do ambiente este ocorreu.
Os componentes que fazem parte dela so os objetivos a que o caso se prope, as
restries associadas a obteno do objetivo e as caractersticas da situao
representada pelo caso. Esses componentes variam conforme a aplicao sendo
desenvolvida, sendo enfatizados em algumas delas apenas um ou dois componentes.
De modo similar, as informaes em um registro de problema trazem os dados
referentes aos sintomas enfrentados e o ambiente de rede onde o problema foi detectado.
Os registros de problemas se propem a diagnosticar um problema um objetivo
simples, nico, que implcito a todos os registros de problemas tratados. Assim, este
componente, que no est presente nos registros tradicionais, tambm no necessrio
aos casos.
As restries e caractersticas da situao em um caso, por sua vez,
correspondem s informaes presentes nos registros que descrevem os sintomas
identificados e as condies do ambiente onde o problema ocorreu. So as informaes
mais importantes no caso para aplicaes de diagnstico [KOL 93]. Em registros de
problemas, entretanto, nem todas as informaes auxiliaro a descobrir a soluo de um
problema: algumas delas possuem propsitos apenas de gerenciamento. Essas
informaes devem ser, porm, mantidas nos casos, a fim de que o sistema preserve as
funes legadas dos sistemas de registro de problemas tradicionais.
Os registros de problemas no contm, contudo, todas as informaes relevantes
sobre o problema que poderiam ser utilizadas para a identificao de situaes similares.
Existem informaes adicionais, tais como perguntas que devem ser feitas aos usurios e
testes que devem ser efetuados, que so identificadas pelos tcnicos especialistas a partir
de alguns dados dos campos dos registros de problema tradicionais. Estes campos so
utilizados como impulso para a identificao de novas informaes a serem buscadas
e a extenso do quanto um tcnico responsvel pelo diagnstico de um problema avana
a partir dos dados de um registro o que faz dele um especialista [LEW 95].
Essas informaes, entretanto, no esto usualmente presentes nos registros, ou
ento so registradas atravs de campos de texto livre indesejveis, como j foi
comentado, nestes sistemas de raciocnio. Assim, a transformao do registro em um
caso demanda a identificao das demais informaes sobre o problema que poderiam
contribuir para a recuperao de um caso similar aquelas informaes que trazem
aspectos relevantes sobre o problema, que so identificadas atravs da experincia pelos
especialistas como caractersticas que podem contribuir para a soluo de um problema,
seja por indicar um sintoma especfico, seja por indicar uma condio do ambiente da
rede que pode ser relacionada ao problema.
O estudo dos problemas em redes, apresentado na seo 4.3, demonstrou que
uma das informaes que subdivide os problemas e que pode ser usada para identificar
dados relevantes a eles o tipo de problema. Diferentes tipos de problemas apresentam
diferentes sintomas e so relacionados a diferentes condies do ambiente. Problemas
com a conectividade em uma rede local, por exemplo, possuem diferentes caractersticas
relevantes de problemas de acessibilidade, ocorrendo com o uso de uma nica aplicao.
Assim, uma abordagem que pode ser utilizada, sugerida por Lewis [LEW 95], a

85

identificao dos provveis tipos de problemas do domnio e, para cada um dos tipos
identificados, analisar as informaes adicionais que poderiam auxiliar para resolver o
problema e adicionar campos ao caso-registro para cada uma destas informaes. Essa
abordagem foi aplicada no modelo identificando, para cada tipo de problema, um
conjunto de informaes que contribui para descrever as informaes relevantes daquele
tipo de problema, sendo chamadas caractersticas adicionais.
Alm do tipo de problema, existem tambm outras caractersticas que influenciam
a determinao das caractersticas relevantes para um problema quando combinadas com
alguns valores particulares de outras. Um exemplo a interface de rede local. Em uma
rede onde a caracterstica interface de rede corresponde a uma Ethernet, por exemplo, as
caractersticas relevantes (tais como taxa de colises e carga da rede) so diferentes das
caractersticas relevantes de uma rede FDDI. Essas inter-relaes entre as caractersticas,
que sero comentadas posteriormente na seo 5.5.2, so usadas para o processo de
classificao. J os tipos de problemas, que envolvem no apenas a relao entre algumas
poucas caractersticas mas influenciam todo o conjunto de caractersticas adicionais
relevantes, so usados como ndices principais no processo de busca, e sero comentados
na seo referente organizao da base de casos.
As caractersticas aqui apresentadas informaes com propsitos de
gerenciamento, informaes gerais sobre o problema, informaes adicionais referentes
ao tipo de problema so obtidas pelo sistema no processo de definio do contexto,
que inserido no sistema de registro de problemas no momento da criao do registro.
O estudo efetuado sobre os problemas enfrentados nas redes demonstrou, porm, que
casos formados apenas por estas caractersticas deixariam lacunas no sistema.
A primeira delas diz respeito grande variao de problemas enfrentados, aliada
complexidade destes. Assim, percebeu-se que mesmo identificando caractersticas
relevantes para cada tipo de problema, entre um mesmo tipo de problema existe uma
grande variao de casos, que possuem caractersticas relevantes diferentes de todos os
demais casos do grupo, embora suas caractersticas possam ser semelhantes a alguns dos
problemas do grupo. Assim, incorporar essas caractersticas ao questionrio das
informaes adicionais do tipo de problema torna-lo-ia exaustivo e poderia obter
informaes no importantes para o problema e nem mesmo para a maior parte dos
problemas do grupo.
A segunda lacuna diz respeito s restries impostas pela utilizao de uma
linguagem estruturada. Conforme citado anteriormente, um sistema deve estabelecer
inicialmente um meio termo entre uma linguagem excessivamente estruturada (que peca
pela restrio s informaes sobre o problema e sobre os problemas que podem ser
manuseados eficientemente) e uma excessivamente flexvel (que peca por permitir uma
m interpretao do sistema), permitindo que a linguagem evolua a partir das novas
experincias do sistema [LEW 95]. Assim, a estrutura dos casos formada apenas pelas
caractersticas adicionais demanda ainda por componentes para expressar informaes
adicionais s identificadas inicialmente como relevantes para cada um dos tipos e meios
de permitir a evoluo da linguagem.
Por fim, uma terceira lacuna diz respeito aos modos de incorporar no sistema
informaes provenientes das aes de diagnstico efetuadas para o isolamento de um
problema. Essas aes, representando muitas vezes informaes com um alto custo para
obteno, so escolhidas a partir dos dados iniciais sobre a situao (representados na

86

criao do registro) e de resultados de aes anteriores, e so algumas vezes

armazenadas nos registros tradicionais, atravs das notas. A seqncia de sua execuo,
entretanto, no necessariamente completa: certas vezes, alguns especialistas, a partir da
sua experincia e de determinados sintomas ou condies da rede, tendem a pular
algumas das aes que especialistas novatos efetuariam. Assim, demonstra-se a
necessidade de representar as informaes provenientes dos resultados dessas aes em
um modo que possam ser utilizadas para os processos de raciocnio, permitindo ainda
que a ordem de sua execuo no seja obrigatria.
Uma alternativa para soluo de algumas dessas lacunas seria a criao de
questionrios alternativos para subconjuntos de problemas, solicitados pela combinao
de valores de algumas das caractersticas j informadas. Essa alternativa se refletiria,
porm, sobre a flexibilidade do sistema, tornando a linguagem ainda mais restritiva, ao
invs de flexibiliz-la e permitir que ela evolua com a experincia do sistema. Ela
exigiria, tambm, a identificao exaustiva de todos os possveis problemas das redes em
detalhes e no apenas os tipos de problemas possveis, uma tarefa complicada em virtude
da complexidade, variao e grau de transformao das tecnologias envolvidas nos
problemas em redes. Alm disso, esta alternativa propiciaria que as informaes fossem
fornecidas no momento de criao do registro, o que se mostra inadequado, porque
muitas dessas caractersticas importantes so obtidas ao longo da execuo do problema,
atravs de aes de diagnstico.
Assim, foi elaborada para o modelo proposto uma abordagem diferente, que
aplicada aps uma primeira recuperao, formando o refino dessa recuperao. Essa
abordagem faz uso do contedo de caractersticas discriminantes presentes nos casos j
recuperados para identificar novas informaes relevantes para o caso corrente, j que
so provenientes dos casos similares a este. Tal abordagem semelhante j utilizada em
outros sistemas de raciocnio baseado em casos, tais como CASCADE [SIM 92] e
SMART [ACO 92], alm de ferramentas para desenvolvimento de sistemas como a
famlia CBR3 (Inference Corp.)[WAT 97][WIL 94], que fazem uso de informaes
provenientes dos casos recuperados, a partir de uma busca inicial com base em uma
breve descrio do problema [ACO 92] ou em caractersticas iniciais deste [SIM 92]
para a identificao de outras possveis informaes relevantes ao problema. O sistema
MASTER [DRE 95] pode ser tambm aqui citado, pelo seu conceito de Master Tickets,
em que feita a recuperao do master ticket mais similar e as atividades de diagnstico
deste caso so solicitadas.
Cada caso, pode, assim, conter uma ou mais destas caractersticas discriminantes
que sero utilizadas posteriormente, quando o caso for recuperado, para o refino da
recuperao. Essas caractersticas, denominadas caractersticas especficas, so as
responsveis por armazenar informaes importantes do caso que no esto presentes
entre as caractersticas do tipo de problema, sendo utilizadas, na recuperao, para
identificar um subconjunto de casos similares dentre os selecionados. Tais caractersticas
permitem que o resultado de aes de diagnstico sejam utilizadas para a recuperao,
no exigindo que todas sejam respondidas numa ordem pr-definida. Alm disso,
contribuem para o aumento do conhecimento do sistema e flexibilizam a linguagem dos
casos, j que permitem que novas caractersticas sejam acrescentadas ao sistema no
momento de aprendizado de um caso.
Assim, a parte descrio do caso formada pelas informaes apresentadas no
momento de criao do registro e pelas caractersticas especficas do caso. Alm disso,

87

formada tambm pelas notas que so acrescentadas ao registro ao longo da evoluo do

problema. A figura seguir demonstra os componentes do caso.

Registro de Problema - Caso

Descrio do Problema
Informaes da Criao do Registro
Informaes Iniciais:
- Informaes com Propsitos de Gerenciamento
- Tipo de Problema
- Breve Descrio do Problema (texto livre)
- Outras Informaes Gerais Acerca do Problema
Informaes Adicionais Referentes ao Tipo de Problema e ao
contexto em geral
Informaes Atravs das Caractersticas Especficas
Para cada caracterstica:
- Caracterstica/Valor
Notas
Para cada nota:
- Informaes com Propsitos de Gerenciamento
- Relao com Caractersticas Especficas
Soluo do Problema
- Informaes com Propsitos de Gerenciamento
- Causas
- Componente Afetado
- Problema no Componente
- Tipo de Problema Final (real causador)
- Soluo Adotada

FIGURA 5.5 - Componentes de um caso

Alm da descrio, o caso formado tambm pelas informaes referentes
soluo do problema. Similar s informaes em um registro tradicional, a soluo
formada pelas informaes com propsitos exclusivamente de gerenciamento (tais como
data de encerramento, usurio que encerrou o problema, etc.) e pelas informaes
referentes s causas do problema, componente afetado (funo deste equipamento no
problema), descrio do problema no componente, soluo empregada e tipo de
problema final.
A caracterstica tipo de problema final foi acrescentada por ter sido constatado
que muitos problemas identificados inicialmente como de um tipo so, ao final, causados
por outros. Assim, os registros devem ser cadastrados pelo tipo de problema final, que
foi o problema que realmente causou os sintomas encontrados, a fim de que esse registro
possa, no futuro, contribuir melhor para a soluo de um problema com causa similar
ocorrida. Para que esse problema contribua tambm para problemas com caractersticas
similares s enfrentadas, identificados tambm como de um tipo diferente do real, so
fornecidos mecanismos de relacionamento entre os problemas, que sero comentados na
seo referente a definio do contexto.

88

5.4.2 Base de Casos: Organizao e Indexao

Alm da representao dos casos, o desenvolvimento de uma base de casos
envolve a escolha dos ndices para eles. Os ndices, formados por combinaes de
caractersticas importantes que distinguem os casos entre si, so os responsveis por
tornar os casos acessveis no momento apropriado. So utilizados em diversos processos
de recuperao para restringir o espao de busca na base de casos, a fim de que
algoritmos de recuperao parcial algoritmos dispendiosos sejam aplicado apenas
nos casos com algum potencial de relevncia para o caso corrente. So, portanto, papel
importante nos algoritmos de recuperao para organizar e direcionar a busca.
Buscou-se, assim, uma forma de organizar os casos na base de modo que a busca
por casos similares a uma situao corrente fosse restrita queles casos que podem
contribuir com sua soluo para a resoluo da situao corrente. Aliando essas questes
s discutidas anteriormente sobre a representao dos casos e s informaes relevantes
para um problema, optou-se, assim, por uma estrutura hierrquica para a base de casos
que se baseasse na informao sobre o tipo de problema enfrentado (tipo de problema
final). Essa abordagem para organizar a base tambm proposta em [LEW 95].
Alm disso, identificou-se que existem informaes teis para restringir a busca
na base, variando com o tipo de problema tais como o padro de interface de rede
encontrado na rede gerenciada, que relevante para os problemas fsicos e de
configurao do hardware. Estas caractersticas sero utilizadas para criao de filtros no
momento da recuperao da base.
A figura a seguir apresenta a hierarquia utilizada na base de casos.
problema

servios
servios
conectividade conectividade roteamento performance alto
servios
outros
aplicao resoluo
fsico e
endereamento
genrico
trfego
autenticao compartilhamento
configHW
nomes
arquivos

FIGURA 5.6 - Hierarquia da base de casos

5.4.3 Base de Conhecimento Geral do Domnio

Os sistemas CBR possuem, usualmente, tambm uma base de conhecimento que
armazena o conhecimento do domnio, que permite identificar fatores tais como a
similaridade entre as caractersticas, as relaes entre elas, etc. Tambm no presente
trabalho, a partir das necessidades envolvidas nos processos de raciocnio e na
representao dos problemas, foram identificados elementos do conhecimento do
domnio que deveriam ser representados no sistema.
Assim, o conhecimento do domnio presente no sistema inclui vrias
informaes:

89

conhecimento das relaes entre os tipos de problema, adquirido a partir da

experincia do sistema e do relacionamento entre o tipo de problema aparente e o tipo de
problema identificado ao final como causador. Essas relaes so armazenadas em
tabelas, representando a probabilidade de um problema comunicado inicialmente como
de um tipo ser, ao final, identificado como cada um dos outros tipos do sistema.
conhecimento da relao entre algumas caractersticas com os tipos de
problema provveis. Essas relaes so expressas atravs de regras em que determinado
valor para determinada caracterstica leva a uma probabilidade maior que um tipo de
problema seja considerado provvel. Um exemplo pode ser encontrado na informao de
que um problema comunicado como de performance da comunicao apresenta tambm
falta de acesso. Assim, um tipo de problema provvel, que poderia ter sido usado em
situaes similares anteriores ou mesmo que pode ser causador da degradao de
performance, o problema de tipo conectividade - genrico.
conhecimento sobre a similaridade entre os valores das caractersticas dos
casos. Permite identificar, por exemplo, que dois equipamentos de uma mesma famlia
so similares ou que determinados valores para o estado de uma interface so mais
similares que outros.
conhecimento sobre as inter-relaes entre algumas caractersticas e sua
relevncia. Permite identificar que uma varivel pode transmitir similaridade (ou seja,
relevante) e deve ser comparada a partir do valor de uma outra, como, por exemplo, o
conhecimento de que a taxa de coliso relevante e sua similaridade deve ser verificada
quando a interface de rede sendo utilizada na rede com problema uma Ethernet.
conhecimento sobre a similaridade de expresses para clculo de similaridade
entre caractersticas em texto livre.

5.5 Modelagem dos Processos CBR

Os processos de raciocnio envolvidos no sistema so separados em quatro
etapas: definio do contexto, recuperao com busca e classificao, reutilizao e
reviso e, aps a soluo ser obtida, aprendizado.
Os processos de raciocnio baseado em casos iniciam com a avaliao da
situao processo responsvel por analisar a situao e determinar quais seriam os
ndices para identificar um caso similar que estivesse armazenado na base se a situao
fosse bem entendida, o que feito atravs de uma interpretao do problema que busca
identificar que tipo de situao est ocorrendo, o que importante nela, e o que poderia
ser concludo a partir dela. A avaliao finalizada atravs de um processo de
elaborao as caractersticas derivveis do caso so calculadas e utilizadas junto com
a descrio original para a busca e classificao.
A avaliao da situao pode ser desenvolvida em trs fases. Pode ser executada
antes da busca ser realizada, elaborando um conjunto de caractersticas que sejam
adequadas para a recuperao processo conhecido como definio do contexto.
Pode ser tambm utilizada durante a busca, utilizando a base de casos para designar que
novas dimenses podem ser geradas para discriminar entre os vrios itens da memria
processo conhecido como refinamento do contexto. Por fim, ela pode tambm ser

90

implementada depois da recuperao processo conhecido como redefinio do

contexto [KOL 93].
Nesse modelo, no processo de definio do contexto, a partir da descrio
inicial do problema ocorrido feita a anlise da situao e o sistema identifica quais as
caractersticas adicionais sobre ela podem contribuir para a identificao de problemas
similares. A avaliao da situao efetuada tambm depois da etapa de recuperao,
quando novas caractersticas importantes para a recuperao so identificadas e obtidas.
Por fim, a avaliao realizada novamente no momento de aprendizado.
Trataremos aqui inicialmente da definio do contexto. A seguir, apresentaremos
o processo de recuperao referente busca e classificao e o processo de reutilizao
e reviso, enfocando a avaliao da situao. Por fim, abordaremos o processo de
aprendizado.

5.5.1 Definio do Contexto

No momento inicial da criao de um registro, so obtidos inicialmente apenas
dados iniciais acerca do problema (tais como responsvel pelo registro, usurio
reclamante, breve descrio do problema, tipo de problema). O processo de definio do
contexto o responsvel ento por especificar ao sistema quais informaes adicionais
so necessrias, definindo a lista de caractersticas que devem ser elaboradas, os
mecanismos que podem ser utilizados para essa elaborao e elaborando-as.
Conforme comentado anteriormente, na seo referente representao dos
problemas, a lista de caractersticas para elaborao no sistema sensvel ao contexto,
sendo associada aos diferentes tipos de problema que o sistema trata, a fim de que a
elaborao seja especializada para cada problema. Esse tipo de abordagem para definio
das caractersticas adotado tambm em outros sistemas, como o CYRUS, desenvolvido
por Janet Kolodner Apud [KOL 93], que se baseia nos diferentes tipos de situao para
agrupar os casos em redes de discriminao redundante, e o sistema
CRITTER [LEW 93], que se baseia tambm nos tipos de problemas de rede.
O processo de definio das caractersticas se desenvolve da seguinte forma. O
sistema analisa a situao e identifica um conjunto de caractersticas que deve ser
elaborado a partir do tipo de problema do caso corrente. A partir dos valores obtidos
com a elaborao destas caractersticas, algumas delas (tais como localizao do
problema) so tambm utilizadas para a definio de outras caractersticas que devem ser
elaboradas. Essas caractersticas, elaboradas a partir do contexto, so denominadas
caractersticas adicionais.
No desenvolvimento do sistema Dumbo, a identificao destas caractersticas foi
feita manualmente, atravs da identificao de que informaes poderiam contribuir para
a identificao de casos similares e do julgamento da relao custo-benefcio da
disponibilidade de cada uma. Outras informaes sobre este processo podem ser
buscadas na seo 5.4.1.
Aps serem identificadas quais so as caractersticas adicionais que devem ser
utilizadas para a situao, o sistema implementa ento mecanismos para executar esta
elaborao. Esses mecanismos podem ser implementados com execuo automtica ou,
caso no seja possvel computar a caracterstica automaticamente pelo sistema, ela
solicitada ao usurio.

91

A elaborao automtica das caractersticas adicionais feita atravs de um dos

procedimentos abaixo:
obteno a partir de uma ou mais combinaes de caractersticas j obtidas, em
conjunto com o conhecimento do domnio presente. Um exemplo a caracterstica
tipo de equipamento (tal como roteador), que pode ser elaborada a partir da
caracterstica produto (tal como Cisco 7000), desde que o sistema possua cadastrado
o produto correspondente, podendo assim identificar qual tipo de equipamento aquele
produto . Outro exemplo a caracterstica dos provveis componentes com falha
fsica, que ser comentado na seo a seguir.
obteno a partir do conhecimento topolgico da rede, obtido com a utilizao e
aprendizado do sistema. Exemplos dessas caractersticas so as informaes
referentes a um equipamento como nmero IP, sistema operacional e produto que
podem ser elaboradas a partir das caractersticas de identificao do equipamento (seu
nome, por exemplo), desde que este equipamento j tenha sido referenciado em algum
caso anterior no sistema e estes dados tenham sido informados em tal situao. Essas
caractersticas poderiam ser tambm obtidas diretamente da rede utilizando uma
plataforma de gerncia que fosse integrada ao sistema e que possusse informaes
sobre o referido equipamento ou atravs de servios de rede como o nslookup (que
pode ser usado para retornar o nmero IP de um nome do servidor DNS). Nesta
verso do trabalho, porm, esses procedimentos no esto disponveis.
obteno de condies do ambiente diretamente da rede. Assim, poderiam ser
elaboradas caractersticas relacionadas s informaes de gerenciamento SNMP
associadas a MIB dos equipamentos envolvidos. So exemplos a taxa de erros de
descartes de entrada e sada de uma interface de um roteador para uma linha serial.
Outras caractersticas poderiam ser tambm obtidas utilizando-se ferramentas de
monitorao integradas ao sistema (como taxa de colises em uma rede Ethernet),
objeto de estudo de uma prxima verso. Na verso do prottipo implementada,
entretanto, esses procedimentos no esto ainda integrados.
Assim, para cada caracterstica a ser elaborada, o sistema avalia se possvel
obt-la automaticamente e, em caso contrrio, solicita-a ao usurio. Essas caractersticas
podem ser solicitadas diretamente (solicitando-se exatamente a informao que se
deseja) ou atravs de uma questo que envolva duas ou mais caractersticas que devem
ser elaboradas, a fim de que o usurio fornea o mnimo de informaes necessrio.
O processo de definio do contexto no , entretanto, responsvel por elaborar
apenas as caractersticas adicionais. Conforme comentado anteriormente, ele efetua
tambm a elaborao dos tipos de problemas que so provveis para a situao alm do
tipo de problema j informado. Essa informao importante em virtude da
complexidade dos problemas, uma vez que um problema aparentemente de um tipo pode
ser causado na verdade por um outro diferente. Assim, necessrio analisar a situao a
fim de identificar quais tipos de problemas adicionais devem ser tambm consultados.
5.5.1.1 Elaborao dos Provveis Componentes com Falha Fsica
Uma das informaes presentes freqentemente da parte soluo de sistemas de
registro de problema o componente afetado. Deste modo, essa informao pode ser
usada para casamento do caso corrente se dispusermos, para essa situao, dos
componentes que podem estar envolvidos no problema. Por ser uma comparao com

92

uma informao de um caso j resolvido parte da prpria soluo essa

caracterstica pode trazer dados importantes para a similaridade entre os casos.
Como foi comentado anteriormente, falhas em um componente podem ser
causadas por problemas fsicos no hardware ou na configurao do hardware, problemas
na camada Internet (por falhas em roteamento, endereamento IP, etc.) e problemas nas
camadas superiores.
Buscou-se, assim, elaborar quais seriam os problemas em componentes que
seriam causados por falhas fsicas (incluindo configurao do hardware envolvido no
acesso ao meio, como, por exemplo, configurao do frame em Ethernet ou IEEE
802.3). Os componentes identificados foram as entidades origem e destino (ponto de
onde partiu e para onde se destina a comunicao), equipamentos de interconexo de
rede (incluindo, assim, aqueles equipamentos que tem funo de roteador, de servidor de
comunicao, etc. na rota entre a estao local e remota), equipamentos de interconexo
de enlace (tais como pontes presentes nas LANs local, remota ou intermediria entre a
origem e destino) e cabeamento (incluindo, neste item, o cabeamento propriamente dito
e os equipamentos que manipulam os dados apenas na camada fsica, tal como
repetidores), como apresentado na figura 5.7.
problema fsico

causado por
causado por

cabeamento

equipamentos
interconexo
enlace

causado por
causado por
equipamentos
interconexo
rede

entidades
origem e
destino

FIGURA 5.7 - Possveis componentes envolvidos em falhas fsicas e de

configurao do HW
A posse de algumas informaes presentes nas caractersticas adicionais,
entretanto, permite que os provveis componentes envolvidos em falha fsica sejam
melhor interpretados. Assim, optou-se por um modo de raciocnio em que feita a
excluso dos componentes (segundo a funo desempenhada por eles no problema) que,
na situao corrente, no devem estar envolvidos em falhas fsicas. Isso pode ser feito
pela no existncia do componente na rede gerenciada ou porque, com a interpretao
da situao, possvel eliminar alguns deles.
Duas regras pertencentes ao conjunto das regras do sistema so apresentadas a
seguir como exemplo. A primeira regra se destina a eliminar os componentes das
entidades origem e destino no caso corrente se o problema encontrado na comunicao
para todas as estaes da sub-rede ou do segmento (eliminando, portanto, a estao
remota de ser a causadora do problema), partindo de todas as estaes (eliminando,
portanto, a estao local de ser o componente com falha), naquelas situaes em que a
sub-rede no foi recm configurada nem alterada. A segunda regra, por sua vez, visa
eliminar os componentes equipamentos de interconexo de enlace se o problema for em
uma sub-rede IP de uma rede local que s possui um segmento/domnio de coliso.

93
SE localizao do problema = entre mesma sub-rede IP E
(abrangncia problema estaes origem da sub-rede = todos E
abrangncia problema estaes origem dos segmentos envolvidos = todos) E
(abrangncia problema estaes destino da sub-rede = todos OU
abrangncia problema estaes destino dos segmentos envolvidos = todos) E
alterao = funcionavam anteriormente sem alterao recente
ENTO provvel componente fsico no possui entidades origem e destino
SE localizao do problema = entre mesma sub-rede IP E
interface de rede uma LAN E
segmentos envolvidos = sub-rede s possui um segmento/domnio de coliso
ENTO provvel componente fsico no possui equipamento interconexo enlace

A elaborao dos componentes com falhas de roteamento e endereamento IP

est sendo tambm estudada. Futuramente, a elaborao de caractersticas para falhas
nas camadas superiores pode tambm ser acrescentada e comparada de modo anlogo ao
realizado com as falhas fsicas.
5.5.1.2 Elaborao dos Tipos de Problema Relacionados
A elaborao da caracterstica referente aos tipos de problema relacionados
situao se baseia em dois pontos distintos: em regras associadas s caractersticas j
informadas que buscam direcionar o tipo de problema para outros tipos provveis e na
relao histrica entre os tipos de problema.
O primeiro ponto uso de regras associadas algumas caractersticas visa
atingir aqueles registros onde o tipo de problema foi informado sem levar em
considerao todos os dados j disponveis no momento, dados estes que indicam um
tipo de problema diferente. Assim, as regras visam direcionar o tipo de problema para o
tipo ou os tipos de problemas que poderiam j ter sido informados. Um exemplo de um
caso como este seria a criao de um registro como um problema de aplicao para uma
situao em que o usurio no conseguiu estabelecer uma conexo de terminal virtual
com uma estao remota, estao remota que no estava, contudo, acessvel via rede.
Assim, uma vez que a estao no est acessvel, o tipo de problema informado
preferencialmente deveria ter sido conectividade, j que a falha com a aplicao foi
apenas um sintoma superficial do sintoma principal relativo falta de acessibilidade.
Para estas situaes, o sistema implementa um mecanismo em que associa para
algumas informaes solicitadas ao usurio regras que, dependendo do valor da resposta,
privilegiam um tipo de problema e, no clculo final, podem adicion-lo caracterstica
relativa aos tipos de problemas provveis sendo elaborada. Algumas regras definidas so
apresentadas a seguir, denominadas regras redirecionadoras.
SE problema mantm utilizando IP = no
ENTO tipo de problema servios-resoluo de nomes PESO 3
SE falta de acesso = constante ou falta de acesso = intermitente E
tipo de problema no conectividade-genrico E
tipo de problema no conectividade-fsico e config/HW E
tipo de problema no roteamento/endereamento
ENTO tipo de problema conectividade-genrico PESO 3
SE falta de acesso = intermitente e tipo de problema != performance
ENTO tipo de problema performance PESO 3

As caractersticas relacionadas a essas regras, como pode ser visto pelo exemplo,
podem no ser relativas a todos os tipos de problemas, sendo utilizadas para apenas um

94

ou alguns tipos de problemas. A segunda regra apresentada, por exemplo, aplica-se

somente para problemas que no sejam de tipo conectividade, a fim de identificar se
estes problemas poderiam ter sido causados por uma falta de acesso ou se, por
envolverem tambm uma acessibilidade, poderiam ter sido em outras situaes
cadastrados desta forma. De forma semelhante, a terceira regra relacionada a
problemas que no sejam de performance, a fim de identificar se, por ser uma falha
intermitente, o problema poderia ter sido percebido desta forma. Neste caso, a funo da
regra obter tipos de problemas que poderiam tambm ter sido escolhidos em outras
situaes, embora no sejam o sintoma principal.
Desta forma, essas regras visam analisar a situao em funo das informaes j
disponveis, a fim de elaborar quais tipos de problemas devem tambm ser consultados
na base. O clculo da probabilidade de cada tipo de problema segundo as regras
redirecionadoras feito da seguinte forma: cada tipo de problema tem peso inicial zero.
O caso passa por todas as regras, e, para cada regra verdadeira, o peso da regra
somado ao peso do tipo de problema correspondente. Aps todas as regras serem
executadas, feita a soma dos pesos resultantes de todos os tipos de problemas e o peso
de cada tipo de problema dividido pelo peso total, formando um valor para cada tipo
de problema denominado probabilidade segundo regras redirecionadoras. Esse valor
ser relacionado relao histrica para clculo da probabilidade final do tipo de
problema, conforme veremos a seguir.
O segundo ponto considerado para elaborao dos provveis tipos de
problema que se baseia na relao histrica entre os tipos de problema visa
atingir os casos em que o tipo de problema real da situao s ser identificado na fase
final de diagnstico da situao, sendo que os dados iniciais apontam para um tipo de
problema superficial causado, na verdade, por outro. Um exemplo desse tipo de situao
pode ser encontrado no caso 2, apresentado no anexo 3. Nesse caso, um problema de
compartilhamento de arquivos mostrou, ao final, ser causado por um problema de
autenticao. Assim, outros casos de autenticao seriam tambm similares ao problema
corrente, que serviriam para indicar ao usurio as atividades de diagnstico e solues
que poderiam ser empregadas. Portanto, casos de tipo servicos-autenticao deveriam
tambm ser consultados.
Essas situaes so tratadas fazendo-se uso da relao histrica da rede entre os
tipos de problema, identificada atravs de uma tabela em que armazenado para cada
tipo de problema o percentual de vezes que este tipo de problema foi no passado
causado pelos outros tipos. Busca-se, com isso, fazer o relacionamento de tipos de
problemas que podem ser causados por outros, por utilizarem seus servios (como no
exemplo citado), e usar esta relao para a busca de uma nova situao. Essas relaes
so atualizadas a cada caso encerrado, e o sistema pode assim, ao longo da sua
utilizao, adaptar essas relaes para o seu domnio em particular. O valor resultante
para cada tipo de problema segundo esta relao histrica chamado probabilidade
segundo a relao histrica.
A elaborao da probabilidade final de cada tipo de problema realizada
utilizando a probabilidade segundo as regras redirecionadoras (se alguma das regras tiver
sido aplicada) e a probabilidade segundo a relao histrica. Seu clculo feito dando
maior importncia relao histrica, pois esta evolui com o uso do sistema e, com isso,
torna-se mais adequada para o domnio em que est sendo usada. Atualmente, a

95

importncia dada probabilidade da relao histrica tem valor 3. A funo para

obteno da probabilidade final apresentada na figura abaixo.
prob(T , C ) =
onde

pred (T , C ) + I * phist (T , C )
I +1

T: tipo de problema
C: caso corrente
pred (T, C): probabilidade segundo regras redirecionadoras
phist (T, C): probabilidade segundo relao histrica
I: importncia da relao histrica

FIGURA 5.8 - Funo para clculo da probabilidade final de cada tipo

de problema
O processo de elaborao se encerra com a seleo automtica para busca dos
tipos de problemas provveis que possurem uma probabilidade maior que um valor prdeterminado (atualmente, o valor 0,2). Os tipos de problema no selecionados podem,
porm, ser includos no grupo dos selecionados por determinao do usurio na etapa de
reutilizao e reviso, quando a avaliao da situao realizada novamente. Assim, essa
caracterstica formada por uma listagem dos diversos tipos de problemas, sendo, para
cada um, associado um valor referente probabilidade resultante para aquele tipo e a
indicao de sua seleo ou no. Esses valores sero utilizados posteriormente no
processo de recuperao.
Em posse da descrio do problema adicionada das demais caractersticas
elaboradas nesta etapa de definio do contexto, o caso segue para o processo de busca
da base de casos.

5.5.2 Recuperao: Busca e Classificao

O processo de recuperao envolve, aps a definio do contexto, a busca na
base pelos casos com potencial de serem similares situao corrente e a seleo, dentre
estes, dos casos com maior similaridade com esta situao. Esta similaridade no ,
entretanto, uma similaridade realizada atravs de casamento exato: no se pode esperar
que um caso na base de casos seja o casamento exatamente da nova situao, de modo
que a recuperao deve resultar no melhor casamento parcial.
Todavia, a utilizao de casamento parcial no processo de busca dos casos na
base resulta num algoritmo de busca excessivamente dispendioso. Assim, deve ser
buscado um modo eficiente para particionar o espao de busca de modo que o
casamento parcial completo seja feito em apenas um pequeno nmero de casos
[KOL 93].
5.5.2.1 Algoritmo de Busca
O algoritmo de busca na base de casos utiliza-se de ndices para buscar os casos
na base segundo a estrutura organizacional desta, procurando cumprir seu objetivo:
selecionar um pequeno nmero de casos potencialmente relevantes, certificando-se ao
mesmo tempo que no mnimo alguns casos que tm o potencial de serem os mais teis
esto no conjunto [KOL 93].

96

Como foi comentado na seo 5.4.2, a base de casos neste trabalho foi
organizada hierarquicamente segundo o tipo de problema dos casos (tipo de problema
final). Esta organizao visa selecionar do conjunto de todos os problemas armazenados
aqueles problemas que dizem respeito situao corrente por envolverem o mesmo tipo
de problema.
A busca na base de casos deve almejar, contudo, que sejam selecionados ao
menos um grupo dos casos com maior potencial de similaridade para a situao, os
quais, como j foi discutido anteriormente, no garantido que sejam do mesmo tipo de
problema identificado no incio da situao corrente. , portanto, a fim de garantir este
conjunto que feita a elaborao dos tipos de problemas provveis na definio do
contexto, os com maior probabilidade so selecionados e estes tipos de problemas so
ento usados como ndices na busca na base.
Assim, o algoritmo de busca percorre a base selecionando os casos que
pertencem a cada um dos tipos de problemas identificados nos tipos de problema
provveis selecionados para busca. A figura a seguir esquematiza o processo.
nodo_atual = raiz
para cada nodo folha tipo_de_problema repetir
se tipo_de_problema tipos_de_problemas_provveis_selecionados
nodo_atual = nodo folha
se nodos folhas nodo_atual so casos
selecionar casos
seno
nodo_atual=nodo folha cujo ndice arco seja melhor casamento
selecionar casos representados pelos folhas do nodo atual

FIGURA 5.9 - Algoritmo para recuperao na base de casos

Aps o processo de busca, tem-se o grupo de casos que parcialmente casaram
com a situao corrente. Esse grupo deve, ento, ser submetido a uma avaliao mais
compreensiva do grau de casamento de cada caso com o caso corrente, considerando
agora todas as caractersticas do caso, a fim de que os casos mais similares sejam
identificados e apresentados para o usurio. Este processo conhecido como
classificao.
5.5.2.2 Classificao: Similaridade entre Caractersticas
O clculo confivel do grau de casamento entre casos envolve diversos
processos: (i) a determinao de que caractersticas correspondem entre si e devem
portanto ser comparadas, (ii) o clculo do grau de casamento entre estas caractersticas e
(iii) a identificao da importncia de cada caracterstica.
No sistema DUMBO, a maior parte das caractersticas possui uma associao
direta (por exemplo, mensagem com mensagem, interface de rede com interface de rede),
mesmo que no seja comparao das mesmas caractersticas (provvel componente com
falha fsica com componente afetado do caso recuperado, por exemplo). Assim, as
caractersticas que sero comparadas j possuem correspondncia direta, no sendo
necessrio determinar a correspondncia entre caractersticas (etapa i). Resta, portanto,
abordar o modo como ser calculada a similaridade entre as caractersticas (ii) e o modo
como foi determinada e como registrada no sistema a relevncia destas (iii).

97

A avaliao da similaridade de uma caracterstica e, conseqentemente, o clculo

do seu grau de casamento dizem respeito ao tipo da caracterstica e conjunto de valores
que ela pode assumir. Algumas suportam apenas casamento exato, seja por possurem
apenas dois valores vlidos, seja por seus valores no possurem similaridade alguma
quando diferentes. Outras suportam casamento parcial. Nesse sistema, a partir da
avaliao das caractersticas definidas para os casos e dos tipos de similaridade utilizadas
nos sistemas apresentados na bibliografia [KOL 93], foram identificados seis tipos de
caractersticas e, por conseguinte, seis tipos de similaridades que o sistema deve
suportar. So elas:
caractersticas numricas, similaridade numrica por distncia de regies
qualitativas: utilizada para caractersticas que assumem apenas valores numricos.
Esse mtodo foi escolhido porque pequenas diferenas nos valores destas
caractersticas so irrelevantes para o grau de casamento, sendo tambm utilizado em
outros sistemas como o CASEY, de Koton Apud [KOL 93]. Nesse mtodo, so
estabelecidas regies ou intervalos qualitativos que abrangem os possveis valores
numricos para cada caracterstica segundo o seu significado no domnio. O valor da
caracterstica atribudo para o intervalo correspondente e o grau de similaridade
ento calculado pela distncia (nmero de regies) entre os dois valores. Assim, dois
valores que se encontram numa mesma regio possuem grau de similaridade mximo,
enquanto que valores que se encontram em regies vizinhas possuem uma
similaridade menor. A fim de acrescentar maior acurcia aos valores localizados
prximos as bordas ou limites dos intervalos, estes possuem limites que se
sobrepem.
caractersticas binrias, similaridade exata: utilizada em caractersticas cujas
respostas incluem apenas o valor SIM e NO, esta similaridade admite apenas
casamento exato. Geralmente, salvo aquelas caractersticas cuja resposta exigida
para o correto andamento do processo, o valor NO_RESPONDIDO tambm
aceito; neste caso, a similaridade no pode ser calculada. Entre as caractersticas que
utilizam este tipo de similaridade podemos citar h muito trfego e
ambiente tem mltiplos protocolos.
caractersticas com termos fixos, similaridade qualitativa: este tipo de
similaridade ocorre com caractersticas que admitem vrios termos (expresses) como
respostas e cujos valores para resposta so previamente identificados e cadastrados no
sistema. A similaridade entre eles definida de acordo com o conhecimento do
domnio, pela comparao qualitativa dos possveis valores. Um exemplo de
caracterstica que utiliza essa similaridade a abrangncia do problema na subrede origem. Nessa caracterstica, o valor um nico equipamento da sub-rede
considerado mais similar quando comparado alguns equipamentos da sub-rede do
que quando comparado ao valor todos equipamentos da sub-rede.
caractersticas com termos variveis, similaridade qualitativa: semelhante
similaridade qualitativa de termos fixos, com a diferena de que novos termos podem
ser acrescentados ao longo da utilizao e aprendizado sofrido pelo sistema. Novos
valores so inseridos, a fim de cadastrar termos tais como novas verses de sistemas
operacionais, novos produtos, etc. A similaridade nessas caractersticas permite
identificar uma maior similaridade entre, por exemplo, as distribuies Red Hat e
Slackware (sistema operacional Linux) do que quando essas so comparadas ao
sistema Solaris 2.x, ao mesmo tempo que permite demonstrar uma maior similaridade

98

entre estes produtos do que quando comparados a um sistema operacional Windows

95. Outro exemplo pode ser encontrado numa maior similaridade entre produtos de
uma mesma famlia, tal como entre um roteador Cisco 2524 e um roteador Cisco
2525.
caractersticas com termos variveis, similaridade exata: utilizada em
caractersticas que descrevem um determinado elemento da rede, como o nmero IP
de um equipamento ou sub-rede. Estas caractersticas admitem apenas casamento
exato.
caracterstica com texto livre, similaridade textual por palavras chave: utilizada
para comparar a caracterstica breve descrio do problema. Nesta caracterstica,
uma maior similaridade identificada por um nmero maior de ocorrncias comuns s
duas descries de expresses pr-cadastradas que possuem um valor semntico
maior em uma descrio, tais como cabeamento, TX, rotas. Expresses iguais com
variao em nmero, gnero e grau so cadastradas com grau de casamento 1,
enquanto que expresses similares (como par tranado e UTP) representam uma
similaridade em menor grau. Cada expresso est cadastrada em um ou mais
conjuntos semnticos. O clculo da similaridade entre duas caracterstica feito pela
comparao de cada expresso cadastrada da descrio no problema corrente com a
descrio do caso recuperado (sendo atualmente atribudo o valor 1 para a ocorrncia
de expresso igual e valor 0,7 para expresso similar), e pela soma do grau de
casamento de todas as expresses comparadas. Uma expresso pode ser aprendida
pelo sistema na fase de aprendizagem, quando o usurio informa as expresses
similares entre as j cadastradas. Termos como o, um e aquele so cadastrados como
termos que podem ser automaticamente anulveis, e no so disponibilizados para
aprendizagem.
Os diversos tipos de caractersticas do sistema acarretam em diferentes modos de
clculo da similaridade da caracterstica, porm o grau de um casamento foi projetado
visando que, independente como tenha sido calculado (por que tipo de similaridade), seja
consistente com as demais caractersticas, como prope Janet Kolodner [KOL 93].
Assim, um valor de casamento 0,75, por exemplo, representa o mesmo grau de
similaridade independente da dimenso (caracterstica) analisada e do mtodo de clculo
de similaridade utilizado.
Para isso, os graus de similaridade possveis entre as caractersticas, sejam estas
com termos fixos ou variveis, foram definidos como total(1,0), alto(0,75), mdio(0,5),
baixo(0,3), nenhum(0). As caractersticas do tipo binrias e do tipo com termos
variveis e similaridade exata admitem, por sua vez, o subconjunto de valores total e
nenhum. As caractersticas numricas possuem o grau adaptado para o nmero de
regies que a caracterstica suporta, de modo que a diferena de uma regio em uma
caracterstica com cinco regies, por exemplo, seja menor que se a caracterstica possuir,
por exemplo, apenas duas regies. A caracterstica com similaridade textual, por sua
vez, utiliza sua frmula prpria para atribuir o grau de casamento. A tabela a seguir
resume os tipos de caractersticas e similaridades apresentados.

99

TABELA 5.1 - Tipos de similaridades das caractersticas do sistema

Similaridade
numrica

binria

Valores Possveis
da Caracterstica
nmeros reais
positivos

Tipo de
Casamento
exato e
parcial

SIM, NO

apenas
exato

qualitativa para termos (expresses)

termos fixos pr-definidos para a
caracterstica

exato e
parcial

qualitativa para termos (expresses)

termos
cadastrados com
variveis
possibilidade de
novos termos

exato e
parcial

exata para
termos
variveis
textual

termos (expresses)
cadastrados com
possibilidade de
novos termos
texto livre

apenas
exato

parcial

Meios de Clculo de
Exemplos
Casamento Parcial
atribuio para
taxa de colises,
regies, clculo pelo
percentual de
nmero de regies
utilizao da rede
entre valores
ambiente tem
mltiplos
protocolos, h
muito trfego
similaridade de termos abrangncia do
pr-definida de acordo problema na subcom conhecimento do
rede origem
domnio
similaridade de termos
sistema
cadastrada com
operacional,
possibilidade de inserir
produto
novas relaes para
novos termos
identificao do
equipamento,
identificao da
sub-rede
comparao de
breve descrio
expresses similares
do problema
cadastradas

5.5.2.3 Classificao: Relevncia das Caractersticas

Uma vez que o modo como feita a anlise da similaridade das caractersticas j
foi abordado (ii), resta ainda comentar a atribuio de valores de importncia para as
caractersticas do sistema (iii) antes de abordarmos o processo de classificao como um
todo. Como comenta Kolodner, a funo que calcula o grau de casamento de uma
situao tem sua eficincia de acordo com o conhecimento que se possui da importncia
dos campos ou dimenses, que indica quais informaes devem receber mais ateno
aquelas informaes que contribuem mais para a similaridade entre casos.
Essa similaridade, como foi dito anteriormente, no representa necessariamente
os casos mais parecidos, mas sim os casos que tm o maior potencial de serem teis
para contribuir para a soluo daquela situao, seja por possurem causas semelhantes,
seja por necessitarem de aes de diagnstico semelhantes. Assim, no basta para o
clculo da similaridade entre dois casos avaliar o nmero de caractersticas casadas de
modo simples, pois isso desprezaria a maior relevncia que algumas caractersticas
possuem em indicar pontos importantes da situao [KOL 93][LEW 95].
A atribuio da importncia das caractersticas do sistema foi desenvolvida
atravs do estudo geral do domnio efetuado e dos casos coletados, quando foram
identificadas informaes ou combinaes de informaes (tais como alguns sintomas em
especial ou condies do ambiente) mais aptas a indicar a similaridade entre casos.

100

Foram, assim, estabelecidos cinco graus de importncia para as caractersticas de um

caso:
caractersticas essenciais (filtros), que eliminam o caso da lista dos selecionados se
ele no possuir um grau de similaridade mnimo pr-determinado, que pode ser grau 1
ou um grau definido de similaridade parcial. As caractersticas essenciais representam
as informaes necessrias para o problema, sem as quais o caso no pode ser
selecionado. Fazem parte desse grupo algumas das caractersticas especficas, a
caracterstica tipo de problema, que j utilizada para a recuperao inicial, e as
caractersticas que para alguns tipos de problemas constituem filtros, como o padro
de interface de rede para problemas de conectividade fsicos e de configurao do
hardware.
caractersticas com importncia excessiva, que representam informaes que
devem idealmente ser similares ao problema corrente por dividir geralmente o grupo
de problemas em um subgrupo com caractersticas muito mais especficas. Fazem
parte desse grupo caractersticas como tipo de interface de rede em problemas de
comunicao em redes locais, que indicam situaes com caractersticas particulares;
tipo de servidor em problemas com servios, etc.
caractersticas muito importantes, tais como abrangncia do problema e mensagem.
caractersticas importantes, tais como equipamento envolvido, enlace ou sub-rede
atingida.
caractersticas sem importncia, englobando as caractersticas com propsitos
apenas de gerenciamento e que, portanto, no contribuem na identificao de
situaes similares.
Apenas algumas destas caractersticas so utilizadas no processo de
classificao (caractersticas filtro, excessivamente importantes, muito importantes,
importantes), sendo atribudo a cada uma destas um valor numrico que o sistema utiliza
para o clculo de similaridade do caso (valores 5, 5, 3 e 1, respectivamente). As demais
no so utilizadas no processo de ordenamento dos casos. Essa abordagem, em que so
associados graus de importncia de acordo com valores fixos, no fornece uma
determinao exata da importncia das informaes muitas vezes at mesmo
desconhecida j que o caso representa uma situao ainda incompreendida mas
captura a importncia relativa dos problemas.
Entretanto, a atribuio de um valor simples esttico para cada caracterstica dos
casos no adequada para este sistema, j que, dependendo da situao enfrentada, a
importncia de algumas informaes varia muito, sendo at mesmo relevante para alguns
tipos de problemas e para outros no. Assim, um valor simples assinalado globalmente
para cada caracterstica no permitiria o julgamento de similaridade necessrio no
domnio, sendo necessrio assinalar valores de importncia que sejam relativos ao
contexto da situao corrente para algumas caractersticas as caractersticas
adicionais do caso. Essa particularidade foi implementada assinalando-se diferentes graus
de relevncia para cada uma das caractersticas adicionais, cada grau correspondente a
um contexto, representado no sistema pelo tipo de problema. A tabela abaixo apresenta a
relevncia de algumas caractersticas do sistema.

101

TABELA 5.2 - Relevncia de algumas caractersticas

Tipo de Problema
Conectividade Genrico

Conectividade Fsico e
Config/HW
Roteamento/Endereamento
Performance

Alto Trfego

Aplicao

Servios Compartilhamento Arq.

Servios Autenticao
Servios Resoluo Nomes

Relevncia das Caractersticas

modo falta acesso PESO 3
falta acesso PESO 3
padro interface rede PESO 5
falta acesso PESO 3
padro interface rede PESO 5
modo falta acesso PESO 3
falta acesso PESO 3
modo falta acesso PESO 3
falta acesso PESO 3
performance ruim quando PESO 3
h muitos erros PESO 5
h muito trfego PESO 3
h alto tempo resposta PESO 5
tipo alto tempo resposta PESO 3
padro interface rede peso 5
modo falta acesso PESO 3
falta acesso PESO 3
alta taxa de trfego quando PESO 3
alto trfego em PESO 3
h muitos erros PESO 3
h muito trfego PESO 3
h alto tempo resposta PESO 3
tipo trfego alta taxa PESO 3
padro interface rede PESO 5
aplicao em uso PESO 3
abrangncia do problema nas estaes PESO 3
abrangncia do problema para usurios PESO 3
tipo de servidor arquivos PESO 5
tipo de servidor autenticao PESO 5
tipo de servidor nomes PESO 5

Alm do tipo de problema, a combinao de alguns valores para certas

caractersticas tambm responsvel por indicar um diferente grau de relevncia para
algumas caractersticas. Essas inter-relaes entre caractersticas so implementadas
atravs de regras, que so aplicadas nos casos que possuem determinados valores para as
caractersticas. Exemplo de uma caracterstica que determina uma maior relevncia o
tipo de interface de rede, que para o valor Ethernet indica uma maior relevncia da
caracterstica tipo especfico de interface. Trs destas regras podem ser vistas a seguir.
Exemplos adicionais destas regras so apresentados no anexo 2.
SE tipo de problema = conectividade-genrico OU
tipo de problema = conectividade-fsico e config/HW OU tipo de problema = performance OU
tipo de problema = alto trfego E provvel componente falha fsica possui cabeamento OU
provvel componente falha fsica possui equipamento interconexo enlace
ENTO tipo interface rede peso 5

102
SE tipo de problema = conectividade-genrico OU
tipo de problema = conectividade-fsico e config/HW OU tipo de problema = performance OU
tipo de problema = alto trfego E provvel componente falha fsica possui cabeamento OU
provvel componente falha fsica possui equipamento interconexo enlace E
tipo interface rede contm Ethernet
ENTO tipo especfico interface PESO 3
SE tipo de problema = conectividade-genrico OU tipo de problema = roteamento/endereamento E
localizao do problema = entre mesma sub-rede IP
ENTO acessibilidade entre hosts e roteador PESO 1

As demais caractersticas do caso, tais como breve descrio do problema e

mensagem, possuem valores de importncia assinalados globalmente, independente do
contexto da situao.
5.5.2.4 Classificao e Ordenamento
O processo de classificao dos casos consiste na avaliao do grau de
similaridade entre cada um dos casos recuperados e o caso corrente, ordenando os casos
em ordem decrescente de similaridade e selecionado os casos melhor classificados.
O processo inicia com a anlise das caractersticas especficas do caso corrente.
Assim, os casos recuperados so passados por filtros onde, para cada caracterstica
especfica filtro do caso corrente, so eliminados os casos que possurem aquela
caracterstica e esta possuir similaridade inferior mnima definida para ela. Foi
estudada, tambm, a incluso de filtros adicionais no problema, representados pelas
caractersticas extremamente relevantes. Optou-se, porm, por no fazer a eliminao
dos casos por essas caractersticas e, sim, utiliz-las atribuindo um alto valor de
relevncia na funo de avaliao, direcionando, assim, os casos com essas
caractersticas para os casos melhores classificados.
A etapa seguinte consiste ento na avaliao numrica dos casos recuperados que
foram mantidos aps passarem pelo filtro das caractersticas especficas. Essa avaliao
efetuada utilizando um clculo em que considerada a similaridade entre todas as
caractersticas do caso: tipo de problema, breve descrio do problema, demais
caractersticas gerais acerca do problema, caractersticas adicionais, caractersticas
especficas.
A similaridade do tipo de problema obtida pela probabilidade do tipo de
problema do caso recuperado resultante da elaborao da caracterstica tipos de
problemas relacionados (vide seo 5.5.1.2). As caractersticas gerais acerca do
problema, assim como a breve descrio, possuem grau de relevncia igual para todos os
problemas. As caractersticas adicionais, por sua vez, possuem grau de relevncia
relativo ao contexto, conforme comentado na seo anterior, sendo utilizado o contexto
do caso recuperado. Por fim, as caractersticas especficas so utilizadas no casamento
segundo sua relevncia.
O clculo da similaridade entre o caso corrente e cada caso recuperado
realizado pelo somatrio da similaridade entre cada caracterstica com valor elaborado
multiplicado pela relevncia desta para o contexto do caso recuperado, conforme
apresenta a funo de avaliao numrica na figura abaixo.

103
n

Similarida de(Cr , R ) =

Wi * sim f
i =1

n
i =1

C
i

R
i

* Ci

Wi * Ci

onde Wi : importncia da caracterstica i

sim: funo de similaridade para a caracterstica
fiC e fiR : valores para a caracterstica fi no caso corrente e
caso recuperado
Ci : confiana da similaridade da caracterstica i, sendo 0
para valor elaborado, 1 para valor no elaborado

FIGURA 5.10 - Funo de avaliao numrica utilizada para a classificao

dos casos recuperados
Entretanto, quando uma caracterstica no foi respondida, ela no calculada no
fator similaridade do caso a similaridade contabiliza apenas aquelas caractersticas que
podem ser comparadas, aquelas que esto elaboradas (representadas pelo fator 1 para
confiana na caracterstica), indicando a similaridade entre os dados disponveis.
Percebeu-se, com isso, a necessidade da criao de um outro fator que levasse em conta
o quanto a similaridade entre dois casos calculada confivel, o quanto ela representa de
fato a similaridade confirmada no caso. Esse fator foi chamado de confiabilidade.
A confiabilidade calcula pelo somatrio das relevncias das caractersticas que
foram contabilizadas na similaridade (as que estavam elaboradas) dividido pelo
somatrio das relevncias de todas as caractersticas que deveriam ter sido
contabilizadas. A funo para clculo da confiabilidade expressa na figura abaixo.
n

Confiabili dade (Cr , R ) =

Wi * Ci
i =1

n
i =1

Wi

onde Wi : importncia da caracterstica i

Ci : confiana da similaridade da caracterstica i, sendo 0
para valor elaborado, 1 para valor no elaborado

FIGURA 5.11 - Funo para clculo da confiabilidade do casamento entre

dois casos
Por fim, feito o ordenamento dos casos de acordo com o resultado da
similaridade e confiabilidade de cada um. A funo para clculo do fator de
ordenamento, utilizando a confiabilidade e similaridade apresentada na figura abaixo,
sendo atualmente utilizado o valor 2 para a importncia da similaridade.

104

FatorOrden amento( R) =
onde

I * Similaridade(Cr , R) + Confiabilidade(Cr , R)
I +1

Similaridade(Cr,R): similaridade entre os casos

Confiabilidade(Cr,R): confiabilidade do casamento entre os casos
I : importncia da similaridade frente a confiabilidade

FIGURA 5.12 - Funo para clculo do fator de ordenamento

5.5.3 Reutilizao e Reviso

Aps os melhores casos serem selecionados entre os casos recuperados da base,
a experincia destes deve ser reutilizada na situao corrente seja a experincia
referente soluo encontrada, seja a experincia referente identificao de que
informaes ou aes de diagnstico devem ser aplicadas situao para levar soluo
do problema.
Os casos recuperados num primeiro ciclo de execuo, contudo, tm a descrio
formada apenas por caractersticas gerais dos problemas e gerais do seu tipo de
problema, no tendo ainda sido identificadas informaes especficas para o problema
corrente. A fim de tratar isso, o sistema oferece nessa etapa um processo de refino da
recuperao, fazendo com que o usurio possa optar por aplicar uma soluo no
ambiente real apenas depois que todas as informaes sobre a situao recuperada sejam
similares situao corrente.
Esse processo realizado atravs de um refinamento do contexto, que permite
que o mdulo de recuperao garanta casos mais similares, j que a nova descrio do
problema prov um maior entendimento da situao corrente. Esse processo pode ser
usado, tambm, depois que uma soluo proposta j tenha sido avaliada no mundo real e
no tenha obtido sucesso, fornecendo meios para o aprimoramento da recuperao de
um caso melhor para a situao corrente.
Optou-se, nesse sistema, por esta abordagem, em que o usurio no necessita
utilizar obrigatoriamente o processo de refino, para permitir uma maior flexibilidade de
uso do sistema para especialistas. Os usurios podem, portanto, por conhecimento
especialista prprio, optar por aplicar imediatamente no ambiente real uma soluo
proposta que no tenha todas as informaes validadas, seja por avaliar que esta soluo
se adeqa perfeitamente situao corrente, seja por conhecer mecanismos de adaptao
que permitam reutiliz-la mesmo sem dispor das informaes especficas sobre os casos
recuperados que so propostas pelo processo de refino.
Nesse caso, o refino no precisa ser utilizado e a experincia proposta
reutilizada diretamente, sendo aplicada ao ambiente real e avaliados os seus resultados.
Nessa verso do sistema no foi desenvolvido um processo de adaptao automtica
pelo sistema da soluo proposta mecanismo que, como aponta Watson,
freqentemente efetuado em muitas aplicaes apenas pelos usurios [WAT 97]. Desta
forma, os casos recuperados so oferecidos aos usurios a fim de que sua soluo possa
ser reutilizada no problema corrente, podendo, quando necessrio, ser adaptada pelo
usurio (adaptao baseada em crtica [LEW 95]).

105

Se os resultados da avaliao no ambiente real mostrarem que o problema foi

solucionado com a experincia reutilizada, o caso corrente deve ser encerrado, sendo ou
no aprendido pelo sistema (dependendo da sua soluo ter sofrido ou no alguma
alterao pelo usurio). Se, entretanto, os resultados da experincia proposta indicarem
que a experincia no pde ser aplicada, uma nova soluo deve ser proposta. Para isso,
aplicado o processo de refino. A figura a seguir esquematiza o processo.

RECUPERAO: BUSCA
E CLASSIFICAO
refino da recuperao
novas informaes
redefinio do contexto
novo processo de recuperao

casos recuperados:
experincia proposta
informaes para redefinio do contexto
usurio aceita refino proposto
pelo sistema
usurio opta por aplicar soluo
utilizando adaptao baseada em crtica
ou no, reutilizao da soluo proposta
avaliao dos resultados

soluo no foi adequada

problema solucionado
encerramento do caso

FIGURA 5.13 - Esquema do processo de reutilizao e reviso do sistema

5.5.3.1 Redefinindo o Contexto
O processo de refino consiste numa nova avaliao da situao, atravs de um
processo de redefinio do contexto, j utilizado em outras aplicaes [SIM 92]
[KOL 93]. Na abordagem adotada nesse sistema, o processo realizado dinamicamente,
definindo novas elaboraes teis baseado nas similaridades entre os casos recuperados.
Assim, uma elaborao escolhida porque identifica uma informao especfica dos
casos recuperados que se avalia ser tambm til para melhor descrever o problema
corrente, e que com isso contribuir por selecionar um subconjunto melhor definido de
casos similares entre os casos recuperados.
Para isso, so extradas dos casos recuperados caractersticas que contriburam,
na situao anterior, para a evoluo do diagnstico do problema, a fim de que a
descrio do caso atual seja melhor definida por possuir tambm estas informaes (que
so implementadas atravs das caractersticas especficas, comentadas anteriormente na
seo 5.4.1). Para que as informaes referentes a essas caractersticas sejam fornecidas
pelos usurios, muitas vezes necessrio que estes efetuem aes de diagnstico para
possui-las. Assim, essa abordagem aplicada no domnio de gerenciamento de redes
contribui de modo conjunto para o fornecimento de uma melhor definio do problema e

106

para a identificao de aes que podem ser efetuadas no problema corrente, permitindo
a evoluo do diagnstico desta situao, j que fornecem novos dados que produzem
um andamento do processo de diagnstico.
O processo inicia com a identificao de todas as caractersticas especficas dos
casos fornecidos pelo mdulo seletor. A seleo de que caractersticas devem ento ser
elaboradas e a ordem como estas caractersticas sero solicitadas realizada
considerando quatro fatores: (i) o custo de obteno da informao, (ii) a probabilidade
desta caracterstica contribuir no problema, (iii) condies desta caraterstica influenciar
um maior nmero de casos e (iv) a ordem em que esta informao foi fornecida no caso
armazenado.
O custo da obteno da informao (i) diz respeito dificuldade do usurio em
obter a resposta para a informao solicitada. Nesse princpio, caractersticas que podem
ser informadas mais facilmente so preferidas frente quelas que envolvem aes mais
demoradas ou complexas de serem efetuadas. A probabilidade da caracterstica
contribuir para o problema (ii) identificada pelo grau de similaridade do caso
recuperado que a indicou, ou, em caso de estar presente em vrios casos, pelo grau de
similaridade do melhor caso. Dessa forma, caractersticas resultantes dos casos com
maior similaridade so preferidas frente s caractersticas dos demais, j que esses casos
possuem uma maior probabilidade de serem teis para o problema corrente.
O nmero de vezes que uma caracterstica aparece nos casos selecionados
tambm considerado. Esse fator permite identificar as caractersticas com condies de
influenciar um maior nmero de casos (iii), que so preferidas em relao s
caractersticas que aparecem em menos casos. Por fim, para selecionar a ordem em que
as caractersticas so solicitadas tambm considerada a ordem em que uma
caracterstica foi informada no caso recuperado (iv). Esse princpio visa privilegiar a
ordem original dessas informaes nos casos armazenados, evitando que uma informao
que relevante por resultado de outra seja solicitada antes da que indicou sua relevncia.
Nessas situaes, ambas caractersticas podem ser solicitadas, mas a ordem em que elas
foram informadas no caso mantida. Juntos, estes quatro fatores contribuem na escolha
das caractersticas que sero elaboradas.
Uma vez que as caractersticas so selecionadas, elas so solicitadas ao usurio.
No foram concebidos, nesta verso, meios de obteno das caractersticas especficas
automaticamente, a menos aquelas caractersticas especficas que so operaes sobre
uma caracterstica adicional. O usurio pode informar aquelas que achar mais
conveniente, respondendo apenas s primeiras ou pulando algumas, conforme seu
conhecimento e condies de obt-las no momento. Uma vez informadas, a descrio do
caso corrente refinada com as novas caractersticas e uma nova recuperao efetuada.
Com essas caractersticas, as solues propostas anteriormente, atravs dos casos
recuperados, podem ser validadas ou consideradas imprprias pelo sistema, podendo,
portanto, ser selecionados novos casos, ser eliminados casos selecionados anteriormente
ou alterando o grau de similaridade dos casos j recuperados.
Aps os novos casos serem recuperados, um novo processo de refino pode ser
solicitado ou uma soluo proposta pode ser reutilizada se for julgada adequada, sendo
aplicada no ambiente real diretamente ou sofrendo algumas adaptaes pelo usurio. Se
o problema for solucionado, o caso encerrado e o sistema solicita do usurio se a
soluo foi utilizada diretamente ou se foi modificada devendo ser, ento, aprendida

107

pelo sistema. Se, entretanto, o problema no foi solucionado, um novo refino pode ser
aplicado, reiniciando o ciclo de recuperao.

5.5.4 Aprendizado
Aps o caso ser solucionado, ele encerrado podendo ou no ser aprendido pelo
sistema. Um caso aprendido quando ele representa uma experincia nova, uma
experincia para a qual o sistema no foi capaz de propor uma soluo adequada seja
porque o sistema props uma soluo que precisou ser adaptada, seja porque no props
a melhor soluo para a situao. Nesses casos, a experincia obtida com o processo
deve ser retida no sistema atravs de um novo caso.
Se, entretanto, a soluo proposta pelo sistema foi adequada, o caso no precisa
ser aprendido como um caso para CBR. Ele deve, porm, ser armazenado no sistema
como um registro simples a fim de permitir que sejam mantidas no sistema as funes
colaborativas de sistemas de registro de problemas tradicionais (tais como anlise
estatstica dos equipamentos da rede, anlise da produtividade do centro de gerncia,
criao de relatrios estatsticos de controle de qualidade, etc.). Para isso, o registro de
problema (caso corrente) encerrado, sendo atualizado com as informaes referente ao
encerramento de um registro (tais como data, hora, causas, tipo de problema real,
soluo, autor) e registrado como um registro simples, que no ser utilizado nos
processos CBR subsequentes. A nica modificao no sistema diz respeito atualizao
da relao entre os tipos de problemas.
O encerramento de um caso que ser aprendido, contudo, exige algumas etapas
adicionais. Inicialmente, o registro-caso atualizado com as informaes referentes ao
encerramento, de modo similar ao encerramento de um registro simples. Aps esta etapa,
as informaes do caso devem ser confirmadas e novas informaes devem ser
fornecidas, tanto para o caso como para o aumento do conhecimento geral do sistema.
Em primeiro lugar, as caractersticas adicionais sobre o tipo de problema final
que ainda no tenham sido informadas pelo usurio so solicitadas e as demais so
apresentadas para que sejam confirmadas. Isso significa, portanto, que se o tipo de
problema real (informado no encerramento do registro) for diferente do tipo de problema
inicial, as caractersticas adicionais que no forem comuns aos dois sero solicitadas.
Nesta etapa, so tambm solicitadas informaes que no tenham sido fornecidas
inicialmente por representarem uma nova informao tais como um novo sistema
operacional, um novo produto, uma nova aplicao. Para isso, o novo termo deve ser
informado e os demais termos daquela dimenso (referentes a mesma caracterstica) j
cadastrados so apresentados, a fim de que a similaridade do novo termo com os demais
seja informada, utilizando-se para isso dos conceitos referentes ao grau de similaridade
total(1,0), alto(0,7), mdio(0,5), baixo(0,3), nenhum(0), sendo este ltimo o grau
atribudo quando o grau entre dois termos no for fornecido.
Embora esta abordagem exija um certo conhecimento especialista do usurio,
pois exige que o usurio relacione o novo termo com os demais, ela necessria porque
permitir a evoluo do sistema com a utilizao de novas tecnologias (representadas
pelos novos termos dentro de cada categoria). Entretanto, essas informaes no
apresentam de modo geral uma complexidade elevada (j que muitas vezes novos
elementos representam novas verses, ou so desenvolvidos como pequenas
modificaes de outros elementos, ou mesmo porque a categoria a que eles fazem parte

108

conhecida usualmente pelos usurios que sabem, por exemplo, que um sistema
operacional Solaris um sistema operacional Unix, informao necessria ao se
acrescentar este sistema operacional ao sistema). Portanto, acredita-se que essa
abordagem possa permitir uma certa evoluo do conhecimento do domnio, ao passo
que se no fosse utilizada, o sistema acabaria por apresentar uma gradativa perda de
desempenho, mesmo com a insero de novos casos, j que as informaes solicitadas
so aquelas que se acreditam ser importantes para diferenciar problemas, e esta
comparao baseia-se sobretudo na similaridade de seus termos.
Por fim, necessria a manipulao sobre as caractersticas especficas do caso.
Para isso, devem ser indicadas quais dentre as caractersticas especficas j informadas
no seriam necessrias para a evoluo do problema aquelas, portanto, que foram
solicitadas pelo sistema, foram respondidas, mas que ao final pde ser identificado que
no contriburam de modo relevante para a evoluo do problema, e no seriam
necessrias para que o problema fosse identificado e a soluo encontrada. Essas
caractersticas sero identificadas como no relevantes no caso e no sero utilizadas
para propor novas informaes no processo de reutilizao nem sero utilizadas como
filtros.
Alm de identificar quais informaes no foram relevantes, o encerramento do
problema permite ainda identificar informaes relevantes que no tenham sido
informadas na descrio do problema. Informaes, portanto, que so importantes para
descrever o problema e devem ser inseridas para que um caso similar seja identificado.
Para isso, apresentado ao usurio o conjunto de caractersticas especficas cadastradas,
assim como os possveis valores para cada uma, e as caractersticas desejadas podem ser
inseridas no caso. Podem existir, entretanto, informaes que no estejam representadas
pelas caractersticas cadastradas: nessa circunstncia, permitido ao usurio inserir uma
nova caracterstica especfica no caso. Nesta verso do sistema, entretanto, no foram
identificados meios para controlar uma insero de caractersticas especficas que seja
feita livremente. Assim, aceito apenas que sejam cadastradas caractersticas especficas
do tipo caracterstica binria (vide seo 5.5.2.2), deixando-se para uma prxima verso
o estabelecimento de processos que controlem a criao de caractersticas com termos
variveis (e, portanto, controlem seus termos e a similaridade entre eles).

5.6 Consideraes Finais

Este captulo apresentou o modelo proposto para o sistema DUMBO. A
representao dos problemas do domnio no qual o sistema validado foi abordada. A
representao dos casos e a organizao da base de casos utilizada para o sistema foram
comentadas, bem como as abordagens concebidas para os processos de raciocnio.
No captulo a seguir, apresentaremos o prottipo desenvolvido para validao
deste modelo, comentando aspectos de sua implementao e a avaliao de seus
resultados.

109

6 Prottipo do Sistema
Este captulo visa, com os subsdios fornecidos pelos captulos anteriores,
apresentar a arquitetura do prottipo desenvolvido para o sistema DUMBO, os
resultados obtidos por ele e comentar sobre sua comparao com os outros sistema
similares encontrados na bibliografia.

6.1 Implementao
A complexidade e variedade das falhas em redes possibilita que ocorram
situaes que atinjam mais de um domnio de gerncia. Essas situaes so tratadas pela
interao dos especialistas dos diversos domnios envolvidos no problema. Se uma
situao for facilmente solucionada pelo sistema, essa interao se torna reduzida. Em
ocorrncias que no possuam antecedentes na rede, entretanto, o diagnstico pode levar
horas ou mesmo dias, exigindo, dessa forma, uma grande interao entre os especialistas.
A fim de suportar esta interao, a interface do ambiente apoiada pelo ambiente
WWW, atravs de CGI. No ambiente disponibilizado, os diversos especialistas podem
interagir com o sistema criando novos registros ou anexando novas informaes a um
registro corrente (aberto) e solicitando novas consultas ao sistema CBR, que pode
aprimorar seu processo de raciocnio com os novos dados fornecidos.
Para disponibilizar o acesso aos vrios usurios de diferentes domnios, o sistema
possui um cadastro destes e apenas usurios autorizados tm acesso criao de
registros e interao com registros de situaes correntes. O aprendizado de um novo
caso tambm controlado, sendo autorizado apenas para usurios com nvel de acesso
superior. Isso necessrio devido relevncia das informaes fornecidas no
aprendizado de um novo caso, as quais devem ser fornecidas corretamente para no
prejudicarem o conhecimento do sistema.
O sistema foi implementado em plataforma Unix, em sistemas SunOS4.x e Linux.
Foi utilizada a linguagem C. O banco de dados utilizado foi o POSTGRES
[RHE 90][STO 90], escolhido por ser utilizado pelos projetos do grupo e pelo sistema
de registro de problema do ambiente CINEMA e por ser de domnio pblico, ampliando
assim a portabilidade do sistema.
Comentaremos a seguir o prottipo implementado. Utilizaremos para a
especificao do prottipo a Linguagem de Descrio e Especificao SDL
(Specification and Description Language). Detalhes sobre esta linguagem podem ser
encontrados em [TRI 92].

6.1.1 Arquitetura do sistema

O sistema foi projetado numa arquitetura cliente-servidor. Os mdulos cliente so
representados pelos diversos mdulos CGI, que so responsveis pelas funes de
interfaces e pequenos procedimentos relativos a ela. O raciocnio principal do sistema
implementado pelo mdulo servidor, que consultado e atualizado pelos diversos
mdulos CGI clientes.
Aos mdulos CGI cabe a interface com o usurio. Atravs deles, feita a
solicitao de criao de um novo registro-caso, a coleta de informaes sobre um caso

110

corrente do usurio seguindo as indicaes providas pelo servidor, a apresentao dos

casos recuperados e a solicitao de novas informaes para refino, a insero de notas e
de novas informaes, o encerramento de um caso. O mdulo servidor, por sua vez, o
responsvel por processar os dados, criando novos casos, realizando os procedimentos
de recuperao de casos similares, selecionando as caractersticas especficas mais
relevantes, etc. A figura abaixo apresenta a definio do sistema.
SYSTEM Dumbo

SIGNAL

B1[dB1]

S1(dados),
S2(dados),
dB1(dadosdB1),
dB2(dados dB2),
SAtualiza(dadosAtualiza),
SLeitura(dadosLeitura)

PEDIDO[S1]

Browser
WWW B2[dB2]

Cliente

RESPOSTA[S2]

Servidor

CLeitura[SLeitura]

CAtualiza[SAtualiza]

Banco de Dados

FIGURA 6.1 - Diagrama do sistema Dumbo

Os clientes, para executarem suas tarefas, fazem uso de funes para a
comunicao com o servidor e para a interface com o usurio, alm do processamento
das informaes fornecidas. O diagrama do bloco cliente pode ser visto na figura a
seguir.
BLOCK Cliente

SIGNAL Si1..Sin
Si1: tuser
Si2: tinf
Si6: queryret

B1 R1[dB1]

Interpreta
Dados

R3[Si1]
R4[Si2]

R10[Si10]

B2

R11[S1]

R2[dB2]

Monta
Tela

R6[Si6]

Processa
Operaes

R9[Si9]

PEDIDO

Comunicao
R12[S2]
Cliente
RESPOSTA

FIGURA 6.2 - Diagrama do bloco cliente

Cada cliente formado por quatro mdulos. Um primeiro mdulo responsvel
pela interpretao dos dados no formato CGI, denominado InterpretaDados. Aps a

111

interpretao dos dados fornecidos pelo usurio, o cliente faz a validao do usurio,
consultando o servidor, atravs do mdulo ComunicaoCliente. Pela estrutura dos
programas CGI e por questes de segurana, cada cliente faz, de modo transparente ao
usurio, a validao do usurio. Quando um usurio no validado, uma mensagem
apresentada ao usurio e o cliente termina suas tarefas, no fazendo nenhuma alterao
sobre o sistema. Em situaes normais, entretanto, um usurio no ser validado apenas
no programa CGI de entrada no sistema, sendo o mecanismo completamente
transparente ao usurio nos programas posteriores.
Aps o usurio ser validado, a comunicao estabelecida com um processo filho
do bloco servidor mantida e utilizada pelo cliente at que nenhuma consulta ao servidor
seja necessria, quando uma mensagem de encerramento enviada e o processo filho do
bloco servidor finalizado. Aps a validao, o cliente passa ao mdulo
ProcessaOperaes, que o responsvel por realizar as operaes referentes funo
do programa CGI em execuo. Essas funes incluem entrada no sistema, opo por
criao de um novo registro de problema, fornecimento das informaes iniciais sobre o
problema, fornecimento das informaes adicionais sobre o problema, solicitao da
recuperao de caso similar, encerramento de um registro de problema, etc. Cada
programa, de acordo com sua funo, pode executar uma ou vrias consultas ao
servidor, fazendo leituras e enviando atualizaes de informaes do banco, solicitando
consultas da caracterstica provveis tipos de problemas, solicitando os casos similares,
entre outras.
Aps todas as operaes necessrias serem executadas pelo mdulo, ele solicita
ao mdulo ComunicaoCliente o envio de uma mensagem de encerramento e envia ao
mdulo MontaTela os dados resultantes das suas operaes, que devem ser apresentados
ou solicitados ao usurio. Os diagramas dos mdulos do bloco cliente podem ser vistos
no anexo 4.
O bloco servidor, por sua vez, o responsvel pela interface com o banco de
dados e pela maior parte das funes de raciocnio do sistema. Esse bloco est
estruturado em quatro mdulos: mdulo responsvel pela comunicao, denominado
ComunicaoServidor; mdulo responsvel pelo encaminhamento das solicitaes,
denominado Servidor; mdulo CBR, responsvel pela execuo dos processos de
raciocnio do sistema e mdulo InterfaceBD, responsvel pelo acesso ao banco de dados.
A figura a seguir apresenta o diagrama do bloco servidor.

112

BLOCK Servidor

SIGNAL Si1..Sin
CBR
R4[Si4]

PEDIDO
RESPOSTA

R5[Si5]]

R1
R2

Si3: tquery
Si4: tdadoscbr
Si5, Si7: tdados
Si6: tbdini

Comunicao R3[Si3]
Servidor

Servidor
R6[Si6,Si7]

Interface
BD
R8[Si9]

CLeitura

R7[Si8]

CAtualiza

FIGURA 6.3 - Diagrama do bloco servidor

O mdulo responsvel por coordenar os pedidos recebidos e distribu-los para os
mdulos correspondentes o mdulo Servidor, apresentado na figura a seguir.
Inicialmente, no momento da ativao do programa, o mdulo Servidor envia para o
banco de dados os procedimentos de inicializao do banco, de acordo com o nmero IP
e a porta de comunicao com o banco, alm de selecionar a base que ser consultada
(base dumbo). Aps esses procedimentos, ele entra num estado em que fica aguardando
mensagens do mdulo ComunicaoServidor com consultas solicitadas pelo bloco
cliente.
Quando uma mensagem recebida, para que o servidor possa atender outros
pedidos de outros clientes, ele cria um processo filho para tratar a mensagem recebida e
efetuar as consultas solicitadas pelo cliente. A primeira mensagem recebida traz os dados
do usurio e sua senha de acesso ao sistema. Com essas informaes, o servidor consulta
o mdulo InterpretaBD sobre o acesso do usurio, e envia para o ComunicaoServidor
se o usurio foi ou no validado. No caso do usurio no ter sido aceito, aps o envio do
sinal ao ComunicaoServidor, o processo filho finalizado e nenhuma outra consulta
do cliente ser aceita enquanto nova validao no for realizada. No caso do usurio ter
sido aceito, o processo filho entra num estado em que aguarda consultas vindas do
cliente, enviando-as para o mdulo InterpretaBD ou CBR de acordo com o seu tipo. As
consultas do tipo BD representam operaes de leitura, criao ou atualizao do banco
de dados diretamente, sem necessitar que os dados sejam manuseados pelo sistema. As
consultas do tipo CBR, entretanto, representam operaes que requerem tratamento do
sistema, representando funes que fazem parte dos processos do ciclo CBR.

113

PROCESS Servidor

PROCESS filho

Servidor

query: tquery
respUser: tdados
dadosIniBD: tdbini

filho

Si6(dadosIniBD)

Si7(..)

EsperaRespUser

idle

Si7(respUser)

Si3(...)

CREATE filho(...)

userOk
(respUser)

idle
Si3(user invlido)

Si3(user vlido)
ProcessaPedidos
Si3(query)

tipo
(query.tipo)

ENCERRA

BD

Si7

AguardaBD

Si7
Si3

ProcessaPedidos

CBR

Si4

AguardaBD

Si4
Si3

ProcessaPedidos

FIGURA 6.4 - Definio do Servidor

O mdulo InterpretaBD apresentado na figura A4.5, no anexo 4. Este mdulo
o responsvel pela interface com o banco de dados, que realizada atravs da
linguagem POSTQUEL [STO 90][RHE 90]. O mdulo composto por procedimentos
que acessam as diversas tabelas do sistema DUMBO, realizando procedimentos de
leitura de dados, criao de novos registros no banco e atualizao de dados existentes.
A base de dados do sistema DUMBO composta por diversas tabelas que
armazenam os dados gerais do sistema, tais como dados de controle e usurios, e a base
de conhecimento, formada pelos registros-casos e pelo conhecimento utilizado pelo
sistema, representado pelas informaes de similaridade entre os dados, pela relao
histrica entre os tipos de problemas, etc. A tabela abaixo apresenta as principais tabelas
presentes no sistema e os dados que elas armazenam.

114

TABELA 6.1 - Tabelas do banco de dados do sistema DUMBO

Tabela
USER
CONTROLE
TTMANAG
TTCBR
TIPOSREL
TTCARAC_ESP
CAD_CARACESP
TIPOSEQUIP
SISOPER
PRODUTOS
FUNCOES
FUNCTIPO
PRODSO
ESTADOSITF
TIPOSITF
NUMCADASTRO
TERMOS
TERMOSNULOS
TERMOSSIM

Descrio
Informaes sobre os usurios cadastrados no sistema.
Informaes de controle do sistema.
Dados dos casos armazenados com as informaes
com carter de gerenciamento.
Dados dos casos armazenados com as informaes
utilizadas pelo raciocnio do sistema.
Relao histrica entre os tipos de problemas.
Caractersticas especficas dos casos armazenados.
Cadastro das caractersticas especficas do sistema.
Cadastro dos tipos de equipamentos j informados.
Cadastro dos sistemas operacionais j informados.
Cadastro dos produtos j informados.
Cadastro das funes dos equipamentos j informadas.
Cadastro das relaes entre as funes e tipos dos
equipamentos.
Cadastro das relaes entre produtos e sistemas
operacionais.
Cadastro dos estados de interface j informados.
Cadastro dos tipos de interfaces j informados.
Cadastro da similaridade das caractersticas numricas.
Cadastro dos termos registrados no sistema para
similaridade da caracterstica breve descrio.
Cadastro dos termos sem significado especial,
registrados como nulos.
Informaes sobre a similaridade entre termos.

A tabela USER e CONTROLE armazenam dados gerais do sistema. Os casos

so formados pelas tabelas TTMANAG, TTCBR e TTCARAC_ESP. As tabelas
TIPOSEQUIP, SISOPER, PRODUTOS, FUNCOES, ESTADOSITF, TIPOSITF,
FUNCTIPO e PRODSO contm o cadastro das informaes dos diversos tipos de
caractersticas presentes no sistema. Estas tabelas so utilizadas no momento da insero
da caracterstica do tipo correspondente em um novo caso, a fim de apresentar os
elementos j cadastrados, e no momento do casamento entre casos, quando suas
informaes sobre a similaridade entre os diversos elementos so utilizadas. Um exemplo
pode ser visto na tabela PRODUTOS, que, alm do nome do produto, permite
armazenar sua famlia. Produtos diferentes mas de uma mesma famlia possuem
similaridade maior que produtos diferentes que no fazem parte da mesma famlia.
Outro exemplo pode ser observado na tabela SISOPER, que permite armazenar,
alm do sistema operacional, sua famlia e seu tipo geral. Assim, por exemplo, dois
sistemas operacionais Solaris podem ser cadastrados como pertencentes a uma mesma
famlia, e um sistema operacional Solaris e um Linux podem ser cadastrados como do
mesmo tipo geral Unix. Com isso, se dois produtos forem diferentes, e sua famlia
tambm, a similaridade pelo tipo (com valor inferior ao da similaridade da famlia) ainda
permitida. Alm destas, a tabela NUMCADASTRO contm informaes sobre os
intervalos que so utilizados para a similaridade entre caractersticas numricas.

115

A tabela TIPOSREL contm as informaes sobre a relao histrica entre os

tipos de problema. Por fim, as tabelas TERMOS, TERMOSNULOS e TERMOSSIM
contm informaes sobre termos de uma descrio que so utilizados para fazer o
casamento do campo breve descrio.
Por fim, o bloco servidor composto pelo mdulo CBR, o mdulo responsvel
por executar aquelas funes de raciocnio do sistema que so executadas pelo bloco
servidor (e no pelos clientes CGI). Para a execuo destas funes, podem ser
necessrias uma ou mais consultas ao banco de dados (atravs do InterpretaBD), como
demonstra o diagrama na figura abaixo, variando de acordo com a funo solicitada.
PROCESS CBR
d1: tdadosCbr
d2, consBD: tdados

CBR
EsperaConsulta
Si4(d1)

d2=null
ProcessaCBR
consBD=processaConsulta(d1,d2)

Si5(consBD)

EsperaResp
Si5(d2)
bool=hNecessidadeMaisProcessamento(d1,d2)

false

Si3(user vlido)

bool

true

ProcessaCBR

EsperaConsulta

FIGURA 6.5 - Definio do CBR

As funes executadas pelo mdulo CBR incluem a identificao dos provveis
tipos de problemas e a recuperao de casos similares e de caractersticas especficas
relevantes. A identificao dos provveis tipos de problemas faz parte do processo de
definio do contexto, apresentado na seo 5.5.1. Esse processo tambm compreende
funes executadas pelo cliente, que faz a elaborao das informaes iniciais e
caractersticas adicionais sobre o problema, e solicita ento a relao dos provveis
tipos de problemas ao servidor para apresent-la ao usurio no momento da
recuperao.

116

A solicitao da recuperao de casos similares pelo cliente, por sua vez, inclui
um conjunto de operaes em que so feitas consultas s informaes do banco e
processamento sobre estas. Inicialmente, o mdulo recebe o identificador do caso que
deseja recuperar e os tipos de problemas que deve consultar (que podem ter sido
alterados pelo usurio, embora mantenham o valor para casamento idntico ao
encontrado na definio do contexto). O caso completo , ento, recuperado do banco, e
so efetuadas algumas operaes.
Inicialmente, a caracterstica referente aos provveis componentes com possvel
falha fsica elaborada pelo sistema. Essa elaborao feita com a implementao das
regras comentadas na seo 5.5.1.1, que foram implementadas atravs de comandos ifthen. Aps esta etapa, feita a definio da relevncia das caractersticas do caso para
cada tipo de problema que ser consultado. Esta definio realizada utilizando valores
fixos para as caractersticas de acordo com o tipo de problema e um conjunto de regras
que so relacionadas a certas caractersticas e valores do caso corrente (vide seo
5.5.2.3), que tambm so implementadas atravs de comandos if-then.
Aps, feita a recuperao no banco dos casos cujos tipos de problemas devem
ser consultados, podendo ser ainda aqui aplicados filtros para determinados tipos de
problemas. Exemplo de filtro o aplicado para problemas de conectividade fsico e de
configurao do HW, em que s so consultados aqueles casos que possuem ao menos
um dos padres de tecnologia de rede do caso corrente (problemas que dizem respeito
somente a uma LAN, por exemplo, no sero recuperados para um problema corrente
em linha serial).
Uma vez que a busca na base foi executada, cada um dos casos selecionados
passa pelo processo de casamento. Inicialmente, as caractersticas especficas do caso
recuperado que tm grau de relevncia filtro so comparadas s do caso corrente para
verificar se o caso deve ser eliminado (filtrado). Se o caso permanecer, calculada a
similaridade, a confiabilidade e o fator de ordenamento do caso, conforme descrito na
seo 5.5.2.4. A similaridade de cada caracterstica implementada segundo seu tipo
(vide tabela 5.1): algumas, utilizando similaridade exata ou proporcional ao nmero de
termos iguais em caractersticas com termos mltiplos (tais como enlaces envolvidos,
sub-redes envolvidas); outras, que possuem termos fixos, utilizando valores pr-definidos
para o casamento destes termos (tais como abrangncia do problema, localizao do
problema); um outro grupo, utilizando a similaridade prpria da caracterstica envolvida,
fazendo, para isso, uso de informaes armazenadas na tabela do tipo da caracterstica
(tal como produtos, sistemas operacionais) ou na tabela com os intervalos numricos (tal
como intervalos de percentual de utilizao da rede); e, por fim, a caracterstica breve
descrio tem sua similaridade segundo a ocorrncia de termos cadastrados iguais ou
similares.
Uma vez que o casamento foi realizado para todos os casos, feito o
ordenamento destes segundo o fator de ordenamento de cada um, e as caractersticas
especficas de um nmero pr-definido de melhores casos so selecionadas, ordenadas e
enviadas ao cliente, junto aos casos com melhor casamento.
Os diagramas SDL dos mdulos ComunicaoServidor, InterfaceBD e dos
mdulos do bloco cliente podem ser encontrados no anexo 4.

117

6.1.2 Interao com o sistema

Como comentado anteriormente, a interao do usurio com o sistema se d
atravs do ambiente WWW. Aps a validao do usurio no sistema, o usurio dispe de
um menu de opes, em que ele pode escolher a criao de um novo registro de
problema e posteriormente consultar similares a este.
A figura a seguir apresenta a tela para obteno das informaes iniciais do
problema na criao de um novo registro. No exemplo da figura, um problema est
sendo cadastrado como de tipo Conectividade-Genrico, descrevendo um problema no
enlace entre Porto Alegre e SP. Como pode ser observado, so solicitadas informaes
com propsito apenas de gerenciamento, tais como dados do reclamante e responsvel, e
informaes sobre o problema corrente.

FIGURA 6.6 - Tela inicial no registro do caso corrente

Aps as informaes iniciais serem fornecidas pelo usurio, o sistema ir solicitar
informaes adicionais, a fim de elaborar as caractersticas adicionais sobre o problema.
As informaes que iro ser solicitadas variam, como j foi comentado e pde ser
visualizado na rede semntica dos tipos de problemas, apresentada no captulo 5, de
acordo com o contexto da situao o tipo de problema e a localizao do problema
so as duas principais caractersticas que guiam a escolha dessas informaes.

118

Assim, no problema exemplo da figura anterior, a criao de um problema do

tipo Conectividade-Genrico leva solicitao da localizao do problema e outras
informaes, como o tipo de falta de acesso ocorrendo (constante, intermitente) e se esta
parcial ou total. Aps a localizao do problema ter sido obtida pelo sistema, questes
especficas para o contexto encontrado so ento solicitadas. Voltando ao exemplo
anterior, em que informado que a localizao do problema em linha serial, o sistema
apresenta a tela indicada na figura abaixo, em que feita a finalizao da obteno das
caractersticas adicionais.

FIGURA 6.7 - Tela de coleta de caractersticas adicionais para linhas seriais

Aps essa etapa, o sistema identifica (atravs de uma solicitao do cliente ao
servidor) quais so os provveis tipos de problemas, que sero utilizados na busca na
base, e o processo de recuperao solicitado pelo cliente ao servidor. A recuperao
segue conforme apresentado na seo anterior, e os casos recuperados so enviados ao
cliente, que os apresenta ao usurio juntamente com informaes sobre os tipos de
problemas consultados, de modo que no refino o usurio possa alterar esta lista se julgar
conveniente. A figura abaixo apresenta os casos recuperados para o exemplo anterior.

119

FIGURA 6.8 - Tela com casos recuperados

Por fim, quando um problema resolvido, seu registro encerrado e ele pode ser
aprendido pelo sistema se o usurio julgar que o sistema no foi capaz de propor um
caso similar, e portanto, essa situao representa uma situao nova que o sistema deve
armazenar como exemplar e ser utilizado para futuras consultas CBR. Se, contudo, o
sistema recuperou uma situao similar, o registro armazenado apenas para fins de
gerenciamento, como utilizado nos sistemas de registro de problemas tradicionais, com
classificao normal. Para a insero de um caso exemplar, algumas questes adicionais
sobre a soluo devem ser informadas pelo usurio, como comentado no captulo 5, o
que est implementado, nesta verso do prottipo, parte pela interface via CGIs e parte
via interao direta com o banco.
A implementao do prottipo foi desenvolvida priorizando os problemas das
camadas inferiores, correspondentes aos problemas na comunicao da rede os tipos
de problemas das camadas superiores no foram ainda implementados.

120

6.2 Avaliao do Prottipo

A avaliao do prottipo foi desenvolvida em duas etapas. A primeira consistiu
num ajuste do grau da relevncia e similaridade das caractersticas do sistema atribudos
inicialmente na modelagem. A segunda consistiu na avaliao propriamente dita, quando
foram feitas recuperaes para diversas situaes e foram avaliados os pontos negativos
e positivos do prottipo. Essas etapas sero comentadas a seguir.
Inicialmente, foram inseridos no sistema um conjunto de casos que haviam sido
definidos na modelagem. Como foi visto anteriormente, em virtude do tempo disponvel
e do volume dos dados tratados no sistema, o prottipo foi desenvolvido apenas para os
problemas na comunicao. Problemas de tipo aplicao e servios, embora tenham sido
tratados na modelagem, no foram implementados nesta verso.
Os casos inseridos representam problemas que (i) ocorreram no ambiente real
estudado e estavam armazenadas no ambiente CINEMA (10 casos); (ii) ocorreram no
ambiente real estudado e foram adquiridos a partir do relato dos especialistas
entrevistados (6 casos) e (iii) foram retirados da bibliografia (8 casos). O maior nmero
de casos encontrados foram de problemas que se diagnosticou como dos tipos
Conectividade - Fsico e Config/HW e Roteamento/Endereamento.
A tabela abaixo apresenta como os casos do sistema esto distribudos por tipo
de problema. No anexo 3, uma lista com maiores informaes sobre os casos, tais como
o tipo de problema inicial e a localizao, apresentada.
TABELA 6.2 - Distribuio dos casos do prottipo por tipo de problema
Tipo de Problema

Nmero de Casos

Conectividade - Genrico
Conectividade - Fsico e Config/HW
Roteamento/Endereamento
Performance
Alto Trfego

0
11
12
0
1

Na primeira etapa, foram feitas diversas recuperaes no sistema, buscando

analisar e ajustar a relevncia e similaridade das informaes. A anlise da relevncia
atribuda a cada uma das caractersticas, para o contexto das situaes de testes, foi
realizada, e pequenos ajustes nos valores iniciais foram efetuados. Um exemplo foram as
informaes sobre o tipo de equipamento e produto (modelo) para equipamentos com
funo de roteamento que estivessem sendo analisados para falhas fsicas. Inicialmente
atribudos como de grau 3 (caractersticas muito importante), estas caractersticas
tiveram sua relevncia modificada para grau 1 (caractersticas importantes) para
problemas como os de Conectividade - Fsico e Config/HW, j que pde ser percebido
que para problemas deste tipo estas caractersticas no tm tanta relevncia. Assim, o
grau 3 foi mantido apenas para problemas cuja localizao informada como
equipamentos de interconexo de rede.
A similaridade, por sua vez, foi analisada buscando-se uma equivalncia nos
valores de similaridade atribuda para as diversas caractersticas, independente do tipo de

121

informao sendo tratada. Essa primeira etapa consistiu, assim, num ajuste das
caractersticas de modo que as recuperaes da fase posterior pudessem ser realizadas.
A segunda etapa, por sua vez, teve como objetivo avaliar se os casos recuperados
traziam informaes com potencial de contribuir para a soluo corrente, incluindo os
prprios casos recuperados e as caractersticas especficas selecionadas pelo sistema.
Para efetuar esse teste, situaes/casos novas teriam de ser inseridas no sistema, deveria
ser avaliado se o sistema props uma situao adequada e se, dentre o conhecimento
presente nele, esta soluo fazia parte das melhores solues disponveis.
Como se desejava fazer testes com situaes que fossem o mais prximo possvel
do real, utilizar unicamente a criao manual de casos poderia resultar num conjunto
irreal de situaes corrente, que no refletisse de modo adequado o ambiente real.
Assim, optou-se por buscar a soluo para uma situao corrente utilizando, para
algumas recuperaes, casos presentes no prprio sistema. Para isso, cada caso
selecionado para corrente foi excludo do conjunto de casos disponveis para
recuperao e foi reutilizado como se representasse uma situao nova. Em outras
recuperaes, foram utilizados casos adicionais adaptados de situaes relatadas em
entrevistas, e que no haviam sido ainda includas no conjunto de casos.
A seguir, apresentamos dois exemplos de recuperaes efetuadas, um para
problemas em linha seriais, um para problemas em uma LAN, executados sobre o
prottipo contendo os casos apresentados no anexo 3. Para cada um, so apresentadas
as etapas envolvidas na recuperao. Inicialmente, podem ser visualizadas as
informaes da criao do registro com suas principais informaes adicionais. Logo
aps, apresentada uma ou duas recuperaes efetuadas.
Cada recuperao formada pelo conjunto dos casos recuperados e o conjunto
das informaes adicionais solicitadas pelo sistema (caractersticas especficas). As
informaes respondidas na situao so indicadas, e os resultados da nova recuperao
so apresentados. Por fim, os dados referentes soluo so mostrados, as
caractersticas especficas que foram cadastradas pelo caso (se houveram) so indicadas,
e o conjunto das caractersticas especficas que foram mantidas aps o caso ser
encerrado apresentado.

Caso 132 - Criao de Registro e Recuperao

Tipo de Problema Inicial: Conectividade - Genrico
Breve Descrio: Estaes em sub-rede pararam de responder.
Outras Informaes: Estaes da sub-rede no respondem e no
conseguem acesso externo. H mensagem do NFS informando que
servidor NFS no responde. (Caso adaptado de caso modelado
nmero 4 - NFS)
Localizao do problema: mesma_subrede_IP-LAN_com_um_segmento
Falta de Acesso: CONSTANTE
rea do Problema: ANTES_PRIMEIRO_ROTEADOR
Padro de Interface: LAN

Caso 132 - Resultados da primeira recuperao

Trouble Ticket 132 - Tipo de Problema Conectividade - Genrico

122
Consulta efetuada para problemas do tipo Conectividade Genrico. Conectividade - Fsico e Config/HW. Performance
Casos recuperados segundo as informaes j fornecidas sobre o
problema atual:
[0.80]
Similaridade [0.80], Confiana [0.80] - Caso 122 Descrio: Estao no consegue acessar demais nodos.
[0.71]
Similaridade [0.66], Confiana [0.80] - Caso 123 Descrio: Estao no consegue acessar nodos.

Informaes Adicionais Solicitadas:

[0.69]

(Id 19) H alta taxa de colises?

Soluo Caso 132:

Causas: Um dos cabos de rede estava defeituoso.
Soluo Adotada: Troca do cabo resolveu o problema.
Tipo de Problema Final: Conectividade - Fsico e Config/HW
Caractersticas Especficas Cadastradas no Sistema (pelo caso 132):
Id: 21
Descrio: Os cabos e transceivers da rede esto

ok, trocando-os o problema mantm? Grau: relev.5

Tipo: binria

Caractersticas Especficas Finais do Caso 132:

Id: 21
Valor: NO, Ordem: 1

Caso 136 - Criao de Registro e Recuperao

(correspondente a caso 104 retirado)
Tipo de Problema Inicial: Conectividade - Genrico
Breve Descrio: A FAPESP avisa que o circuito com SP esta fora.
Outras Informaes: (Caso correspondente a recriao do caso 104
excludo - caso 104 originado do CINEMA).
Localizao do Problema: linha_serial
Falta de Acesso: CONSTANTE
Padro de Interface: SERIAL
Enlaces com Problema: UMA_UNICA_LINHA
Estado Interface Local: SERIAL UP, LINE PROTOCOL DOWN

Caso 136 - Resultados da primeira recuperao

Trouble Ticket 136 - Tipo de Problema Conectividade - Genrico
Consulta efetuada para problemas do tipo Conectividade Genrico. Conectividade - Fsico e Config/HW
Casos recuperados segundo as informaes j fornecidas sobre o
problema atual:
[0.90]
Similaridade [0.95], Confiana [0.79] - Caso 105 Descrio: O circuito POA-SC esta fora.
[0.87]
Similaridade [0.95], Confiana [0.71] - Caso 108 Descrio: Usurio no consegue acessar rede externa.

123
[0.86]
Similaridade [0.89], Confiana [0.79] - Caso 106 Descrio: A linha com SC no esta funcionando.
[0.82]
Similaridade [0.89], Confiana [0.67] - Caso 107 Descrio: UCS sem conexo.
[0.81]
Similaridade [0.82], Confiana [0.79] - Caso 102 Descrio: A UCS comunica que esta sem contato com o resto do
mundo.
[0.73]
Similaridade [0.73], Confiana [0.71] - Caso 103 Descrio: A linha 64kb da Unisinos no esta funcionando.
[0.65]
Similaridade [0.66], Confiana [0.62] - Caso 100 Descrio: Taxa de erros na comunicao entre POA-SP, POA-DF
muito alta, com perda de pacotes grandes no teste ping.

Informaes Adicionais Solicitadas:

[0.63]
(Id 3) Contatar empresa de telecomunicaes
fornecedora do servio.
[0.62]
(Id 1) Realizar teste de loop: configurar roteador
local e remoto com keepalive set, e pressionar LDL no modem
remoto. Qual o estado da interface local?
[0.57]
(Id 8) Utilizar comando show interfaces no roteador
remoto. Configurao esta ok?
[0.56]

(Id 7) Contatar nodo remoto.

[0.54]
(Id 4) Realizar teste de loop: configurar roteador
local e remoto com keepalive set, e pressionar LDL no modem
remoto. Qual o estado da interface remota?

Informaes Respondidas:
(Id 3) Contatar empresa de telecomunicaes fornecedora do
servio.
(Id 1) Realizar teste de loop: configurar roteador local e
remoto com keepalive set, e pressionar LDL no modem remoto. Qual
o estado da interface local? Resposta: SERIAL UP, LINE PROTOCOL
DOWN
(Id 4) Realizar teste de loop: configurar roteador local e
remoto com keepalive set, e pressionar LDL no modem remoto. Qual
o estado da interface remota? Resposta: SERIAL UP, LINE PROTOCOL
UP (LOOPED)

Caso 136 - Resultados da segunda recuperao

Trouble Ticket 136 - Tipo de Problema Conectividade - Genrico
Consulta efetuada para problemas do tipo Conectividade Genrico. Conectividade - Fsico e Config/HW.
Casos recuperados segundo as informaes j fornecidas sobre o
problema atual:
[0.90]
Similaridade [0.95], Confiana [0.79] - Caso 105 Descrio: O circuito POA-SC esta fora.
[0.86]
Similaridade [0.89], Confiana [0.79] - Caso 106 Descrio: A linha com SC no esta funcionando.
[0.81]
Similaridade [0.82], Confiana [0.79] - Caso 102 Descrio: A UCS comunica que esta sem contato com o resto do
mundo.

124
[0.73]
Similaridade [0.73], Confiana [0.71] - Caso 103 Descrio: A linha 64kb da Unisinos no esta funcionando.
[0.65]
Similaridade [0.66], Confiana [0.62] - Caso 100 Descrio: Taxa de erros na comunicao entre POA-SP, POA-DF
muito alta, com perda de pacotes grandes no teste ping.

Informaes Adicionais Solicitadas:

[0.63]

(Id 6) Ha perda de pacotes grandes com teste ping?

[0.56]

(Id 7) Contatar nodo remoto.

[0.46]
(Id 5) Contatar nodo remoto. Outros enlaces deste
ponto apresentam problemas?
[0.54]

(Id 22) Ha alta taxa de erros CRC?

Soluo Caso 136:

Causas: Problema foi isolado entre EMBRATEL e FAPESP.
Soluo Adotada: Problema foi solucionado pela EMBRATEL.
Tipo de Problema Final: Conectividade - Fsico e Config/HW
Caractersticas Especficas Cadastradas no Sistema (pelo caso
100/134):
Id: 2 Descrio: Fazendo teste de loop ate ponto

intermedirio do enlace, qual o estado da interface local? Grau:

relev.5 Tipo: Sobre carac. adicional itfst, operao com mesmos
valores e similaridade.
Caractersticas Especficas Finais do Caso 134:
Id: 1 Valor: SERIAL UP, LINE PROTOCOL DOWN, Ordem: 1
Id: 4 Valor: SERIAL UP, LINE PROTOCOL UP (LOOPED),
Ordem: 1
Id: 3
Id: 2 Valor: SERIAL UP, LINE PROTOCOL UP (LOOPED),
Ordem: 1

O exemplo de recuperao do caso 132 corresponde a um problema em uma rede

Ethernet, causado por cabo defeituoso. Os casos retornados foram os casos 122 e 123.
O caso 122, retornado em primeiro lugar, corresponde ao caso cadastrado no sistema
mais prximo situao corrente. Este caso representa um problema em que uma
estao no conseguia acessar os demais nodos porque havia uma placa de rede
defeituosa e casos com problemas causados por falhas em cabeamento mais
semelhantes ao corrente no esto cadastrados no prottipo.
O segundo exemplo, por sua vez, corresponde a um problema causado por uma
falha no enlace fornecido pela EMBRATEL. Tambm nesse caso foram retornados
problemas similares. Na primeira recuperao, o primeiro caso selecionado (caso 105)
corresponde a um problema tambm causado por falha no enlace serial. Alm disso, as
caractersticas especficas propostas so relevantes para problemas deste tipo.
A caracterstica 3, apenas informativa, sugere que a empresa de telecomunicaes
seja contatada, sugesto relevante e que, nos problemas similares coletados, representa
uma das primeiras aes que foram efetuadas. A caracterstica 1 apresenta tambm uma

125

ao de diagnstico utilizada freqentemente nesses tipos de problemas, e pode

contribuir de modo significativo para o isolamento da falha.
Para o caso real sendo tratado, as caractersticas 1 e 3 foram relevantes, e haviam
sido utilizadas de fato no caso coletado no ambiente CINEMA de modo que o
sistema foi capaz de propor as aes adequadas e que j haviam, na situao real que deu
origem ao registro no ambiente CINEMA, contribudo no diagnstico.
Alm dessas, a caracterstica 4 tambm relevante. Idealmente, ela deveria ter
sido proposta em seqncia caracterstica 1, pois ambas representam resultados da
mesma ao de diagnstico assim, meios de relacionar caractersticas especficas
poderiam ser estudados para uma prxima verso, contribuindo para usurios que
prefiram refinar muitas vezes uma recuperao respondendo poucas especficas por vez.
Na recuperao sendo comentada (caso 136), foram inseridas as caractersticas
especficas 1, 3 e 4. A recuperao subseqente, mais uma vez, props em primeiro lugar
o caso 105, que foi causado tambm por falha na linha serial. Mas alm do caso proposto
ser similar, a sugesto do sistema de aes de diagnstico relevantes j contribui para a
evoluo da situao corrente da a importncia das caractersticas especficas.
O conjunto dos testes desenvolvidos permitiu que algumas concluses fossem
retiradas sobre o prottipo em geral e aprimoramento que pode ser efetuado sobre ele.
Como foi comentado, foram implementados nesta verso apenas dois tipos de
caractersticas especficas: do tipo binria e do tipo que usa os mesmos valores para
similaridade de uma caracterstica adicional. Assim, caractersticas especficas como
H alta taxa de colises? e H os protocolos RIP e IGRP no ambiente? tiveram que
ser cadastradas para permitir que estas informaes fossem utilizadas.
Entretanto, verses posteriores podem aprimorar o sistema, implementando os
tipos de caractersticas especficas que elaboram sua resposta automaticamente,
utilizando valores j fornecidos para caractersticas adicionais. Assim, as duas
caractersticas especficas citadas acima, por exemplo, poderiam ser elaboradas
automaticamente, a partir de respostas das caractersticas adicionais taxa de colises e
protocolos de roteamento do ambiente. Com isso, a recuperao ser aperfeioada pelo
sistema, que pode fazer um refino da recuperao mesmo antes de consultar o usurio
(elaborando automaticamente estas caractersticas e utilizando-as imediatamente), e,
assim, fornecer casos com similaridade maior. Essa abordagem, contudo, ainda mantm a
necessidade do usurio identificar, no momento do aprendizado de um caso aps,
portanto, a situao ter sido solucionada , quais caractersticas especficas foram de
fato relevantes para o diagnstico, a fim de evitar que informaes especficas que
tenham sido elaboradas mas que no contribuam para o entendimento do caso sejam
utilizadas em recuperaes futuras.
Uma dificuldade encontrada na atual implementao das caractersticas
especficas foi a ausncia de meios para restringir estas informaes apenas para
problemas num determinado contexto. Um exemplo disso foram as informaes
especficas 6 e 22, solicitadas na segunda recuperao do caso 136. Embora elas tenham
sido requeridas apenas numa segunda recuperao, aps as informaes mais relevantes
cadastradas no sistema j terem sido solicitadas, elas no sero teis para problemas
desse contexto, pois, no caso 136, h falta de acesso constante. Assim, uma questo que
pode contribuir para o aprimoramento do sistema o estudo de meios de definir para

126

algumas especficas contextos onde elas no devem ser selecionadas. Uma proposta
inicial seria permitir que a caracterstica s fosse aplicada se uma caracterstica adicional
com um valor pr-determinado casasse com o valor daquela caracterstica do caso
corrente com similaridade mnima de um valor X. Entretanto, essa abordagem poderia
restringir a flexibilidade e simplicidade do sistema, e estudos adicionais so necessrios.
Sobre as caractersticas especficas, pode ser vislumbrado ainda que a associao
de notas a essas informaes, como proposto na modelagem, poderia auxiliar o usurio a
compreender a ao de diagnstico proposta, que se torna, muitas vezes, pouco clara se
feita unicamente atravs da descrio. Assim, para cada especfica retornada, a nota
associada a esta caracterstica poderia ser fornecida ao usurio, que teria mais
informaes sobre os procedimentos envolvidos na ao se esta no fosse familiar a ele.
Algumas consideraes podem ser levantadas tambm sobre a probabilidade dos
tipos de problemas calculada na definio do contexto e utilizada para identificar o
conjunto de casos que ser consultado. Nos testes avaliados, pode ser constatado que,
muitas vezes, o valor 0,2 no adequado para ser o limiar da similaridade mnima para a
probabilidade de um tipo de problema a fim de que este seja consultado. Dessa forma,
percebeu-se que realizar um refino deste limiar medida que o problema vai se
desenvolvendo pode contribuir para aperfeioar a recuperao, selecionando, numa
segunda busca, casos com limiar menor se os casos recuperados anteriormente no
foram os mais adequados. Com isso, mesmo quando o usurio no selecionar um tipo de
problema com probabilidade reduzida por considerar que os casos recuperados no
foram suficientes, o sistema pode, automaticamente, ajustar esse valor e garantir que um
caso similar presente na base no seja excludo da busca.
Uma das dificuldades da avaliao da acurcia do prottipo para os diversos
contextos encontrada foi causada pelo nmero de casos cadastrados que representam um
grupo inicial coletado e que no correspondem ao aprendizado pelo uso normal do
sistema. Assim, o conjunto dos casos recuperados pode, muitas vezes, indicar os
melhores dentre os casos do sistema, embora no represente a melhor situao possvel,
o que dificulta sua avaliao.
Os testes efetuados permitiram, contudo, verificar que o sistema tem a
capacidade de recuperar situaes similares adequadas para uma situao, e seu uso
pode ser aplicado num ambiente real. Nesse ambiente, juntamente com uma etapa inicial
de acompanhamento para ajustes finais dos graus de relevncia e similaridades
decorrentes das diferenas em um ambiente real, o aprendizado do sistema
principalmente atravs dos novos casos e do aprimoramento a relao histrica ir
aumentar seu conhecimento e permitir que situaes mais similares corrente possam ser
recuperadas.
Em relao s demais abordagens encontradas na bibliografia, o sistema DUMBO
pode ser comparado ao CRITTER [LEW 93][LEW 95] e MASTER [DRE 95], ambos
sistemas de gerenciamento de falhas para redes de computadores que usam CBR. Entre
seus pontos negativos, pode ser citada a ausncia de adaptao automtica e a sugesto
da soluo de modo indireto, diferente do que ocorre no CRITTER. Isso acontece, de
certo modo, porque o DUMBO foi desenvolvido com o propsito de permitir grande
interao dos usurios no processo os casos sero criados, utilizados e encerrados por
usurios e no de modo automtico, o que uma importante contribuio do DUMBO.
Para que isso fosse possvel, entretanto, uma representao dos casos mais flexvel e

127

menos estruturada teve que ser utilizada para os campos da soluo, o que trouxe
maiores dificuldades para adaptao e para propor solues de modo direto.
Outra contribuio do DUMBO diz respeito sugesto de aes de diagnstico
alm da soluo, que permitem a evoluo do problema, o que no ocorre no CRITTER,
onde a soluo proposta imediatamente. No MASTER, h tambm a sugesto de aes
ao usurio, que permitem descrever a situao melhor. O sistema DUMBO, contudo,
parece possuir uma estrutura muito mais simplificada e de fcil manuteno, enquanto
que no MASTER, pelo seu conceito de master tickets que envolve a generalizao das
informaes sobre a falha, h uma complexidade maior no sistema para aprendizado e
manuteno.
Alm disso, uma importante contribuio do DUMBO diz respeito a sua
estrutura, que foi concebida com o propsito de ser flexvel e incluir a maior parte das
situaes que podem ser encontradas no domnio.
Em relao aos resultados, a sua comparao entre os sistemas no foi possvel
pela ausncia de informaes nas referncias que permitam a comparao com os
resultados obtidos nos testes com o DUMBO.

128

7 Consideraes finais
O presente trabalho se props a desenvolver um sistema destinado ao auxlio de
gerentes de redes no diagnstico de falhas. Para isso, foi feita a definio de um modelo
apropriado, desenvolvido utilizando o paradigma de raciocnio baseado em casos
aplicado sobre um sistema de registro de problemas. Uma vasta reviso bibliogrfica
sobre o paradigma foi feita (captulo 2), visando identificar as particularidades do
paradigma para possibilitar sua correta utilizao na modelagem do sistema. Alm disso,
a reviso bibliogrfica da rea de gerenciamento de redes foi tambm desenvolvida
(captulo 3), enfocando, principalmente, os sistemas de registro de problemas, o uso de
paradigmas de raciocnio no domnio e o uso do paradigma de raciocnio baseado em
casos em aplicaes referenciadas na bibliografia.
Uma vez efetuado o estudo do paradigma e da rea de gerenciamento de redes, o
desenvolvimento do modelo exigiu uma etapa de aquisio do conhecimento para o
sistema, quando foi feito o estudo dos problemas tpicos do domnio e das
particularidades de cada tipo de informao relevante para reconhecer dois problemas
similares (captulo 4). Em posse desses dados e fazendo uso do conhecimento obtido na
reviso do paradigma e da rea de gerenciamento, os dados a serem representados no
sistema foram organizados na representao em redes semnticas e a representao dos
casos e os processos de raciocnio necessrios foram concebidos para o sistema.
O sistema DUMBO, nome escolhido para o sistema desenvolvido, permite que a
soluo ou auxlio ao diagnstico em uma situao de problema corrente seja feito
atravs de casos similares ocorridos anteriormente, os quais esto armazenados na base
do sistema. Para isso, faz uso da comparao de informaes relevantes entre os dois
casos, utilizando o conhecimento do sistema para efetuar, nesta comparao, no apenas
um casamento simples, mas permitir tambm o casamento parcial das informaes.
Cabe, agora, apresentarmos uma anlise crtica sobre o trabalho desenvolvido,
salientando as falhas encontradas durante o percurso e os aspectos positivos que o
mesmo apresenta.
O primeiro dos pontos a ser comentado diz respeito aos problemas tratados pelo
sistema. Em virtude da ampla gama de problemas do ambiente de rede enfocado e das
restries de tempo disponveis para o desenvolvimento do trabalho, o estudo mais
detalhado dos problemas encontrados foi dificultado. Entretanto, a nfase em um nico
tipo de problema ou em um ambiente com tecnologias reduzidas prejudicaria o objetivo
do trabalho, que visava auxiliar o diagnstico das falhas nas redes de modo geral.
Assim, como no foram encontrados trabalhos disponveis que pudessem ser
encaixados ao sistema e aplicados para alguns problemas, deixando ao DUMBO o
enfoque apenas dos demais, foi necessrio o desenvolvimento de uma estrutura para as
informaes que permitisse que a maior parte dos problemas possveis de ocorrer
pudesse ser tratada pelo sistema, mesmo que um enfoque maior fosse dado para um
grupo dentre estes. Desta forma, um aspecto positivo a ser ressaltado o
desenvolvimento dessa estrutura para representao dos problemas. Esta estrutura
poder ser utilizada posteriormente em outros trabalhos, que podem at mesmo enfocar
apenas um tipo especfico de problemas, e se associar ao sistema DUMBO para executar
o tratamento dos demais.

129

No modelo proposto para o sistema, em virtude das restries de tempo e

volume de dados encontrados pelo trabalho, uma nfase maior foi dada aos problemas
das camadas inferiores do modelo TCP/IP, englobando os problemas na comunicao.
Destes, como pde ser avaliado pelo prottipo desenvolvido, resultados melhores foram
obtidos com falhas fsicas e de configurao do hardware do que os obtidos em falhas de
roteamento, em virtude da complexidade envolvidas nos problemas deste tipo.
Entre as deficincias constatadas no tratamento de falhas de roteamento, pode ser
citado o uso de informaes pouco precisas, uma vez que a situao foi tratada com a
viso de um problema de acessibilidade, havendo um nmero menor de informaes nas
caractersticas adicionais relevantes que faam uso das informaes mais detalhadas em
uma situao que j foi identificada como de roteamento. Esse aspecto foi contornado no
sistema pelo uso das caractersticas especficas para estes dados.
Um aspecto que traz dificuldades no uso deste sistema a necessidade de
informar os diversos dados solicitados. Como no foi possvel implementar, em virtude
das restries comentadas, esquemas de elaborao automtica das informaes no
prottipo desenvolvido, o usurio tem de responder a quase todas as informaes, o que
torna seu uso menos amigvel. Entretanto, como foi comentado amplamente no captulo
5, o uso destas informaes, com uma linguagem estruturada, necessrio para o
desenvolvimento de sistemas deste tipo.
Um dos importantes aspectos positivos do modelo foi a possibilidade de
identificar informaes de diagnstico, alm dos casos recuperados propriamente ditos.
No domnio do gerenciamento de falhas em redes, o estudo efetuado sobre os problemas
demostrou que estas aes so utilizadas de modo corrente na atividade de diagnstico,
e sua integrao no sistema contribui de modo significativo para auxiliar estas atividades.
Por fim, a avaliao do prottipo desenvolvida mostrou que o modelo contribui
para a identificao de casos similares e atividades de diagnstico relevantes para os
problemas de rede, e est apto para ser testado e aplicado a um ambiente maior e real.

7.1 Trabalhos Futuros

A partir dos pontos negativos identificados no sistema, e visando tambm o
aprimoramento dos processos envolvidos e do uso do sistema, algumas metas foram
estabelecidas para futuro desenvolvimento do trabalho. Entre estas, podemos citar:
Estudo e implementao das informaes adicionais identificadas no sistema
para os problemas nas camadas inferiores e ainda no implementadas, tais como as
citadas no anexo 2. Estudos complementares e implementao das informaes
adicionais dos problemas das camadas superiores.
Desenvolvimento das caractersticas especficas com elaborao automtica.
Desenvolvimento de uma interface mais adequada para o aprendizado do
sistema, assim como os meios de controle deste aprendizado apenas para usurios
capacitados.
Integrao do sistema em plataformas ou outros sistemas de gerenciamento, de
modo a fornecer novas informaes e dados mais especficos disponibilizados por estes
sistemas nas caractersticas adicionais ou especficas. Um exemplo seria a integrao com

130

o MAD [NUN 97], que poderia fornecer dados especficos sobre os erros encontrados
em uma situao. O uso de plataformas de gerenciamento integradas tambm
proporcionariam que informaes disponibilizadas pelo protocolo SNMP ou em agentes
distribudos na rede fossem identificadas automaticamente pelo sistema. Com isso, a
interface com o usurio tambm seria simplificada, liberando-o da necessidade de
informar um nmero grande de informaes.
Identificao de formas de implantar tcnicas de adaptao automtica ao ciclo
de raciocnio.
Estudo de meios de integrar ao sistema aplicaes que possuam facilidades de
interpretao de textos livres, que poderiam ser encaixadas ao sistema preenchendo, a
partir da descrio em texto livre fornecida pelos gerentes, algumas das caractersticas
adicionais e especficas j comentadas, de modo anlogo ao comentado em [DRE 95].

131

Anexo 1 Rede Semntica dos Tipos de Problemas

No captulo 5, a rede semntica dos problemas foi apresentada, com as categorias
de problema que uma situao pode assumir. Os problemas de comunicao, como foi
visto, possuem um atributo localizao do problema, que pode assumir os valores linha
serial, entre mesma sub-rede IP, entre sub-redes IP, canal de uma LAN e canal de
diversas sub-redes IP. A seguir, apresentamos a parte da rede semntica referente estas
especializaes da localizao do problema.
quais enlaces
enlaces com
problema

linha serial

_caracterizado_por

_caracterizado_por

informaes
sobre roteador

_um

_um

_caracterizado_por

_um

vrias linhas
sem roteador
em comum

uma nica
linha

_caracterizado_por

_caracterizado_por

identificao
roteador remoto

estado interface
roteador local

_caracterizado_por
vrias linhas
com roteador
em comum

_caracterizado_por

informaes
sobre roteador

estado interface
roteador remoto

acessibilidade
entre hosts e
roteador
_caracterizado_por

identificao
subrede

_caracterizado_por
interface de
rede
entre mesma subrede IP

_caracterizado_por
_caracterizado_por

_caracterizado_por

_um

sub-rede IP possui
um segmento /
domnio de coliso

informaes
entidades
origem da com.
informaes
entidades
destino da com.

_um

sub-rede IP possui
mais de um segmento /
domnio de coliso

_caracterizado_por

quais segmentos
envolvidos.

FIGURA A1.1 - Rede semntica da localizao dos problemas (parte 1)

132

abrangncia
problema na
sub-rede origem
abrangncia
problema na
sub-rede destino

_caracterizado_por
_caracterizado_por
entre
sub-redes IP

_caracterizado_por
rea do
problema

_um

_um

problema para outra

sub-rede IP

problema para vrias

outras sub-redes IP

_um

primeiro roteador
no atingido

_um

_um

roteador
diferente do final
ltimo atingido

ltimo roteador
atingido

entre mesma
sub-rede IP

_caracterizado_por
primeiro roteador
no atingido
_caracterizado_por

rota para subredes destino

_um

atravs de vrios
roteadores

_um

atravs de um
mesmo roteador

informaes
sobre roteador
_caracterizado_por

entre mesma
sub-rede IP
ltimo roteador
atingido

_caracterizado_por

FIGURA A1.2 - Rede semntica da localizao dos problemas (parte 2)

133

todas sub-redes a
partir do roteador
so afetadas

_caracterizado_por

_caracterizado_por

_um

_um
_um

informaes
sobre roteador

rota para subredes destino

roteador diferente
do final ltimo
atingido

_um

algumas sub-redes
a partir do roteador
so afetadas

_caracterizado_por

segue por diversas

interfaces

abrangncia
sub-rede
afetada

segue por uma nica

interface
_caracterizado_por
_caracterizado_por

_um

identificao
sub-rede
afetada
interface
de rede

_um

_caracterizado_por

acessando sub-rede IP
que possui
um segmento /
domnio de coliso

acessando sub-rede IP
que possui mais de um
segmento / domnio
de coliso

quais segmentos
envolvidos.

identificao
sub-rede

_caracterizado_por

percentual
de utilizao do
canal

_caracterizado_por

canal de LAN

_um

_caracterizado_por

interface de
rede

_um

LAN com um nico

segmento / domnio de
coliso

LAN com mais de um

segmento / domnio de
coliso

canal de diversas
sub-redes IP

percentual de
utilizao do
canal
_caracterizado_por
_um

_um
_um
em seqncia sem
equipamento em
comum

sem sequncia sem

equipamento em
comum

com equipamento
em comum

FIGURA A1.3 - Rede semntica da localizao dos problemas (parte 3)

134

interface
de rede
_um

_um

Serial

LAN
_um

Ethernet

_caracterizado_por

tipo interface
especfico

identificao
roteador
_caracterizado_por
produto
_caracterizado_por
tipo
informaes sobre
equipamento faz
roteador
_caracterizado_por roteamento
_caracterizado_por

sistema
operacional

tipo
equipamento

_caracterizado_por
informaes
entidades destino
da com.

_caracterizado_por

abrangncia
entidades destino no
segmento afetado

_caracterizado_por
abrangncia
entidades destino da
sub-rede afetada

_caracterizado_por

modo ligao
s LANs

_um

_um

_um

equipamento
intermedirio
_caracterizado_por

conectadas
diretamente

conectadas
diretamente e
indiretamente

conectadas
indiretamente

_caracterizado_por

acessibilidade
ao equipamento
intermedirio

_caracterizado_por
equipamento
ser/no nodo IP
_caracterizado_por
meio que liga ao
intermedirio

FIGURA A1.4 - Rede semntica da localizao dos problemas (parte 4)

135

Anexo 2 Caractersticas de um Caso

Caractersticas Adicionais
Relevncia para caractersticas que tem relevncia varivel
Como foi apresentado na seo 5.5.2.2, algumas caractersticas tm a relevncia
varivel de acordo com o contexto da situao. A seguir, apresentamos algumas das
principais regras utilizadas para identificar esta relevncia presentes no prottipo
implementado.
SE tipo de problema = conectividade-genrico OU tipo de problema = conectividade-fsico e
config/HW OU tipo de problema = performance OU tipo de problema = alto trfego E
provvel componente falha fsica possui cabeamento OU
provvel componente falha fsica possui equipamento interconexo enlace
ENTO tipo interface rede peso 5
SE tipo de problema = conectividade-genrico OU tipo de problema = conectividade-fsico e
config/HW OU tipo de problema = performance OU tipo de problema = alto trfego E
provvel componente falha fsica possui cabeamento OU
provvel componente falha fsica possui equipamento interconexo enlace E
tipo interface rede contm Ethernet
ENTO tipo especfico interface PESO 3
SE tipo de problema = conectividade-genrico OU tipo de problema = roteamento/endereamento E
localizao do problema = entre mesma sub-rede IP
ENTO acessibilidade entre hosts e roteador PESO 1
SE tipo de problema = conectividade-genrico OU tipo de problema = roteamento/endereamento OU
tipo de problema = performance OU tipo de problema = alto trfego E
localizao do problema = entre sub-redes IP OU
localizao do problema = canal de diversas sub-redes IP
ENTO rea do problema PESO 3
SE tipo de problema = conectividade-genrico OU tipo de problema = conectividade-fsico e
config/HW OU tipo de problema = performance OU tipo de problema = alto trfego E
provvel componente fsico contm equipamento interconexo rede
ENTO equip. interconexo rede falha fsica nmero IP PESO 1,
equip. interconexo rede falha fsico tipo PESO 1,
equip. interconexo rede falha fsica produto PESO 1
SE tipo de problema = conectividade-genrico OU tipo de problema = conectividade-fsico e
config/HW OU tipo de problema = performance OU tipo de problema = alto trafego E
localizao do problema = linha serial E
enlaces com problema = uma nica linha
ENTO equip. interconexo rede falha fsica estado interface PESO 5
SE tipo de problema = conectividade-genrico OU tipo de problema = roteamento/endereamento OU
tipo de problema = performance OU tipo de problema = alto trfego E
localizao do problema = entre mesma sub-rede IP OU
localizao do problema = entre sub-redes IP OU localizao do problema = canal de LAN
ENTO abrangncia sub-rede afetada destino PESO 3, abrangncia sub-rede origem PESO 3
SE tipo de problema = conectividade-genrico OU tipo de problema = roteamento/endereamento OU
tipo de problema = performance OU tipo de problema = alto trfego E
localizao do problema = entre mesma sub-rede IP OU
localizao do problema = entre sub-redes IP OU localizao do problema = canal de LAN E
padro interface rede possui LAN

136
ENTO abrangncia das entidades destino do segmento afetado PESO 3,
abrangncia das entidades origem do segmento afetado PESO 3,
quais segmentos envolvidos PESO 3
SE tipo de problema = roteamento/endereamento E localizao do problema = entre mesma sub-rede
IP OU (localizao do problema = entre sub-redes IP E rea do problema = primeiro roteador no
atingido)
ENTO tipo de equipamento origem PESO 1
SE tipo de problema = roteamento/endereamento E
localizao do problema = entre mesma sub-rede IP OU
(localizao do problema = entre sub-redes IP E rea do problema = ltimo roteador atingido)
ENTO tipo de equipamento destino PESO 1

Similaridade das Caractersticas Adicionais

A seguir, apresentamos o conjunto das caractersticas adicionais implementadas
no prottipo desenvolvido, comentando qual o tipo de similaridade utilizada em cada
uma delas. Como ser visto, o clculo da similaridade de algumas feito independente
do tipo de informao, tais como a similaridade exata entre os dois valores, ou a
similaridade em que feita a comparao dos diversos elementos em cada valor e a
similaridade final proporcional ao nmero de elementos iguais pelo nmero de
elementos presentes em cada uma das caractersticas (chamada possui termos,
percentual simples). J em outras, a similaridade prpria do tipo de informao, sendo
manuseada, tais como a similaridade de produtos, de interfaces de rede, de estados de
interfaces de rede, podendo ser aplicada para valores sempre fixos ou variveis, que
podem aprendidos pelo sistema. Esxa similaridade prpria pode ser usada em apenas
uma caracterstica ou para vrias caractersticas que trazem o mesmo tipo de informao
(estado da interface do roteador local e remoto, por exemplo).
TABELA A2.1 - Similaridade das caractersticas adicionais implementadas
Caracterstica
tipo de problema
tipo de problema inicial
breve descrio
houve alterao
padro interface rede
localizao do problema
problema mantm usando IP
falta de acesso (intermitente, constante, nunca)
modo de falta de acesso (parcial, total)
performance ruim como (intermitente, constante)
alto trfego (constante, intermitente)
qual tipo de trfego com taxa elevada
ocorrncia de alta taxa de erros
ocorrncia de alto trfego
ocorrncia de alto tempo de resposta
identificao sub-rede
interface de rede
tipo interface especfico
percentual de utilizao do meio
acessibilidade entre hosts e roteador
rea do problema
identificao roteador com possvel falha

Similaridade
probabilidade calculada
exata com tipo corrente
textual
prpria
possui termos, percentual simples
prpria
usada apenas para regras redirecionadoras do
tipo de problema
exata
exata
exata
exata
exata
exata
exata
exata
exata
prpria
possui termos, percentual simples
numrica valores prprios
exata
prpria
exata

137
Caracterstica
roteamento
tipo equipamento faz roteamento com possvel
falha roteamento
produto (modelo) roteador com possvel falha
roteamento
sistema operacional roteador com possvel falha
roteamento
identificao roteador com possvel com possvel
falha fsica
tipo equipamento faz roteamento com possvel
falha fsica
produto (modelo) roteador com possvel falha fsica
sistema operacional roteador com possvel falha
fsica
estado da interface do roteador com possvel falha
fsica
percentual de utilizao da interface
rota para sub-rede destino segue por uma/vrias
interfaces
identificao roteador remoto
estado interface roteador remoto
enlaces com problema
quais enlaces
quais segmentos envolvidos
abrangncia entidades destino no segmento afetado
abrangncia entidades origem no segmento afetado
abrangncia entidades destino da sub-rede afetada
abrangncia problema na sub-rede destino
abrangncia problema na sub-rede
tipo equipamento destino
tipo equipamento origem
modo ligao s LANs entidades destino
modo ligao s LANs entidades origem
equipamento intermedirio entidades destino
equipamentos intermedirio entidades origem
equipamento destino ser/no nodo IP
equipamento origem ser/no nodo IP
qual tipo de trfego com taxa elevada
qual tipo de erros

Similaridade
prpria
prpria
prpria
exata
prpria
prpria
prpria
prpria
numrica com valores prprios
segundo tipo de interface
exata
exata
prpria
prpria
possui termos, percentual simples
prpria tipo um, alguns, todos
prpria tipo um, alguns, todos
prpria tipo um, alguns, todos
prpria tipo um, alguns, todos
prpria tipo um, alguns, todos
prpria tipo um, alguns, todos
possui termos, percentual simples
possui termos, percentual simples
prpria
prpria
exata
exata
exata
exata
possui percentual simples
possui percentual simples

Existem, ainda, outras caractersticas que foram identificadas no desenvolvimento

do sistema DUMBO como indicadoras de similaridade entre casos em alguns tipos de
problemas e contextos. Essas caractersticas, entretanto, no puderam ser implementadas
no prottipo, em virtude das restries de tempo e volume de informaes do sistema. A
seguir, apresentamos uma lista destas caractersticas, bem como a similaridade proposta
inicialmente para elas.

138

TABELA A2.2 - Algumas caractersticas adicionais propostas

Caracterstica
qual tipo de trfego com taxa elevada

em que h alto tempo de resposta

mensagem

possveis causas
definio do problema

quais protocolos no tem acesso

taxa de erros CRC da rede
taxa de colises da rede
taxa de broadcast da rede
protocolos de roteamento envolvidos no
ambiente
ambiente tem mltiplos protocolos
funo do equipamento de interconexo de
enlace/fsico
identificao do equipamento de
interconexo de enlace/fsico
tipo de equipamento de interconexo de
enlace/fsico
produto (modelo) do equipamento de
interconexo de enlace/fsico
protocolos manuseados pelo roteador com
possvel falha roteamento
taxa de erros de entrada da interface do
roteador
taxa de erros de sada da interface para
roteador
taxa de descartes de entrada da interface
do roteador
taxa de descartes de sada da interface do
roteador
taxa de erros CRC da interface do roteador
ocorrncia de resets na interface do
roteador
taxa de colises da interface do roteador
identificao do servidor de nomes
identificao do tipo de servidor de nomes
identificao do produto (modelo) do
servidor de nomes
identificao do sistema operacional do
servidor de nomes
identificao do servidor de autenticao

Similaridade
similaridade atravs de caractersticas do trfego
envolvido, como protocolo de transporte utilizado, funo
do protocolo, p. e.
prpria, para valores fixos como no estabelecimento da
conexo, aps estabelecimento da comunicao, em todas
as etapas da comunicao, etc.
preferencialmente, com tabela prpria com cadastro das
mensagens mais freqentes de cada sistema e a que tipo
de mensagem pertence
prpria, com cadastro das causas mais freqentes
no utilizada no casamento de modo direto, mas que
permita elaborar uma ou mais caractersticas especficas
de acordo com esta definio fornecida no momento da
insero do caso por usurio com mais conhecimento do
problema
prpria, com similaridades do protocolo envolvido, tais
como protocolo de transporte
numrica com valores prprios
numrica com valores prprios
numrica com valores prprios
prpria, com similaridades atravs de caractersticas do
protocolo como seu tipo, se tem sub-endereamento, etc
exata, sendo a caracterstica elaborada automaticamente a
partir dos protocolos de roteamento envolvido ambiente
prpria, de acordo com a camada em que atua, por
exemplo
exata
prpria segundo tipo de equipamento (j implementado)
prpria segundo produto (j implementado)
prpria segundo caractersticas dos protocolos
numrica com valores prprios
numrica com valores prprios
numrica com valores prprios
numrica com valores prprios
numrica com valores prprios
numrica com valores prprios
numrica com valores prprios
exata
prpria para tipo de servidores de nomes
prpria para produtos
prpria para sistemas operacionais
exata

139
Caracterstica
identificao do tipo de servidor de
autenticao
identificao do produto (modelo) do
servidor de autenticao
identificao do sistema operacional do
servidor de autenticao
identificao do servidor de arquivos
identificao do tipo do servidor de
arquivos
identificao do produto (modelo) do
servidor de arquivos
identificao do sistema operacional do
servidor de arquivos
provveis componentes com falha fsica

provveis componentes com falha de

roteamento

Similaridade
prpria para tipo de servidores de autenticao
prpria para produtos
prpria para sistemas operacionais
exata
prpria para tipo de servidores de arquivos
prpria para produtos
prpria para sistemas operacionais
exata, por comparao com componente
envolvido informado na soluo
(sua elaborao j est implementada, sendo usada,
entretanto, apenas para definio de relevncia)
exata, por comparao com componente envolvido
informado na soluo

Alguns grupos do sistema implementados em tabelas

A seguir, apresentamos como exemplo dois grupos do sistema que so utilizados
para cadastrar valores para aquelas caractersticas que possuem um tipo de similaridade
prprio e com termos variveis, que podem ser aprendidos pelo sistema. Inicialmente,
apresentado o grupo dos estados das interfaces, e em segundo lugar, o grupo produtos.
TABELA A2.3 - Grupo estados das interfaces
Estado Indicado

Estado Geral

DOWN
SERIAL DOWN, LINE PROTOCOL DOWN
SERIAL UP, LINE PROTOCOL DOWN
SERIAL UP, LINE PROTOCOL DOWN (DISABLED)
SERIAL ADMINISTRATIVELY DOWN, LINE PROTOCOL DOWN
UP
SERIAL UP, LINE PROTOCOL UP (LOOPED)
SERIAL UP, LINE PROTOCOL UP

0
0
0
0
0
1
1
1

TABELA A2.4 - Grupo produtos

Produto
RISC 6000
SPARC 20
PC Pentium 133
Cisco 2524
Cisco 2525
Catalyst 5002
Catalyst 5005
Catalyst 5500

Familia/Sim.Verses

Pentium
Cisco 2500 Series
Cisco 2500 Series
Catalyst 5000 Series
Catalyst 5000 Series
Catalyst 5000 Series

Tipo Equipamento
estao de trabalho
estao de trabalho
microcomputador
roteador
roteador
switch
switch
switch

140

Caractersticas Especficas
A seguir, apresentamos uma lista de algumas das caractersticas especficas
cadastradas no prottipo.
TABELA A2.5 - Algumas caractersticas especficas do prottipo
Descrio
Fazendo teste de loop ate ponto intermedirio do enlace,
qual o estado da interface local?

Grau
relev. 5

Contatar nodo remoto. Outros enlaces deste ponto

apresentam problemas?
H perda de pacotes grandes com teste ping?

relev. 5
relev. 5

Observaes
Custo
tipo carac. ad. estados
2
de itf., operao usar
mesmos valores
similaridade
binria
2
binria

binria

2
2

binria

binria

As sub-redes que no conseguem acesso externo usam

filtro
sub-endereamento?
O protocolo de roteamento utilizado possui campo para relev. 5
sub-endereamento?
Contatar empresa de telecomunicaes fornecedora do informativa
servio.
As tabelas de roteamento dos roteadores envolvidos
filtro
possuem gateway default correto?
H alto percentual de trfego IP em IP?
filtro

binria

binria

Problema se agrava em certos horrios definidos (como

horrios de pico, horrio de ligao das estaes, etc)?
H alta taxa de colises?

Contatar nodo remoto.

informativa
Utilizar comando show interfaces no roteador remoto. relev. 5
Configurao est ok?
O roteador afetado est recebendo as rotas do roteador
filtro
remoto que deveria anunciar a rota para a sub-rede sem
acesso (comando sh ip route, por exemplo, onde deve ser
verificado se aparecem entradas enviadas por este
roteador remoto)?
H os protocolos RIP e IGRP no ambiente?
filtro

2
binria

binria

relev. 5

binria

relev. 5

binria

Rotas para as sub-redes envolvidas difundidas pelos

roteadores esto corretas?
H alta taxa de erros CRC?

relev. 5

binria

relev. 5

binria

Realizar teste de loop: configurar roteador local e remoto

com keepalive set, e pressionar LDL no modem remoto.
Qual o estado da interface local?

filtro

Realizar teste de loop: configurar roteador local e remoto

com keepalive set, e pressionar LDL no modem remoto.
Qual o estado da interface remota?

relev. 5

tipo carac. ad. estados

de itf., operao usar
mesmos valores
similaridade
tipo carac. ad. estados
de itf., operao usar
mesmos valores
similaridade

141

Anexo 3 Alguns Casos do Sistema

Na tabela a seguir, apresentada uma lista dos casos presentes no prottipo.
Exemplos de dois casos completos assim como a recuperao resultante destes casos
comentada na seo 6.2.
TABELA A3.1 - Lista dos casos presentes no prottipo
Id
100
102
103
104
105
106
107
108
111
115
116
117
118
119
121
122

Tipo de Problema
Conectividade - Fsico e
Config/HW
Conectividade - Fsico e
Config/HW
Conectividade - Fsico e
Config/HW
Conectividade - Fsico e
Config/HW
Conectividade - Fsico e
Config/HW
Conectividade - Fsico e
Config/HW
Conectividade - Fsico e
Config/HW
Conectividade - Fsico e
Config/HW
Roteamento/Endereamento
Roteamento/Endereamento
Roteamento/Endereamento
Roteamento/Endereamento
Roteamento/Endereamento
Roteamento/Endereamento
Alto Trfego

Tipo de Problema Inicial

Performance

Localizao do Problema
linha_serial

Conectividade - Genrico

linha_serial

Conectividade - Genrico

linha_serial

Conectividade - Genrico

linha_serial

Conectividade - Genrico

linha_serial

Conectividade - Genrico

linha_serial

Conectividade - Genrico

linha_serial

Conectividade - Genrico

linha_serial

Roteamento/Endereamento
Roteamento/Endereamento
Roteamento/Endereamento
Roteamento/Endereamento
Roteamento/Endereamento
Alto Trafego
Performance

outra_sub-rede_IP
outra_sub-rede_IP
outra_sub-rede_IP
outra_sub-rede_IP
outra_sub-rede_IP
canal_diversas_sub-redes_IP
mesma_subrede_IPLAN_com_um_segmento
mesma_subrede_IPLAN_com_um_segmento
mesma_subrede_IPLAN_com_um_segmento
mesma_subrede_IPLAN_com_um_segmento
outra_sub-rede_IP
mesma_subrede_IPLAN_com_um_segmento
outra_sub-rede_IP
outra_sub-rede_IP
mesma_subrede_IPLAN_com_um_segmento
outra_sub-rede_IP

Conectividade - Genrico

125

Conectividade - Fsico e
Config/HW
Conectividade - Fsico e
Config/HW
Roteamento/Endereamento

127
128

Roteamento/Endereamento
Roteamento/Endereamento

Conectividade - Genrico
Performance

129
130
132

Roteamento/Endereamento
Roteamento/Endereamento
Conectividade - Fsico e
Config/HW
Roteamento/Endereamento

Conectividade - Genrico
Roteamento/Endereamento
Conectividade - Genrico

123

133

Conectividade - Genrico

Conectividade - Genrico

Roteamento/Endereamento

Alm dos casos citados, foram coletados tambm casos para os tipos de
problemas envolvendo as aplicaes e servios, que no foram, entretanto,
implementados no prottipo. Apresentamos, a seguir, dois exemplos de casos coletados
para tais problemas.

142
Caso 1
Dados iniciais:
Tipo de Problema Inicial: Aplicao
Breve Descrio: no se consegue fazer FTP para mquina servidora.
Outras informaes: Percebe-se que o problema no com a rede, mas
no se consegue completar a conexo.

Aplicao utilizada: FTP

Aes efetuadas:
1. Acompanhando o processo (com telnet para a porta
correspondente ao FTP) possvel identificar onde est
ocorrendo algo incorreto? Resposta: SIM
Soluo:
Causas: Alguns servidores, como o do exemplo, exigem uso de IP
reverso na mquina cliente. Uma vez que a mquina cliente no
estava com o IP reverso configurado, ela no era autenticada e o
processo de conexo era interrompido.
Soluo Adotada: Configurar o IP reverso na mquina envolvida no
problema.

Caso 2
Dados iniciais:
Tipo de Problema Inicial: Servios - Servidor de Arquivos
Breve Descrio: uma nica estao da sub-rede no consegue ler
mails.

Outras Informaes: verificou-se que o problema ocorre devido a

incapacidade da estao em montar o /var/mail (estao gordini).
Houve Alterao: recm configurados
Mensagem: estao sem permisso no servidor NFS
Possveis Causas: NFS mal configurado, no havendo permisso
para exportar na estao origem dos arquivos.
Tipo de servidor de arquivos: NFS
Aes efetuadas:
1. A estao consta no /etc/exports do servidor de arquivos, com
atributos e permisses corretos? Resposta: SIM
2. No /etc/netgroups do servidor de NIS a mquina consta como
membro da sub-rede a qual faz parte? Resposta: SIM
3. Pela data de criao dos .db no NIS e a data de alterao do
/etc/netgroups, as alteraes foram atualizadas (foi dado o
push)? Resposta: SIM
4. O nome est sendo resolvido corretamente? (isso pode ser
feito atravs de um ping na estao envolvida via IP, para
verificar NIS, e um ping na estao envolvida via nome, para
verificar DNS. Resposta NO
Soluo:
Causas: Mapa do NIS estava inconsistente em relao ao mapa do
DNS, e nome resolvido pelo NIS no obtinha a mesma resposta do
nome resolvido pelo DNS. O mapeamento estava errado no NIS (mapa
com precedncia), ento, na validao do NFS, o IP no conferia
com o IP do pacotes de pedido de montagem.
Soluo Adotada: Tabela de resoluo no NIS foi corrigida.
Tipo de Problema Final: Servios - Autenticao

143

Anexo 4 Especificao SDL do Sistema

O diagrama do sistema, dos blocos cliente e servidor e dos principais processos
foi apresentado no captulo 6. Apresentamos, aqui, o diagrama dos demais processos do
sistema, que foram abordados nos diagramas de blocos mas ainda no foram definidos.
Inicialmente, apresentamos as definies dos mdulos do bloco cliente nas
figuras A4.1(InterpretaDados), A4.2(MostraTela), A4.3(ProcessaOperaes) e
A4.4 (ComunicaoCliente). Por fim, apresentamos a definio do InterpretaBD e do
ComunicaoServidor, mdulos do bloco servidor, nas figuras A4.5 e A4.6.
user: tuser
inf: tinf

PROCESS InterpretaDados
InterpretaDados
St 1
dB1(..)

Processa R.user

user=processaUsuario(...)
inf=processaQuery(...)

false

ValidaUsurio

EnviaInvalido

user
retornado

true

EnviaPedido

Si1(user)
Si10

Si2(inf)

EsperaRest
Si1(user)
Processa R.user

FIGURA A4.1 - Definio do InterpretaDados

PROCESS MostraTela
MostraTela

tela: html
ret: query ret

EsperaMsg

Si10
tela=usurio invlido
dB2(tela)

Si6(ret)
tela=montaResposta(ret)
dB2(tela)

FIGURA A4.2 - Definio do MostraTela

144

PROCESS ProcessaOperaes

inf: tinf
resp2=query ret
dadosI, ret: tdados

ProcessaOperaes

EsperaPedido

Si2(inf)
TrataDados
FazProcessamento
bool=hMaisConsultas(inf,dadosI,ret)
dadosI=processaInformaes(inf)
false

true

bool

Si9(dadosI)
resp2=montaResposta(inf, dadosI, ret)

FazProcessamento

EsperaResp
Si6(resp2)
Si9(ret)

TrataDados

FIGURA A4.3 - Definio do ProcessaOperaes

PROCESS ComunicaoCliente
ComunicaoCliente

EsperaDados

Si1(user)
msg=montaMensagem(user)
msg.tipo=USER

S1(msg)

msg: dados
msg_r: dados_r
user: tuser
dadosI: tdados

Si9(dadosI)

msg=montaMensagem(dadosI)

Si1(msg)

EsperaServidor

EsperaServidor

S2(msg_r)

S2(msg_r)

desmontaMensagem(msg_r)
Si1

EsperaDados

desmontaMensagem(msg_r)
Si9

EsperaDados

FIGURA A4.4 - Definio do ComunicaoCliente

145

PROCESS InterfaceBD
InterfaceBD

dadosLeitura: dadosLeitura
dados: tdados

EsperaConsulta

Si6

Si7

Si8

Si5

Si8

Si8

EsperaConsulta

Si8

AguardaBanco

AguardaBanco

Si9(dadosLeitura)

Si9(dadosLeitura)

dados=trataDados(dadosLeitura)

Si7(dados)
EsperaConsulta

dados=trataDados(dadosLeitura)

Si5(dados)
EsperaConsulta

FIGURA A4.5 - Definio do InterfaceBD

PROCESS ComunicaoServidor
ComunicaoServidor

msg: dados
msg_r: dados_r
query, query_r: tquery

EsperaDados
S1(msg)
query=desmontaMensagem(msg)

Si3(query)
EsperaResp

Si3(query_r)
msg_r=montaMensagem(query_r)

S2(msg_r)

EsperaDados

FIGURA A4.6 - Definio do ComunicaoServidor

146

Bibliografia
[AAM 94] AAMODT, A; PLAZA, E. Case-Based Reasoning: Foundational Issues,
Methodological Variations, and System Approaches. AI Communications, [S.l.],
v.7, n.1, p.39-59, Mar. 1994.
[ABE 95] ABEL, Mara; REATEGUI, Eliseo B.; CASTILHO, Jos M.V. Aquisio,
Modelagem e Processamento de Conhecimento utilizando Raciocnio Baseado em
Casos. In: SEMINRIO INTEGRADO DE SOFTWARE E HARDWARE, 12.,
1995, Canela. Anais... Porto Alegre: Instituto de Informtica da UFRGS, 1995.
p.363-374.
[ABE 95a] ABEL, Mara et al. Evaluating Case-Based Reasoning in a geological Domain. In:
INTERN. CONFERENCE AND WORKSHOP ON DATABASE AND
EXPERT SYSTEMS APLICATIONS, DEXA, 6., 1995, London. Proceedings...
Berlin: Springer-Verlag, 1995. p.364-373.
[ABE 96] ABEL, Mara. Um Estudo sobre Raciocnio Baseado em Casos: Trabalho
Individual. Porto Alegre: CPGCC da UFRGS, 1996.
[ACO 92] ACORN, T.; WALDEN, S. H. SMART: Support Management Automated
Reasoning Technology for Compaq Customer Service. [S.l.:s.n.], 1992
[BRA 91] BRANDAU, Richard.; LEMMON, Alan.; LAFOND, Carol. Experience with
Extended Episodes: Cases with Complex Temporal Structure In: DARPA
WORKSHOP ON CASE-BASED REASONING, 1991, Washington.
Proceedings... San Francisco: Morgan Kaufmann, 1991.
[CAB 97] CABLETRON SYSTEMS. SpectroRX: Add-on module for network and systems
management. Rochester: Cabletron Systems, 1997.
[CAB 97a] CABLETRON SYSTEMS. Technical Tips. Cabletron Systems. Documento
disponvel em http://www.cabletron.com/support/techtips/ (1997).
[CAB 97b] CABLETRON SYSTEMS. Troubleshooting Tips. Cabletron Systems. Documento
disponvel em http://www.cabletron.com/support/trbltips/ (1997).
[CAR 93] CARVALHO, T.C.M.B. (Org.) Gerenciamento de Redes: Uma Abordagem de
Sistemas Abertos. So Paulo: Makron Books, 1993.
[CAR 94] CARVALHO, T.C.M.B. (Org.) Arquiteturas de Redes de Computadores OSI e
TCP/IP. So Paulo: Makron Books, 1994.
[CAU 95] CAULIER, P.; HOURIEZ, B. A Case-Based Approach in Network Traffic Control.
In: IEEE INTERNATIONAL CONFERENCE ON SYSTEMS, MAN AND
CYBERNETICS. INTELLIGENT SYSTEMS FOR THE 21ST CENTURY.
1995, Vancouver, Canada. Proceedings... Piscataway: IEEE, 1995. p.1430-1435.
[CHA 96] CHANG, Kai H. et al. A self-improving helpdesk service system using case-based
reasoning techniques. Computers in Industry, Eindhoven, v.30, n.2, p.113-125,
Sept. 1996.

147

[CIS 97]

CISCO SYSTEMS, Inc. Internetwork Design Guide. 1997. Documento disponvel

em http://www.cisco.com/univercd/cc/td/doc/cisintwk/idg4/index.htm.

[CIS 97a] CISCO SYSTEMS, Inc. Internetwork Troubleshooting Guide. 1997. Documento
disponvel
em
http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1
/index.htm.
[CIS 97b] CISCO SYSTEMS, Inc. Internetworking Case Studies. 1997. Documento
disponvel em http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/index.htm.
[CIS 97c] CISCO SYSTEMS, Inc., Troubleshooting Internetworking Systems. 1997.
Documento disponvel em http://www.cisco.com/univercd/cc/td/doc/cisintwk/
tis_doc/index.htm.
[COM 91] COMER, Douglas E. Internetworking With TCP/IP Vol I: Principles, Protocols,
and Architecture. 2.ed. Englewood Cliffs: Prentice-Hall, 1991. 547p.
[CRO 88] CRONK, R. N.; CALLAHAN, P. H.; BERNSTEIN, L. Rule-Based Expert Systems
for Network Management and Operations: An Introduction. IEEE Network
Magazine, New York, v.5, n.2 , p.7-21, Sept. 1988. Artigo reimpresso em
ERICSON, E.C.; ERICSON, L.T.; MINOLI, D. Expert systems applications in
integrated network management. Norrwood: Artech House, 1989. 451p. p.94-104.
[DRE 95] DREO, Gabi., VALTA, Robert. Using master tickets as a storage for problemsolving expertise. In: INTERNATIONAL SYMPOSIUM ON INTEGRATED
NETWORK MANAGEMENT, 4., 1995. Proceedings... London: Chapman &
Hall, 1995. 716p. p.328-340.
[ENC 95] ENCK, John; BECKMAN, Mel. LAN to WAN interconnection. New York:
McGraw-Hill, 1995. 265p.
[ERI 89]

ERICSON, E.C.; ERICSON, L.T; MINOLI, D. (Eds.) Expert systems applications

in integrated network management. Norwood: Artech House, 1989. 451p.

[GOY 90] GOYAL, S.; WEIHMAYER, R.; BRANDAU, R. Intelligent systems in the future
network In: IEEE NETWORK OPERATIONS AND
MANAGEMENT
SYMPOSIUM OPERATIONS FOR THE INFORMATION AGE, 1990, San
Diego. Proceedings... New York: IEEE, 1990.
[GOY 91] GOYAL, S. Knowledge technologies for evolving networks. In: INTEGRATED
NETWORK MANAGEMENT, 2., 1991. Proceedings... Amsterdam: Elsevier
Science, 1991.
[HAR 89] HARMON, P.; SAWYER, B. Creating Expert Systems For Business and
Industry. New York: John Wiley, 1989. 329p.
[HAR 97] HARTMANN, L. Gerncia de Roteamento em Redes Interconectadas. Porto
Alegre: CPGCC da UFRGS, 1997. Dissertao de Mestrado.
[HUN 98] HUNT, Craig. TCP/IP Network Administration. 2.ed. Sebastopol: OReilly, 1998.
[JAC 86] JACKSON, P. Introduction to expert systems. Wokingham: Addison-Wesley,
1986.

148

[JOH 92] JOHNSON, D. NOC Internal Integrated Trouble Ticket System: Funcional
Specification Wishlist. RFC 1297. [S.l.]: IAB, 1992.
[KOL 93] KOLODNER, Janet. Case-Based Reasoning. San Mateo: Morgan Kaufmann, 1993.
668p.
[KOP 88] KOPEIKINA, Ludmila et al. Case Based Reasoning for Continuous Control In:
WORKSHOP ON CASE-BASED REASONING, DARPA, 1988. Proceedings...
San Mateo: Morgan Kaufmann, 1988.
[KRI 91] KRISHNAN, I.; ZIMMER, W. (Eds.). INTERNATIONAL SYMPOSIUM ON
INTEGRATED NETWORK MANAGEMENT, 2., 1991, Crystal City, US.
Proceedings... Amsterdan: North-Holland, 1991.
[LEA 96] LEAKE, David (Ed). Case-Based Reasoning: Experiences, Lessons & Future
Directions. Menlo Park: AAAI Press/MIT Press, 1996.
[LEI 96]

LEINWAND, A.; CONROY, K. F. Network Management. A Practical Perspective.

2.ed. Menlo Park: Addison-Wesley, 1996.

[LEW 92] LEWIS, Lundy. Case-based Reasoning with Fuzzi Inference: A Backend to Network
Analyzers. In: INTERNATIONAL CONFERENCE ON FUZZI THEORY AND
TECHNOLOGY, 1., 1992. Proceedings... [S.l.:s.n.], 1992.
[LEW 93] LEWIS, Lundy. A Case-Based Reasoning Approach to the Management of faults in
Communications Networks. IEEE INFOCOM, San Francisco, v.3, p.1422-1429,
Apr. 1993. Trabalho apresentado no Annual Joint Conference of The IEEE
Computer and Communications Societies, 20., 1993.
[LEW 93a] LEWIS, Lundy.; DREO, Gabi. Extending Trouble Tickets Systems to Fault
Diagnostics. IEEE Network, New York, v.7, n.6, p.44-51, Nov. 1993.
[LEW 95] LEWIS, Lundy. Managing Computer Networks: A Case-Based Reasoning
Approach. Norwood: Artech House, 1995. 205p.
[LEW 95a] LEWIS, Lundy. AI and Intelligent Networks in the 1990s and into the 21st Century.
In: LIEBOWITZ, J; PRERAU, D. (Eds.) Wordwide Intelligent Systems:
Approaches to Telecommunications and Network Management. Amsterdam: IOS
Press, 1995.
[MAD 94] MADRUGA, E. L. Ferramentas de Apoio Gerncia de Falhas e Desempenho
em Contexto Distribudo. Porto Alegre: CPGCC da UFRGS, 1994. Dissertao
de Mestrado.
[MAR 94] MARIR, Farhi; WATSON, Ian. Case-Based Reasonig: A Categorised Bibliography.
The Knowlege Engineering Review, London, v.9, n.4, p.355-381, 1994.
Documento disponvel tambm em http://www.salford.ac.uk/docs/depts
/survey/staff/IWatson/cbrefs.htm
[MAT 95] MATSUMOTO, K.; HASHIMOTO, K.; OBANA, S. Design and implementation of
real-time expert system for troubleshooting in international telephone networks. In:
INTERNATIONAL CONFERENCE. INDUSTRIAL AND ENGINEERING
APPLICATIONS OF ARTIFICIAL INTELLIGENCE AND EXPERT

149

SYSTEMS, 8., 1995, Melbourne, Australia. Proceedings... Newark: Gordon &

Breach, 1995. p.345-352.
[MEI 97] MEIRA, D.M; NOGUEIRA, J.M.S. Mtodos e Algoritmos para Correlao de
Alarmes em Redes de Telecomunicaes. In: SIMPSIO BRASILEIRO DE
REDES DE COMPUTADORES, 15., 1997, So Carlos. Anais... So Carlos:
UFSCAR, 1997. p.79-98.
[MEL 97] MELCHIORS, Cristina. Suporte para Gerenciamento Distribudo Colaborativo. In:
SEMANA ACADMICA DO CPGCC, 2., 1997, Porto Alegre. Anais... Porto
Alegre: CPGCC da UFRGS, 1997. 243p. p.211-214.
[MEL 99] MELCHIORS, Cristina. Um Estudo sobre Raciocnio Baseado em Casos: relatrio
tcnico. Porto Alegre, PPGC da UFRGS, 1999. (RP 301).
[MEL 99a] MELCHIORS, Cristina; TAROUCO, Liane M. R. Fault Management in Computer
Networks
Using
Case-Based
Reasoning:
DUMBO
System.
In:
INTERNATIONAL CONFERENCE ON CASE-BASED REASONING, 3.,
1999, Seeon Monastery, Germany. Proceedings... Berlin: Springer, 1999.
p. 510-524. (Lecture Notes in Artificial Intelligence, v. 1650).
[MEL 99b] MELCHIORS, Cristina; TAROUCO, Liane M. R. DUMBO: Uma Abordagem para
Gerenciamento de Falhas Utilizando Raciocnio Baseado em Casos. In:
SIMPSIO BRASILEIRO DE REDES DE COMPUTADORES, 17., 1999.
Salvador. Anais... Salvador: SBC, 1999. p. 575-576.
[MIL 95] MILLER, Mark. A. Troubleshooting Internetworks: tools, techniques, and
protocols. San Mateo: M&T Books, 1995. 528p.
[MIL 96] MILLER, Mark. A. Troubleshooting TCP/IP: analyzing the protocols of the
Internet. New York: M&T Books, 1996. 772p.
[NAS 94] NASSAR, D. J. Network Optimization and Troubleshooting. Indianopolis: New
Rider Publishing, 1994. 639p.
[NEM 95] NEMETH, Evi et al. UNIX System Administration Handbook. New Jersey:
Prentice Hall, 1995. 779 p.
[NUN 97] NUNES, C. M. Um Discriminador Inteligente de Eventos de Rede para o
Ambiente CINEMA. Porto Alegre: CPGCC da UFRGS, 1997. Dissertao de
Mestrado.
[PAR 97] PARNELL, Ter. LAN Times Guide to Wide Area Networks. Berkeley: McGrawHill, 1997. 528p.
[PEN 99] PENIDO, G.; NOGUEIRA, J.M.; MACHADO, C. An automatic fault diagnosis and
correction system for telecommunications management. In: IFIP/IEEE
INTERNATIONAL SYMPOSIUM ON INTEGRATED NETWORK
MANAGEMENT, 6. 1999. Proceedings... [S.l.]:IEEE, 1999.
[PHD 97] PHD. When Someone on eht Other End of the Line Depends on You Depend On
Us PHD: The Virtual Help Desk. Stamford: PHD, 1997.
[RAM 95] RAMAN, Pradeep. Case-Based Reasoning: An Implemented Methodology. Auburn:

150

Auburn University, 1995. (Technical Report 04-95, MCSE Desingner Project

Report).
[RHE 90] RHEIN, Jon et al. The POSTGRES User Manual. Berkeley: University of
California, 1990. 31p.
[SIM 92] SIMOUDIS, Evangelos. Using Case-Based Retrieval for Customer Technical
Support. IEEE Expert, Los Alamitos, v.7, n.5, p.7-12, Oct.1992.
[SIN 96]

SINGH, Harry. Heterogeneous Internetworking: networking technically diverse

operanting systems. New Jersey: Prentice-Hall, 1996. 644 p.

[SNG 90] SNG, Dennis Cheng-Hong. Network Monitoring and Fault Detection on the
University of Illinois at Urbana-Champaign Campus Computer Network.
Urbana-Champaign: DCS/UIUC, 1990. (Technical Report UIUCDCS-R-901595).
[STA 93] STADLER, M. Case-Based Reasoning for Network Management. In: TOPICS IN
CASE-BASED REASONING EUROPEAN WORKSHOP EWCBR-93, 1.,
1993. Berlin: Springer-Verlag, 1994. p. 414-423.
[STA 97] STALLINGS, William. Local & Metropolitan Area Networks. 5.ed. New Jersey:
Prentice-Hall, 1997. 605 p.
[STE 95] STEFIK, M. Introduction to Knowledge Systems. San Francisco: Morgan
Kaufmann Publishers, 1995. 870p.
[STO 90] STONEBRAKER, Michael et al. POSTGRES Reference Manual. Berkeley, CA,
EUA: University of California, 1990. 128p.
[TAN 96] TANEMBAUM, Andrew S. Computer Networks. 3.ed. New Jersey: Prentice-Hall,
1996. 814p.
[TAR 90] TAROUCO, L. M. R. Inteligncia Artificial Aplicada ao Gerenciamento de Redes
de Computadores. So Paulo: Escola Politcnica da USP, 1990. Tese de
Doutorado.
[TAR 96] TAROUCO, Liane M.R. et al. Um ambiente para gerenciamento integrado e
cooperativo. In: WORKSHOP SOBRE ADMINISTRAO e INTEGRAO
DE SISTEMAS, WAIS, 2., 1996, Fortaleza. Anais... Fortaleza: UFC, 1996.
p.235-246.
[TAR 96a] TAROUCO, Liane M.R. et al. Um ambiente para gerenciamento integrado e
cooperativo. In: WORKSHOP DE GERNCIA DE REDES DE
COMPUTADORES, 1996, Fortaleza. Anais... Fortaleza: UFC, 1996.
[TIS 97]

TISCHLER, F.; LAMM, J. The Intranet/Support Connection Support

Management. [S.l.]: PHD, 1997.

[TRI 92]

TRINDADE, Rodrigo S. Um Estudo da Linguagem SDL para Especificao e

Teste de Protocolos: Trabalho Individual. Porto Alegre: CPGCC da UFRGS,
1992. 87p.

[TUR 92] TURBAN, Efraim. Expert Systems and Applied Artificial Intelligence. New York:

151

Macmillan Publishing, 1992.

[UDU 96] UDUPA, D. K. Network Management Systems Essentials. New York: McGrawHill, 1996.
[WAT 94] WATSON, Ian; MARIR, Farhi. Case-based Reasoning: A review. The Knowledge
Engineering Review, London, v.9, n.4, p. 327-354, 1994.
[WAT 95] WATSON, Ian. Case-Based Reasoning Development Tools: A Review. 1995.
Documento obtido em http://www.salford.ac.uk/docs/depts/survey/staff/IWatson
/cbrefs.htm
[WAT 97] WATSON, Ian. Applying Case-Based Reasoning: Techniques for Enterprise
Systems. San Francisco: Morgan Kaufmann, 1997. 289p.
[WIL 94] WILLIAMS, C. CLAYTON, B. D. Case Based Retrieval. [S.l.]: Inference
Corporation, 1994.