Modelagem de Sistemas de Tempo-

Real

2

Requisitos de Sistemas de Software Confiabilidade Disponibilidade Segurança Manutenibilidade Portabilidade Reuso

3

Requisitos não Funcionais Requisitos tecnológicos Tolerância a Falhas Redundâncias Funcionamento Degragadado Manutenção Consumo de Energia Tamanho, Peso Ergonomia ………..

4

Sistemas de Tempo-Real controle de processos, aviônica, sistemas militares de defesa,

telecomunicações e controle de plantas nucleares diferenciam-se dos demais sistemas de computação pela

necessidade do atendimento das restrições temporais (prazos ou deadlines) Perder o prazo equivale a não cumprir sua funcionalidade

podem ser classificados em sistemas "soft“ quando as condições impostas admitem a perda ocasional de prazos

ou "hard” quando a perda de prazos é inaceitável por causar graves

conseqüências Se essas conseqüências forem tão graves ao ponto de

resultarem em danos catastróficos (perda de vidas ou grandes prejuízos), será considerado um Sistema de Segurança Crítica.

5

Modelagem de Sistemas de Tempo-real Técnicas Informais ( ou semi-formais)

Abordagem Orientada a Objetos Enfatizam a compreensão, simplificando a comunicação entre o

desenvolvedor e o usuário Apresentam redundâncias, inconsistências, lacunas,…

Técnicas de Especificação Formais Z, SCR, SDL, etc. Satecharts FSP Caracterizam-se pelo formalismo, em detrimento da

compreensão do modelo ou da sua facilidade de uso Permitem validação do modelo

6

Especificação de Requisitos Formal

Tem uma base rigorosa matemática Informal

Não pode ser completamente traduzida para uma notação matemática rigorosa

Uma especificação textual Não são suficientes para sistemas de tempo-

real Semi-formal

Entre formal e informal UML? UML 2.0?

Métodos Formais na Especificação de

Sistemas

8

Visão Geral São usadas na:

Verificação de Consistência onde o comportamento dos requisitos do sistema são

descritos usando uma notação de base matemática Model checking

Utiliza máquinas de estado para verificar onde uma determinada propriedade é satisfeita sob todas as condições

Prova de Teoremas Axiomas do comportamento do sistema são empregados

para derivar uma prova de que o sistema vai se comportar sob uma determinada forma

9

Exemplo• Considere um sistema de monitoramento com as seguintes

características: Possui as tarefas A e B

Se a interrupção A ocorre, a tarefa B deve parar sua execução.

Tarefa A inicia execução após a ocorrência da interrupção A.

Ou a Tarefa A está executando e a Tarefa B não está ou B está executando e A não está, ou ambas não estão

Estes requisitos podem ser formalizados da seguinte forma:

p: A ocorre q: Tarefa B está executando r: Tarefa A está executando

10

Exemplo

Vamos reescrever empregando estas proposições e conectivos lógicos

1.1

1.2

1.3

p q� �

p r

( ) ( ) ( )r q q r q r�� � �� �� ��

11

Exemplo

1 2 3 4 5 6 7 8 p q r q¬ r¬ p q⇒ p r⇒ ( ) ( ) ( )r q q r q r∧ ¬ ∨ ∧ ¬ ∨ ¬ ∧ ¬

1 T T T F F T T F 2 T T F F T T T T 3 T F T T F T T T 4 T F F T T T T T 5 F T T F F F F F 6 F T F F T F T T 7 F F T T F T F T 8 F F F T T T T T

Tabela verdade empregada para validar a consistência deste conjunto de requisitos.

12

Máquinas de Estados Finitas FSA– Autômato Finito FSM – Máquina de Estados Finitos Diagrama de Transições de Estados

É um modelo formal, matemático usado na especificação e projeto de sistemas

Muitos sistemas podem ser representados por um número finito de estados

Os sistemas transitam de estado pela ocorrência de eventos

A decorrência de um período de tempo é um evento Estas máquinas podem ser especificadas sob a forma de

diagramas.

13

Máquinas de Estados Finitas

S={calibration, diagnostic, operational}, i=calibration, T=S and = {op_op, op_cal, error}. A função transição pode ser descrita pelo conjunto de tuplas da seguinte forma (state, signal, next_state).

