Tópicos em Engenharia de Software II

Tópicos em Engenharia de Software II
Fernando Castor Profa.: Eliane Martins

Roteiro Introdução e Objetivos Técnica 1: Cálculo de Refinamentos
Técnica 2: Árvore de Falhas Conclusões

Introdução Nos dias atuais, sistemas de software são empregados em praticamente todos os ramos de nossa sociedade Complexidade desses sistemas aumenta a cada dia Cada vez mais, requisitos de dependability são exigidos

Introdução (cont.) Dependability envolve diversos fatores:
Confiabilidade (reliability) Segurança contra acidentes (safety) Disponibilidade (availability) Segurança contra intrusão (security)

Confiabilidade “The probability that a system will perform its intended function for a specified period of time under a set of specified environmental conditions” Nancy G. Leveson Um sistema é confiável se ele se comporta de acordo com sua especificação

Objetivos Apresentar uma técnica para assegurar confiabilidade e outra para analisar segurança contra acidentes Através de uma mesma aplicação exemplo: algoritmo BubbleSort A segunda técnica será usada para analisar a confiabilidade do exemplo, devido à sua simplicidade Ressaltar as vantagens e desvantagens de cada técnica, com relação ao estudo de caso

Refinamento Se um programa prog2 é melhor que um programa prog1, dizemos que prog2 refina prog1, ou prog1 prog2 Exemplos: Algoritmos de ordenação: inteiros e números de ponto flutuante ou apenas inteiros? Altímetro de um avião: faixa de valores ou valor preciso?

Cálculo de Refinamentos
Conjunto de leis que visam produzir programas confiáveis a partir de uma especificação formal Código produzido através do uso dessas leis garantidamente implementa a especificação Baseado no cálculo de predicados Especificações são programas que não podem ser executados por um computador: x :[pre, pos] Programas executáveis = código

Refinamento de Programas
Exemplo: x:[ x > 0 ^ x|2, x > 100] x:[ x > 0, x = 101] ou x:[x > 100 ^ x < 120] Exemplo do altímetro do avião para ilustrar o fortalecimento da pós e enfraquecimento da pré. No caso de pré = true, falar de um sensor de propósito geral que mede tanto altitude quanto profundidade. Pré-condições são enfraquecidas Pós-condições são fortalecidas

Algoritmo BubbleSort m := #as; do !(m = 0) { n := 0; do !(n = m – 1) {
if(as[n] > as[n+1]) { swap(as[n], as[n+1]) } else { skip n := n + 1 }; m := m - 1

Especificação do BubbleSort
var as:seqNZ; con A; and A = bag as as:[ ]

Refinamento (1)

Refinamento (2)

Refinamento (3)

Código resultante:

Características da Técnica
Vantagens: O código gerado garantidamente atende à especificação Desvantagens: Trabalho muito grande é necessário para realizar o refinamento Não garante a corretude da especificação

Algoritmo BubbleSort (versão implementada)
int m = as.length-1; int n = 0; while(0<m) { while(n<m) { if(as[n] > as[n+1]) { int t = as[n+1]; as[n+1] = as[n]; as[n] = t; } n++; n=0; m--; return as;

Árvore de Falhas para o BubbleSort
Array desordenado OR While externo não executado While externo executado m vezes m 0 na primeira iteração 0 as.length 1 Se as.length = 0, não há elementos para ordenar Se as.length = 1, o array está ordenado Contradição (...)

Árvore de Falhas para o BubbleSort (2)
(...) AND 0<m antes o while externo Um sub-conjunto das iterações não ordena o array corretamente (...)

(...) OR While interno não executado While interno executado m-1 vezes para cada valor de m m n, na primeira iteração n = 0, na primeira iteração 0 < m Por 2 e 3, n < m, na primeira iteração Por 1 e 4, Contradição (se o laço mais externo é executado pelo menos uma vez, o mais interno também é) (...)

(...) AND n<m antes o while interno Um sub-conjunto das iterações não coloca o maior elemento de as[0..m] na posição m (...)

(...) OR (...) Primeira iteração: n = 0 ^ v[0] > v[1] => swap(v[0], v[1]) (n-1)-ésima iteração: n > 0 ^ v[n] > v[m] => swap(v[n], v[m]) Indutivamente, percebe-se que a situação não ocorre Um sub-conjunto das iterações não (...) Primeira iteração: n > 0 ^ v[n] < v[m] => skip

Características da Técnica
Vantagens: Pode ser usada tanto para analisar confiabilidade quanto segurança contra acidentes Mais fácil de aplicar e entender do que uma técnica inteiramente formal Representação gráfica Desvantagens: Não garante a corretude da especificação Pouco empregada, no contexto de software Não provamos que o programa atende à especificação

Conclusões Técnicas que analisar e garantir confiabilidade e segurança contra acidentes são importantes, mas caras Suporte de ferramentas pode amenizar esse custo Técnicas formais são extremamente trabalhosas Árvores de falhas são mais práticas, mas fornecem menos garantias

Referências T. Anderson e P. A. Lee. Fault Tolerance: Principles and Practice. Prentice-Hall, 2a edição, 1990. S. Coutinho, T. Reis e A. L. Cavalcanti. Uma ferramenta educacional de refinamentos. Anais do XIII Simpósio Brasileiro de Engenharia de Software - Sessão de Ferramentas, páginas 61-64, 1999. N. Leveson. Software Safety: Why, What and How. ACM Computing Surveys, 18(2): , junho 1986. C. Morgan. Programming from Specifications. Prentice-Hall, 2a edição, 1998. J. D. Reese e N. Leveson. Software Deviation Analysis: A “Safeware” Technique. 1996 Safeware Engineering Corporation. Verification of Safety. Disponível para download em

Tópicos em Engenharia de Software II

Apresentações semelhantes

Apresentação em tema: "Tópicos em Engenharia de Software II"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Tópicos em Engenharia de Software II

Apresentações semelhantes

Apresentação em tema: "Tópicos em Engenharia de Software II"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback