Dissertao submetida avaliao, como requisito parcial para a obteno do grau de Mestre em Cincia da Computao
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.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
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
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.
12
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.
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
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.
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.
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.
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:
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]:
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)
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.
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.
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:
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.
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:
31
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
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.
35
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
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:
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
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.
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].
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
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;
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.
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.
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
Criticador
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
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++.
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
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
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
Entra
Recupera
Adapta
Prope
Processa
Determinadores
Tcnicas Adaptao
Usurio
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.
59
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.
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.
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]:
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.
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]
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 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]
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
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
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
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
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
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
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 97c]
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)
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
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
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.
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
conectividade genrico
_um
outros
80
falta de acesso _caracterizado_por conectividade genrico modo de falta de acesso roteamento endereamento _caracterizado_por
falta de acesso
_caracterizado_por
_caracterizado_por
_caracterizado_por
_caracterizado_por
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
ocorrncia de alta taxa de erros _caracterizado_por ocorrncia de alto tempo de resposta falta de acesso _caracterizado_por
_caracterizado_por
_caracterizado_por
_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
81
localizao do problema
_um _um linha serial entre mesma sub-rede IP entre sub-redes IP canal de uma LAN _um _um
_um
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
Criao Registro
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
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.
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.
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
servios servios conectividade conectividade roteamento performance alto servios outros aplicao resoluo fsico e endereamento genrico trfego autenticao compartilhamento configHW nomes arquivos
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.
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.
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
cabeamento
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.
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
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
Alto Trfego
Aplicao
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.
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
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
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
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).
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].
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]
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]
B2
R2[dB2]
Monta Tela
Processa Operaes
R9[Si9]
PEDIDO
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
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)
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)
false
bool
true
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
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
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.
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.
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
_um
_caracterizado_por
_caracterizado_por
_caracterizado_por vrias linhas com roteador em comum _caracterizado_por informaes sobre roteador estado interface roteador remoto
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
_caracterizado_por
132
_um
_um
_um
_um
_um
_um
133
_um
_caracterizado_por
_um
_um
identificao sub-rede
_caracterizado_por _caracterizado_por
canal de LAN
_caracterizado_por
interface de rede
_um
_um
LAN com mais de um segmento / domnio de coliso percentual de utilizao do canal _caracterizado_por _um
_um _um em seqncia sem equipamento em comum sem sequncia sem equipamento em comum
134
Serial
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 _caracterizado_por
_caracterizado_por
_um
_um
_um _caracterizado_por
equipamento intermedirio
conectadas diretamente
conectadas indiretamente
_caracterizado_por _caracterizado_por
135
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
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
mensagem
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
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
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
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
false
user retornado
true
ValidaUsurio Si1(user)
EnviaInvalido
EnviaPedido
Si2(inf)
EsperaMsg
144
PROCESS ProcessaOperaes
ProcessaOperaes
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
PROCESS ComunicaoCliente
ComunicaoCliente
EsperaDados
Si9(dadosI)
msg=montaMensagem(dadosI)
S1(msg)
Si1(msg)
EsperaDados
EsperaDados
145
PROCESS InterfaceBD
InterfaceBD dadosLeitura: dadosLeitura dados: tdados
EsperaConsulta
Si7 Si8
Si5 Si8
AguardaBanco Si9(dadosLeitura)
AguardaBanco Si9(dadosLeitura)
EsperaConsulta
dados=trataDados(dadosLeitura)
dados=trataDados(dadosLeitura)
Si7(dados) EsperaConsulta
Si5(dados) EsperaConsulta
Si3(query) EsperaResp
Si3(query_r) msg_r=montaMensagem(query_r)
S2(msg_r)
EsperaDados
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.