19
Universidade Estadual do Piauí – UESPI Licenciatura Plena em Computação P r o f . E r i v e l t o n d a S i l v a R o c h a 1

Aula 21 de engenharia de software -tópicos avançados

Embed Size (px)

Citation preview

Page 1: Aula   21 de engenharia de software -tópicos avançados

Universidade Estadual do Piauí – UESPI Licenciatura Plena em Computação

Pro

f. Erive

lton

da

Silva

Ro

cha

1

Page 2: Aula   21 de engenharia de software -tópicos avançados

Em muitos sistemas, é possível implementar a tolerância

a defeitos de software por meio da inclusão explícita de

ações de verificação e recuperação no software.

Isso é denominado programação defensiva. Contudo,

essa abordagem não trabalha eficientemente com

defeitos do sistema que surgem com base em interações

entre o hardware e o software.

Além disso, a má compreensão dos requisitos pode

significar que tanto o código do sistema quanto a defesa

associada estão incorretos. 2

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 3: Aula   21 de engenharia de software -tópicos avançados

Para a maioria dos sistemas críticos,

particularmente aqueles com requisitos

rigorosos de disponibilidade, pode ser

necessária uma arquitetura específica

projetada para apoiar a tolerância a defeitos.

3

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 4: Aula   21 de engenharia de software -tópicos avançados

Exemplos de sistemas que usam essa

abordagem de tolerância a defeitos são os

sistemas de aviação, que devem estar em

operação durante o vôo, os sistemas de

telecomunicações, e os sistemas críticos de

comando e controle.

4

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 5: Aula   21 de engenharia de software -tópicos avançados

Há muitos anos existe a necessidade de se

construir hardware tolerante a defeitos.

A técnica de hardware tolerante a defeitos

mais comum é baseada na noção de

redundância modular tripla – TMR (Triple-

Modular Redundancy).

5

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 6: Aula   21 de engenharia de software -tópicos avançados

A unidade de hardware é replicada três (ou

algumas mais) vezes.

A saída de cada unidade passa para um

comparador de saída normalmente

implementado como um sistema de votação.

Se uma das unidades falha e não produz a

mesma saída que as outras unidades, sua

saída é ignorada

6

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 7: Aula   21 de engenharia de software -tópicos avançados

7

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 8: Aula   21 de engenharia de software -tópicos avançados

Um gerenciador de defeitos pode tentar

reparar a unidade defeituosa

automaticamente, mas se isso for impossível,

o sistema será automaticamente

reconfigurado para tirar a unidade de

serviço. Em seguida, o sistema continuará a

funcionar com duas unidades operando.

8

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 9: Aula   21 de engenharia de software -tópicos avançados

Através dessa técnica é que foi possível a

NASA colocar o homem na lua. Embora com

computadores precários e extremamente

simples, foi somente com esse tipo de

arquitetura tolerante a falhas que foi possível

garantir o pleno sucesso dessa missão.

9

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 10: Aula   21 de engenharia de software -tópicos avançados

Essa abordagem de tolerância a defeitos

baseia-se no fato de que a maioria das falhas

de hardware é resultante das falhas de

componente em vez de ser ocasionada por

defeitos de projeto. Os componentes são,

portanto, propensos a falhar

independentemente.

10

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 11: Aula   21 de engenharia de software -tópicos avançados

Supõe-se que, quando completamente

operacionais, toas as unidades de hardware

operem de acordo com a especificação. Há,

portanto, baixa probabilidade de falha

simultânea de componentes em todas as

unidades de hardware.

11

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 12: Aula   21 de engenharia de software -tópicos avançados

Naturalmente, todos os componentes

poderiam ter um defeito de projeto em

comum e, assim, todos produziriam a mesma

resposta errada. Usando unidades de

hardware com uma especificação em

comum, mas projetadas e construídas por

fabricantes diferentes, reduzem-se as

chances de uma falha de modo comum.

12

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 13: Aula   21 de engenharia de software -tópicos avançados

Presume-se que a probabilidade de equipes

diferentes cometerem o mesmo erro de

projeto ou de fabricação seja bem pequena.

13

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 14: Aula   21 de engenharia de software -tópicos avançados

Se os requisitos de disponibilidade e

confiabilidade de um sistema forem tais que

você necessite usar um hardware tolerante a

falhas, você pode também precisar de um

software tolerante a defeitos. Existem duas

abordagens para fornecer software tolerante

a defeitos.

14

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 15: Aula   21 de engenharia de software -tópicos avançados

Ambas as técnicas foram derivadas do

modelo de hardware em que componentes,

ou sistemas, redundantes são incluídos e

componentes defeituosos podem ser

desativados.

15

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 16: Aula   21 de engenharia de software -tópicos avançados

AS DUAS ABORDAGENS PARA TOLERÂNCIA A DEFEITOS DE SOFTWARE

SÃO:

Programação Em N-Versões:

Usando uma especificação comum, o sistema de

software é implementado em uma série de

versões por diferentes equipes. Essas versões

são executadas paralelamente em

computadores separados. Suas saídas são

comparadas com a utilização de um sistema de

votação, e saídas inconsistentes ou saídas não

produzidas em tempo, são rejeitadas. 16

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 17: Aula   21 de engenharia de software -tópicos avançados

No mínimo três versões de sistema devem

ser disponibilizadas de modo que duas

versões sejam consideradas consistentes no

evento de uma única falha. Essa é a

abordagem mais comum usada para

tolerância a defeitos de software. Ela foi

usada em sistemas de sinalização de

ferrovias, em sistemas de aviação e em

sistemas de proteção de reatores.

17

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 18: Aula   21 de engenharia de software -tópicos avançados

BLOCOS DE RECUPERAÇÃO:

Nessa abordagem, cada componente do programa inclui

um teste para verificar se componente foi executado

com sucesso. Também inclui um código alternativo que

permite ao sistema fazer uma cópia e repetir o

processamento se o teste detectar uma falha.

As implementações são, deliberadamente,

interpretações diferentes da mesma especificação. Elas

são mais executadas em seqüência do que em paralelo.

18

Pro

f. Erive

lton

da

Silva

Ro

cha

Page 19: Aula   21 de engenharia de software -tópicos avançados

Dessa maneira, o hardware replicado não é

necessário. Na programação em n-versões,

as implementações podem ser diferentes,

mas não é incomum que duas ou mais

equipes escolham o mesmo algoritmo para

implementar a especificação.

19

Pro

f. Erive

lton

da

Silva

Ro

cha