Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr.

1. Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr. 03 - Modelos para especificação de sistemas de software Universidade Federal do Paraná Setor de Ciências ExatasDepartamento de InformáticaESPECIALIZAÇÃO EM INFORMÁTICA 03 - Modelos para especificação

2. 1. Considerações iniciais 1.1. Especificação 1.1.1. Tipos 1.1.2. Estágios 1.1.3. Verificação e validação 1.1.4. Qualidade x grau de formalidade 2. Modelos e princípios da E. S. 2.1. Um exemplo Conteúdos 03 - Modelos para especificação

3. 3. Modelos do mundo real 3.1. O modelo de função 3.2. O modelo de dados 3.3. O modelo comportamental 3.4. O modelo de objetos 3.5. O modelo formal 3.6. O modelo dinâmico 3.7. Dicionário de dados Conteúdos (cont.) 03 - Modelos para especificação

4. 4. Modelos de projeto 4.1. Modelos para projeto geral 4.2. Modelos para projeto detalhado 5. Modelos para teste de programas 6. Modelos de planejamento do projeto 6.1. Modelos de custo 6.2. Modelos de programação de projetos Conteúdos (cont.) 03 - Modelos para especificação

5. 7. Metodologias, métodos e ferramentas 7.1. Métodos estruturados 7.2. Métodos orientados a objetos 7.3. Métodos formais 8. Comentários finais 9. Exercícios Conteúdos (cont.) 03 - Modelos para especificação

6. “Um modelo de sistema de software é uma representação em miniatura de uma realidade complexa, que reflete certas características específicas do sistema que está sendo representado.” (CARVALHO; CHIOSSI, 2001) Modelos Ferramentas úteis para representar especificações Especificação - dois estágios / processos Construção de modelos Transmissão de mensagens entre grupos 1. Considerações iniciais 03 - Modelos para especificação

7. Objetivos do uso de modelos na especificação das diferentes fases do desenvolvimento Representar visão do ambiente antes da automação Indicar diferentes alternativas de solução Apontar necessidades futuras Permitir avaliação / refinamento de características Representar componentes como partes bem definidas e com dependência mínima entre elas Permitir o trabalho gradual com a complexidade Fornecer informações quantitativas sobre escopo / complexidade de um projeto 1. Considerações iniciais (cont.) 03 - Modelos para especificação

8. Desenvolver sistemas = obter e organizar dados Volume  (dimensão + complexidade) Princípios auxiliadores Abstração - filtro dos aspectos relevantes a cada fase Decomposição Reflexo das propriedades do sistema em suas partes Paradigmas: decomposição em fases / associação de tarefas 1.1. Especificação 03 - Modelos para especificação

9. Especificação Duas classes gerais de atores: produtor e consumidor Atores e objetivos da especificação variáveis = f(contexto) Especificação ... ... de requisitos: desenvolvedor + cliente ... de projeto geral: projetista + implementador ... de projeto detalhado (de módulos): programadores implementadores + programadores usuários => propósito: criar ponte de comunicação entre os diversos tipos de pessoas envolvidas 1.1. Especificação 03 - Modelos para especificação

10. Considerado o enfoque dado aos atributos do sistema Especificação operacional Representa o comportamento desejado do sistema utilizando modelos abstratos que, de alguma forma, simulem seu comportamento Auxilia na verificação direta dos requisitos Especificação descritiva Busca declarar as propriedades desejadas do sistema de forma puramente descritiva Representa as propriedades de maneira formal Exemplo: trajetória de um satélite Especificação operacional: desenho de uma circunferência Especificação descritiva: x2 + y2 + c = 0 1.1.1. Tipos de especificação 03 - Modelos para especificação

11. Após a fase inicial de extração e análise de requisitos Contrato entre cliente e desenvolvedor Documento: Declaração de objetivos e restrições do projeto (DORP) Antecede o Plano preliminar de projeto (detalhes adiante) 1o. Estágio: Especificação de requisitos Com base nos objetivos da DORP Descrição precisa e não ambígua do comportamento desejado para o sistema (o que é esperado?) Com base nas restrições da DORP Delimitações do sistema especificadas como propriedades 1.1.2. Estágios da especificação 03 - Modelos para especificação

12. 2o. Estágio: Especificação de projeto Características operacionais Estrutura do sistema => Como o sistema deve ser implementado Mais detalhes que a E. R. Dados, ações, controle e execução Passos Especificação do projeto geral (÷ sistema em subsistemas, definir relações entre eles, ÷ subsistemas em módulos) Especificação do projeto detalhado (lógica dos módulos) Especificação das interfaces do sistema 1.1.2. Estágios da especificação (cont.) 03 - Modelos para especificação

13. 3o. Estágio: Especificação de programas Deve garantir a correta tradução das decisões de projeto Decisões inclusas: escolha de algoritmos Outros estágios Garantem a qualidade Permitem o acompanhamento e controle do projeto Exemplos Especificação de planos para o projeto Especificação de testes 1.1.2. Estágios da especificação (cont.) 03 - Modelos para especificação

14. F(natureza das especificações) Várias possibilidades de haver erros Provável não traduzirem exatamente as necessidades => Todas devem ser verificadas Pode ser necessário Modificar especificações existentes Incluir novas especificações Podem ser utilizadas técnicas diferentes para a validação em cada estágio 1.1.3. Verificação e validação 03 - Modelos para especificação

15. Durante o desenvolvimento Várias especificações Cada uma em uma fase Cada uma com um determinado fim Dirigida a públicos diferentes Projetista, implementador, usuário final, gerente, etc. => Propósitos diferentes Especificação de requisitos: auxiliar usuário a entender suas necessidades / validar produto final / tomar decisões de projeto e conferir implementação (desenvolvedor) Especificação de projeto: avaliar impactos de modificações / controlar e redirecionar recursos (gerente) 1.1.4. Qualidade x grau de formalidade 03 - Modelos para especificação

16. Fatores que influenciam a qualidade das especificações Ambigüidade Consistência Omissão Fatores dependem do grau de formalidade F(criticidade de propriedades / componentes) Formalismos muitas vezes são evitados F(consumo de tempo, custo, dificuldade de comunicação, falta de domínio de métodos formais, necessidade de treinamento, etc.) 1.1.4. Qualidade x grau de formal. (cont.) 03 - Modelos para especificação

17. Especificações devem seguir os princípios Abstração: concentração nos aspectos importantes, sem ater-se a detalhes não relevantes Conceito geral dos modelos: top-down Decomposição: divisão de problemas complexos em menores, independentes, fáceis de entender e solucionar; representação das relações entre partes Técnicas descendentes / ascendentes; hierarquias de programas / classes de objetos; modelagem em rede Formalidade: modelos formais / semiformais permitem Instituir controles para o desenvolvimento / qualidade Comunicação mais eficiente Representação precisa de interfaces entre estágios 2. Modelos e princípios da E. S. 03 - Modelos para especificação

18. => Modelos Devem permitir alcance dos princípios Boa prática para sistemas complexos Modelo do mundo real (para E. R.) Modelo de dados Modelo de função Modelo de comportamento do sistema Modelo do projeto (para especificação do projeto) Modelo do plano de projeto (planejamento do desenvolvimento) 2. Modelos e princípios da E. S. (cont.) 03 - Modelos para especificação

19. Caso exemplo para especificação com modelos Subsistema de consulta a bibliotecas de uma universidade Entrada: título e/ou autor (título, autor) informado: pertencente ao acervo? Sim: verificar a disponibilidade de exemplares / fornecer localização Não: informar que (título, autor) não pertence ao acervo título informado Listar ocorrências do título no acervo (títulos iguais com autores diferentes) autor informado Listar todos os títulos daquele autor pertencentes ao acervo 2.1. Um exemplo 03 - Modelos para especificação

20. 03 - Modelos para especificação 3. Modelos do mundo real Utilizados para representar sistemas Representação da especificação de requisitos Descrição da percepção do sistema a ser construído Foco em 3 características diferentes O que o sistema faz Que dados o sistema mantém Como o sistema se comporta Ilustração 

21. 03 - Modelos para especificação 3. Modelos do mundo real (cont.) Sistema de consulta a bibliotecas: Percepções do mundo real

22. 03 - Modelos para especificação 3.1. O modelo de função Entende o sistema todo como uma função Transformador de entradas em saídas Diagrama de contexto (YOURDON, 1990): relacionamento do sistema com interfaces externas Entrada Saída Interface SISTEMA Interface Modelo de contexto do sistema

23. 03 - Modelos para especificação 3.1. O modelo de função (cont.) Decompõe o sistema identificando como componentes suas principais funções A função do sistema todo fica constituída por um conjunto de subfunções conectadas Cada subfunção é possivelmente formada por outras subfunções conectadas ... Modelo funcional do sistema Série de desenhos (rede) Sucessivas divisões das partes que constituem o sistema

24. 03 - Modelos para especificação 3.1. O modelo de função (cont.) Sistema Função 2 Conexão Conexão Entrada Saída Interface Interface Função 1 Função 4 Conexão Conexão Função 3 Modelo funcional: Decomposição

25. 03 - Modelos para especificação 3.1. O modelo de função (cont.) O modelo de função pode ser considerado completo quando Descreve todo o sistema Mostra as transformações de todas as entradas em saídas Decompõe convenientemente o sistema Todos os componentes não particionados são elementares Cada componente do sistema está ligado corretamente ao resto da rede Nenhuma conexão necessária foi omitida As conexões estão minimizadas Cada conexão da rede está definida no dicionário de dados Todos os elementos que compõem cada conexão estão definidos

26. 03 - Modelos para especificação 3.1. O modelo de função (cont.) Diagramas de fluxo de dados – DFD (DEMARCO, 1979) Especificação semiformal de funcionalidades Notação gráfica atrativa e fácil de usar Descrevem um sistema como uma coleção de dados manipulados por funções Dados podem estar Armazenados em depósitos de dados (estáticos) Contidos em fluxos de dados (conexões) (dinâmicos) Fluindo de uma função para outra Sendo transferidos para / do ambiente externo

27. 03 - Modelos para especificação 3.1. O modelo de função (cont.) DFD – Elementos básicos Bolhas / cilindros: processos (funções) Transformadores(as) dos fluxos de dados Setas: fluxos de dados (conexões) Meios por onde trafegam pacotes de dados Caixas abertas: depósitos de dados Armazenam dados entre processos Caixas retangulares: entidades externas Origem ou destino de transações (/ dados associados) do sistema

28. 03 - Modelos para especificação 3.1. O modelo de função (cont.) DFD – Exemplo MR Exemplares MR Disponibilidade Títulos e Autores Verifica(r) disponibi-lidade Exemplar disponível ! Localiza(r) exemplar Informações do acervo ! Verifica(r)acervo Mensagem 2 MR Bibliotecas Nome da biblioteca Título, Autor ! = dados de ... Mensagem 1: Título e/ou autor não pertence(m) ao acervo Mensagem 1 Usuário Lista Título-Autor Mensagem 2: Exemplar pertencente ao acervo mas não disponível

29. 03 - Modelos para especificação 3.1. O modelo de função (cont.) DFD – Limitações É necessária alguma experiência com o sistema para poder deduzir certas informações a partir da figura O diagrama não especifica claramente como as entradas são usadas para produzir as saídas Sincronização de componentes não representada É necessário o uso de um dicionário de dados para a inclusão dos detalhes não representados

