Profa. Reane Franco Goulart

Slides:



Advertisements
Apresentações semelhantes
Um pouco mais de cardinalidade e Relacionamentos
Advertisements

Análise e Projeto de Sistemas I
DFD - Diagrama de Fluxo de Dados
Engenharia de Software
UML Visões – Parte 2.
Diagrama de Fluxo de Dados – DFD
Resumo 1.1) Introdução 1.2) Abordagem Convencional de Arquivos
O Modelo E-R Definição: Características
Diagrama de fluxo de dados (DFD)
Identificando requisitos
Prof.: Bruno Rafael de Oliveira Rodrigues
Análise e Projeto de Sistemas I
Engenharia de Software
Análise e Projeto de Sistemas
Faculdade de Ciências Sociais e Aplicadas de Petrolina – FACAPE
Professora: Aline Vasconcelos
Modelo de Arquitetura Diagrama de Componentes
Análise Estruturada O mais amplamente usado dos métodos de modelagem de requisitos Modelos que retratam fluxo e o conteúdo da informação (dados e controle)
Análise e Projeto de Sistemas
1 - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – Noções de Engenharia de Software COINFO – CEFET-PB 7.3 Diagrama de transição de.
6. Análise estruturada 6.1 DFD
Engenharia de Requisitos Requisito – sistema Caso de uso - usuário
TIPOS DE TESTES APLICÁVEIS E NÃO APLICÁVEIS AO PROJETO
Aspectos Avançados em Engenharia de Software Aula 3 Fernanda Campos
RUP: Fluxo de Análise e Projeto
Princípios e Conceitos de Software(v2)
Classes e objetos Modelagem
DIAGRAMA DE COMPONENTES
Análise Estruturada.
SQL Server 2012 Introdução a Modelagem de Dados
DFD – Data Flow Diagram Diagrama de Fluxo de Dados
Análise Estruturada.
Análise Estruturada Diagramas de Fluxo de Dados
Expansão dos Casos de Uso
Ferramentas de modelagem do SI
Especificação de Processos e Dicionário de Dados
Prof. Kelly E. Medeiros Bacharel em Sistemas de Informação
Fase de Elaboração: Fluxo de Análise Análise de Sistemas de Software Prof. Rodrigo Ribeiro.
Thelma Elita Colanzi Lopes
MODELO ESSENCIAL Modelo Comportamental
Projeto de Banco de Dados
Análise e Projeto de Sistemas de Informação 2o. Semestre de 2014
REVISÃO DFD.
Analises de sistemas ESTRUTURADA Analise de sistema estruturada.
Arquitetura de Desenvolvimento Web MVC vs. Three Tiers
O Processo Unificado (UP)
Banco de Dados Aplicado ao Desenvolvimento de Software
Análise e Projetos de Sistemas Prof. Jorge Manuel Lage Fernandes
1 - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – COINFO – CEFET-PB 7. Análise e projeto orientados a objetos 7.1 Técnica de modelagem.
Campus de Caraguatatuba Aula 2: Introdução a Tecnologia de BD
METODOLOGIA, MÉTODOS E FERRAMENTAS
IEEE Melhores Práticas para Descrições de Projeto de Software (DPS)
Análise Estruturada Prof: JOSE CARLOS MILLAN.
Metodologias de Desenvolvimento de Sistemas
Sistemas de Informação (SI)
Análise Estruturada de Sistemas
TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANÁLISE E PROJETO DE SISTEMAS Aula /08/2012 Professor Leomir J. Borba-
Modelagem e arquitetura
Profa. Reane Franco Goulart. É uma representação de engenharia de algo que vai ser construído. Para a engenharia de software o projeto foca em quatro.
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
Engenharia de Software Orientada a Objetos
1 Database Systems, 8 th Edition Sistemas de Banco de Dados: Projeto, Implementação e gestão Oitava Edição Capítulo 2 Modelo de Dados.
1 Database Systems, 8 th Edition Sistemas de Banco de Dados: Projeto, Implementação e gestão Oitava Edição Capítulo 2 Modelo de Dados.
Princípios de Análise 1. O domínio de informação de um problema deve ser representado e compreendido. 2. Modelos que descrevam a informação, função e comportamento.
Banco de Dados Distribuídos Sílvia Cristina de Matos Soares
Aula 04 – Analise de Sistemas Profª Rita de Cassia Gaieski
Análise e Projeto de Sistemas
1 Especificação de Sistemas de Software e a UML. 2 Modelagem de sistema A modelagem de sistema auxilia o analista a entender a funcionalidade do sistema.
Prof. Thales Castro. Depósito de dados Entidade externa Processo Fluxo de dados.
Prof. Thales Castro.  Histórico  Vantagens & Desvantagens  DFD’s  Exercício.
Transcrição da apresentação:

Profa. Reane Franco Goulart Modelagem de Sistema Profa. Reane Franco Goulart

O que é um 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 formar uma documentação do sistema.

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.

Modelagem de Sistemas de Informação Ao longo do processo de desenvolvimento, um sistema é representado através de vários modelos. Esses modelos representam: Sistema em dimensões do mundo real Níveis de abstração distintos.

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.

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 - Características dependentes de um sistema computacional específico, isto é, linguagem e compilador específicos, hardware de um determinado fabricante, etc.

Análise estruturada

