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

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

Metodos de Especificação de Software 1ª Parte Patrícia Macedo Joaquim Filipe João Ascenso Engenharia de Software 2004/2005 EST, Setúbal.

Apresentações semelhantes


Apresentação em tema: "Metodos de Especificação de Software 1ª Parte Patrícia Macedo Joaquim Filipe João Ascenso Engenharia de Software 2004/2005 EST, Setúbal."— Transcrição da apresentação:

1

2 Metodos de Especificação de Software 1ª Parte Patrícia Macedo Joaquim Filipe João Ascenso Engenharia de Software 2004/2005 EST, Setúbal

3 Engenharia de Software2 Indice Geral 1ª Parte Especificação de Software Especificação de Software DFDs DFDs Maquinas de estados Maquinas de estados Petri Nets Petri Nets 2ª Parte UML UML 3ª Parte Exemplos Exemplos

4 Engenharia de Software3 Motivação Ao longo de várias disciplinas do curso temos utilizado várias formas de especificar o software. Ao longo de várias disciplinas do curso temos utilizado várias formas de especificar o software. Fluxogramas (IP, ATAI, POO Microprocessadores) Fluxogramas (IP, ATAI, POO Microprocessadores) DFDs - ASI DFDs - ASI Maquinas Finitas - Microprocessadores Maquinas Finitas - Microprocessadores Redes Petri Redes Petri UML – POO UML – POO O objectivo desta aula é fazer uma breve revisão de algumas destas diferentes tecnicas de especificar o software.

5 Engenharia de Software4 Especificação No dicionário: No dicionário: Especifica: que pertence a uma espécie particular Especifica: que pertence a uma espécie particular No contexto da engenharia: No contexto da engenharia: Descrição dos detalhes estruturais e comportamentais de um produto a desenvolver Descrição dos detalhes estruturais e comportamentais de um produto a desenvolver No contexto da ES: No contexto da ES: Descrição precisa das entidades de um sistema, do conjunto de métodos para as manipular e do seu comportamento. Descrição precisa das entidades de um sistema, do conjunto de métodos para as manipular e do seu comportamento.

6 Engenharia de Software5 Especificação Vários significados possíveis, em ES: Vários significados possíveis, em ES: Especificação de requisitos Especificação de requisitos Acordo entre o utilizador e o responsável pelo sistema de SW completo Acordo entre o utilizador e o responsável pelo sistema de SW completo Especificação de desenho Especificação de desenho Acordo entre o arquitecto do sistema e os programadores Acordo entre o arquitecto do sistema e os programadores Especificação de módulos Especificação de módulos Acordo entre os programadores que utilizam o módulo e os programadores que o implementam Acordo entre os programadores que utilizam o módulo e os programadores que o implementam

7 Engenharia de Software6 Para que servem as especificações Indicar as necessidades do utilizador Indicar as necessidades do utilizador Importante para o programador saber quais são as necessidades do utilizador Importante para o programador saber quais são as necessidades do utilizador O utilizador não sabe bem o que quer O utilizador não sabe bem o que quer Tentar obter uma especificação clara e precisa Tentar obter uma especificação clara e precisa Evitar ambiguidades e diferentes interpretações entre o utilizador e o programador Evitar ambiguidades e diferentes interpretações entre o utilizador e o programador VERIFICAR as especificações VERIFICAR as especificações As especificações podem ser construídas de uma forma muito clara e precisa As especificações podem ser construídas de uma forma muito clara e precisa e.g. métodos formais e.g. métodos formais

8 Engenharia de Software7 Para que servem as especificações Indicação dos requisitos para a implementação Indicação dos requisitos para a implementação Ponto de referência durante a implementação Ponto de referência durante a implementação Especificação define o comportamento: Especificação define o comportamento: Interno – Especificação de desenho Interno – Especificação de desenho Externo – Especificação de requisitos Externo – Especificação de requisitos A especificação de desenho deve ser escrita de forma mais formal e precisa que as de requisitos A especificação de desenho deve ser escrita de forma mais formal e precisa que as de requisitos Especificação de desenho programadores Especificação de desenho programadores Especificação de requisitos utilizadores Especificação de requisitos utilizadores