30. 03 - Modelos para especificação 3.1. O modelo de função (cont.) DFD – Considerações finais O desenho pode ser feito com o auxílio de ferramenta automatizada Entradas de dicionário de dados são geradas automaticamente Cabe ao desenvolvedor completar as entradas com os detalhes não especificados

31. 03 - Modelos para especificação 3.2. O modelo de dados Deve representar Os dados que precisam ser armazenados A melhor organização dos dados O relacionamento entre grupos de dados Como os dados serão utilizados “É uma representação concisa dos requisitos do sistema sob o ponto de vista de dados”. (ELMASRI; NAVATHE, 1994)

32. 03 - Modelos para especificação 3.2. O modelo de dados (cont.) Dados armazenados Descrevem “coisas” do mundo real Possibilitam o atendimento dos requisitos Relação entre dados dentro do sistema e pessoas ou coisas fora do sistema Gera uma espécie de mapa... Pista de como se deve organizar os dados Perseguir esta pista significa agrupar itens associados à mesma entidade do mundo real

33. 03 - Modelos para especificação 3.2. O modelo de dados (cont.) Ilustração MUNDO REAL DENTRO DO SISTEMA Entidade Propriedade Relacionamento Cliente: nome endereço cic Cliente Alugar Carro: marca cor nº chassis Carro Abstração de dados

34. 03 - Modelos para especificação 3.2. O modelo de dados (cont.) Abstração da entidade Cliente Propriedades nome, endereço e cic dentro do sistema Boa desde que as informações sejam necessárias e suficientes para representar um cliente Relacionamento entre entidades Representa uma associação essencial ao sistema Relacionamento “Alugar” Associação entre as entidades “Cliente” e “Carro”

35. 03 - Modelos para especificação 3.2. O modelo de dados (cont.) Modelo entidade-relacionamento – MER (ELMASRI; NAVATHE, 1994) Modelo para a especificação dos dados armazenados pelo sistema Conceitos Entidades Atributos Relacionamentos Ferramenta gráfica Diagrama entidade-relacionamento – DER

36. 03 - Modelos para especificação 3.2. O modelo de dados (cont.) Diagrama entidade-relacionamento – DER: notações Retângulos: entidades sobre as quais o sistema mantém dados Elipses: atributos (propriedades) das entidades Losangos: relacionamentos entre entidades Linhas: conexões das entidades com atributos e/ou relacionamentos

37. 03 - Modelos para especificação 3.2. O modelo de dados (cont.) DER: exemplo 1 m Cliente Alugar Carro nome endereço cic marca cor nº chassis

38. 03 - Modelos para especificação 3.2. O modelo de dados (cont.) DER exemplo representa Duas entidades: Cliente e Carro Cliente aluga carro Carro é alugado por cliente Modelo entidade-relacionamento Faz especificação descritiva! Apresenta Propriedades (atributos) das entidades Relacionamentos com outras entidades Ainda outras características do mundo real Participação Cardinalidade

39. 03 - Modelos para especificação 3.2. O modelo de dados (cont.) Participação (de entidades) em relacionamentos Parcial Nem todos os elementos da entidade participam Notação: linha simples ligando a entidade ao relacionamento Ex.: participação de carro no relacionamento alugar (alguns carros podem não estar associados a clientes) Total Ex.: Cliente no relacionamento alugar (não interessa ao sistema clientes que não aluguem carro)

40. 03 - Modelos para especificação 3.2. O modelo de dados (cont.) Cardinalidade de um relacionamento Quantidade de instâncias de uma entidade que se relacionam com instâncias de outra entidade Relacionamentos Um para um (1:1) Um para muitos (1:m) Muitos para muitos (m:n) Ex.: Relacionamento alugar Um para muitos Significado Um cliente pode alugar vários carros (ex.: empresas) Cada carro pode estar alugado a apenas um cliente

