Universidade do Estado do Rio Grande do Norte
Núcleo de Ensino Superior de Santa Cruz
Disciplina: Sistema Tolerante a Falha
Professor: Giliard Faustino
SOFTWARE TOLERANTE A FALHA
Acadêmicas: Islâne Gomes
Maria Aline
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Guias e Dicas
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Encontrar documentos
Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity
Encontra documentos específicos para os exames da tua universidade
Encontra documentos específicos para os exames da tua universidade
Videoaulas
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Quiz
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Apresentação STF, Notas de estudo de Informática
Técnicas de Software Tolerante a Falha
Tipologia: Notas de estudo
2013
1 / 40
Esta página não é visível na pré-visualização
Não perca as partes importantes!
Documentos relacionados
Pré-visualização parcial do texto
Baixe Apresentação STF e outras Notas de estudo em PDF para Informática, somente na Docsity!
Universidade do Estado do Rio Grande do Norte Núcleo de Ensino Superior de Santa Cruz Disciplina: Sistema Tolerante a Falha Professor: Giliard Faustino
SOFTWARE TOLERANTE A FALHA
Acadêmicas: Islâne Gomes Maria Aline
Sumário
- (^) Introdução
- (^) Computação Pervasiva
- (^) Falha em Software
- (^) Software Confiável
- (^) Macanismos para `` Dependability '‘
- (^) Prevenção de Falhas
- (^) Remoção de Falhas
- (^) Previsão de Falhas
- (^) Tolerância a Falha - TF
- (^) Redundância de Software
- (^) Conclusão
- (^) Referências
Computação Pervasiva
- (^) Computação pervasiva:
- (^) Computação invisível ao usuário;
- (^) Obter informações do ambiente no qual está inserido;
- (^) Ajusta a aplicação para melhor atender as necessidades do usuário.
Computação Pervasiva
- (^) Softwares normalmente assumem a maior parte da funcionalidade destes sistemas pervasivos e ubíquos críticos. - (^) Erros neles podem ser catastróficos. - (^) Apesar dos avanços, nem todos os erros são identificados
- (^) Os ambientes de desenvolvimento integrado(do inglês , Integrated Development Environment - IDE) ajudam a minimizar estes erros.
Falhas em Softwares
- (^) É diferente, pois eles não 'deterioram' com o tempo
- (^) Os erros são mais de lógica, o que os tornam mais complexos
- (^) Não podemos simplesmente duplicar o sistema, pois isto duplicará os erros
Software Confiável ( Dependable )
- (^) Alguns motivos que nos fazem necessitar de STF:
- (^) Onipresença do software (pervasivo) e o seu uso tanto em aplicações críticas e cotidianas - (^) e.g. equipamentos domésticos
- (^) Aumento da complexidade
- (^) e.g. sistemas embarcados em aviões
- (^) Presença de software em aplicações críticas (e.g. em reatores nucleares)
- (^) Precisamos deles em ambientes críticos?
Mecanismos para “Dependability”
- (^) São de dois tipos:
- (^) Mecanismos empregados durante a construção do software, i.e., construction - (^) Prevenção de Falha : evitar que ocorram erros (e.g. verificar se o usuário digitou os dados corretamente)
- (^) Mecanismos que contribuem para validar o software após a sua construção, i.e., validation. - (^) Remoção e Previsão de Falha : eliminar os erros e estimar a presença de erros e as suas consequências
Software Confiável
- (^) Mecanismos na construção
- (^) Prevenção de Falhas : evitar a introdução de erros
- (^) Tolerância a Falha : verificar o que o sistema pode garantir (dentro do especificado) apesar das falhas
- (^) Mecanismos na validação
- (^) Remoção de Falha : identificar a presença de falhas e eliminá-las
- (^) Previsão de Falha : estimar a presença de falhas, assim como a ocorrência e as suas consequências
Prevenção de Falha
- (^) 1) Especificação de Requisitos do Sistema
- (^) Especificações de requisitos são muitas vezes consideradas como imperfeitas
- (^) Isto ocorre pela falta de comunicação entre os desenvolvedores e os que especificam o sistema
- (^) Muitas das ferramentas endereçam mais os erros de implementação do que os da engenharia de requisitos
- (^) Porém, existem ferramentas interativas que ajudam neste processo
- (^) Estudo de caso na construção de sistemas reais(e.g. ALEPA)
Prevenção de Falha
- (^) 2) Projeto estruturado e técnicas de programação
- (^) Estas técnicas tem se mostrado eficiente Reduzem a complexidade (e.g. evitar o goto )
- (^) Dissociação e modularização tanto na implementação e no projeto ajudam a reduzir falhas (i.e., menor interdependência entre os 'módulos')
- (^) Sistemas coesos ajudam neste processo
- (^) Outra técnica é a componentização: reusabilidade em todos os níveis (multilinguagem)
- (^) Todas estas técnicas ajudam a reduzir a complexidade e a resolução dos problemas
- (^) Levam a sistemas com menos falhas
Prevenção de Falha
- (^) 4) Reuso de Software
- (^) O reuso de software permite uma maior confiabilidade. Por que?
- (^) Objetos e componentes testados e aprovados poderão ser reusados
- (^) Pode trazer outras vantagens além da confiabilidade: economia no processo de desenvolvimento
- (^) Promove a coesão, o que aumenta a confiabilidade
- (^) Reuso deve ser medido de caso a caso, pois há diferentes níveis de confiabilidade requisitados em cada sistema individual.
Prevenção de Falha
- (^) Outros mecanismos são também perfeitamente aceitos - (^) Refinamento de requisitos de forma interativa com o usuário final, por exemplo - (^) Utilização de bons métodos de ES (e.g. XP) - (^) Implementação de códigos legíveis (e.g. documentação de código)
- (^) A técnica de métodos formais é baseada em mecanismos muito complexos
- (^) O reuso de software deve ser avaliado em cada caso, pois os requisitos alteram de sistema para sistema
Remoção de Falha
- (^) 1) Software testing
- (^) A técnica mais comum para remover erros
- (^) Dificuldade chave: custo para realizar testes exaustivos
- (^) Testar o software sob todas as circunstância e com todos as possíveis entradas
- (^) A chave é ter uma cobertura adequada de testes e derivar uma boa qualidade nos testes (para cada sistema)
- (^) Testes multiníveis: componentes mais críticos devem receber uma maior gama de testes
Remoção de Falha
- (^) 2) Formal Inspection
- (^) É uma técnica prática bastante utilizado pela comunidade da indústria
- (^) Possui um rigoroso processo acompanhado de uma documentação que foca em: - (^) Examinar o código fonte - (^) Encontrar falhas - (^) Corrigi-las - (^) Certificar que eles foram retiradas
- (^) Esta técnica é realizada por um grupo de pessoas antes da fase de testes