￥

14

Máquinas de Estados Finitas

evento

Estado corrente op_op op_cal error

calibration operational calibration diagnostic

diagnostic operational calibration diagnostic

operational operational calibration diagnostic

15

Máquinas de Estados Finitos Pode ser descritamatematicamente pela tupla

S é um conjunto finito não vazio de estados i é o estado inicial (i S), T é um conjunto de estados terminais, é um alfabeto de símbolos ou eventos usados

para marcar transições, é a função de transição que descreve o póximo

estado da máquina dado o estado atuale um evento.

{ }, , , ,M S i T δ= Σ

Σ

δ

16

Statecharts Máquinas de estado finitos Hierarquia Comunicação em Broadcast Statecharts Empregado em diagramas de estado da

UML.

17

Petri nets Usado para especificar as operações a executar em

um ambiente de multiprocessamento ou multitarefas

Grafo de lugares e transições A topologia do grafo não altera com o tempo

Apenas os tokens mudam de lugar quendo uma transição dispara

Devido a sua natureza matemática, técnicas de otimização e programação formal podem ser empregadas

Modelam em detalhe e são difícies de analisar para sistemas reais.

18

T1P1 P2

Before firing

T1P1 P2

after firing

Petri nets

19

m0

m1

P1

P2

P3P4

T1

T2

T3

Petri nets

20

m2

m3

Petri nets

21

m4

Petri nets

22

F1

F2

F1

F2

P2

P1

T2

T1

Petri nets

23

?

F1 F2

T1

True

T2

True

F1 F2

Petri nets

24

Keep looping?

True

F1

F1T1 T3

T3 (stop looping)

Petri nets

25

Limitações de Métodos Formais Formalismo é usado para garantir correção

e segurança Temos limitações para assegurar esta garantia

Técnicas formais nem sempre são boas alternativas para projetos e arquiteturas

Especificações formais de software tem que ser convertidas em design e implementação Isto pode introduzir erros se feita

manualmente

Uso de Métodos Formais

27

Quando empregar Empregar uma abordagem formal no

desenvolvimento é justificado por: Concorrência

Estes sistemas tem um padrão complexo Sistemas de controle em tempo-real, sistemas

distribuídos, projeto de hardware e processamento paralelo

Qualidade crítica Sistemas cuja confiabilidade e disponibilidade são

importantes Aplicações financeiras, telecomunicações e Sistemas

Operacionais

28

Quando empregar Empregar uma abordagem formal no

desenvolvimento é justificado por: Segurança crítica

Controle de sistemas vitais – defesa, medicina, trens, entre outros

Prevenção de acesso não autorizados – sistemas bancários, segurança nacional, etc.

Padronizações Para definição de padrões, em especial padrões internacionais Especificação de Protocolos Existem Formal Description Techniques – FDTs

Lotos Estelle SDL

29

Propósito O propósito das FDTs é obter especificações:

não ambígua; completa; consistente; tratável; conformidade da implementação com a especificação

O uso de um FDT requer cuidados em especificar exatamente o que está sendo requisitado.

30

O que se ganha? Descobrir antecipadamente

Erros Ambigüidades Inconsistências

Escrever uma descrição formal também impõe uma boa estrutura ao domínio do problema

FSP

32

Modelando Processos Um processo é a execução de um programa

seqüencial O seu estado consiste nos valores de suas

variáveis Conforme executa, transforma seu estado através

da execução de comandos Cada comando consiste de uma seq. De uma ou mais

ações não atomicas que faz com que um estado mude Um modelo mais abstrato apenas considera um

processo tendo um estado modificado por ações atômicas indivisíveis

Cada ação causa uma transição de estados A ordem possível das ações é determinada pelo grafo de

transições Uma representação abstrata do programa

33

O que é programação concorrente Múltiplas linhas de execução Processamentos em paralelo Controle de Atividades externas

Vantagens Aumento de desempenho e throughput Estrutura apropriada para sistemas de tempo-real

Atendimento às restrições temporais

Desvantagens Aumento da Complexidade Sincronização

34

Modelando Processos Utilizaremos um LTS

(Labeled Transition State) Transições são rotuladas

com nomes de ações P= (x->P).

P está inicialmente engajado na ação x

Após esta ação ele volta a P