41. 03 - Modelos para especificação 3.2. O modelo de dados (cont.) Limitações Algumas características do mundo real (propriedades de entidades) não podem ser representadas Ex.: formação do cic => notação semiformal Sintaxe / semântica não precisas Necessidade Comentários informais para completar o modelo e/ou Utilização de um dicionário de dados para detalhar o modelo

42. 03 - Modelos para especificação 3.2. O modelo de dados (cont.) DER subsistema de consulta a bibliotecas nº item 1 m Biblioteca Conter Exemplar n estado nome código local Possuir Observações: 1) Entidade usuário não modelada: sem interesse 2) Estado (exemplar): disponível, emprestado, reservado para disciplina 3) Relacionamentos permitem verificar existência, disponibilidade e localização de um título título autor 1 editora Acervo data de publicação edição área

43. 03 - Modelos para especificação 3.3. O modelo comportamental Sistemas Tendem a assumir vários estados Cada estado se caracteriza por responder de forma única a um determinado conjunto de estímulos Análise de estados de um sistema exige enumerar Possíveis estados Eventos: condições e/ou ações que causam mudança de estado

44. 03 - Modelos para especificação 3.3. O modelo comportamental (cont.) Modelo de comportamento do sistema representa Estados Eventos que alteram os estados Condições e ações para mudanças de estados Se a condição para a ocorrência de um evento for verdadeira, a ação correspondente será ativada Ao longo da realização de determinada ação, o estado do componente do sistema sendo alterado não é observável Completada a ação, o componente passa ao estado determinado pelo evento correspondente

45. 03 - Modelos para especificação 3.3. O modelo comportamental (cont.) Máquina de estados finitos – MEF (ALAGAR; PERIYASAMI, 1998) Inclui conceitos Estados Cadeias de dados de entrada (eventos) Ferramenta gráfica para especificações semiformais Utiliza um grafo para representar o comportamento do sistema Sistema descrito como Conjunto de estados que se alternam Em conseqüência de algum evento modelado por dados de entrada

46. 03 - Modelos para especificação 3.3. O modelo comportamental (cont.) Máquina de estados finitos – MEF: notações Elipses: estados Setas: eventos que causam mudanças de estados Podem ser rotuladas para representar Condições sobre eventos que ocasionam mudanças de estados e/ou Ações realizadas nas mudanças de estados

47. 03 - Modelos para especificação 3.3. O modelo comportamental (cont.) MEF: exemplo Estado inicial: disparado por um evento que não tem origem em outro estado Estado 1 Ação 1 (condição 1) Evento 1 Estado 2 Ação 2 (condição 2) Evento 2 Estado 3 Ação 3 (condição 3) Evento 3 Estado 4 Ação 4 (condição 4) Evento 4 Estado final: nenhum evento parte dele Estado 5

48. 03 - Modelos para especificação 3.3. O modelo comportamental (cont.) MEF: títulos de uma biblioteca registrar retirada disponível emprestado registrar devolução cancelar reserva (final do semestre) Observação: Eventos são representados através de ações e/ou condições (quando existirem) registrar reserva (área disciplina = área exemplar) reservado para disciplina

49. 03 - Modelos para especificação 3.3. O modelo comportamental (cont.) Traço de eventos Outra ferramenta para modelar comportamento Utilizado para representar cenários em sistemas orientados a objetos Cenários descrevem como o sistema trabalhará quando estiver em operação Notação simples Representa os objetos das classes envolvidas em um serviço do sistema e as interfaces Traço vertical: classes envolvidas no serviço Traço horizontal: mensagens trocadas entre as classes

50. 03 - Modelos para especificação 3.3. O modelo comportamental (cont.) Traço de eventos: exemplo biblioteca Localização de um exemplar Entrada: (título, autor) Resposta: nome da biblioteca onde disponível Acervo Exemplar Biblioteca título, autor verifica estado procura nome nome da biblioteca nome da biblioteca nome da biblioteca