A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Especificação Formal de Software

Apresentações semelhantes


Apresentação em tema: "Especificação Formal de Software"— Transcrição da apresentação:

1 Especificação Formal de Software
Alexandre Mota

2 Desenvolvendo o Sistema
Documento de Requisitos Problema Solução ...

3 Um Modelo Banco 1 1 0..* 0..* Conta 1..* 1..* Cliente Poupança

4 Mais Precisão... Para caracterizar melhor um sistema, sem entrar em detalhes de implementação, fazemos uso de: Pré-condições Pós-condições Invariantes Propriedades

5 Pré-condição Pré-condições são associadas a operações (métodos)
Sua utilidade é caracterizar uma condição (restrição) sobre a aplicabilidade da operação Se a condição for válida, a execução da operação é garantida não gerar exceções

6 Pós-condição Pós-condições são associadas a operações também
Sua utilidade é descrever em que condição o sistema irá estar após a realização com sucesso (terminação) da operação

7 Invariante Para modelos orientados a objetos, o invariante é associado a classes Daí, denominar-se de invariante da classe Sua utilidade é estabelecer os limites válidos sobre as instâncias (objetos) criadas por uma classe Assim, devido ao invariante, nem todos as instâncias são possíveis de serem criadas ou de efetuarem certas operações que mudem seus atributos

8 Propriedades Todo sistema é esperado satisfazer a propriedades desejáveis Ausência de deadlock, composições de operações bem-sucedidas, etc. Portanto, para toda classe podemos estabelecer quais propriedades ela deve satisfazer Tais propriedades podem ser usadas posteriormente na fase de testes

9 Anotando um Modelo Um diagrama de classes UML pode ser anotado com formalismos O padrão de UML é anotar seus diagramas com OCL (Object Contraint Language) OCL é uma linguagem que explora textualmente elementos de lógica de predicados e teoria dos conjuntos  é substituído por implies  é substituído por forall

10 Anotando um Modelo Banco Conta Cliente idade: int Poupança
1 1 0..* 0..* Conta 1..* 1..* Cliente idade: int {idade>17} Poupança

11 Anotando um Modelo Infelizmente, OCL não possui suporte de ferramentas para explorar as restrições estabelecidas A única ferramenta para OCL atualmente é um verificador de sintaxe e de tipos (parcial) Portanto, usaremos lógica de predicados e teoria dos conjuntos (Z) pois existem mais ferramentas

12 A Notação Tal qual OCL, nossa linguagem também é bastante textual
Assim,  é obtido através de \implies  é conseguido com \forall Essa linguagem é nada mais que uma codificação em LaTeX (versão LaTeX para os elementos gráficos de Z)

13 Tipos Pré-Definidos Em nossa notação, assumiremos três tipos básicos pré-definidos Naturais (\nat) 0, 1, 2, 3, ... Inteiros (\num) ..., -3, -2, -1, 0, 1, 2, 3, ... Booleanos (Bool) true, false

14 Construtores de Tipos Dispomos de vários tipos para caracterizarmos os problemas Given sets (conjuntos genéricos) Free-types (tipos enumerados) Conjunto potência (das partes) Produto cartesiano Relações Funções Seqüências Bags

15 Hierarquia de Tipos Given Sets Conjuntos ( P) I Tuplas (...)
Free-Types Relações () Funções () Seqüências (seq) Bags (bag)

16 Given Sets Usam-se given sets quando não se tem interesse sobre a estrutura dos elementos de tais conjuntos Elementos de given sets são meramente identificadores Somente operações sobre conjuntos independentes de tipos podem ser aplicadas a given sets (, , , etc.) Para criá-los em um diagrama, basta digitar seus nomes nos espaços referentes a tipos

17 Exemplo de Given Set Cliente id: ID Given set ID

18 Free-Types São os conhecidos tipos enumerados de linguagens de programação (apesar de mais versáteis) Sua versatilidade advém do fato de podermos definir tipos recursivos (construtores) Normalmente usados para caracterizar as mensagens que o sistema irá exibir

19 Free-Types ok Enumeração Simples falha zero succ \ldata Nat \rdata
<<enumeration>> Mensagens ok falha Enumeração Simples <<enumeration>> Nat zero succ \ldata Nat \rdata Enumeração Recursiva

20 Produto Cartesiano Quando se deseja formar tuplas de elementos de tipos base Usa-se T1 \cross T2 \cross ... \cross Tn Seus elementos são identificados como (A, 2, casa) ou (3, 4) As funções first e second aplicam-se a 2-uplas ou pares first (1, 2) = 1 e second (1, 2) = 2

21 Produtos Cartesianos first (x, y) second (x, y)

22 Conjunto Potência Para usar o conjunto potência, basta prefixar o tipo base com \power Exemplo: \power \{0, 1\} = \{ \{\}, \{0\}, \{1\}, \{0, 1\}\} O tipo potência deve ser usado quando instâncias são conjuntos em si