Introdução a Análise Estruturada As técnicas estruturadas surgiram no sentido bottom-up, isto é, da programação para a análise. A programação estruturada, introduzida no final da década de 60, teve como principal propósito a construção de programas mais fáceis de serem lidos e compreendidos.

Introdução a Análise Estruturada O projeto estruturado, introduzido em meados da década de 70, preocupou-se com a organização dos programas. As recomendações do projeto estruturado para organizar um sistema em módulos de tamanho reduzido, cada qual executando uma única função específica, e sobre a maneira como os módulos devem ser interligados, contribuíram para a manutenibilidade do sistema.

Introdução a Análise Estruturada No final da década de 70, a análise estruturada possibilitou especificar os requisitos lógicos do sistema em um modelo gráfico de alto nível, capaz de ser compreendido pelos usuários e de ser mapeado para a arquitetura do projeto. O modelo gráfico introduzido pala análise estruturada representa os dados utilizados por um sistema, os fluxos que transportam e os processos que os transformam.

Características da Análise Estruturada Utiliza linguagem gráfica com suporte de texto Fornece uma visão top-down e particionada do sistema Possibilita eliminar redundâncias Os instrumentos conseguem ser transparentes ao leitor

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.

Princípios Utilizados na Solução de Problemas 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.

Princípios Utilizados na Solução de Problemas 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.

Metodologia da analise estruturada

Modelos da Metodologia 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.

Diagrama de Fluxo de Dados (DFD) O Diagrama de Fluxo de Dados possui os seguintes componentes: Entidade Externa Processos Fluxo de Dados Depósito de Dados

Diagrama de Fluxo de Dados (DFD)

Sugestão para as etapas de elaboração de um D.F.D Identificar e descrever os requisitos funcionais; Identificar entidades externas(EE); Associar o fluxo de dados que as entidades enviam, consomem ou recebem; Identificar consultas Desenhar o primeiro DFD: Iniciar no canto esquerdo com a entidade externa principal; procurar deixar todas as entidades externas nos cantos; na esquerda as EE de Origem e na direita as EE de Destino; desenhe fluxos que surgem, processo e depósitos de dados; verificar se todas as entradas e saídas foram incluídas; associar manutenções aos depósitos de dados; Explodir ou derivar processos complexos em níveis inferiores.

Exemplo: Video Locadora Requisitos: Cadastro da locadora Cadastro dos filmes Cadastro dos clientes Registro de locação Relatórios

Entidade Externa São categorias lógicas de objetos ou pessoas que representam Origem ou destino de dados, e, que acionam um sistema e/ou recebem informações; Podem ser pessoas, sistemas ou unidades departamentais; possuem as seguintes regras: nome - nome da entidade : Ex: Clientes, Sistema Acesso, Banco, etc.

Entidade Externa Como descobrir entidades externas ?  No mínimo temos duas: quem usa o sistema (cliente) e quem opera o sistema (departamento A)

Fluxo de Dados São o Meio por onde os dados e as informações trafegam; Regras: nome : nome do dado. Ex: Pedido, Nota Fiscal, Produto, Item, arg: argumento de acesso  a um depósito . Ex: Cgc, CPF, CEP, código , matricula, Nome, etc... Sempre envolvem processos não sendo possível o fluxo de entidade para entidade, entidade para depósito de dados, depósito de dados para  depósito de dados

Fluxo de Dados 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).

Processos Transformam fluxos de dados em uma atividade; São módulos do sistema; Regras: n: número de referência do processo. Ex: 0, 1,2,3,, 1.1, 1.2 função: descreve o processo no verbo infinitivo. Ex: Cadastrar Cliente, Gerar Arquivo, Imprimir Relatório, etc. loc: local físico onde se desenvolve o processo. Ex: Almoxarifado; Contabilidade, etc. Dica : Para descobrir um processo relate os requisitos do sistema. (Cadastrar Cliente, Efetuar Logon, etc.)

Processos 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). Notação: Nome do Processo = Verbo no infinitivo + substantivo + (qualificador)

Depósito de Dados São locais de armazenamento de dados São arquivos físicos Regras: Dn : número do depósito. Ex: 0,1,2,3, D1/1, D1/2 nome : nome do depósito. Ex: Clientes, Produtos, Contas, etc.       Para tornar mais fácil identificar DD leve em conta dois tipos de arquivos :  Cadastral e de Movimento ( Movimento de Itens, etc.)

Exemplo: Video Locadora Requisitos: Cadastro da locadora Cadastro dos filmes Cadastro dos clientes Registro de locação Relatórios

Clínica Médica

Recomendações para Construção de DFD Escolha nomes significativos para todos os objetos do DFD. Utilize nomes do próprio ambiente do usuário; Os processos devem ser numerados de acordo com o diagrama ao qual pertencem; Evite desenhar DFDs complexos; Cuidado com as bolhas sem entrada ou sem saída; Cuidado com os processos e fluxos não nomeados; Cuidado com os depósitos de dados que só possuem fluxos de entrada ou de saída; Fique atento ao princípio da conservação dos dados;

Recomendações para Construção de DFD Os fluxos que entram e saem em um nível devem entrar e sair no nível inferior; 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; Não perca tempo procurando um bom nome para um processo que só pode chamar-se “processar dados”. Livre-se dele;

DICIONÁRIO DE DADOS http://www.ebah.com.br/content/ABAAAA03EAF/metodologia-analise-estruturada