Correção de Software com Verificação de Modelos

Transcrição

1 Correção de Software com Verificação de Modelos Aline Maria Santos Andrade Departamento de Ciência da Computação (DCC) Laboratório de Sistemas Distribuídos (LaSiD) Universidade Federal da Bahia (UFBA)

2 Sumário Motivação Correção de Software Conceito de Métodos Formais Técnicas de Verificação Formal Verificação de Modelos Conceitos A ferramenta SPIN

3 Engenharia? de Software Não existe um modelo universalmente aceito para desenvolver software As técnicas utilizadas normalmente são derivadas de uma abordagem informal adotada no processo, não incluem teorias e formalismos essenciais a um desenvolvimento científico Ambientes (ferramentas) existentes em geral não possuem uma fundamentação teórica. Difícil garantir a confiabilidade dos software Certificação e garantia? Aline Maria Santos Andrade (aline@ufba.br)

4 Engenharia de Software Incorporou novos paradigmas e metodologias sistematização do processo de desenvolvimento melhoria da confiabilidade do software produzido. Embora os processos sistemáticos de desenvolvimento de software aumentem o grau de confiabilidade, a validação de software é feita de maneira informal ou semi formal e não garantem com precisão que o software atende aos requisitos desejados. Em sistemas que envolvem riscos, como sistema de monitoração de pacientes, controle de tráfego aéreo, etc é necessário um processo de validação mais seguro de maneira que possamos garantir a correção do software gerado. Aline Maria Santos Andrade (aline@ufba.br)

5 O que são métodos formais Utilização de modelos matemáticos para representar o sistema Métodos matemáticos de prova para verificação Adicionar precisão, auxiliar no entendimento e raciocinar sobre propriedades de um projeto Certificação/Garantia! Engenharia Pode ser comparado à forma com que cálculo estrutural é usado no projeto de construções, mecânica computacional de fluídos é usada no projeto de aeronaves, etc

6 Validação de Software Simulação Teste Verificação

7 Correção de Software Aplicação Formal => Verificação Formal => Correção Requisitos Não Formal => Testes => Confiável Confiabilidade i = 0 Especificação i i= i+1 Refinamento Confiável / Correta Testes / Simulação / Verificação Máquina Virtual Testes Aline Maria Santos Andrade (aline@ufba.br)

8 Verificação Um passo de verificação pode cobrir todo possível comportamento do sistema Verificação antes da implementação diminui o custo $$!! É especialmente importante quando o comportamento é complexo. Aline Maria Santos Andrade (aline@ufba.br)

9 Especificação formal Linguagem formal Verificação Refinamento Geração automática de código Propriedades desejadas consistência correção completude Aline Maria Santos Andrade

10 Desenvolvimento formal de software Especificação formal do problema B, Z, VDM, CSP, LOTOS, Pi-Calculus, SPIN, SMV, UPPAAL... Validação Simulação Verificação Refinamento Geração automática de código Aline Maria Santos Andrade

11 Tipos de Sistemas Sequencial Concorrente Distribuído Móvel Transformacional Reativo Aline Maria Santos Andrade

12 Requisitos Sistemas seqüenciais funcionalidade Sistemas concorrentes concorrência funcionalidade Sistemas Reativos necessitam interagir com o ambiente frequentemente e frequentemente não terminam. Portanto, não podem ser modelados pelo seu comportamento de entrada/saída. Aline Maria Santos Andrade (aline@ufba.br)

13 Técnicas de verificação formal Provadores de teoremas Provam propriedades em uma teoria sobre o sistema Verificadores de modelos (Model checking) Verificam se certas propriedades valem em um modelo da aplicação Sistemas de estados finitos As abordagens se complementam Aline Maria Santos Andrade (aline@ufba.br)