23  AA,  AA Conjuntos Potência # A A = B, A  B x  A, x  A
A  B, A  B, A \ B  AA,  AA

24 Relações O tipo relação é obtido através do operador \rel entre dois tipos Pessoa \rel Endereço Produz subconjuntos de produtos cartesianos Usado para capturar dependência entre dois tipos base

25 Relações dom R, ran R R ; S, S  R A R, R A A R, R A R~ R A     (
| ) |

26 Funções Funções são tipos especiais de relações
Assim, funções provém de relações com acréscimos de restrições Tipo mais comum de função é a parcial Pessoa \pfun Endereço Esse relacionamento indica que nem toda pessoa tem endereço

27 Funções F  G

28 Seqüências Seqüências são especializações de funções
São obtidas com o prefixo \seq sobre o tipo base \seq Pessoa Contrariamente a conjuntos, seqüências são empregadas quando se deseja capturar a ordem entre os elementos

29 Seqüências ( S S2 head S, tail S front S, last S rev S

30 Bags Bags são usados para capturar a repetição de elementos através de freqüência (ocorrência) Usa-se o operador \bag prefixado sobre o tipo base Normalmente, bags são usados como armazenadores de quantidades (“estoques”)

31 Bags count B x x in B B1  B2, B1  B2 items S + -

32 Detalhando o Modelo: Banco
cadastrar remover creditar debitar getSaldo transferir clientes contas 0..n 0..n Conta numero: NUM saldo: \nat getNum getSaldo creditar debitar Cliente id: ID nome: NOME getId getNome dono 1 0..n Poupança renderJuros

33 Detalhando as Classes Para cada classe do diagrama anterior:
Descrever a funcionalidade de cada método através de: Pré-condição Pós-condição Caracterizar o invariante da classe

34 Classe Cliente Cliente - id: ID - nome: NOME getId setId getNome
pré: pós: result! = id Cliente - id: ID - nome: NOME getId setId getNome setNome setId(id: ID) pré: pós: id’ = id? getNome() pré: pós: result! = nome setNome(nome: NOME) pré: pós: nome’ = nome?

35 Classe Conta Conta - num: NUM - saldo: IN getNum() setNum() getSaldo()
pré: pós: result! = num Conta - num: NUM - saldo: IN getNum() setNum() getSaldo() setSaldo() creditar() debitar() setNum(num: NUM) pré: pós: num’ = num? getSaldo() pré: pós: result! = saldo setSaldo(saldo: IN) pré: pós: saldo’ = saldo?

36 Classe Conta Conta - num: NUM - saldo: IN ... creditar() debitar()
creditar(val: IN) pré: pós: saldo’ = saldo + val? debitar(val: IN) pré: saldo  val? pós: saldo’ = saldo - val?

37 Invariante Classe Banco
cl: clientes  cl  null cc: contas  cc  null c1,c2: contas | c1  c2  c1.getNum()  c2.getNum() cl1,cl2: clientes | cl1  cl2  cl1.getId()  cl2.getId()

38 Classe Banco ATENÇÃO: Esta classe possui dois atributos implícitos nomeados de contas: IP Conta e clientes: IP Cliente, respectivamente cadastrar(conta: Conta) pré: conta?  null  cc:contas  cc.getNum()  conta? pós: contas´ = contas  {conta?} Banco cadastrar() remover() creditar() debitar() transferir() remover(conta: Conta) pré: conta?  null  cc:contas  cc.getNum() = conta? pós: contas´ = contas \ {conta?}

39 Desenvolvendo o Sistema
O que eu desejo GARANTIR na minha solução??? Problema Solução ...

40 Operadores em Propriedades
Para estabelecer propriedades entre operações, podemos usar , , , ,  , , \ (.../...) pre, ;

41 Propriedade sobre Conta
É verdade que, para uma mesma conta, creditar um valor e, em seguida, debitar o mesmo valor resultará no mesmo estado inicial da conta? Como garantir isso? v, saldo, saldo’: IN  creditar(v) ; debitar(v)  saldo’=saldo

42 Propriedade sobre Conta
Como garantir que creditar é uma operação comutativa? Ou seja, creditar um valor v1 e depois v2 é o mesmo que creditar o valor v2 e depois o v1.

43 Bibliografia Booch, G. et al. The Unified Modeling Language User Guide
Sommerville, I. Software Engineering Tepfenhart, W. et al. Practical Object-Oriented Development with UML and Java Woodcock, J. et al. Using Z ( Spivey, J.M. The Z Notation ( Kruchten, P. The Rational Unified Process: An Introduction


Carregar ppt "Especificação Formal de Software"

Apresentações semelhantes


Anúncios Google