1 métodos formais no desenvolvimento de sist. prof. e.h.haeusler tecmf validação formal de...

TECMF

1

Métodos Formais no Desenvolvimento de Sist.

Prof. E.H.Haeusler

Validação Formal de Sistemas de Software

Prof. Edward Hermann Haeusler

Depto de Informática PUC-RIO

TECMF

2


Prof. E.H.Haeusler

- Aplicação da Ciência e Matemática através da qual as

propriedades da matéria e as fontes de energia são tornadas

úteis às pessoas (Dic. Merriam-Webster, 2001)

===> Projeto e Manufatura de Sistemas Complexos

- Desenvolvimento e Aplicação Sistemática de Modelos de Comprovada Eficácia gerando Soluções Tecnológicas para Problemas da Humanidade

- Engenharia é a prática da aplicação segura e econômica das leis científicas que

governam as forças e materiais da Natureza, através da organização, design e

construção, para o benefício da humanidade. S. E. Lindsay (1920)

- Engineering is the application of math and science to create something of

value from our natural resources. (IEEE- 2002)

Engenharia

TECMF

3


Prof. E.H.Haeusler

Construção de um artefato para uso pela Sociedade

Levantamentodas

CaracterísticasDesejadas

Artefato

Validação

==> Métodos e Processos de Fabricação de Artefatos

- É mais econômico validar um processo de fabricação de um artefato que um artefato individualmente.

==> Engenharia !!!

Matemática e Teorias Científicas

FABRICAÇÃO

TECMF

4


Prof. E.H.Haeusler

Construindo uma Ponte

Cálculos p/

Ponte

Espec.

-Projeto(template)

-Material

-Profund.

-Ventos

-Correnteza.

Implementação

-Fluxoda Obra

- $$$

- Carga

-Recursoshumanos

-ProjetoFísico

Física

MatemáticaQuímica

Engenharia

TECMF

5


Prof. E.H.Haeusler

Engenharia de Software X Engenharias tradicionais

Aspecto Eng. Software Eng. Tradic.

Evolução doartefato

Extremamentedinâmica

Lenta eGradual

Forma deprodução

Cópia doexecutável

Fabricaçãodas unid.

Garantia doFabricante

??????? Alguma

Elic. de requis. Complexa Simples

Adaptabilidade Flexível Rígido

==> As engenharias tradicionais baseiam-se fortemente em “Frameworks” para construção de tipos bem específicos e determinados de artefatos (aviões, carros, pontes, edifícios, navios, etc).

TECMF

6


Prof. E.H.Haeusler

Casos famosos de softwares 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 en- contrar a razão da falha nas 100.000 linhas de código.

TECMF

7


Prof. E.H.Haeusler

O Conhecimento básico em Engenharia de Software compreende :

==> Lógica Matemática:

Trata das leis da argumentação (provas) formal.

==> Álgebra

Descreve leis de construção de “objetos” e determina a identidade entres estes.

==> Complexidade de Algoritmos e Computabilidade

Escopo e Limitações da noção de “computável”.

==> Experiência prévia com modelos de desenvolvimento de Software.

Apresenta métodos e técnicas de desenvolvimento em base empírica.

TECMF

8


Prof. E.H.Haeusler

Métodos Formais e Arquitetura de Software

Porque Arquitetura de Software é essencial para a validação de sistemas ??

TECMF

9


Prof. E.H.Haeusler

Validação Formal e Arquitetura de Software

- Validação Formal de Software x Testes

- Sistemas Reativos e Transformacionais

- Como o projeto se reflete na etapa de validação

- Arquitetura de Software

- Adicionalmente o tempo aos requisitos funcionais

TECMF

10


Prof. E.H.Haeusler

Requisitos

Especificação

Implementação

Testes

Testes

Verificação

Verificação Formal

- 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.

TECMF

11


Prof. E.H.Haeusler

Validação x Prova de Correção

Mundo Real

Espec. Formal

cenários resultado

Espec. Formal A

Espec. Formal B

Prova que B tem as propriedadesque A também tem.

Verifica a adequação daEspecificação Formala Situações Reais

