03-08EngSoft(EspecificaçãoFormal)

Engenharia de Software

Prof. Wilkerson de L. Andrade

Versão resumida e traduzida dos slides originais produzidos por Ian Sommerville, Software Engineering, 7th edition. Chapter 10.

Estes slides foram adaptados dos slides gentilmente cedidos pela professora Patrícia D. L. Machado (DSC/UFCG).

Objetivos

•

Explicar porque técnicas para especificação

formal ajudam a descobrir problemas nos

requisitos do sistema

•

Descrever o uso de técnicas algébricas para

descrição de interface

•

Exemplificar o uso de técnicas baseadas em

Métodos Formais

• Especificação formal é parte de uma coleção

geral de técnicas conhecida como “métodos formais”

• Métodos formais são baseados em

representação matemática e análise do software

• Métodos Formais incluem

▫ Especificação Formal;

▫ Análise e prova da especificação;

▫ Desenvolvimento baseado em transformações;

Aceitação de Métodos Formais

• Diferentemente do previsto, métodos formais não se

configuraram em uma solução universal e amplamente aceita:

▫ Outras técnicas de engenharia de software têm obtido sucesso e melhorado a qualidade de sistemas. Portanto, a necessidade de métodos formais foi reduzida;

▫ Mudanças de mercado guiam o processo de

desenvolvimento de software (time-to-market). Métodos formais não necessariamente reduzem o tempo de

desenvolvimento;

▫ O escopo de métodos formais é limitado. Não são

adequados para especificação e análise de interfaces do usuário e suas interações;

▫ Métodos formais ainda são de difícil aplicação em sistemas de grande porte.

Uso de Métodos Formais

• Os principais benefícios são reduzir o número

de defeitos em sistemas

• Consequentemente, sua maior área de

aplicação é no desenvolvimento de sistemas críticos. Vários projetos com sucesso já foram desenvolvidos nesta área usando métodos

formais

• Para sistemas críticos, o uso de métodos

formais tem maior probabilidade de ser efetivo e dentro dos custos previstos, visto que os custos de falhas são muito altos e devem ser evitados

Especificação no Processo de

Software

•

Especificação e design são atividades

intercaladas

•

Design de arquitetura é essencial para

estruturar a especificação e o processo de

especificação

•

Especificações formais são expressas em

notação matemática com vocabulário,

Especificação e Design

Envolvimento crescente do fornecedor Diminuição do envolvimento do cliente Definição de requisitos do usuário Especificação de requisitos do sistema Projeto de arquitetura Especificação

formal Projeto em _{alto nível}

Especificação

Uso de Especificação Formal

• Especificação formal envolve investir mais esforço

nas fases iniciais do processo de desenvolvimento de software

• Reduz erros de requisitos e força uma análise

detalhada dos requisitos

• Incompletudes e inconsistências podem ser

descobertas e resolvidas

• Portanto, este esforço é compensado pela redução

de problemas de requisitos que se propagariam para fases posteriores no processo de desenvolvimento

• Geração automática de casos de teste

Perfil de Custos

•

O uso de especificação formal implica em

mudanças no perfil de custos de projeto

▫ Custos de especificação são maiores;

▫ Custos de implementação e validação são

reduzidos, visto que defeitos nos requisitos são minimizados.

Custos de Desenvolvimento sem e

com Especificação Formal

Custos Especificação Projeto e implementação Validação Especificação Projeto e implementação Validação

Técnicas de Especificação

Especificação Algébrica

• O sistema é especificado em termos de suas operações e suas relações.

Especificação Baseada em Modelos

modelo de estado que é desenvolvido usando construções matemáticas tais como conjuntos e seqüências. Operações são definidas para modificar o estado do sistema.

Linguagens de Especificação Formal

Sequential Concurrent

Algebraic Larch (Guttag et al., 1993) },

OBJ (Futatsugi et al., 1985)}

Lotos (Bolognesi and Brinksma, 1987)},

Model-based Z (Spivey, 1992)}

VDM (Jones, 1980)} B (Wordsworth, 1996)}

CSP (Hoare, 1985)}

Especificação de Interface na

Abordagem Algébrica

• Sistemas grandes são decompostos em

subsistemas com interfaces bem definidas entre eles

• Especificação da interface de subsistemas torna

possível o desenvolvimento independente dos diferentes subsistemas

• Interfaces podem ser definidas como tipos

abstratos de dados ou classes

• A abordagem Algébrica para especificação

formal é adequada a especificação de interface porque enfoca a definição de operações de um objeto

Interfaces entre Subsistemas

Objetos de interface

Subsistema

Especificação Algébrica de

Componentes

• Define o tipo (nome do tipo) e declara outras especificações que serão usadas.

Introdução

• Descreve informalmente as operações sobre o tipo.

Descrição

• Define a sintaxe das operações na interface e seus parâmetros.

Assinatura

• Define a semântica das operações através de axiomas que caracterizam comportamento.

Especificação Algébrica: Sistemática

•

Especificações Algébricas de um sistema

podem ser desenvolvidas de forma

sistemática:

▫ Estruturação da Especificação;

▫ Nomenclatura da Especificação;

▫ Seleção de Operações;

▫ Especificação Informal da Operação;

▫ Definição de sintaxe (assinatura);

Especificação de Operações

•

Construtores.

Operações que criam

entidades do tipo especificado.

•

Operações de Inspeção.

Operações que

avaliam entidades do tipo sendo

Operações sobre uma Lista

•

Construtores:

▫

Create

▫

Cons

▫

Tail

•

Operações de Inspeção:

▫

Head

▫

Length

•

Tail pode ser definida usando os

Especificação de Lista

Head (Create) = Undefined exception (em pty list) Head (Cons (L, v)) = if L = Create then v else Head (L) Length (Create) = 0