SWITCH = OFF, OFF = (on -> ON), ON = (off-> OFF).

SWITCH on

off

0 1

35

Histórico Robin Milner, o qual em 1973, desenvolveu a

teoria chamada por ele CCS ( Calculus of Communicating Systems - Cálculo de Sistemas Comunicantes)

CSP de Tony Hoare, que se baseia nos principios de Milner, que tem sua base fixada nas teorias de concorrência, paralelismo e distribuição de sistemas computáveis

De maneira simples, podemos dizer que Álgebras de Processos são linguagens algébricas que permitem a descrição de sistemas distribuí-dos e concorrentes e a verificação formal de suas propriedades

36

Histórico Robin Milner, o qual em 1973, desenvolveu a

teoria chamada por ele CCS (Calculus of Communicating Systems - Cálculo de Sistemas Comunicantes)

CSP de Tony Hoare, que se baseia nos principios de Milner, que tem sua base fixada nas teorias de concorrência, paralelismo e distribuição de sistemas computáveis

De maneira simples, podemos dizer que Álgebras de Processos são linguagens algébricas que permitem a descrição de sistemas distribuí-dos e concorrentes e a verificação formal de suas propriedades

37

Modelando processos Se x e y são ações

(x->P | y->Q) Se x ocorrer o comportamento

susequente é descrito por P senão (y ocorrendo) é descrito por Q

DRINKS = (red ->coffee->DRINKS |blue->tea ->DRINKS ).

DRINKS

redblue

teacoffee

0 1 2

38

Processos Concorrentes Se P e Q são

processos (P||Q) representa a

execução de P e Q

ITCH = (scratch->STOP).

CONVERSE = (think->talk->STOP).

||CONVERSE_ITCH = (ITCH || CONVERSE).

CONVERSE think talk

0 1 2

ITCH scratch

0 1

CONVERSE_ITCH

scratch

think

scratch

talk scratch

talk think

0 1 2 3 4 5

39

Sincronizando

MAKER = (make->ready->MAKER).

USER = (ready->use->USER).

||MAKER_USER = (MAKER || USER).

MAKER make

ready

0 1

USER ready

use

0 1

MAKER_USER make ready make

use use

0 1 2 3

40

Exemplo

AOFF=(intA->AON),AON = (bon->AOFF).

BON =(intA->BOFF),BOFF = (bon->BON).

||AB = (AOFF||BON).AB intA

bon

0 1

AOFF intA

bon

0 1

BON intA

bon

0 1

p q� �p r

( ) ( ) ( )r q q r q r�� � �� �� ��

41

Verificação de Propriedades Uma propriedade é um atributo de um

sistema que é verdadeiro para todas as suas possíveis execuções

As propriedades de interesse de sistemas concorrentes podem ser divididas em duas categorias: Safety liveness

42

Verificação de propriedades Uma propriedade safety garante que nada

de errado ira ocorrer durante uma execução

Nenhum estado não desejado ira ocorrer

43

Verificação de propriedades Uma propriedade liveness garante que o

sistema, eventualmente, realize algo bom Algum estado desejado deve,

eventualmente, ser atingido

44

Verificação de propriedades Em programas seqüenciais a propriedade

safety mais importante é que o estado final esteja correto

Em programas concorrentes as propriedade safety mais importantes são: exclusão mutua e ausência de deadlock

45

Verificação de propriedades Em sistemas seqüenciais a propriedade

liveness mais importante é a que o programa, eventualmente, termine

Em sistemas concorrente, modelamos sistemas que, na maioria das vezes, não termina

46

O Paradigma de Objetos É mais do que um estilo de Programação

abrange as fases de Análise e Projeto lidam com sistemas de software grandes, complexos e

sujeitos a mudanças Análise

enunciado do problema Projeto

planta para a solução

47

Desenvolvimento de Sistemas Programar os componentes individuais não

é o desafio O desafio está em

identificar a decomposição do problema em componentes

integração dos componentes garantindo-se: fácil manutenção,

entendimento , modificação e adaptação

48

Metodologia OO Um mesmo conjunto de conceitos e

notação é usado em todas as fases do processo de desenvolvimento

Idéia principal: o estado de um programa é encapsulado em

objetos objetos só são acessados através de suas

operações públicas definidas por ele

UML – Unified Modeling Language

Abordagem de Casos de Uso

50

UML O que significa ter um sistema OO bem

projetado? Possuir um martelo não torna alguém um

arquiteto UML – uma linguagem, primordialmente

gráfica, para modelar sistemas usando os conceitos de Orientação a Objetos

51

Análise Orientada a Objetos Casos de Uso

Caso de Usop para um sistema de posição inercial.

Um exemplo

53

Um exemplo Antes de nos perdermos em uma floresta de

detalhes Vamos apresentar uma visão geral de alguns passos e

diagramas Jogo de dados

Um jogador joga dois dados Se o total é sete os dados vencem Caso contrário o jogador ganha

Obs: serão mostrados os passos essenciais e diagramas mais usuais

Maiores detalhes no decorrer do curso

54

Passos

Casos de uso Artefato da análise Descrevem processos Passo preliminar na descrição de requisitos

Casos de Uso

Modelo Conceitual

Diagramas de Colaboração

Diagramas de Classes

55

Casos de Uso Jogar um jogo

Atores: jogador Descrição: Começa quando o jogador lança os

dados. Se o total dos dados é sete os dados vencem, caso contrário o jogador vence.

Jogar um jogo

jogador

56

Definindo um modelo conceitual Conceitos?

Jogador, JogoDeDados, Dado Identifica-se atributos para explicitar a

relevância do conceito Identifica-se como os conceitos estão

associados

57

Definindo um modelo conceitual

Jogadornome

DadovalorFace

JogoDeDadosvencedor

1 lança 2

1

joga

1

1

2

inclui

representa conceitos do domínio do problema no mundo real

58

Definindo Diagramas de Colaboração Temos que definir especificações lógicas

de software que atendem os requisitos funcionais Decomposição por classes de objetos Alocação de responsabilidades aos objetos Como os objetos interagem

Diagramas de colaboração mostram o fluxo de mensagens entre instâncias de objetos e a invocação de métodos

59

Diagrama de Colaboração

:Jogadorjogar()

d1:Dado

d2:Dado

1:r1:=lança()

2:r2:=lança()

60

O Diagrama de Classe Para definir uma classe

Como os objetos se conectam a outros objetos?

Quais os métodos de uma classe? Os Diagramas de colaboração sugerem as

conexões entre objetos e seus métodos O Diagrama de classes expressa esses

detalhes

61

O Diagrama de Classes

Jogador

nome

Dado

valorFace

JogoDeDados

vencedor

1 lança 2

1

joga

1

1

2

inclui

jogar() lançar()

iniciar()

62

O Diagrama de Classes Em comparação com o modelo conceitual

este diagrama não ilustra conceitos do mundo real Ele descreve componentes de software A linha com uma flecha na extremidade sugere um

atributo JogoDeDado possui um atributo que é uma instância de

Jogador Este é apenas um diagrama inicial Ele é estendido no projeto do software

63

Análise x Projeto A divisão entre as fases análise e projeto é

vaga Não é de grande valia ser rígido Análise não deve considerar tecnologia de

implementação Análise: investigação Projeto: solução

64

UML UML é uma linguagem que ajuda a especificar,

visualizar e documentar modelos de sistemas de software

UML disponibiliza 12 tipos de diagramas UML é aceita pela OMG (Object Management Group)

é a forma de modelar não apenas a estrutura da aplicação, seu comportamento e arquitetura

mas também o processo de negócio e a estrutura de dados.

65

UML A modelagem permite a compreensão do

sistema Nenhum modelo é inteiramente suficiente

serão necessários vários modelos, conectados entre si

várias visões, consistentes do mesmo problema

66

UML Modelos explícitos facilitam a

comunicação linguagem gráfica linguagem textual todos os sistemas contêm estruturas que

transcendem o que uma linguagem de programação é capaz de representar

67

UML Abrange todas as visões necessárias ao

desenvolvimento e implantação de sistemas de software

Aprender UML equivale ao entendimento de três principais elementos blocos básicos da construção da UML regras que determinam como esses blocos de

construção deverão ser combinados mecanismos básicos que se aplicam a toda a linguagem

68

UML É apenas uma linguagem É somente uma parte de um método de

desenvolvimento de software Utilizada em um processo de