14 Provador de Teoremas Especificar: O sistema (em algum nível adequado de abstração) Propriedades requeridas do sistema Suposições (restrições de ambiente, usuário, etc) Teorias sobre os tipos de dados envolvidos Provar: Teorias + Suposições + Sistema -- Requisitos Variação: Provar que a implementação é um refinamento da especificação Funciona melhor em sistemas com intenso tratamento de dados Aline Maria Santos Andrade (aline@ufba.br)

15 Verificador de Modelos Especificar Modelo do sistema Estrutura de Kripke Propriedades em uma linguagem lógica Lógica temporal Provar que as propriedades são válidas no modelo do sistema modelo do sistema = propriedades Algoritmo faz varredura no modelo do sistema (sistema de transição) Aline Maria Santos Andrade (aline@ufba.br)

16 Estrutura de Kripke Estado - é uma descrição instantânea do sistema que captura os valores das variáveis em um particular instante de tempo. Transições entre estados representam as ações do sistema. Estrutura de Kripke - conjunto de estados, conjunto de transições entre estados e uma função que rotula cada estado com um conjunto de propriedades que são verdadeiras naquele estado. Aline Maria Santos Andrade (aline@ufba.br)

17 Verificação de Modelos Dado uma estrutura de Kripke M = (S,R,L) que representa um sistema concorrente e uma fórmula na lógica temporal f que expressa alguma especificação desejada, encontre todos os estados em S que satisfaz f: {s S M, s = f} Aline Maria Santos Andrade (aline@ufba.br)

18 Verificação de modelos Estados definidos pelas variáveis do sistema, que assumem valores dentro de um conjunto finito de valores Um componente do sistema unfolding modelo de Kripke ----> sistema de transição Vários componentes produto síncrono (ou assíncrono) do sistema de transição de cada componente

