Carregar apresentação
A apresentação está carregando. Por favor, espere
1
Profa. Reane Franco Goulart
Modelagem de Sistema Profa. Reane Franco Goulart
2
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.
3
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.
4
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.
5
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.
6
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.
7
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.
8
Análise estruturada
9
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.
10
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.
11
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.
12
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
13
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.
14
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.
15
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.
16
Metodologia da analise estruturada
17
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.
18
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
19
Diagrama de Fluxo de Dados (DFD)
20
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.
21
Exemplo: Video Locadora
Requisitos: Cadastro da locadora Cadastro dos filmes Cadastro dos clientes Registro de locação Relatórios
23
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.
24
Entidade Externa Como descobrir entidades externas ?
No mínimo temos duas: quem usa o sistema (cliente) e quem opera o sistema (departamento A)
25
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
26
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).
27
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.)
28
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)
29
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.)
30
Exemplo: Video Locadora
Requisitos: Cadastro da locadora Cadastro dos filmes Cadastro dos clientes Registro de locação Relatórios
35
Clínica Médica
40
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;
41
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;
42
DICIONÁRIO DE DADOS
Apresentações semelhantes
