Baixe o app para aproveitar ainda mais
Prévia do material em texto
Modelagem da Análise (ou Análise Estruturada) Paulo Cesar de Macedo - Aula 12 Organização o Breve Histórico Caracterização Os elementos do Modelo de Análise (Estruturada) Como começar o Modelagem de Dados o Modelagem Funcional e Fluxo da Informação o Modelagem Comportamental o O mecanismo (processo) da Análise Estruturada o O Dicionário de Dados o Outros métodos clássicos de Análise Visões para um problema Histórico e Caracterização o Projeto Estruturado (de Tom DeMarco): – primeira metodologia a ser amplamente aceita pela comunidade de Engenharia de Software – surgiu como evolução natural do sucesso das linguagens de programação estruturadas – surgiu a partir da necessidade de notações específicas para representar a arquitetura de um sistema estruturado o Cenário anterior: somente fluxogramas Histórico o Análise Estruturada – Douglas T. Ross (1978) – Tom DeMarco (1979) Criou a notação básica para facilitar a especificação e permitir o diálogo com usuário – Nos anos seguintes, variações surgiram por diferentes autores o Gane e Sarson (1982) e Page-Jones (19980) – Na metade da década de 1980, surgiram extensões para tempo real Caracterização o Privilegia a observação dos aspectos funcionais para a modelagem do software o Durante muito tempo - quando do auge da Programação Estruturada – as metodologias Estruturadas foram as mais conhecidas, utilizadas e criticadas Os Elementos do Modelo de Análise Os Elementos do Modelo de Análise o De maneira simplificada, o processo de Análise Estruturada pode ser descrito como sendo a aplicação dos modelos abaixo: – Entidade Relacionamento Mostra as relações entre os dados – Fluxo de Dados Fornece a indicação de como os dados são transformados à medida que se movem pelo sistema Mostra as funções (e sua decomposição) – Transição de Estados Indica como o sistema se comporta em conseqüência de eventos externos Como começar A definição do escopo pode ser obtida a partir de – Um documento de trabalho FAST ou – Um conjunto de casos de uso A definição do escopo deve ser “processada” para extrair os domínios de dados, funções e comportamento esperados. Definição do Escopo Uma descrição simples do sistema a ser construído... – Indica quais os dados de entrada e saída e a funcionalidade básica esperada – Indica o processamento condicional (em um alto nível de abstração) – Indica restrições e limitações do sistema Roteiro para Identificação objetos e operações Análise Gramatical – Definir “objetos” destacando todos os substantivos na definição escrita para o escopo do sistema Produtores e consumidores de dados Locais onde os dados são armazenados Itens de dados compostos – Definir “operações” sublinhando todos os verbos ativos Processos relevantes para a aplicação Transformações de dados – Considere outros “serviços” que podem ser requeridos pelos objetos e não estão apresentados explicitamente na definição Por que fazer modelagem de dados? Examina os objetos de dados de maneira independente do seu processamento Atenção especial ao domínio dos dados Indica qual a relação entre objetos de dados Fluxo de Dados o Todo sistema baseado em computador é a transformação automatizada de informação Notação DFD o Yourdon Notação DFD o Gane-Sarson Entidade Externa Produtor ou consumidor de dados Exemplos: pessoa, sensor Outro exemplo: sistema de computação existente Princípio: Dados devem surgem em algum lugar e devem ser enviados para algum processamento Processo Transformador de dados (de entrada em saída) Exemplos: cálculo de imposto, determinar a área de figura, formatar um relatório, exibir um gráfico Princípio: Os dados sempre devem ser processados de alguma maneira para atender uma função do sistema Fluxo de Dados Os dados fluem pelo sistema, desde a entrada até a saída Todos os fluxos devem ser descritos, isto é, rotulados com a informação transmitida Depósito de Dados o Dados são armazenados para uso posterior (em outro processo) Diretrizes para a construção de DFD Todos os ícones devem ser rotulados com nomes com significado claro O DFD deve ser fornecido em múltiplos níveis de detalhe – Deve-se começar com o Diagrama de Contexto (nível 0) que apresenta o sistema sendo desenvolvido como um único processo – Todas as entidades externas devem estar presentes no nível zero – O processo deve ser refinado (ou “explodido”) em novos processos que, por sua vez, podem ser refinados novamente Critério de parada: nunca chegar no nível do detalhamento algorítmico em um DFD Sempre inclua rótulos nas setas que indicam fluxo de dados Processo para construção de um DFD - I o Revise DER para identificar objetos de dados que irão atuar como produtores ou consumidores de dados Identifique a principal “operação” do sistema através da Análise Gramatical Crie um DFD de nível 0 Processo para construção de um DFD - I o Exemplo de Diagrama de Contexto Processo para construção de um DFD - II Escreva uma narrativa que descreva a transformação realizada por um processo Faça a análise gramatical novamente para identificar as sub-funções do sistema Faça o “balanceamento” do fluxo de dados para garantir a sua continuidade – Isto é, todas as entradas e saídas presentes no nível superior devem estar presentes no nível inferior – Obs: item de dados representado em um nível pode ser refinado nas suas partes constituintes no nível seguinte Construa um processo de nível 1 Use aproximadamente a razão 1:5 para a explosão de processos Processo para construção de um DFD - II o Exemplo de Diagrama de Nível 1 DFD - Observações (1) Cada bolha (processo) deve refinado até que seja identificada claramente sua identidade funcional – isto é, realiza exatamente uma única função A razão para explosão de processos descreve a medida que o número de níveis cresce A maioria dos sistemas requer entre 3 e 7 níveis para modelagem adequada de fluxo Um único fluxo de dados (seta) pode ser expandido a medida que os níveis crescem (o dicionário de dados fornecerá o detalhamento necessário) DFD - Observações (2) DFDs não mostram a ordem da execução das atividades - não se preocupa com o aspecto temporal ou de controle Não há preocupação com erros Abordagem de desenvolvimento top-down - os processos devem ser divididos até encontrarmos processos atômicos DFD é lógico (múltiplas implementações físicas alternativas) DFD: Exemplo 2 DFD: Exemplo 2 DFD: Exemplo 3 DFD: Exemplo 3 DFD: Exemplo 3 Modelagem Comportamental Estados de um sistema Definições – Estado - conjunto de circunstâncias observáveis que caracterizam o comportamento do sistema em um momento específico – Transição de Estados - a movimentação de um estado para outro – Evento - ocorrência que faz com que o sistema apresente algum comportamento previsível – Ação - processo que ocorre como conseqüência do disparo de uma transição Processo de Modelagem Comportamental Faça uma lista dos diferentes estados de um sistema – Responder apergunta: como o sistema deve se comportar? Indique como o sistema realiza uma transição de um estado para outro – Pergunta: como ocorre mudanças de estado no sistema? – Indique o evento – Indique a ação (opcional) Desenhe um diagrama de transição de estados Dicionário de Dados Gramática “quase-formal” para descrição dos itens de dados Notação também útil para descrever dados de controle e seus valores permitidos (p.ex: “on” e “off”) É um repositório que também pode conter informações sobre “quem-usa” e “como usa” Pode ser representada manualmente, mas é melhor se apoiada por ferramenta CASE Definição do Dicionário de Dados Notação para DD Outros métodos Desenvolvimento de Sistemas Estruturados pelos Dados (Warnier/Orr) Jackson System Development (Michael Jackson) Structured Analysis and Design Technique (Douglas Ross) SADT SADT
Compartilhar