19 1 ev1 C=true/act1 3 ev2 act2 2 C Kripke estendida (guardas) (Máquina de estados finita) Fonte: Prof E. H. Haeusler - PUC-Rio ev2 act2 2c act2 2c 3 1 act2 2c ev2 act1 ev2 3 act ev1 act2 2c ev2 3 ev2 act2 2c 3 act ev1 ev1 act2 2c ev2 ev2 3 act2 2c act1 3 ev1 act2 2c ev2 Sistema de transição (unfolding da estrutura de Kripke 3

20 Produto síncrono / assíncrono Combinar os modelos dos componentes do sistema ---> autômato global Produto cartesiano dos autômatos representando os componentes (estado global é um vetor construído a partir dos diferentes estados dos componentes) Componentes se sincronizam ---> produto síncrono ---> subconjunto de transições do produto cartesiano definido através de um conjunto de sincronização Explosão de estados!

21 Produto assíncrono X = Explosão de estados!!!

22 Otimizações Explosão de estados ocorre quando se resolve representar em memória todos os estados do autômato Symbolic Model Checking representa estados e transições simbolicamente ao invés de explicitamente BDD - Diagrama de decisões binárias utilizados para representar simbolicamente conjunto de estados de um autômato On the Fly Model Checking

23 Um Programa de Exclusão Mútua P = m: cobegin P 0 P 1 coend m S 0 (V,PC) pc = m pc 0 = pc 1 = Nenhuma restrição é imposta ao valor de turn P 0 :: l 0 : While True do NC 0 : wait(turn = 0) CR 0 : turn := 1; end while; l 0 P 1 :: l 1 : While True do NC 1 : wait(turn = 1) CR 1 : turn := 0; end while; l 1 Aline Maria Santos Andrade (aline@ufba.br)

24 Turn =0, Turn =0 l 0,l 1 Turn =1, Turn =1 l 0,l 1 Garantido exclusão mútua. Não garante ausência de starvation. Turn =0 l 0,NC 1 Turn =0 NC 0,l 1 Turn =1 l 0,NC 1 Turn =1 NC 0,l 1 Turn =0 NC 0,NC 1 Turn =0 CR 0,l 1 Turn =1 l 0,CR 1 Turn =1 NC 0,NC 1 Turn =0 CR 0,NC 1 Turn =1 NC 0,CR 1 Estados alcançáveis da estrutura de Kripke para o exemplo de exclusão mútua

25 Verificação de Modelos Usualmente não há necessidade de teorias auxiliares Normalmente, as únicas suposições dizem respeito às propriedades dinâmicas do sistema (safety, fairness, liveness) Funciona melhor com sistemas voltados ao controle e com um pequeno espaço de estados Aline Maria Santos Andrade (aline@ufba.br)

26 Lógica temporal Operadores modais de tempo (G) sempre (F) em algum tempo futuro Relativos a mundos possíveis (estrutura de kripke)

27 Mundos Possíveis (Kripke) - A verdade de uma proposição é verificada em relação a um mundo. - Os mundos estão relacionados ao tempo (lógica temporal) - Mundos podem ser vistos como estados locais/globais. - Estrutura ramificada, ou, linear de tempo. (obs: P P ) P P EP P,Q,Q P,Q,P P,Q,Q P,Q,P P,Q,P P,Q,P P,Q,P P,Q,P P,Q,P P,Q,EP P,Q,P P,Q P,Q P,Q P,Q P,Q P,Q P,Q P,Q P,Q P,Q P,Q P,Q Fonte: Prof E. H. Haeusler - PUC-Rio EP Eventualmente P P

28 Lógicas temporais Lógica temporal ramificada (CTL - Computational Tree Logic) CTL apresenta quantificação sobre caminhos e sobre estados AG(p) : p é verdade em todo estado ao longo de cada caminho AF(p) : p é verdade em algum estado ao longo de cada caminho EG(p) : p é verdade em todo estado ao longo de algum caminho EF(p) : p é verdade em algum estado ao longo de algum caminho Lógica temporal linear (LTL) único caminho de computação

29 TL Gp Fp GFp FGp p p p p p p p p p p p p p p p p p p p p TL p p AGp AFp AGAFp Não existe Existem também fórmulas em CTL que não são expressáveis em LTL

30 Sistemas concorrentes Safety - algo ruim nunca acontece ausência de deadlock exclusão mútua sempre a resposta dada é correta Liveness - algo bom acontece se um processo solicita um recurso eventualmente ele será atendido se uma resposta é solicitada então ela será fornecida Aline Maria Santos Andrade (aline@ufba.br)

31 Alarme de Cofre sound alarm count = = 3 /count = 0 count attempts enter code code entered check code invalid code/ count ++ delay timeout unlock door valid code/count = 0 Fonte: Prof E. H. Haeusler - PUC-Rio

32 - Verificando AG(enter_code & valid_code ===> AF(unlock_door)) resulta em verdade - Verificando AG(enter_code ===> AF(unlock_door)) resulta no seguinte caminho de computação como contra-exemplo enter code check code count attempts sound alarm 3 times enter code check code count attempts 3 times Fonte: Prof E. H. Haeusler - PUC-Rio

33 SPIN Ferramenta para analisar a consistência lógica de sistemas concorrentes, especialmente protocolos de comunicação de dados. (free) Linguagem Promela Permite criação dinâmica de processos concorrentes Comunicação via canal pode ser síncrona ou assíncrona Aline Maria Santos Andrade (aline@ufba.br)

34 SPIN Dado um modelo do sistema especificado em Promela, SPIN pode fazer: simulações verificação online de propriedades de correção do sistema verificação de ausência de deadlocks, código não executável, etc verificação de propriedades de correção (safety e liveness) expressas em lógica temporal linear (LTL) On the Fly Model Checking Aline Maria Santos Andrade (aline@ufba.br)

35 Verificação On the fly A propriedade verificada é traduzida em um autômato Este autômato é utilizado para guiar a criação do grafo de transição de estados (modelo do sistema) Isto evita a necessidade de se construir grandes pedaços ou todo o grafo de estados do modelo do sistema

36 Autômatos Finitos Sobre Palavras Infinitas Em muitos sistemas concorrentes a computação não pára durante uma execução normal Nestes casos, a computação é modelada como uma sequência infinita de estados Estas computações podem ser representadas através de autômatos finitos sobre palavras infinitas

37 Autômatos Büchi Um autômato Büchi tem a mesma estrutura que um autômato sobre palavras finitas Estados finais são chamados de estados de aceitação Considere inf(ρ) como o conjunto de estados que aparecem infinitamente freqüentemente em uma execução ρ Uma execução ρ de um autômato Büchi sobre uma palavra infinita é aceita se e somente se inf(ρ) F

38 Exemplo q1 b q2 b a a Se interpretamos o grafo acima como um autômato Büchi, a linguagem aceita será: (b*a) ω a palavra (ab)* (sequência infinita de a s e b s alternando, começando por a) é aceita

39 Verificação de Modelos usando Autômatos Autômatos finitos podem ser usados para modelar sistemas concorrentes de execução infinita Uma vantagem de se utilizar autômatos para verificação de modelos é a possibilidade de usar a mesma forma de representação para o sistema modelado e para as propriedades

40 Convertendo estruturas Kripkes em autômatos s 0 s 1 {p,q} i {p} {p},q} {p} s 0 s 1 s 2 {q} {p,q} {q} {p,q} s 2