9 Engenharia de Software8 Qualidades das Especificações Três características fundamentais a ter em conta na especificaçaõ do software: Três características fundamentais a ter em conta na especificaçaõ do software: Clareza: Clareza: Sem ambiguidades e compreensíveis Sem ambiguidades e compreensíveis Consistência: Consistência: Sem regras contraditórias Sem regras contraditórias Ser completa Ser completa Internamente: toda a terminologia interna estar definida Internamente: toda a terminologia interna estar definida Relativamente aos requisitos: documentar todos os requisitos Relativamente aos requisitos: documentar todos os requisitos

10 Engenharia de Software9 Estilos de Especificação Critério 1: especificações formais vs. especificações informais Critério 1: especificações formais vs. especificações informais Formais: A notação utilizada possui uma sintaxe e uma semântica totalmente precisa Formais: A notação utilizada possui uma sintaxe e uma semântica totalmente precisa Informal: Escritas em linguagem natural Informal: Escritas em linguagem natural As linguagens TDN e GDN são semi-formais. Porquê? As linguagens TDN e GDN são semi-formais. Porquê? Critério 2: Especificações operacionais vs. especificações descritivas Critério 2: Especificações operacionais vs. especificações descritivas A especificação operacional define comportamentos desejados através de um modelo do sistema A especificação operacional define comportamentos desejados através de um modelo do sistema A especificação descritiva define propriedades desejáveis, de forma puramente declarativa A especificação descritiva define propriedades desejáveis, de forma puramente declarativa Exemplo: a especificação de uma elipse – através do desenho da sua forma ou através da sua fórmula: ax 2 + by 2 + c = 0 Exemplo: a especificação de uma elipse – através do desenho da sua forma ou através da sua fórmula: ax 2 + by 2 + c = 0

11 Engenharia de Software10 Especificações Informais Escritas em linguagem natural Escritas em linguagem natural Fáceis de serem entendidas pelo cliente Fáceis de serem entendidas pelo cliente Mais susceptíveis de possuírem: Mais susceptíveis de possuírem: Erros, omissões, imprecisões ou ambiguidades Erros, omissões, imprecisões ou ambiguidades As falhas são descobertas mais tarde, na integração, no teste do sistema ou mesmo na entrega do produto As falhas são descobertas mais tarde, na integração, no teste do sistema ou mesmo na entrega do produto Conclusão: Não é uma boa forma de especificar um sistema complexo Conclusão: Não é uma boa forma de especificar um sistema complexo Facto: ainda é utilizado por muitas empresas. Facto: ainda é utilizado por muitas empresas. Principais razões: gestão não uniformizada, pessoal não qualificado, pressões do cliente, falta de investimento Principais razões: gestão não uniformizada, pessoal não qualificado, pressões do cliente, falta de investimento No entanto, o panorama está a mudar. No entanto, o panorama está a mudar.

12 Engenharia de Software11 Especificações Formais Comunicação fácil entre os arquitectos do sistema de SW, programadores e responsáveis pela escrita dos requisitos Comunicação fácil entre os arquitectos do sistema de SW, programadores e responsáveis pela escrita dos requisitos Representações formais: Representações formais: Análise automática Análise automática O desempenho é baixo ? Existem deadlocks ? O desempenho é baixo ? Existem deadlocks ? Medidas objectivas Medidas objectivas e.g. de acoplamento e/ou de coesão entre módulos e.g. de acoplamento e/ou de coesão entre módulos Verificação de algumas propriedades do SW Verificação de algumas propriedades do SW Podem ser utilizadas para testar o sistema de SW: Podem ser utilizadas para testar o sistema de SW: E.g. através de test scripts E.g. através de test scripts

