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