Docsity
Docsity

Prepare-se para as provas
Prepare-se para as provas

Estude fácil! Tem muito documento disponível na Docsity


Ganhe pontos para baixar
Ganhe pontos para baixar

Ganhe pontos ajudando outros esrudantes ou compre um plano Premium


Guias e Dicas
Guias e Dicas

Metodologia Análise Estruturada, Notas de estudo de Informática

Metodologia Análise estruturada

Tipologia: Notas de estudo

2010

Compartilhado em 30/05/2010

marcelo-rodrigues-da-silva-6
marcelo-rodrigues-da-silva-6 🇧🇷

5

(1)

4 documentos

Pré-visualização parcial do texto

Baixe Metodologia Análise Estruturada e outras Notas de estudo em PDF para Informática, somente na Docsity! UNIVERSIDADE ESTÁCIO DE SÁ ANÁLISE ESTRUTURADA Outubro,2001 1 ÍNDICE CAPÍTULO 1 Conceitos Básicos 1. Introdução 7 2. Análise de Sistemas 8 3. Metodologia 8 4. Processo de Desenvolvimento de Sistemas de Informação 9 5. Modelo 13 6. Dimensão de um Modelo 13 7. Nível de Abstração de um Modelo 13 8. Modelagem de Sistemas de Informação 13 1.8.1 Modelagem de Sistemas de Informação 13 1.8.2 Níveis de Abstração 14 CAPÍTULO 2 ANÁLISE ESTRUTURADA 2.1 Introdução 1 5 2.2 Características da Metodologia 15 2.3 Princípios Utilizados na Solução de Problemas 16 2 ÍNDICE DE FIGURAS Figura 1 – Representação Gráfica de Processo 17 Figura 2 – Representação Gráfica de Fluxo de Dados 18 Figura 3 – Convergência e Divergência de Fluxo de Dados 19 Figura 4 – Representação Gráfica de Fluxo de Dados 19 Figura 5 – Semântica dos Acessos aos Depósitos de Dados 20 Figura 6 – Representação Gráfica de Entidade Externa 20 Figura 7 – DFD Organizado em Níveis Hierárquicos 21 5 1 CONCEITOS BÁSICOS 1. Introdução De uma maneira abrangente, Sistema é definido como “um conjunto de elementos, interrelacionados, que possuem características comuns e que podem ser entendidos como um todo”. Dessa forma, podemos pensar no “Sistema Solar”, composto de vários elementos como o Sol, os planetas, a força gravitacional, as órbitas, etc. Podemos pensar também em um “Sistema Político” ou um “Sistema Digestivo”. Os sistemas se dividem em Sistemas Naturais e Sistemas Construídos pelo Homem. Nos sistemas construídos pelo homem podemos identificar claramente o propósito para o qual o sistema foi construído. Nos sistemas naturais, esse propósito nem sempre é muito claro. Os sistemas construídos pelo homem podem ser definidos como um conjunto de componentes relacionados entre si, que podem ser vistos como um todo, onde os componentes trabalham juntos na execução de um conjunto de funções para alcançar um propósito. Assim, um sistema tem: • Componentes: partes básicas ou elementos que compõem o sistema; • Estrutura: maneira como os componentes estão organizados; • Comportamento: modificação dos componentes e da estrutura com o passar do tempo; • Funções: transformações que o sistema executa; e • Propósito: objetivo que o sistema deve alcançar. Dentre os sistemas construídos pelo homem, existem aqueles onde um dos componentes fundamentais são informações. Esses sistemas, chamados “Sistemas de Informação”, 7 provêem procedimentos para armazenar e tornar disponíveis informações, que são utilizadas em atividades relacionadas a uma organização. Se os sistemas de informação utilizam computadores, eles são denominados “Sistemas de Informação Automatizados”. Esse tipo de sistema é o alvo principal de nosso curso. 2. Análise de Sistemas É um processo de comunicação entre Analistas de Sistemas e Usuários do Sistema, com o objetivo de definir o propósito e os requisitos de um sistema de informação. Requisitos de um sistema é o conjunto de características que um sistema deve possuir para atingir seu propósito. A análise de um sistema é um processo de transmissão de conhecimento. Ela envolve três etapas: o aprendizado; a estruturação e a representação dos requisitos do sistema; e a validação dos requisitos pelos usuários. Ao longo do processo, o analista enfrenta o desafio de “lidar com a complexidade”, isto é, situações complexas do mundo real devem ser entendidas e representadas de forma simples, para facilitar a compreensão e validação. Requer delimitar a área de estudo, subdividir o todo complexo em partes inteligíveis e de tamanho gerenciável, extrair as características essenciais da realidade e modelar essas características para mostrar o relacionamento entre seus componentes. Pode-se afirmar que complexidade e falta de estrutura caracterizam o ambiente da Análise de Sistemas. 3. Metodologia As metodologias são utilizadas para orientar e ordenar o trabalho do analista de sistemas ao longo do processo de desenvolvimento de sistemas. Uma boa metodologia deve definir o processo de desenvolvimento, possuir modelos para representar abstrações e diretivas para orientação do trabalho. 4. Processo de Desenvolvimento de Sistemas de Informação O Processo de Desenvolvimento de Sistemas, também chamado Ciclo de Vida do Sistema, compreende todas as atividades necessárias para definir, desenvolver, testar, operar e manter um sistema. 8 e) definição dos requisitos para um novo sistema: Em linhas gerais, os requisitos para um novo sistema corresponderão ao que o sistema atual faz, menos os seus problemas, mais as necessidades não atendidas. Os requisitos são expressos na forma de uma lista. f) formulação de alternativas de solução: o analista deverá formular alternativas de solução para o atendimento dos requisitos listados na tarefa anterior. As alternativas devem propor desde soluções mais simples, mais baratas e de execução mais rápida e que atendam apenas aos requisitos mais prioritários, até a mais complexa, possivelmente cara e demorada, mas que atenda a todos os requisitos. Todas as alternativas devem apresentar, de forma detalhada, os custos quantificados (hardware, software, mão de obra e tempo) e os benefícios esperados (informações fornecidas, redução de custos, aumento de lucro, qualidade de atendimento, etc.) que, se possível, devem também serem quantificados. De posse dessas informações, o usuário seleciona uma das alternativas, a qual passará a ser desenvolvida na fase de análise. g) redação do plano do projeto: O plano do projeto inclui as informações de custo e prazo da solução escolhida, define as responsabilidades da gerência e descreve as demais etapas do processo de desenvolvimento, os produtos de cata etapa, os requisitos de qualidade e o cronograma do projeto. Etapa 3: ANÁLISE Atividade para a qual o analista deve dedicar a maior parte de seu tempo de esforço. Sua principal tarefa consiste em definir e modelar o que o sistema irá fazer, independente da tecnologia que será utilizada na implementação. É feita uma reavaliação do plano do projeto, principalmente dos custos e benefícios quantificados na fase anterior. 11 Etapa 4: PROJETO O objetivo desta etapa é definir a melhor alternativa para implementar, em um dado ambiente computacional, todas as características do sistema definidas na Análise. Os critérios utilizados na escolha das alternativas são: performance, interatibilidade (facilidade de uso), manutenibilidade (facilidade de alteração), segurança (contra acessos indevidos e perdas acidentais de dados) e confiabilidade. Etapa 5: IMPLEMENTAÇÃO Consiste na codificação dos programas e criação dos arquivos de dados. Etapa 6: TESTES Consiste na definição de casos de testes e na realização dos testes de programas, testes de integração, teste do sistema e teste de aceitação. Etapa 7: IMPLANTAÇÃO Consiste em implantar o sistema nas instalações do usuário,. Nessa etapa são prontificados os manuais, os arquivos são carregados, os sistema é instalado e os usuários treinados. Um bom planejamento dessas atividades é um fator crítico para o sucesso do sistema. Todo o trabalho executado no sistema após a sua implantação é denominado manutenção, a qual pode ser corretiva (corrigir erros), adaptativa (adaptar o sistema a um novo ambiente ou ao mesmo ambiente modificado ou evolutiva (dotar o sistema de novas capacidades). 1.5 Modelo É uma representação de um sistema (ou de um objeto qualquer). Um modelo é uma abstração da realidade, ou seja, representa uma seleção de características do mundo real, que são relevantes para o propósito com o qual o modelo foi construído. Razões para Modelar um Sistema: • possibilitar o estudo do comportamento do sistema; • possibilitar a discussão de correções e modificações com o usuário, a baixo custo, minimizando o risco de não aceitação do produto final; • facilitar a comunicação entre os componentes da equipe de desenvolvimento; e 12 • formar uma documentação do sistema. 1.6 Dimensões de Um Modelo Conjunto de características da realidade que são enfatizados no modelo. 1.7 Nível de Abstração de um Modelo Consiste no grau de detalhamento com que as características do sistema são representadas no modelo. Em cada nível há uma ênfase seletiva nos detalhes representados. 1.8 Modelagem de Sistemas de Informação Ao longo do processo de desenvolvimento, um sistema é representado através de vários modelos. Esses modelos representam o sistema em dimensões e níveis de abstração distintos. 1.8.1 Dimensões do Mundo Real Dado – aspecto estático e estrutural do sistema; Controle – aspecto temporal e comportamental do sistema; e Função – transformação de valores. Os modelos de dados, controle e função de um mesmo sistema, devem ser consistentes entre si. 1.8.2 Níveis de Abstração CONCEITUAL Características do sistema independentes do ambiente computacional (hardware e software) no qual será implementado o sistema. Essas características são dependentes unicamente das necessidades do usuário. LÓGICO Características dependentes de um determinado tipo de sistema computacional (não representa características de produtos específicos). FÍSICO 13 2.3 Princípios Utilizados na Solução de Problemas Os seguintes princípios, quando utilizados, auxiliam o analista de sistemas a lidar com suas limitações, na solução de problemas: • Abstração: utilizado para separar aspectos que estão ligados a uma determinada particularidade da realidade. Possibilita a construção de modelos genéricos e simplificados do mundo real. • Rigor e Fomalidade: fornece uma abordagem metódica e rigorosa para resolver um problema, ao contrário de uma abordagem ad-hoc, que não permite o estabelecimento de controles. • Dividir-para-Conquistar: um problema grande e complexo pode ser dividido em um conjunto de problemas menores e independentes, mais fáceis de serem compreendidos e resolvidos. • Organização Hierárquica: os componentes da solução de um problema podem ser organizados em uma estrutura hierárquica. Assim, a solução de um problema pode ser compreendida e construí da nível a nível. A cada nível são acrescentados mais detalhes. 2.4 Modelos da Metodologia A análise estruturada utiliza os seguintes modelos para especificar os requisitos lógicos dos sistema. • Diagrama de Fluxo de Dados (DFD): representa um sistema de informações como uma rede de processos, interligados entre si por fluxos e depósitos de dados. • Dicionário de Dados (DD): contém a definição dos dados utilizados no DFD. • Especificação da Lógica dos Processos: especifica a lógica dos processos representados no DFD. 2.5 Diagrama de Fluxo de Dados (DFD) O Diagrama de Fluxo de Dados possui os seguintes componentes: 2.5.1 Processo 16 Representa as transformações ocorridas com os dados. Corresponde a uma função ou atividade do sistema de informação. Uma transformação significa uma ou mais: transformação do conteúdo variável de um dado de entrada no conteúdo variável de um dado de saída; modificação ou criação de dados armazenados, a partir do conteúdo (possivelmente transformado) de dados de entrada; e transformação de dados previamente armazenados no conteúdo variável de um dado de saída. O nome do processo deve estar relacionado com uma atividade ou função do negócio., Devem ser evitados nomes muito físicos (gravar, imprimir), muito técnicos (deletar, becapear) ou nomes muito genéricos (processar). A figura 1 mostra a representação gráfica de processo, na notação proposta por DeMarco (1978) e Gane (1979). 2.5.2 Fluxo de Dados É utilizado para representar a movimentação de dados pelo sistema. Os dados transportados pelos fluxos são associados a um valor variável ou a um conjunto de valores variáveis, definidos em um ponto discreto no tempo. 17 O nome do fluxo deve ser um substantivo que facilite a identificação do dado ou pacote de dados transportado. Todo fluxo de dados possui direção (origem e destino). A figura 2 mostra a representação gráfica de fluxos de dados, na notação proposta por DeMarco (1978) e Gane (1979). Conforme representado na figura 3, fluxos de dados podem convergir ou divergir em um DFD, representando múltiplas fontes, múltiplos destinos ou combinação/separação de conteúdo. 18 processo que está sendo detalhado e um número seqüencial, separados por um ponto. A figura 7 ilustra a organização do DFD em níveis hierárquicos. 2.7 Recomendações para Construção de DFD a) escolha nomes significativos para todos os objetos do DFD. Utilize nomes do próprio ambiente do usuário; b) os processos devem ser numerados de acordo com o diagrama ao qual pertencem; c) evite desenhar DFDs complexos; d) cuidado com as bolhas sem entrada ou sem saída; e) cuidado com os processos e fluxos não nomeados; f) cuidado com os depósitos de dados que só possuem fluxos de entrada ou de saída; g) fique atento ao princípio da conservação dos dados; h) os fluxos que entram e saem em um nível devem entrar e sair no npivel inferior; i) mostre um depósito de dados no nível mais alto em que ele faz interface entre dois ou mais processos. Passe a representá-lo em todos os níveis inferiores que detalham os processos da interface; j) não perca tempo procurando um bom nome para um processo que só pode chamar-se “processar dados”. Livre-se dele; k) só represente fluxos de rejeição nos diagramas de mais baixo nível; l) não represente no DFD fluxos de controle ou de material; e m) só especifique a lógica dos processos primitivos, ou seja, dos processos não explodidos em outros diagramas. 21 2.8 Diretivas da Metodologia a) Identificar as entidades externas envolvidas; b) Preparar um lista com as entradas e saídas necessárias para que o sistema atinja o seu propósito. Assinale as entradas e saídas que estão associadas a situações de erros ou exceção; c) Identificar as consultas e os pedidos de informação aos sistemas que possam surgir; d) Desenhar, a partir do canto esquerdo de uma folha de papel, as entidades externas que fornecem dados ao sistema, os processos necessários para transformar os dados de entrada nos dados de saída e os depósitos de dados para manter dados em repouso. Termine com as entidades externas que recebem informações do sistema. e) Nesse primeiro diagrama não represente fluxos associados a erros ou exceções; f) Verificar se todas as entradas e saídas da lista foram incluídas no diagrama; g) Produzir diagramas de nível inferior para detalhar os processos do primeiro diagrama. Nesses novos diagramas, incluir os fluxos associados a erros ou exceções. 22 ESTUDO DE CASO 1 LIVRARIA ABC Descrição do Mini-Mundo A Livraria ABC atua no mercado de livros há mais de 20 anos. Sua estratégia de atuação não prevê a manutenção de livros em estoque. Todos os livros solicitados por seus clientes são, semanalmente, encomendados às editoras. As editoras e os livros oferecidos são selecionados pela Direção da Livraria. Atualmente, a Editora possui 1.200 clientes cadastrados, fornece 170 livros e atende a uma média de 150 pedidos por semana. Os clientes enviam seus pedidos pelo correio. O pedido é aceito se o cliente e os livros estiverem previamente cadastrados. Caso contrário, o pedido é rejeitado e devolvido ao cliente. Ao final da semana, a livraria emite requisições para as editoras, com base nos pedidos recebidos. Quando os livros são fornecidos, a livraria confere as notas fiscais das editoras com as requisições, devolve as que contiverem erros e atende os pedidos dos clientes, emitindo as respectivas faturas, que acompanham os livros. Uma cópia da fatura é encaminhada à Tesouraria, onde é feito o controle de pagamentos. 23 f) o cliente deve possuir um telefone, podendo ser comercial ou residencial. cliente = * cliente da livraria * @código-cliente + nome cliente + endereço-cliente + [telefone-comercial | telefone-residencial] g) o cliente pode possuir telefone comercial, residencial ou ambos. cliente = * cliente da livraria * @código-cliente + nome cliente + endereço-cliente + [telefone-comercial | telefone-residencial | telefone-comercial + telefone-residencial] 3.3 Estrutura das Definições Todas as definições do Dicionário de Dados contém o nome do dado, um comentário sucinto sobre o significado do dado, sua composição - no caso de dados compostos, ou suas características – no caso de dados elementares. Quando o nome do dado for suficiente para indicar o seu significado, este não necessita ser especificado. Nesses casos, para indicar que a descrição está completa e que não houve esquecimento, mantêm-se apenas os asteriscos no lugar da especificação do significado. Exemplo: A seguir são apresentadas as convenções utilizadas nas definições de cada tipo de dado: 3.3.1 Depósitos de Dados, Entidades e Relacionamentos com Atributo A definição de um depósito de dados deve conter o significado do depósito, volume inicial de dados armazenados, taxa de crescimento e o nome do registro, o qual corresponderá a uma entidade ou a um relacionamento com atributo do ERA. Os nomes dos depósitos de dados serão sempre escritos no plural e com letras maiúsculas. Exemplo: 26 As chaves primárias dos depósitos de dados são assinaladas na definição do registro do depósito. Exemplos: O Dicionário de Dados pode ser utilizado para descrever a composição dos Depósitos de Dados que correspondem às generalizações e especializações do ERA. Exemplo: 27 3.3.2 Fluxos de Dados e Estruturas de Dados A definição de um fluxo de dados ou de uma estrutura de dados contém o significado e a composição do dado. No dicionário de dados, os nomes desses dados são escritos com letras minúsculas. Exemplos: cliente-pedido = * cliente que encaminhou o pedido * Estrutura de dados nome-cliente + [endereço-cliente | telefone-cliente] item-pedido = * item do pedido de um cliente * Estrutura de dados nome-item + quantidade-item pedido-livro = * pedido de livros dos clientes da livraria* Fluxo de dados cliente-pedido + 1 (item-pedido) Para que a composição dos fluxos e estruturas de dados sejam apresentados de maneira top- down, o que facilita o seu entendimento, deve-se procurar agrupar os elementos de dados em estruturas intermediárias. Exemplo: pedido-livro = * pedido de livros dos clientes da livraria* nome-cliente + endereço-cliente + (telefone-cliente) + {nome-item + quantidade-item} 28 data = ** * formato: dd/mm/aa * data-fatura = * data de emissão de uma fatura * data data-pedido = * data de emissão de um pedido * data 31 4 PORTUGUÊS ESTRUTURADO 4.1 Introdução O Português Estruturado é um subconjunto do Português, cujas sentenças são organizadas segundo as três estruturas de controle, introduzidas pela Programação Estruturada (seqüência, seleção e repetição). A Análise Estruturada e a Análise Essencial utilizam o Português Estruturado para especificar a lógica dos processos primitivos do DFD, isto é, dos processos que não são detalhados em diagramas de nível inferior. 4.2 Características da Especificação Uma especificação em Português Estruturado deve especificar apenas “o que o processo deve fazer “ e nunca “como o processo deve fazer”. O exemplo abaixo caracteriza essa diferença: Para registrar a matrícula de um aluno, o processo :Matrícula Aluno: deve atribuir um valor numérico e seqüencial para :código-matrícula:. No item “a”, abaixo, está sendo especificado como o processo obtém o valor para código-matrícula (como fazer). Já no item “b”, está sendo especificado apenas o que o processo deve fazer. a) especificação incorreta “obter novo-aluno localizar último registro de aluno em ALUNOS ler matrícula-aluno do registro localizado acrescente 1 a matrícula-aluno armazene novo registro em ALUNOS com matrícula-aluno, nome-aluno e endereço-aluno” b) especificação correta 32 “obter novo-aluno atribuir valor numérico sequencial a matrícula-aluno armazenar matrícula-aluno, nome-aluno e endereço-aluno em ALUNOS” Uma especificação, em Português Estruturado, deve possuir as seguintes características gerais • deve ser clara, concisa, completa e livre de ambigüidades; • todos os dados citados na especificação e que estejam definidos no dicionário de dados devem ser sublinhados; • os dados definidos localmente não são sublinhados; • os depósitos de dados, além de serem sublinhados, devem ser escritos com letras maiúsculas e no plural; • as palavras reservadas para as estruturas de controle são escritas com letras maiúsculas; e • suas estruturas devem estar identadas. 4.3 Estruturas de Controle Uma especificação em Português Estruturado deve utilizar apenas as seguintes estruturas de controle: 4.3.1 Sequência Sintaxe: sentença – 1 sentença – 2 sentença – n Exemplo: ler nome-aluno em ALUNOS com matrícula-aluno de solicitação-nota ler nota-aluno associada a matrícula-aluno em NOTAS acrecentar nome-aluno e nota-aluno em nota-solicitada 33 4.5 Exemplos de Especificações em Português Estruturado a) especificar a lógica do processo 1.1 abaixo Processo 1.1: Emitir Relação Faturas Vencidas *Ocorre quando existir fatura vencida* INÍCIO 36 FAÇA ENQUANTO existir fatura em FATURAS com data-vencimento anterior a data-atual e não relacionada a fatura-paga em FATURAS- PAGAS ler próxima fatura com a condição acima acrescentar uma linha em relação-faturas-vencidas com fatura FIM ENQUANTO enviar relação-faturas-vencidas FIM b) especificar a lógica do processo 1.2 abaixo Processo 1.2: Fornecer Detalhes de Livro INÍCIO obter título-livro ler editora em LIVROS com título-livro acrescentar título-livro e editora em detalhes-livro FAÇA ENQUANTO existir autor em AUTORES relacionado com título-livro ler próximo autor com a condição acima acrescentar autor em detalhes-livro FIM ENQUANTO enviar detalhes-livro FIM c) especificar a lógica do processo 1.3 abaixo 37 Processo 1.3: Informar Vendas do Dia *Ocorre ao final de cada dia * INÍCIO FAÇA ENQUANTO existir pedido em PEDIDOS com data-pedido = data- atual ler número-pedido ler nome-cliente em CLIENTES relacionado com número-pedido acrescentar número-pedido e nome-cliente em relação-vendas-do- dia FAÇA ENQUANTO existir item-pedido em ITENS PEDIDOS relacionado com número-pedido ler próxima quantidade ler valor-item relacionado com quantidade em ITENS valor-pedido = valor-pedido + valor-item F 02 A quantidade FIM_ENQUANTO acrescentar valor-pedido em relação-vendas-do-dia total-dia = total-dia + valor-pedido FIM_ENQUANTO 38 FIM 41 42
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved