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 CMIP CMIS CNPq CPGCC CPU IA IAD IP ISO MBR MOP OSI RBR SDL SNMP TCP UFRGS Case-Based Reasoning (raciocnio baseado em casos) Common Management Information Protocol Common Management Information Services Conselho Nacional de Desenvolvimento Cientfico e Tecnolgico Curso de Ps-Graduao em Cincia da Computao Central Processing Unit Inteligncia Artificial Inteligncia Artificial Distribuda Internet Protocol International Organization for Standardization Model-Based Resoning (raciocnio baseado em modelos) Memory Organization Packets Open Systems Interconnection Rule-Based Reasoning (raciocnio baseado em regras) Specification and Description Language Simple Network Management Protocol Transmission Control Protocol 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

REVISO Caso Proposto

REUTILIZAO

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 Reinstanciao Parametrizada Busca local Consulta memria Substituio baseada em casos Transformao de senso comum Reparo guiado ao modelo Adaptao ou reparo de propsitos especiais Adaptao por derivao Adaptao baseada em crtica Orientao estrutural senso comum especializada, senso comum especializada casos senso comum modelo causal especializada, senso comum, modelo causal casos senso comum Tarefa substituio substituio substituio substituio substituio transformao transformao, substituio transformao, substituio transformao, substituio transformao, substituio Opera com valores valores valores, estruturas valores, estruturas valores valores, estruturas valores, estruturas valores, estruturas valores, estruturas 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 deteco dos erros da soluo corrente modificao das falhas na soluo proposta

caso corrente com soluo satisfatria

caso corrente com soluo com falhas

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].
comandos do analisador de dump do sistema para a mquina do cliente

engenheiro de front-line

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?? 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

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

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);

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:

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;

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].

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;

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 Pr-Processador Monitor Histria Tratamento

Indexador / Casador
Casos Recuperados

Aprendiz

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 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 [0, 1].

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 Alarm ID
00000000116 57

Submitter Create-date Notify-method

SPECTRUM 07/24/92 08:51:08

oNone oNotifier oE-mail

Alarm Date/Time 07/24/92 08:51:07 Condition oRed oOrange oYellow Device Name Ethernet-Randy Device Type IP Address Trouble Additional Data History of Trouble Probable Cause Resolution Resolution Status Ticket Status
o Good o o o

Assigned-Priority oLow oMedium oHigh Assigned-to Last-modified-by SPECTRUM Modified-date 07/24/92 08:51:08

Ethernet

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

No Good Assigned

o o

In Progress Reject
o

New

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

Biblioteca Trouble Tickets

Entra

Recupera

Adapta

Prope

Processa

Determinadores

Tcnicas Adaptao

Adaptao baseada Usurio

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 Referncias [HUN 98]

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

[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 cabos Ethernet sem terminao cabos Ethernet com comprimento excessivo nmero excessivo de repetidores na rede 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) incompatibilidade entre IEEE 802.3 e Ethernet software defeituoso na placa de rede cabeamento defeituoso associado a um nodo Ethernet (falhas na placa de rede, transceiver, conectores) Possveis Sintomas alta taxa de colises colises tardias Referncias [CIS 97a] [CIS 97a]

ausncia de integridade no enlace [CIS 97a] em 10BaseT, 100BaseT4 ou 100BaseTX

ausncia de acesso para nodos [MIL 96] configurados diferentes, estaes [SIN 96] recm configuradas taxa excessiva de frames [CIS 97a] pequenos, sem alta taxa de colises simultnea 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) taxa excessiva pequenos de frames [CIS 97a]

alta taxa de colises

66

Causas rudo excessivo no meio, causado por cabeamento defeituoso, pancadas espaadas causando reflexes

Possveis Sintomas

Referncias

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 ocorrncia de falha associada a [NAS 94] uma porta especfica do equipamento no segmento especfico, nodos no operam ou congelam e penduram durante operao 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 nenhum trfego atravessa a ponte [NAS 94] ou dados so corrompidos intermitentemente quando atravessam o equipamento trfego excessivo presente em um [NAS 94] certo segmento broadcast storms excessivas vindo da ponte equipamento conectado ao nodo [NAS 94] Ethernet no pode ser acessado

porta de repetidor ou hub com falha

repetidor ou hub com falha

configurao de hardware ou software de uma ponte incorreto configurao de parmetros que controlam a quantidade de trfego a ser enviada na ponte incorretos 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

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 equipamentos da companhia telefnica defeituosos linha serial com rudo cabos incorretos ou longos demais trfego de entrada na interface serial excede a largura de banda disponvel trfego na entrada excede a capacidade do roteador filas de entrada excedem o tamanho das filas de sada Possveis Sintomas Referncias

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

descartes de crescente

sada

em

taxa [CIS 97c]

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 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 conectividade intermitente [CIS 97a] ocorrncia de resets na interface [CIS 97c] em nmero crescente alta taxa de erros de entrada contador das transies portadora crescente na [CIS 97a]

congestionamento no enlace

problemas de hardware no CSU/DSU, ou no enlace

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

ausncia de conectividade

[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 rota default no especificada ou incorreta gateway default no especificado ou incorreto em estao local ou remota Possveis Sintomas 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 mtricas incorretas ausncia de conectividade Referncias [CIS 97a] [CIS 97a] [CIS 97c]

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]

[MIL 96]

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 Referncias [MIL 96]

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)

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 tipo problema _caracterizado_por _um problemas nas camadas superiores provveis causas

_um problemas na comunicao

_caracterizado_por problemas na comunicao localizao do problema

_um _um _um _um

_um

conectividade genrico

alto trfego conectividade fsico e config/HW roteamento / endereamento performance

problemas nas camadas superiores

_um _um _um _um

_um

aplicao servios resoluo de nomes servios autenticao servios servidor arquivos

outros

FIGURA 5.1 - Rede semntica dos tipos de problemas

80

falta de acesso _caracterizado_por conectividade genrico modo de falta de acesso roteamento endereamento _caracterizado_por

falta de acesso

_caracterizado_por

_caracterizado_por

modo de falta de acesso

_caracterizado_por

problema mantm usando IP

_caracterizado_por

problema mantm usando IP

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

falta de acesso conectividade fsico e config HW _caracterizado_por

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

performance ruim como falta de acesso

_caracterizado_por alto trfego

_caracterizado_por

_caracterizado_por

qual tipo de trfego com taxa elevada

ocorrncia de alta taxa de erros _um _um quais tipos de erros

no h alta taxa de erros

h alta taxa de erros

_caracterizado_por

ocorrncia de alto tempo de resposta _um no h alto tempo de resposta _um em que h alto tempo de _caracterizado_por resposta

h alto tempo de resposta

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

81

localizao do problema

_um _um linha serial entre mesma sub-rede IP entre sub-redes IP canal de uma LAN _um _um

_um

canal de diversas sub-redes IP

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

- consulta das caractersticas adicionais por tipo_de_problema - relao histrica entre tipos de problema - caractersticas redirecionadoras

Recuperador Recuperador Inicial

Criao Registro

ndices/filtro do problema Interface Usurio

Seletor adaptao baseada em crtica avaliao do problema reviso do problema quando necessrio

ndices/relevncia do problema

Encerramento Registro
insero similaridades definio ndices especiais problema definio de novo caso

Reutilizador Revisor

- 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 equipamentos interconexo enlace causado por

causado por

cabeamento

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 Valores Possveis da Caracterstica nmeros reais positivos Tipo de Casamento exato e 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

binria

SIM, NO

apenas exato

qualitativa para termos (expresses) termos fixos pr-definidos para a caracterstica qualitativa para termos (expresses) termos cadastrados com variveis possibilidade de novos termos exata para termos variveis textual termos (expresses) cadastrados com possibilidade de novos termos texto livre

exato e parcial

exato e parcial

apenas exato

parcial

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 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

Conectividade Fsico e Config/HW Roteamento/Endereamento Performance

Alto Trfego

Aplicao

Servios Compartilhamento Arq. Servios Autenticao Servios Resoluo Nomes

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

Similarida de(Cr , R ) =

Wi * sim f
i =1

C i

R i

* Ci

n i =1

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.

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 S1(dados), S2(dados), dB1(dadosdB1), dB2(dados dB2), SAtualiza(dadosAtualiza), SLeitura(dadosLeitura)

B1[dB1]

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
R10[Si10]

R3[Si1] R4[Si2] R11[S1] R6[Si6]

B2

R2[dB2]

Monta Tela

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
CBR
R4[Si4] R5[Si5]]

SIGNAL Si1..Sin Si3: tquery Si4: tdadoscbr Si5, Si7: tdados Si6: tbdini

PEDIDO RESPOSTA

R1 R2

Comunicao R3[Si3] Servidor

Servidor
R6[Si6,Si7]

Interface BD
R8[Si9] R7[Si8]

CLeitura

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
Servidor Si6(dadosIniBD)

PROCESS filho
filho Si7(..) query: tquery respUser: tdados dadosIniBD: tdbini

idle

EsperaRespUser

Si3(...)

Si7(respUser)

CREATE filho(...)

userOk (respUser)

idle Si3(user invlido) Si3(user vlido) ProcessaPedidos Si3(query)

tipo (query.tipo)

ENCERRA

BD

CBR

Si7

Si4

AguardaBD

AguardaBD

Si7 Si3

Si4 Si3

ProcessaPedidos

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
CBR EsperaConsulta Si4(d1) d1: tdadosCbr d2, consBD: tdados

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

Si5(consBD)

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

false

bool

true

Si3(user vlido) EsperaConsulta

ProcessaCBR

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 Conectividade - Genrico Conectividade - Fsico e Config/HW Roteamento/Endereamento Performance Alto Trfego Nmero de Casos 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 Caractersticas Especficas Finais do Caso 132: Id: 21 Valor: NO, Ordem: 1