TECMF

12


Prof. E.H.Haeusler

Métodos Formais- Métodos Formais apresentam “frameworks” mentais, notações, e, métodos sistemáticos para o projeto, documentação, e análise de sistemas computação.

- Os principais benefícios da aplicação de métodos formais é permitir que algumas questões sobre o projeto possam ser respondidas por avaliação simbólica(e.g. prova de teorema ou verificação de modelo)

- A avaliação simbólica pode ser usada para “debugging” e inspeção do projeto, bem como para verificação a posteriori.

- 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

- Bons para certificação e garantia de qualidade.

TECMF

13


Prof. E.H.Haeusler

Técnicas Formais para a Validação de Sistemas

- Model Cheking (verificação de modelos)

- Theorem Proving (prova de teoremas)

Verificar se certas propriedades valem em um certo modelo

Provar propriedades em uma teoria sobre o sistema

Podem ser usados como métodos complementares

TECMF

14


Prof. E.H.Haeusler

Model Checking: O que é ?

- Especificar - O sistema como um sistema de transição (finito em geral). - Uma propriedade como uma sentença em uma linguagem de consulta. - Estabelecer que o sistema é um modelo da sentença

sistema |= sentença

Obs: Tarefa realizada por varredura no espaço de busca

- Usualmente não há necessidade de teorias auxiliares

- Normalmente, as únicas suposições dizem respeito às propriedades dinâmicas do sistema (branching vs. linear time, fairness, liveness)

- Funciona melhor com sistemas voltados ao controle e com um pequeno espaço de estados

TECMF

15


Prof. E.H.Haeusler

Sistema Transformacional

Sistema Reativo

tempo

entradas saídas

tempo

entradase saídas

TECMF

16


Prof. E.H.Haeusler

- Sistemas Reativos podem ser entendidos como um conjunto de threads concorrentes recebendo sinais de sensores no ambiente, e, atuando sobre mecanismos que produzem a mudança desejada no ambiente.

- Sistemas embutidos (dvd, injetor de combustível, celular) são normalmente reativos

sensores

atuadores

condic. daentrada

condic. saída

interface entrada

interfacesaída

Processador

TECMF

17


Prof. E.H.Haeusler

Propriedades que são verificadas em S. Reativos (CMP1995)

Segurança (Safety) : “algo ruim nunca acontece”

se uma resposta é dada então a mesma está correta

Toda vez que a porta do avião abre, há uma escada.

Não há ``deadlocks''

Progresso (Liveness) : “algo bom acontece”

Garantia : “algo pode acontecer”. Ex: O vídeo pode ser repetido

Obrigação : “algo sempre acontece”. Ex: O motor sempre funciona.

Atividade : “sempre a postos”. Ex: Toda requisição é atendida.

Persistência : Uma vez a porta fechada, sempre é possível abrí-la

Reatividade = Atividade & PersistênciaOportunidade (Fairness) :

“se algo pode acontecer então ocorre infinitas vezes”

“se algo pode acontecer infinitas vezes então acontece infinitas vezes

TECMF

18


Prof. E.H.Haeusler

Especificação (modelo) de sistemas reativo

Threads/Processos + Composição

- Abordagens : - Algébra + Lógica (CCS/Pi-calculus + -calculus) - Modelo + Lógica (Mundos Possíveis + Lógica Temporal)

TECMF

19


Prof. E.H.Haeusler

Mundos Possíveis (Kripke)

- A verdade de uma proposição é verificada em relação à 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�P�

P,Q Q ,P�P�

P,Q

P,Q

P,Q Q ,P�

P�

P,Q Q ,P�P�

P,Q

P,Q

P,Q Q ,P�

P,Q� ,P�P�

P,Q

P,Q

PP,Q ,P�

P,Q

P,Q

P,Q ,P�

P � Sempre P AP

TECMF

20


Prof. E.H.Haeusler

PUQ

P,Q Q ,P�P�

P,Q

P,Q

P,Q Q ,P�

Outras modalidades temporais

PUQ P until Q

P,Q Q ,P�P�

P,QQ

P,Q

P,Q Q ,P�

PP,Q ,P�P�

P,Q

P,Q

P,Q Q ,P�

NP

P,Q Q ,P�P�

P,Q

P,Q

PP,Q Q ,P�

NP Next P

EP

PP,Q Q ,P�P�

P,Q

PP,Q

PP,Q Q ,EP

PP,Q Q ,P�P�

PP,Q

PP,Q

PP,Q Q ,P�P�

EP Eventualmente P P

TECMF

21


Prof. E.H.Haeusler

O Until e o Next são suficientes

- true U P EP

- AP ¬ E ¬ P

TECMF

22


Prof. E.H.Haeusler

Threads e Máquinas de Estado Finitas - Cada Thread pode ser modelada por uma MEF

MEF

3

Est.2

Est.1

cond/act1

act2ev1

ev2

3

2c 2ccact2 act2

1

ev2 act1 ev2

ev1

3

2c 2ccact2 act2

3 1

ev2 act1

3

ev2

3

ev13

2c 2ccact2 act2

3 1

ev2 act1

3

ev2

3

ev1

3

2c 2ccact2 act2

3 1

ev2 act1

3

ev2

3

ev1

Comportamento da MEF

TECMF

23


Prof. E.H.Haeusler

entercode

checkcode

unlockdoordelay

countattempts

sound alarm

valid code/count = 0

invalid code/

code entered

timeout

count = = 3/count = 0

Alarme de Cofre

count ++

TECMF

24


Prof. E.H.Haeusler

Model Checking

- Usualmente se usa estrutura de tempo ramificado (branching time) e CTL como linguagem lógica de consulta (CTL = Computational Tree Logic)

- CTL : 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.

Inclui “next” e “until” e invariantes “fair”(O modelo só é verificado para os caminhos onde a condição de Fairness vale em uma quantidade infinita de estados)

TECMF

25


Prof. E.H.Haeusler

Threads and Finite State Machines

- Each thread can be modeled by a finite state machine

entercode

checkcode

unlockdoordelay

countattempts

sound alarm

valid code/count = 0

code entered

timeout

count = = 3/count = 0

invalid code/count ++

TECMF

26


Prof. E.H.Haeusler

- Checking

AG(enter_code & valid_code ===> AF(unlock_door))

results in “true” - Checking

AG(enter_code ===> AF(unlock_door))

results in the following computation path as a counter-example

entercode

checkcode

countattempts

3 times

sound alarm

entercode

checkcode

countattempts

3 times

TECMF

27


Prof. E.H.Haeusler

The whole system as an async. product of state machines

3

1

2

1

2

X =

11

22

13

23

21

12

State Explosion !!!!!!

TECMF

28


Prof. E.H.Haeusler

Semáforo

1

0

fora da região crítica

entrando

na região crítica

saindo

fora da região crítica

entrando

na região crítica

saindo

!semaforo

entrandosaindo

processo1 processo2

!semaforo

TECMF

29


Prof. E.H.Haeusler

- Considere uma pizzaria com 3 fornos. Por razões de segurança,

somente dois fornos podem ser abertos por vez. Mesmo assim,

toda vez que dois fornos são abertos, para evitar sobrecarga, o

terceiro forno deve estar em pré-aquecimento.

- Uma pizza leva 30 min para estar pronta, após 5 minutos de

pré-aquecimento, e, se o tempo passar de 30 min a pizza ficará

queimada.

Problema

=> Projetar o sistema de controle de abertura de portas de forno e gerenciamento da fabricação de pizzas

TECMF

30


Prof. E.H.Haeusler

fechado aberto pre_aquec

vai_assar

assando

vai_abrirxaberto&yaberto

!xaberto& yaberto

passou30 &!sem_vai_abrir

!passou30

!passou5 v(passou5 &!sem_vai_assar)

passou5 &!sem_vai_assar

xaberto& yaberto

!(xaberto& yaberto)

!(aberto(1)&aberto(2)&aberto(3)) // só 2 fornos abertos por vez

!(assando&passou30) // não pode queimar pizza

!(aberto(1)&aberto(2)&assando(3)) // não pode

!(aberto(1)&assando(2)&aberto(3)) // ter

!(assando(1)&aberto(2)&aberto(3)) // sobrecarga

Região

Estado

Crítica

passou30 &sem_vai_abrir

!sem_vai_abrir

sem_vai_abrir

TECMF

31


Prof. E.H.Haeusler

MODULE mainVAR sem_vai_assar : boolean ; sem_vai_abrir : boolean ; forno1 : process forno(sem_vai_assar,sem_vai_abrir,forno2.state,forno3.state) ; forno2 : process forno(sem_vai_assar,sem_vai_abrir,forno1.state,forno3.state) ; forno3 : process forno(sem_vai_assar,sem_vai_abrir,forno1.state,forno2.state) ;

ASSIGN init(sem_vai_assar) := 0 ; init(sem_vai_abrir) := 0 ;

SPEC!EF(forno1.state = aberto & forno2.state = aberto & forno3.state = aberto) &!EF(forno1.state = aberto & forno2.state = aberto & forno3.state = assando) &!EF(forno1.state = aberto & forno2.state = assando & forno3.state = aberto) &!EF(forno1.state = assando & forno2.state = aberto & forno3.state = aberto) &!EF(forno1.state = assando & forno1.passou30 = 1 & forno1.running=1 & EX(forno1.state = assando)) & !EF(forno2.state = assando & forno2.passou30 = 1 & forno2.running=1 & EX(forno2.state = assando)) &!EF(forno3.state = assando & forno3.passou30 = 1 & forno3.running=1 & EX(forno3.state = assando))

Em SMV

TECMF

32


Prof. E.H.Haeusler

MODULE forno(sem_vai_assar,sem_vai_abrir,xstate,ystate)VAR state : { fechado, aberto, pre_aquec, assando, vai_abrir, vai_assar } ; passou5 : boolean; passou30 : boolean;

ASSIGN init(state) := fechado ; next(state) := case state = fechado & ! sem_vai_abrir : vai_abrir; state = aberto : { aberto, pre_aquec } ; state = pre_aquec & passou5 & ! sem_vai_assar : vai_assar ; state = assando & passou30 & ! sem_vai_abrir : vai_abrir ; state = assando & passou30 : fechado ; state = vai_assar & (xstate = aberto) & (ystate = aberto) : pre_aquec ; state = vai_assar : assando ; state = vai_abrir & ((xstate = aberto) & (ystate = aberto) | ((xstate = aberto & ystate = assando) | (ystate = aberto & xstate = assando))): fechado ; state = vai_abrir : aberto ;

1 : state ; esac ; next(sem_vai_assar) := case state = vai_assar : 1 ; state = pre_aquec | assando : 0 ; 1 : sem_vai_assar ; esac ;

next(sem_vai_abrir) := case state = vai_abrir : 1 ; state = fechado | aberto : 0 ; 1 : sem_vai_abrir ; esac ; next(passou30) := case 1: { 0, 1 } ; esac ;

next(passou5) := case 1: { 0, 1 } ; esac ;

FAIRNESS running

TECMF

33


Prof. E.H.Haeusler

Types of Real-Time embedded systems

Hard - where not meeting a deadline is a failure

Soft- where deadline can be missed and the system may still work if it is possible to recover

Slow - the system will have to respond within seconds

Fast - the system has to respond within a second (typically within mili- or microseconds

TECMF

34


Prof. E.H.Haeusler

Characteristics of RT-Reactive Systems

response time deadline - The system must respond to the environment within a specified time after the input has been recognized

validity of the data - The inputs may become obsolete with time. The interval for which input data is valid must be take into account for proc. requirements.

periodic execution - Reactive systems tend to collect data at predetermined time intervals.

TECMF

35


Prof. E.H.Haeusler

Timed Automata as a model for RT-Reactiveness

3

Est.2

Est.1

C >= 2,4

startreset

- Clock-variables and time/delay conditions for enabling transitions

- Can be enriched with other data-type variables (global vars)- Communication by means of channels (CSP-style)

req?

v[i]:= CC := 0i++

i := 0

req!

T <= r

TECMF

36


Prof. E.H.Haeusler

TECMF

37


Prof. E.H.Haeusler

Theorem Proving: O que é ?

- 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

- E provar que:

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

TECMF

38


Prof. E.H.Haeusler

Teoria sobre os Números Naturais

x(s(x) 0)

xy( s(x) = s(y) x = y)

y(y 0x( s(x) = y) )

(P(0) & x(P(x) P(s(x)))) xP(x)

Especificação Lógica de um Tipo de dado

Teoria |-- Prop

TECMF

39


Prof. E.H.Haeusler

Semântica Axiomática de uma LP

TECMF

40


Prof. E.H.Haeusler

Prova de correção de código

Teoria

TeoriaTeoria

TECMF

41


Prof. E.H.Haeusler

Architectural connectors

- Sequential Composition

- Parallel synchronous composition

- Parallel asynchronous composition *

- Behavior inheritance

- Factorization of common Behaviors

Software Architecture = components + structure

TECMF

42


Prof. E.H.Haeusler

An Example: Harel Statecharts

- Conditions and Actions

- Design Hierarchy

- On-entry, on-exit during actions

- Independent Threads of Control

- Visual synchronization/complex Transition (as in Petri-nets)

?condition!action

TECMF

43


Prof. E.H.Haeusler

Pattern used in ARTS (Haeusler & Fontoura 99) - Horizontal Composition

M

S

b_off

b_on

Brake

Car

Off

On

t_off

t_on

Lunlink

link

Motor

sync(b_off,link)

sync(b_on,unlink)

TECMF

44


Prof. E.H.Haeusler

In categorial terms the horizontal composition is a Colimit

CatL

Th(Brake) Th(Motor)

x={,} Th(x)

Th(Car)

b_onb_off

linkunlink

TECMF

45


Prof. E.H.Haeusler

OO ProjectsTTS

RETOOLTheories

Mathematicaly

TECMF

46


Prof. E.H.Haeusler

CORBA

OOProjects

Gen. of RETOOL Theories

Gen. of C++Code

ProjectsBase

RETOOLTheorem

Prover

Model-Chec.Spec.

Generation.

Model-Checker

FormalValidationLayer

TECMF

47


Prof. E.H.Haeusler

Mathematical and Engineering Foundations forInteroperability via Architecture

- Formally based Software Architectures

- Tools and Techniques for the Software Development Process

- Compositionality

Projeto MEFIA - CNPq/NSF

partners: PUC-Rio, UFRGS, Stanford Univ, SRI, Univ. of Illinois

TECMF

48


Prof. E.H.Haeusler

- Cada Model-Checker trata com técnicas e abordagens diferentes o problema de especificações com grande número de estados

SMV - BDD’s

SPIN - Supertrace

UppAll - Prog. Lógica

Hytech - Diferenças finitas + varredura simples

TECMF

49


Prof. E.H.Haeusler

Alguns “detalhes” importantes :

1- A menos que P=NP não existe um sistema de prova eficiente (polinomial) para a lógica proposicional.

2- A lógica de primeira ordem é indecidível.

3- Composicionalidade é uma propriedade que não coexiste muito bem com concorrência.

==> Lógicas modais (doxástica, deôntica, epistêmica e suas versões multi-agentes (multi-modais) também têm modelos de Kripke como semântica).

TECMF

50


Prof. E.H.Haeusler

Métodos e Modelos importantes :

CCS - Álgebra de processos com teoria de equivalência e lógica associada (-calculus).

Pi-Calculus - Álgebra de processos que inclui abstração sobre canal de comunicação e conseguente habilidade de especificar mobilidade.

Redes de Petri - Modelo não composicional de concorrência real (true concurrency)

Autômatos Híbridos - Levam a variação em conta (derivada em relação ao tempo)

Model-checkers - CWB, MWB e simulação em redes de petri

1 métodos formais no desenvolvimento de sist. prof. e.h.haeusler tecmf validação formal de...

Documents