desenvolvimento, orientado a Casos de Uso, centrado na arquitetura, iterativo e incremental UP – Unified Process

69

O Problema dos Filósofos Este é um problema clássico de

programação concorrente Vamos desenvolver o modelo UML O correspondente em FSP

Vamos verificar propriedades

70

O Problema dos Filósofos 5 filósofos compartilham uma mesa circular Cada filósofo gasta seu tempo de um das duas

formas Pensando Comendo

No centro da mesa está uma travessa de macarrão Para comer o filósofo precisa de dois garfos Na mesa temos 5 garfos Cada garfo está entre dois filósofos Eles só podem usar os garfos que estão a sua direita e

a sua esquerda

71

72

Casos de Uso Filósofos são nossos atores O Filósofo:

Eventualmente tem fome Caso de Uso – Comer Neste momento requisita ao sistema os garfos a sua

esquerda e direita para comer Quando estiver satisfeito

Caso de Uso – Parar de Comer Devolve os garfos ao sistema

73

Casos de Uso No entanto, estaremos fazendo uma

simulação para testar as propriedades do nosso modelo Vamos ter que simular os filósofos

74

Casos de Uso

Pensar

Comer

Filosofo

75

Comer O Filósofo deseja comer. Cada filósofo tem uma posição na mesa. Ele pega então os garfos a sua direita e a sua

esquerda Dispondo dos dois garfos ele come. Fluxos Alternativos:

Estando um dos garfos ocupados o filósofo fica esperando segurando o garfo livre

76

Comer Uma implementação

1. Estando o garfo da direita ocupado ele espera. Só quando este estiver disponível ele pega o da esquerda2. Estando o garfo da esquerda ocupado ele espera segurando o garfo da direita.

77

Pensar Estando o filósofo satisfeito, ele libera os

garfos e volta a pensar

78

Diagrama de Classes

Garfo

livreposicao

pega()solta()Garfo()

<<ativa>>

Mesa

<<[5]>> assento : Integer<<[5]>> garfos : int

qualGarfoD()qualGarfoE()

<<ativa>>

1

5

1

5

Filósofo

assentoestadogarfoEgarfoD

comer()pensar()Filosofo()

<<ativa>>

2

1

2

1

1

5

1

5

esta sentado

SimulaFilosofo

geraVontade()SimulaFilosofo()

1

1

1

1

79

Diagramas de Colaboração

: Filósofo

: Mesa

Para todos os filosofos

: SimulaFilosofo

Ins tanciacao do problema

: Garfopara todos os garfos

3: qualGarfoD( )4: qualGarfoE( )

2: f:Filosofo( assento)

5: SimulaFilosofo( f )1: pos=1..5 g: Garfo( pos)

80

Diagramas de Colaboração

: Filósofo

garfoD : Garfo

: SimulaFilosofo

1: [Decorrido DeltaT] acao:geraVontade( )

2: [acao=fome] comer()

3: pega( )

garfoE : Garfo

4: pega( )

O filosofo tinha que estar pensando

81

Diagramas de Colaboração

: Filósofo

garfoD : Garfo

: SimulaFilosofo

garfoE : GarfoO filosofo tinha que estar

comendo

3: solta( )

1: [Decorrido DeltaT] acao:geraVontade( )

2: [acao=pensar] pensar()

4: solta( )

82

Diagrama de EstadosFilósofo

pensando

^qualGarfoD && mesa.qualGarfoE

com fome

pegando garfoD

pegando garfoE

comendo

comer

pegando garfoD

garfoD.pega()

pegando garfoE

de posse do garfoD garfoE.pega

de posse do garfoE

pensar garfoD.solta && garfoE.solta

83

Diagrama de EstadosGarfo

livre

apenas para ressaltar que caso um filosofo peca um garfo ocupado, o filosofo fica em espera.

ocupado

entry: posse= filosofo com a posse

ocupado com espera

entry: espera = filosofo em espera

pega

solta

pega

solta / posse = espera && espera = null

84

Jantar dos filosofos

85

Um Filosofo

phil.0:PHIL phil[0].sitdown phil[0].right.get phil[0].left.get phil[0].eat phil[0].left.put phil[0].right.put

phil[0].arise

0 1 2 3 4 5 6