13 Engenharia de Software12 Formalidade vs Informalidade Método informal Método informal Linguagem natural Linguagem natural Métodos semi-formais Métodos semi-formais Gane & Sarsen/DeMarco/Yourdon Gane & Sarsen/DeMarco/Yourdon Entity-Relationship Diagrams Entity-Relationship Diagrams Jackson/Orr/Warnier, Jackson/Orr/Warnier, SADT, PSL/PSA, SREM, etc. SADT, PSL/PSA, SREM, etc. Métodos formais Métodos formais Finite State Machines Finite State Machines Petri Nets Petri Nets Z ANNA, VDM, CSP, etc. ANNA, VDM, CSP, etc.

14 Engenharia de Software13 Formalidade vs Informalidade Notações semi-formais Notações semi-formais Possuem uma fraca semântica associada com a estrutrura Possuem uma fraca semântica associada com a estrutrura Muito utilizadas, fácil compreensão Muito utilizadas, fácil compreensão Notações formais Notações formais A semântica é claramente definida (conceito matemático) A semântica é claramente definida (conceito matemático) As especificações não são ambíguas As especificações não são ambíguas Menos atrito entre o cliente e o produtor de SW Menos atrito entre o cliente e o produtor de SW Implementação mais fácil Implementação mais fácil Díficil compreensão Díficil compreensão

15 Engenharia de Software14 Especificação Formal: Exemplo A system consists of a set of object files. Each object file is derived from one or more source files. Object and source files have a timestamp indicating when they were last modified. If an object file is older than any source file, then the object file must be rederived.

16 Engenharia de Software15 Especificação Formal: Primeiro Passo A system consists of a set of object files. Each object file is derived from one or more source files. Object and source files have a timestamp indicating when they were last modified. If an object file is older than any source file, then the object file must be rederived.

17 Engenharia de Software16 Especificação Formal O = {o1, o2, o3, …} S = {s1, s2, s3, …} F = O U S T: F R D: O PowerSet(S) ForAll(o ε O), ForAll(s ε D(o)) T(o) > T(s) O = conjunto dos ficheiros obj S = conjunto dos ficheiros fonte F = Todos os ficheiros T = relação do timestamp D = relação deriva Um exemplo: os timestamp de O devem ser maiores que os timestamps de s

18 Engenharia de Software17 Especificações Operacionais Notações para indicação de especificações em estilo operacional: Notações para indicação de especificações em estilo operacional: Diagramas de Fluxo de Dados - Data Flow Diagrams Diagramas de Fluxo de Dados - Data Flow Diagrams Especificação de colecções de dados que são manipulados por funções, em termos de repositórios e fluxos de dados Especificação de colecções de dados que são manipulados por funções, em termos de repositórios e fluxos de dados Máquinas de Estados Finitas - Finite State Machines Máquinas de Estados Finitas - Finite State Machines Especificação de estruturas de controlo Especificação de estruturas de controlo Redes de Petri – Petri Nets Redes de Petri – Petri Nets Especificação de sistemas assíncronos, em termos de lugares e transições entre lugares Especificação de sistemas assíncronos, em termos de lugares e transições entre lugares

19 Data Flow Diagrams (DFDs)

20 Engenharia de Software19 DFDs Servem para especificar as funções de um sistema de informação Servem para especificar as funções de um sistema de informação O sistema é descrito como uma colecção de dados manipulados por funções O sistema é descrito como uma colecção de dados manipulados por funções Os dados podem ser organizados de várias formas: Os dados podem ser organizados de várias formas: Repositórios de dados Repositórios de dados Transferências de dados Transferências de dados Entradas/saídas Entradas/saídas

21 Engenharia de Software20 DFDs Notação gráfica: Notação gráfica: Nós (bubble): representam funções. Nós (bubble): representam funções. Setas: representam fluxos de dados Setas: representam fluxos de dados Caixas abertas: representam repositórios de dados. Caixas abertas: representam repositórios de dados. Caixas de E/S: Representam a aquisição e produção de dados durante a interacção humano-máquina. Caixas de E/S: Representam a aquisição e produção de dados durante a interacção humano-máquina. FunçãoDispositivo de entrada Dispositivo de saída Fluxo de Dados Repositório De Dados

22 Engenharia de Software21 Exemplo (a + b) * (c + a * d) ou, em notação prefixa: (* (+ a b) (+ c (* a d))) a b d c + * + *

23 Engenharia de Software22 Outro Exemplo: Biblioteca Prateleira Lista de Autores Lista de Titulos Lista de Tópicos Obter um livro Procurar por Tópico Pedido de Livro pelo utilizador Recepção do Livro Lista de livros emprestados Lista de Títulos Tópico pedido pelo utilizador. Livro Autor Título Tópico Lista de Títulos Referentes ao Tópico Titulo; utilizador Livro Título e Autor do livro pedido; Nome do utilizador

24 Engenharia de Software23 Problemas com os DFDs Os DFDs possuem uma notação gráfica atractiva capaz de capturar de forma intuitiva o fluxo de dados e as operações envolvidas num sistema de informação: Os DFDs possuem uma notação gráfica atractiva capaz de capturar de forma intuitiva o fluxo de dados e as operações envolvidas num sistema de informação: No entanto falta-lhes uma semântica precisa No entanto falta-lhes uma semântica precisa Requerem uma interpretação intuitiva Requerem uma interpretação intuitiva Notação semi-formal Notação semi-formal O controlo não é definido por este modelo: O controlo não é definido por este modelo: Um nó ("bubble") utiliza todas as suas entradas ? Um nó ("bubble") utiliza todas as suas entradas ? Espera por todas ou por um determinado número ? Espera por todas ou por um determinado número ? Repete os cálculos quando as entradas são constantes ? Repete os cálculos quando as entradas são constantes ?

25 Engenharia de Software24 Ultrapassar os problemas Utilizar uma notação complementar para descrever os aspectos não abrangidos pelas DFDs Utilizar uma notação complementar para descrever os aspectos não abrangidos pelas DFDs Especificação completa = DFDs + descrições auxiliares Especificação completa = DFDs + descrições auxiliares Aumentar o modelo DFD, por forma a abranger mais funcionalidades. Aumentar o modelo DFD, por forma a abranger mais funcionalidades. e.g. Introdução de setas de controlo de fluxo e.g. Introdução de setas de controlo de fluxo Rever a notação DFD tradicional para a tornar completamente formal Rever a notação DFD tradicional para a tornar completamente formal Revela-se muito complicado !!! Revela-se muito complicado !!!

26 Máquinas de estado finitas

27 Engenharia de Software26 Switch on Switch off Current State Action OffOn Switch on Switch off On Off On Switch on Switch off Switch on Máquinas de Estado Finitas As MEF assumem que o sistema está sempre em um dos estados permitidos

28 Engenharia de Software27 Máquinas de Estados Finitas Trata-se de um modelo bem conhecido para representar controlo. Trata-se de um modelo bem conhecido para representar controlo. Uma MEF é adequada para representar: Uma MEF é adequada para representar: Sistemas com num número finito de estados, e Sistemas com num número finito de estados, e Transições entre estados como consequência de um evento Transições entre estados como consequência de um evento Anos de experiência com as MEF !!! Anos de experiência com as MEF !!! Exemplos: Exemplos: Relógios Relógios Calculadoras Calculadoras Máquinas ATM Máquinas ATM Por vezes o manual de utilização têm diagramas de MEF Por vezes o manual de utilização têm diagramas de MEF

29 Engenharia de Software28 Máquinas de Estado Finitas Estados Estados Distinção entre estado iniciais e/ou finais Distinção entre estado iniciais e/ou finais Transição entre estados é accionada por eventos: Transição entre estados é accionada por eventos: Tais como pressionar o botão de uma calculadora Tais como pressionar o botão de uma calculadora Ou de um relógio Ou de um relógio Ou uma item de um menu numa GUI Ou uma item de um menu numa GUI

30 Engenharia de Software29 Máquinas de Estado Finitas Definição formal: Definição formal: M = {Q,I, }, onde M = {Q,I, }, onde Q é um conjunto finito de estados Q é um conjunto finito de estados I é um conjunto finito de entradas I é um conjunto finito de entradas é uma função de transição : Q x I -> Q é uma função de transição : Q x I -> Q A função pode ser uma função parcial (i.e. indefinida para certos valores do seu domínio) A função pode ser uma função parcial (i.e. indefinida para certos valores do seu domínio)

31 Engenharia de Software30 Máquinas de Estado Finitas Representação gráfica Representação gráfica Os nós (círculos) representam estados Os nós (círculos) representam estados Os arcos são dirigidos e possuem uma etiqueta (label) que pertence ao conjunto I Os arcos são dirigidos e possuem uma etiqueta (label) que pertence ao conjunto I Um arco com uma etiqueta i vai do estado q1 para q2 se e só se (q1,i) = q2 Um arco com uma etiqueta i vai do estado q1 para q2 se e só se (q1,i) = q2

32 Engenharia de Software31 Exemplo I q0q0 q1q1 q3q3 q2q2 aa bc b

33 Engenharia de Software32 Exemplo II

34 Engenharia de Software33 Máquinas de Estado Finitas Modelo de execução Modelo de execução A MEF está sempre em algum estado A MEF está sempre em algum estado A entrada obriga a mudanças de estado de acordo com A entrada obriga a mudanças de estado de acordo com Extensões comuns: Extensões comuns: Estados iniciais e estados de paragem Estados iniciais e estados de paragem A saída é gerada quando existe uma transição entre estados A saída é gerada quando existe uma transição entre estados : Q x I -> Q x O : Q x I -> Q x O

35 Engenharia de Software34 Exemplo III

36 Engenharia de Software35 Geração de Linguagens Seja E = {a,b} um conjunto de eventos. Considere a linguagem: Seja E = {a,b} um conjunto de eventos. Considere a linguagem: L = {a,aa,ba,aaa,aba,baa,bba,...} L = {a,aa,ba,aaa,aba,baa,bba,...} i.e. Todas as strings de a e b seguidas de a. i.e. Todas as strings de a e b seguidas de a. 0 1 b a a b

37 Engenharia de Software36 MEF equivalentes 0 1 b a ab 0 1 b a a 0 1 b a 2 a a 0 1 b a n a … a n+1 a a b b b

38 Engenharia de Software37 Blocking and Livelock Estado 5 é uma deadlock Estado 5 é uma deadlock Estados 3 e 4 uma livelock Estados 3 e 4 uma livelock

39 Engenharia de Software38 Vantagens do modelo MEF Simples de entender e mais precisa que outras abordagens semi-formais: Simples de entender e mais precisa que outras abordagens semi-formais: Um menu de um GUI é uma MEF Um menu de um GUI é uma MEF Representação gráfica evidente e clara Representação gráfica evidente e clara É fácil construir ferramentas de suporte É fácil construir ferramentas de suporte Transformadores: Transformadores: Transformam o modelo MEF em outras representações, e.g. código C++ Transformam o modelo MEF em outras representações, e.g. código C++ Análise e Validação: Análise e Validação: Esta MEF irá correr para sempre ? Quando é que irá parar ? Deadlock ? Esta MEF irá correr para sempre ? Quando é que irá parar ? Deadlock ?

40 Engenharia de Software39 Limitações das MEF Limite teórico no poder computacional Limite teórico no poder computacional A MEF não possui memória A MEF não possui memória A utilização de estados como memória é ineficiente: A utilização de estados como memória é ineficiente: Considere modelar um sistema de navegação com estados que modelam a velocidade: Considere modelar um sistema de navegação com estados que modelam a velocidade: Registo de 8 bits = 256 estados Registo de 8 bits = 256 estados Explosão de estados na combinação de vários módulos: Explosão de estados na combinação de vários módulos: Os estados são multiplicativos Os estados são multiplicativos Inerentemente síncrona: Inerentemente síncrona: Em cada instante, o estado global do sistema tem de estar definido e apenas pode ocorrer uma transição de cada vez Em cada instante, o estado global do sistema tem de estar definido e apenas pode ocorrer uma transição de cada vez

41 Redes de Petri

42 Engenharia de Software41 Introdução Introduzidas por Carl Adam Petri em 1962 Introduzidas por Carl Adam Petri em 1962 Ferramenta de diagramas para modelar concorrência e sincronização em sistemas distribuídos Ferramenta de diagramas para modelar concorrência e sincronização em sistemas distribuídos Baseada numa fundação matemática muito forte Baseada numa fundação matemática muito forte

43 Engenharia de Software42 Uma especificação de Redes Petri Consiste em três tipos de componentes: lugares (círculos), transições (rectângulos ou barras) e arcos (setas): Consiste em três tipos de componentes: lugares (círculos), transições (rectângulos ou barras) e arcos (setas): Os lugares representam os estados possíveis do sistema Os lugares representam os estados possíveis do sistema As transições são eventos ou acções que causam a mudança de estado As transições são eventos ou acções que causam a mudança de estado Cada arco liga um lugar com uma transição ou uma transição com um lugar Cada arco liga um lugar com uma transição ou uma transição com um lugar

44 Engenharia de Software43 Exemplo de Rede de Petri

45 Engenharia de Software44 Exemplo: Sistema de Segurança Initial 1 digit d1d2d3 d4 OK pressed approve approved OK Reject Rejected!

46 Engenharia de Software45 Mudança de estado Ocorre quando existe um movimento de token(s) (pontos pretos) de lugar em lugar e é causado pelo disparo de uma transição Ocorre quando existe um movimento de token(s) (pontos pretos) de lugar em lugar e é causado pelo disparo de uma transição O disparo representa a ocorrência de um evento ou uma acção tomada O disparo representa a ocorrência de um evento ou uma acção tomada O disparo é sujeito às condições de entrada, i.e. pela disponibilidade de tokens(s) O disparo é sujeito às condições de entrada, i.e. pela disponibilidade de tokens(s)

47 Engenharia de Software46 Mudança de estado Uma transição está activa quando existem tokens suficientes nas suas entradas Uma transição está activa quando existem tokens suficientes nas suas entradas Depois do disparo, os tokens irão ser transferidos dos lugares de entrada (estado anterior) para os lugares de saída (novo estado) Depois do disparo, os tokens irão ser transferidos dos lugares de entrada (estado anterior) para os lugares de saída (novo estado) Quando uma transição está activa a rede pode evoluir de formas diferentes: Quando uma transição está activa a rede pode evoluir de formas diferentes: O modelo é não determinístico O modelo é não determinístico Mesmo estado inicial – vários estados finais possíveis Mesmo estado inicial – vários estados finais possíveis Salienta-se que o exemplo anterior é uma rede de Petri de uma MEF Salienta-se que o exemplo anterior é uma rede de Petri de uma MEF

48 Engenharia de Software47 Exemplo: Sistema de Segurança Cenário 1: NormalCenário 1: Normal Introduz os 4 dígitos e pressiona em OK. Introduz os 4 dígitos e pressiona em OK. Cenário 2: ExcepcionalCenário 2: Excepcional Introduz apenas 3 dígitos e pressiona em OK. Introduz apenas 3 dígitos e pressiona em OK.

49 Engenharia de Software48 Exemplo: Sistema de Segurança Initial 1 digit d1d2d3 d4 OK pressed approve approved OK Reject Rejected!

50 Engenharia de Software49 Múltiplos estados locais No mundo real, existem eventos que acontecem ao mesmo tempo No mundo real, existem eventos que acontecem ao mesmo tempo Um sistema pode ter muitos estados locais para obter um estado global Um sistema pode ter muitos estados locais para obter um estado global Existe uma necessidade de modelar concorrência e sincronização Existe uma necessidade de modelar concorrência e sincronização

51 Engenharia de Software50 Estruturas da rede Uma sequência de eventos/acções: Uma sequência de eventos/acções: Execuções concorrentes: Execuções concorrentes: e1 e2e3 e1 e2 e3 e4 e5

