1 / 74

Metodos de Especificação de Software 1ª Parte

Metodos de Especificação de Software 1ª Parte. Patrícia Macedo Joaquim Filipe João Ascenso Engenharia de Software 2004/2005 EST, Setúbal. Indice Geral. 1ª Parte Especificação de Software DFD’s Maquinas de estados Petri Nets 2ª Parte UML 3ª Parte Exemplos. Motivação.

marlie
Download Presentation

Metodos de Especificação de Software 1ª Parte

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Indice Geral 1ª Parte • Especificação de Software • DFD’s • Maquinas de estados • Petri Nets 2ª Parte • UML 3ª Parte • Exemplos Engenharia de Software

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

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

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

  6. Para que servem as especificações • Indicar 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 • Tentar obter uma especificação clara e precisa • Evitar ambiguidades e diferentes interpretações entre o utilizador e o programador • VERIFICAR as especificações • As especificações podem ser construídas de uma forma muito clara e precisa • e.g. métodos formais Engenharia de Software

  7. Para que servem as especificações • Indicação dos requisitos para a implementação • Ponto de referência durante a implementação • Especificação define o comportamento: • Interno – Especificação de desenho • Externo – Especificação 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 requisitos  utilizadores Engenharia de Software

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

  9. Estilos de Especificação • Critério 1: especificações formais vs. especificações informais • Formais: A notação utilizada possui uma sintaxe e uma semântica totalmente precisa • Informal: Escritas em linguagem natural • As linguagens TDN e GDN são semi-formais. Porquê? • 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 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: ax2 + by2 + c = 0 Engenharia de Software

  10. Especificações Informais • Escritas em linguagem natural • Fáceis de serem entendidas pelo cliente • Mais susceptíveis de possuírem: • 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 • Conclusão: Não é uma boa forma de especificar um sistema complexo • 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 • No entanto, o panorama está a mudar. Engenharia de Software

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

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

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

  14. 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. Engenharia de Software

  15. 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. Engenharia de Software

  16. 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 Engenharia de Software

  17. Especificações Operacionais • Notações para indicação de especificações em estilo operacional: • 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 • Máquinas de Estados Finitas - Finite State Machines • Especificação de estruturas de controlo • Redes de Petri – Petri Nets • Especificação de sistemas assíncronos, em termos de lugares e transições entre lugares Engenharia de Software

  18. Data Flow Diagrams (DFDs)

  19. DFDs • 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 • Os dados podem ser organizados de várias formas: • Repositórios de dados • Transferências de dados • Entradas/saídas Engenharia de Software

  20. DFDs • Notação gráfica: • Nós (“bubble”): representam funções. • Setas: representam fluxos 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. Função Dispositivo de entrada Dispositivo de saída Repositório De Dados Fluxo de Dados Engenharia de Software

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

  22. Outro Exemplo: Biblioteca Livro Título e Autor do livro pedido; Nome do utilizador Obter um livro Autor Livro Recepção do Livro Título Titulo; utilizador Título Procurar por Tópico Tópico Tópico Lista de Títulos Referentes ao Tópico Lista de Títulos Engenharia de Software

  23. 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: • No entanto falta-lhes uma semântica precisa • Requerem uma interpretação intuitiva • Notação semi-formal • O controlo não é definido por este modelo: • Um nó ("bubble") utiliza todas as suas entradas ? • Espera por todas ou por um determinado número ? • Repete os cálculos quando as entradas são constantes ? Engenharia de Software

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

  25. Máquinas de estado finitas

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

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

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

  29. Máquinas de Estado Finitas • Definição formal: • M = {Q,I,}, onde • Q é um conjunto finito de estados • I é um conjunto finito de entradas •  é 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) Engenharia de Software

  30. Máquinas de Estado Finitas • Representação gráfica • Os nós (círculos) representam estados • 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 Engenharia de Software

  31. Exemplo I q1 a a q0 q2 b c b q3 Engenharia de Software

  32. Exemplo II Engenharia de Software

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

  34. Exemplo III Engenharia de Software

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

  36. MEF equivalentes b a a a a 1 1 0 0 b b a a a 2 1 0 b b a … a a a a n n+1 1 0 b b b Engenharia de Software

  37. Blocking and Livelock • Estado 5 é uma deadlock • Estados 3 e 4 uma livelock Engenharia de Software

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

  39. Limitações das MEF • Limite teórico no poder computacional • A MEF não possui memória • A utilização de estados como memória é ineficiente: • Considere modelar um sistema de navegação com estados que modelam a velocidade: • Registo de 8 bits = 256 estados • Explosão de estados na combinação de vários módulos: • Os estados são multiplicativos • 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 Engenharia de Software

  40. Redes de Petri

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

  42. 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): • 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 • Cada arco liga um lugar com uma transição ou uma transição com um lugar Engenharia de Software

  43. Exemplo de Rede de Petri Engenharia de Software

  44. 1 digit 1 digit 1 digit 1 digit d4 Initial d1 d2 d3 OK OK OK OK OK OK pressed Rejected! approve Reject approved Exemplo: Sistema de Segurança Engenharia de Software

  45. 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 • 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) Engenharia de Software

  46. Mudança de estado • 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) • Quando uma transição está activa a rede pode evoluir de formas diferentes: • O modelo é não determinístico • Mesmo estado inicial – vários estados finais possíveis • Salienta-se que o exemplo anterior é uma rede de Petri de uma MEF Engenharia de Software

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

  48. 1 digit 1 digit 1 digit 1 digit d4 Initial d1 d2 d3 OK OK OK OK OK OK pressed Rejected! approve Reject approved Exemplo: Sistema de Segurança Engenharia de Software

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

  50. e2 e3 e1 e3 e2 e1 e5 e4 Estruturas da rede • Uma sequência de eventos/acções: • Execuções concorrentes: Engenharia de Software

More Related