Length (Cons (L, v)) = Leng th (L) + 1 Tail (Create ) = Create

Tail (Cons (L, v)) = if L = Create then Create else Cons (T ail (L), v) sor t List

im por ts INTEGER

Defines a list where elements are added at the end and remo ved from the front. The oper ations are Create , which br ings an empty list

into e xistence , Cons , which creates a ne w list with an added member , Leng th, which e valuates the list siz e, Head, which e valuates the front

element of the list, and Tail, which creates a list b y remo ving the head from its input list. Undefined represents an undefined value of type Elem.

Create  List

Cons (List, Elem )  List Head (List)  Elem Length (List)  Integer Tail (List)  List

LIST ( Elem )

Define uma lista onde elementos são adicionados ao final da lista e removidos do início...

Especificação de Comportamento

• Especificações algébricas podem se tornar

complicadas/desajeitadas quando as operações não são independentes do estado do objeto

• Especificações baseadas em modelos expõem

o estado do sistema e definem as operações em termos de mudanças sobre o estado

• A notação Z possui uma técnica madura de

especificação. Combina descrições formais e informais e usa uma notação gráfica

• Existem também notações semi-formais com

Estrutura de um Esquema em Z

Modelagem da Bomba de Insulina

• O esquema Z para a bomba de insulina declara variáveis de estado incluindo:

▫ Variáveis de entrada tais como switch? (switch do

dispositivo), InsulinReservoir? (quantidade atual de insulina no reservatório) e Reading? (leitura do sensor);

▫ Variáveis de saída tais como alarm! (alarme do

sistema), display1!, display2! (displays da bomba) and dose! (a dose de insulina liberada).

Invariante

• Cada esquema Z possui um invariante que define condições que sempre deverão ser satisfeitas.

• Para a bomba de insulina deve ser sempre verdade que:

▫ A dose deve ser menor ou igual a capacidade de

insulina do reservatório;

▫ Nenhuma dose pode ser maior que 4 unidades

de insulina e a dose total liberada em um período de tempo não deve exceder 25 unidades de

insulina. Restrição de segurança;

▫ Display2! Exibe a quantidade de insulina

Insulin Pump Schema

INSULIN_PUMP_STATE

//Input device definition

switch?: (of f, manual, auto) ManualDelivery Button?: N Reading?: N

HardwareTest?: (OK, batterylow, pumpf ail, sensorfail, deliveryfail) InsulinReservoir?: (present, notpresent)

Needle?: (present, notpresent) clock?: TIME

//Output device definition

alarm! = (on, of f ) display1!, string display2!: string clock!: TIME dose!: N

// State variables used for dose comp utation

status: (running, warning, error) r0, r1, r2: N

capacity, insulin_available : N

max_daily_dose, max_single_dose, minimum_dose: N safemin, safemax: N

State Invariants

r2 = Reading?

dose! <= insulin_available insulin_available <= capacity

// The cumulative dose of insulin delivered is set to zero once every 24 hours

clock? = 000000 cumulative_dose = 0

// If the cumulative dose exceeds the limit then operation is suspended

cumulative_dose >= max_daily_dose  status = error  display1! = “Daily dose exceeded”

// Pump configuration parameters

capacity = 100  safemin = 6  safemax = 14

max_daily_dose = 25  max_single_dose = 4  minimum_dose = 1 display2! = nat_to_string (dose!)

Computação da Dosagem

• A bomba de insulina computa a quantidade de

insulina necessária através da comparação da leitura atual com duas leituras prévias

• Se esta leitura sugerir que glicose no sangue

está aumentando então insulina é liberada

• Informação sobre a dose total administrada é

mantida para permitir que o invariante seja validado

• Observe que o invariante é aplicado como

condição padrão em qualquer operação – deve ser válido antes e após a execução de qualquer operação

RUN Schema (1)

INSULIN_PUMP_STATE

switch? = auto

status = running status = warning insulin_available >= max_single_dose cumulative_dose < max_daily_dose

// The dose of insulin is computed depending on the blood sugar level

(SUGAR_LOW  SUGAR_OK SUGAR_HIGH)

// 1. If the computed insulin dose is zero, don’t deliver any insulin

CompDose = 0 dose! = 0



// 2. The maximum daily dose would be exceeded if the computed dose was delivered so the insulin dose is set to the difference between the maximum allowed daily dose and the cumulative dose delivered so far

CompDose + cumulative_dose > max_daily_dosealarm! = on status’ = warning dose! = max_daily_dose – cumulative_dose

RUN Schema (2)

// 3. The normal situation. If maximum single dose is not exceeded then deliver the computed dose. If the single dose computed is too high, restrict the dose delivered to the maximum single dose

CompDose + cumulative_dose < max_daily_dose 

( CompDose <= max_single_dose  dose! = CompDose



CompDose > max_single_dose dose! = max_single_dose ) insulin_available’ = insulin_available – dose!

cumulative_dose’ = cumulative_dose + dose!

insulin_available <= max_single_dose * 4  status’ = warning  display1! = “Insulin low”

r1’ = r2 r0’ = r1

Sugar Ok Schema

r2 >= safemin r2 <= safemax

// sugar level stable or falling

r2 <= r1 CompDose = 0



// sugar level increasing but rate of increase falling

r2 > r1  (r2-r1) < (r1-r0)CompDose = 0



// sugar level increasing and rate of increase increasing compute dose // a minimum dose must be delivered if rounded to zero

r2 > r1  (r2-r1) >= (r1-r0)  (round ((r2-r1)/4) = 0) 

  CompDose = minimum_dose



r2 > r1  (r2-r1) >= (r1-r0)  (round ((r2-r1)/4) > 0)  CompDose = round ((r2-r1)/4)