52 Engenharia de Software51 Estruturas de rede Eventos não determínisticos - conflito, escolha ou decisão : A escolha de e1, e2 … ou e3, e4... Eventos não determínisticos - conflito, escolha ou decisão : A escolha de e1, e2 … ou e3, e4... e1e2 e3e4

53 Engenharia de Software52 Estrutura da rede Sincronização Sincronização e1

54 Engenharia de Software53 Estruturas de Rede Sincronização e Concorrência Sincronização e Concorrência e1

55 Engenharia de Software54 Exemplo: Obtenção de um recurso Estado Inicial T1 dispara T2 dispara Modelo não deterministico Tanto t3 como t4 podem disparar Modelo concorrente. O disparo de t1 não impede t2 de disparar

56 Engenharia de Software55 Exemplo: Obtenção de um recurso Estado Inicial T1 e T2 dispara T3 dispara T5 dispara Não está definida uma política de resolução de conflitos Pode ocorrer starvation

57 Formalizando...

58 Engenharia de Software57 Definição de Rede de Petri Def.: Uma Rede de Petri (grafo ou estrutura) é um grafo pesado bipartido (P,T,A,w), onde: P={p 1, p 2,... p n } é o conjunto finito de lugares (places) T ={t 1, t 2,... t m } é o conjunto finito de transições (transitions) é o conjunto de arcos de lugares para transições (p i,t j ) e transições para lugares (t j,p i ) é a função de pesos associados aos arcos Conjunto de lugares de entrada de Conjunto de lugares de saída de

59 Engenharia de Software58 Exemplo de Rede de Petri p1p1 p2p2 p3p3 p4p4 t1t1 t2t2 t3t3

60 Engenharia de Software59 Marcações, Dinâmica e Espaço de Estados Def.: Uma Rede de Petri marcada é um 5-túpulo (P,T,A,w,x), em que (P,T,A,w) é um grafo de Rede de Petri e x é uma marcação do conjunto de lugares P; é o vector linha associado a x. Def. (Dinâmica de RdP): A função de transição de estado, da rede de Petri (P,T,A,w,x), está definida para a transição sse Se f(x,t j ) estiver definida, o novo estado é dado por x = f(x,t j ), onde t j Permitida (Enabled)

61 Engenharia de Software60 p1p1 p2p2 p3p3 p4p4 t1t1 t2t2 t3t3 Marcações, Dinâmica e Espaço de Estados

62 Engenharia de Software61 p1p1 p2p2 p3p3 p4p4 t1t1 t2t2 t3t3 Marcações, Dinâmica e Espaço de Estados

63 Engenharia de Software62 p1p1 p2p2 p3p3 p4p4 t1t1 t2t2 t3t3 Marcações, Dinâmica e Espaço de Estados

64 Engenharia de Software63 p1p1 p2p2 p3p3 p4p4 t1t1 t2t2 t3t3 Marcações, Dinâmica e Espaço de Estados

65 Engenharia de Software64 p1p1 p2p2 p3p3 p4p4 t1t1 t2t2 t3t3 Marcações, Dinâmica e Espaço de Estados

66 Engenharia de Software65 Caracteristicas das Petri Nets Petri Nets servem para modelar o comportamento de um sistema durante o desenvolvimento do SW Petri Nets servem para modelar o comportamento de um sistema durante o desenvolvimento do SW Petri Nets modelam MEF Petri Nets modelam MEF Modelam um estado global e muitos estado locais no mundo real Modelam um estado global e muitos estado locais no mundo real Uma rede de Petri permite múltiplos cenários Uma rede de Petri permite múltiplos cenários Diferentes tokens para diferentes cenários Diferentes tokens para diferentes cenários Redes de Petri : Sequência, Escolha, Sincronização e Concorrência Redes de Petri : Sequência, Escolha, Sincronização e Concorrência Mais expressivas que as MEF Mais expressivas que as MEF