Tipo: binria

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] [0.56] (Id 6) Ha perda de pacotes grandes com teste ping? (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 linha serial enlaces com problema _caracterizado_por _caracterizado_por

_um

_um _um _caracterizado_por

informaes sobre roteador

vrias linhas sem roteador em comum

uma nica linha

_caracterizado_por

identificao roteador remoto

_caracterizado_por

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 informaes entidades origem da com. informaes entidades destino da com.

_um

_um

sub-rede IP possui um segmento / domnio de coliso

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

_um

_um

primeiro roteador no atingido

roteador diferente do final ltimo atingido

ltimo roteador atingido

_caracterizado_por primeiro roteador no atingido _caracterizado_por

entre mesma sub-rede IP

rota para subredes destino

_um

_um informaes sobre roteador _caracterizado_por

atravs de vrios roteadores

atravs de um mesmo roteador

entre mesma sub-rede IP ltimo roteador atingido _caracterizado_por

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

133

roteador diferente do final ltimo atingido

rota para subredes destino _caracterizado_por

informaes sobre roteador _caracterizado_por

_um _um _um

_um

todas sub-redes a partir do roteador so afetadas

algumas sub-redes a partir do roteador so afetadas segue por diversas interfaces

_caracterizado_por

abrangncia sub-rede afetada identificao sub-rede afetada interface de rede

segue por uma nica interface _caracterizado_por _caracterizado_por

_um

_um

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

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

quais segmentos envolvidos.

identificao sub-rede

_caracterizado_por _caracterizado_por

percentual de utilizao do canal

canal de LAN

_caracterizado_por

interface de rede

_um

_um

LAN com um nico segmento / domnio de coliso

LAN com mais de um segmento / domnio de coliso percentual de utilizao do canal _caracterizado_por _um

canal de diversas sub-redes IP

_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 tipo interface especfico

Ethernet

_caracterizado_por

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

sistema operacional

_caracterizado_por informaes entidades destino da com.

tipo equipamento abrangncia entidades destino no segmento afetado

_caracterizado_por _caracterizado_por

_caracterizado_por

abrangncia entidades destino da sub-rede afetada modo ligao s LANs

_um

_um

_um _caracterizado_por

equipamento intermedirio

conectadas diretamente

conectadas diretamente e indiretamente

conectadas indiretamente

_caracterizado_por _caracterizado_por

acessibilidade ao equipamento intermedirio

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 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

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

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 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

provveis componentes com falha de roteamento

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 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 Estado Geral 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 Tipo Equipamento estao de trabalho estao de trabalho microcomputador roteador roteador switch switch switch

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

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 Observaes Custo tipo carac. ad. estados 2 de itf., operao usar mesmos valores similaridade binria 2 binria 1 2 2 2

Contatar nodo remoto. Outros enlaces deste ponto apresentam problemas? H perda de pacotes grandes com teste ping?

relev. 5 relev. 5

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 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 Problema se agrava em certos horrios definidos (como horrios de pico, horrio de ligao das estaes, etc)? H alta taxa de colises? Rotas para as sub-redes envolvidas difundidas pelos roteadores esto corretas? H alta taxa de erros CRC? Realizar teste de loop: configurar roteador local e remoto com keepalive set, e pressionar LDL no modem remoto. Qual o estado da interface local? 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 relev. 5 relev. 5 relev. 5 filtro

binria binria

binria binria binria

1 1 2 2

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

2 2 2 1 2 1 2

relev. 5

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 123 125 127 128 129 130 132 133 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 Conectividade - Fsico e Config/HW Conectividade - Fsico e Config/HW Roteamento/Endereamento Roteamento/Endereamento Roteamento/Endereamento Roteamento/Endereamento Roteamento/Endereamento Conectividade - Fsico e Config/HW Roteamento/Endereamento Tipo de Problema Inicial Performance Conectividade - Genrico Conectividade - Genrico Conectividade - Genrico Conectividade - Genrico Conectividade - Genrico Conectividade - Genrico Conectividade - Genrico Roteamento/Endereamento Roteamento/Endereamento Roteamento/Endereamento Roteamento/Endereamento Roteamento/Endereamento Alto Trafego Performance Conectividade - Genrico Conectividade - Genrico Conectividade - Genrico Conectividade - Genrico Performance Conectividade - Genrico Roteamento/Endereamento Conectividade - Genrico Roteamento/Endereamento Localizao do Problema linha_serial linha_serial linha_serial linha_serial linha_serial linha_serial linha_serial linha_serial 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

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.
PROCESS InterpretaDados
InterpretaDados St 1 dB1(..) user=processaUsuario(...) inf=processaQuery(...) Processa R.user user: tuser inf: tinf

false

user retornado

true

ValidaUsurio Si1(user)

EnviaInvalido

EnviaPedido

Si10 EsperaRest Si1(user) Processa R.user

Si2(inf)

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
ProcessaOperaes

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

EsperaPedido

Si2(inf) TrataDados FazProcessamento bool=hMaisConsultas(inf,dadosI,ret) dadosI=processaInformaes(inf) false Si9(dadosI) resp2=montaResposta(inf, dadosI, ret) EsperaResp Si6(resp2) Si9(ret) FazProcessamento bool true

TrataDados

FIGURA A4.3 - Definio do ProcessaOperaes

PROCESS ComunicaoCliente
ComunicaoCliente

EsperaDados

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

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

Si9(dadosI)

msg=montaMensagem(dadosI)

S1(msg)

Si1(msg)

EsperaServidor S2(msg_r) desmontaMensagem(msg_r) Si1

EsperaServidor S2(msg_r) desmontaMensagem(msg_r) Si9

EsperaDados

EsperaDados

FIGURA A4.4 - Definio do ComunicaoCliente

145

PROCESS InterfaceBD
InterfaceBD dadosLeitura: dadosLeitura dados: tdados

EsperaConsulta

Si6 Si8 Si8

Si7 Si8

Si5 Si8

AguardaBanco Si9(dadosLeitura)

AguardaBanco Si9(dadosLeitura)

EsperaConsulta

dados=trataDados(dadosLeitura)

dados=trataDados(dadosLeitura)

Si7(dados) EsperaConsulta

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. TRINDADE, Rodrigo S. Um Estudo da Linguagem SDL para Especificao e Teste de Protocolos: Trabalho Individual. Porto Alegre: CPGCC da UFRGS, 1992. 87p.

[TRI 92]

[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.