41 Turn =0, 1 Turn =1, 2 Turn =0 l 0,l 1 Turn =1 l 0,l 1 4 Turn =0 l 0,NC 1 Turn =0 NC 0,l Turn =1 Turn =1 l 0,NC 1 NC 0,l 1 7 Turn =0 NC 0,NC 1 Turn =0 CR 0,l 1 5 Turn =1 l 0,CR 1 Turn =1 NC 0,NC 1 Turn =0 CR 0,NC 1 Turn =1 NC 0,CR 1 Estados alcançáveis da estrutura de Kripke para o exemplo de exclusão mútua

42 Turn=0,, i Turn=1,, 1 2 Turn=1, l 0,l 1 Turn=1, l 0, l Turn=0, CR 0, l Turn=1, l Turn=1, NC 0, l 1 1 0, NC Turn=1, NC 0, l 1

43 Especificações como autômatos Considere L(A) a linguagem do autômato A que representa a estrutura kripke A especificação pode ser dada como um autômato S sobre o mesmo alfabeto de A

44 Exemplo de Especificação como Autômato (CR 0 CR 1 ) (CR 0 CR 1 ) true Exclusão mútua CR 0 true CR 0 Liveness: o processo P 0 entrará na região crítica

45 Verificação de Modelos usando Autômatos Considere L(A) a linguagem do autômato A que representa a estrutura kripke Considere L(S) a linguagem do autômato que representa a especificação S O sistema A satisfaz S quando: L(A) L(S) L(A) L(S) =

46 Algoritmo de Verificação de Modelos O sistema modelado é convertido em um autômato Büchi A O autômato Büchi S é gerado a partir da negação da especificação ϕ Se a interseção A S é vazia a especificação é satisfeita Senão um contra-exemplo é exibido

47 Algoritmo de Verificação de Modelos On the Fly Constrói-se inicialmente o autômato de S Este autômato é usado para dinamicamente guiar a construção do autômato do sistema A, ao mesmo tempo em que a interseção é computada Desta forma é possível encontrar um contra-exemplo ou garantir a satisfatibilidade sem precisar construir todo autômato A

48 Promela PROMELA (PROcedural MEta LAnguage) é uma linguagem de especificação cuja sintaxe é baseada em: C CSP (canais para troca de mensagens) Comandos Guardados (controle de fluxo) Não determinismo Utilizada pelo SPIN para especificação do sistema Permite abstrações de protocolos (ou sistemas distribuídos em geral) suprimindo detalhes que não são relacionados para a interação entre processos

49 Promela Programas em Promela consistem de: Processos - são objetos globais que especificam comportamento Canais e variáveis - podem ser declaradas globalmente ou localmente dentro de um processo; canais podem ser síncronos ou assíncronos. Definem o ambiente em que o processo executa. Aline Maria Santos Andrade (aline@ufba.br)

50 Problema dos filósofos 5 filósofos Uma mesa circular com 5 cadeiras rotuladas cada uma com o nome do filósofo À esquerda de cada filósofo tem um garfo e no meio da mesa uma tigela de macarrão, que é constantemente preenchida Para comer o macarrão, o filósofo pega o garfo da esquerda e depois o da direita Após o filósofo comer o macarrão, ele deve deitar os dois garfos na mesa Aline Maria Santos Andrade (aline@ufba.br)

51 Aline Maria Santos Andrade

52 chan garfo[5] = [0] of {mtype}; mtype = {wait, signal}; proctype Garfo(int id){ do :: garfo[id]!wait -> proctype filosofo(int id){ pensando: do ::skip -> faminto: garfo[id]?wait; /*tenta adquirir garfo da esquerda fica bloqueado caso o garfo tenha sido adquirido*/ deadlock: garfo[(id+1)%5]?wait; /*tenta adquirir garfo da direita*/ comendo: skip; garfo[id]!signal; /*cede garfo da esquerda*/ garfo[(id+1)%5]!signal; /*cede garfo da direita*/ } garfo[id]?signal od } od Aline Maria Santos Andrade (aline@ufba.br)

53 init{ } atomic{ } run filosofo(0); run filosofo(1); run filosofo(2); run filosofo(3); run filosofo(4); run Garfo(0); run Garfo(1); run Garfo(2); run Garfo(3); run Garfo(4); Aline Maria Santos Andrade (aline@ufba.br)

54 #define f1 #define f2 #define f3 #define f4 #define f5 /* * Formula As Typed: <> (f1 && f2 && f3 && f4 && f5) */ never { /* (<> (f1 && f2 && f3 && f4 && f5)) */... pan: claim violated! (at depth 550)... A verificação aponta um erro indicando que a propriedade não é mantida, ou seja, existe a possibilidade do sistema entrar em deadlock. O Spin salva a seqüência na qual o erro foi detectado em arquivo.trail. É possível, então, realizar uma simulação desta seqüência na tentativa de identificar as possíveis causas para a violação da propriedade. Aline Maria Santos Andrade (aline@ufba.br)

55 Extensão de Promela Extensão de Promela para especificar sistemas de agentes móveis trabalho realizado no LaSiD/UFBA Permite a utilização do ambiente SPIN para a simulação e verificação de sistemas de agentes móveis

56 Ferramentas UPPAAL Verificador de modelos para sistemas de tempo real Especificação: autômato com tempo Lógica temporal: dialeto de CTL Outras ferramentas SMV KRONOS HYTECH

57 Casos famosos de software complexos que não funcionaram a contento Explosão do foguete Ariadne (projeto europeu) poucos segundos após seu lançamento devido a falha de programação. Sistema de triagem/controle de bagagem do aeroporto internacional de Denver (EUA) atrasou a inauguração do aeroporto. Custo do sistema (193 milhões $$ ) Inauguração estava prevista para Out/1993 Em Junho/1994 o sistema ainda não estava funcionando, mas custava $$!! No começo de 1995 um controle MANUAL de bagagem foi instalado para que o aeroporto pudesse ser inaugurado (com atraso de mais de um ano). O Therac-25, um equipamento de radioterapia controlado por computador, aplicou doses fatais de radiação em alguns pacientes de câncer. Quando decidiram testar o subsistema de desligamento de emergência da Sizewell-B, uma usina nuclear na Inglaterra, este falhou em mais de 50% das vezes. Não conseguiram encontrar a razão da falha nas linhas de código.