67 Engenharia de Software66 Comportamento Estados alcançáveisEstados alcançáveis Pode-se alcançar um estado particular a partir de outro? Pode-se alcançar um estado particular a partir de outro? Limite de armazenamentoLimite de armazenamento Irá haver overflows num círculo ? Irá haver overflows num círculo ? Deadlocks ?Deadlocks ? Irá o sistema morrer num estado particular ? Irá o sistema morrer num estado particular ?

68 Engenharia de Software67 Limite Diz-se que uma rede de Petri possui um limite em k ou é simplesmente limitada se o número de tokens em cada lugar não excede um número finito k para qualquer estado a partir de M0 Diz-se que uma rede de Petri possui um limite em k ou é simplesmente limitada se o número de tokens em cada lugar não excede um número finito k para qualquer estado a partir de M0 A rede de Petri para a máquina de vendas possui um limite em 1 A rede de Petri para a máquina de vendas possui um limite em 1 A rede de Petri net diz-se segura (safe) A rede de Petri net diz-se segura (safe)

69 Engenharia de Software68 Bloqueio Uma rede de Petri pode entrar num estado de bloqueio (deadlock) quando não é possível disparar nenhuma transição Uma rede de Petri pode entrar num estado de bloqueio (deadlock) quando não é possível disparar nenhuma transição Uma rede de Petri em que não é possível haver bloqueios diz-se viva Uma rede de Petri em que não é possível haver bloqueios diz-se viva É possível analisar a existência de estados de bloqueio no sistema através da análise manual da rede de Petri que modela o sistema É possível analisar a existência de estados de bloqueio no sistema através da análise manual da rede de Petri que modela o sistema

70 Engenharia de Software69 Deadlocks ? A máquina de vendas e o sistema produtor- consumidor não possuem deadlocks A máquina de vendas e o sistema produtor- consumidor não possuem deadlocks Uma transição está morta se não pode ser disparada por qualquer sequência de disparo Uma transição está morta se não pode ser disparada por qualquer sequência de disparo Outra definição: Uma rede de Petri com um marcas iniciais M0 não possui deadlocks se, para qualquer situação alcançada a partir de M0, é possível disparar uma transição através de uma sequência de disparo Outra definição: Uma rede de Petri com um marcas iniciais M0 não possui deadlocks se, para qualquer situação alcançada a partir de M0, é possível disparar uma transição através de uma sequência de disparo

71 Engenharia de Software70 Bloqueio

72 Engenharia de Software71 Um exemplo A bounded but non-live Petri net p1 p2 p3 p4 t1 t2 t3t4 M0 = (1,0,0,1) M1 = (0,1,0,1) M2 = (0,0,1,0) M3 = (0,0,0,1)

73 Engenharia de Software72 Outro exemplo p1 t1 p2p3 t2t3 p4 p5 t4 An unbounded but live Petri net M0 = (1, 0, 0, 0, 0) M1 = (0, 1, 1, 0, 0) M2 = (0, 0, 0, 1, 1) M3 = (1, 1, 0, 0, 0) M4 = (0, 2, 1, 0, 0)

74 Engenharia de Software73 Métodos de Análise Análise de alcançabilidade:Análise de alcançabilidade: Árvore de cobertura Árvore de cobertura Problema na explosão de estados Problema na explosão de estados Matriz de Incidência e Equações de estadoMatriz de Incidência e Equações de estado Análise estruturalAnálise estrutural Baseado em estruturas de rede Baseado em estruturas de rede

75 Engenharia de Software74 Limitações das Redes de Petri Marcas anónimas => não é possível a tomada de decisões (de selecção) com base no conteúdo nem a modificação do conteúdo Marcas anónimas => não é possível a tomada de decisões (de selecção) com base no conteúdo nem a modificação do conteúdo Não existe o conceito de tempo de uma forma explicita: Não existe o conceito de tempo de uma forma explicita: Limita a sua utilização em sistemas de tempo real Limita a sua utilização em sistemas de tempo real


Carregar ppt "Metodos de Especificação de Software 1ª Parte Patrícia Macedo Joaquim Filipe João Ascenso Engenharia de Software 2004/2005 EST, Setúbal."

Apresentações semelhantes


Anúncios Google