Diagrama de fluxo de dados com exemplos - Plataforma de negociação de valores mobiliários 16 de fevereiro de 2015 Visualizações: 16,033 PDF Link Edição (s) compatível (s): Enterprise, Professional, Standard, Modeling Data Flow Diagram (DFD) fornece uma representação visual do fluxo de informações (ou seja, dados) Dentro de um sistema. Ao desenhar um Diagrama de fluxo de dados, você pode informar as informações fornecidas e entregues a alguém que faça parte dos processos do sistema, as informações necessárias para completar os processos e as informações necessárias para serem armazenadas e acessadas. Este artigo descreve e explica o Diagrama de Fluxo de Dados (DFD) usando uma plataforma de negociação de títulos como um exemplo. O Contexto do Exemplo de Plataforma de Negociação de Valores Mobiliários DFD A figura abaixo mostra um Diagrama de Fluxo de Dados do contexto que é desenhado para uma plataforma de negociação de segurança. Contém um processo (forma) que representa o sistema a modelar, neste caso, a plataforma de negociação de valores mobiliários. Também mostra os participantes que irão interagir com o sistema, chamados de entidades externas. Neste exemplo, CS Assistant. Cliente e corretor são as entidades que irão interagir com o sistema. Entre o processo e as entidades externas, existem fluxos de dados (conectores) que indicam a existência de troca de informações entre as entidades e o sistema. Contexto DFD é a entrada de um modelo de fluxo de dados. Contém um e um único processo e não mostra qualquer armazenamento de dados. DFD de Nível 1 A figura abaixo mostra o DFD de nível 1, que é a decomposição (ou seja, a quebra) do processo da plataforma de negociação de valores mobiliários mostrado no contexto DFD. Leia o diagrama, e então vamos apresentar alguns dos principais conceitos baseados neste diagrama. O exemplo do Diagrama de fluxo de dados da Plataforma de negociação de valores mobiliários contém cinco processos, três entidades externas e três lojas de dados. Embora não existam diretrizes de design que regulem o posicionamento das formas em um Diagrama de Fluxo de Dados, tendemos a colocar os processos no meio e nos estoques de dados e entidades externas nos lados para facilitar a compreensão. Com base no diagrama, sabemos que um Assistente de Atendimento ao Cliente fornece detalhes do cliente para o processo de Conta Aberta. O resultado é que os detalhes do Cliente estão armazenados no armazenamento de dados do Cliente e os detalhes da Conta estão sendo armazenados no armazenamento de dados da conta. Embora dissemos que a tentativa de armazenar detalhes do cliente e da conta acontece depois que os detalhes estão sendo fornecidos pelo Assistente de Atendimento ao Cliente. O Diagrama de fluxo de dados não implica tal coisa. É nosso senso comum que nos leva a interpretar o diagrama na forma como o entendemos naturalmente. Estritamente falando, o diagrama apenas nos diz que o processo Open Account recebe detalhes do cliente e produz os detalhes do cliente e da conta, sem ordem especificada. Observe que o Diagrama de fluxo de dados não responde de que maneira e em que ordem a informação está sendo usada em todo um sistema. Se esta informação é importante e vale a pena mencionar, considere modelá-la com diagramas como o Diagrama de Processo de Negócios BPMN ou Diagrama de Atividades UML. O processo Verificar Transação recebe os detalhes da transação da loja de dados da Transação e transmite-a ao Cliente. Um Cliente pode depositar dinheiro comprovando o montante do depósito e o resultado é o saldo da conta atualizado armazenado no armazenamento de dados da conta. Da mesma forma, um Cliente pode retirar dinheiro. O resultado é que ele receberá o montante Retirado e o saldo da conta atualizado será armazenado no armazenamento de dados da Conta. Finalmente, tanto o Cliente como o Agente podem iniciar o processo de Solicitação de Lugar, o que resulta em que os detalhes da transação sejam armazenados no armazenamento de dados da Transação. O processo do pedido de lugar também passa os detalhes da transação para o Stock Exchange Center. Que é uma entidade fora do escopo do sistema. Na próxima seção, vamos apresentar uma maneira de representar esse tipo de entidade. Nível 2 DFD Assim como o processo em contexto DFD, os processos no DFD de nível 1 também podem ser decompostos em um nível mais profundo ou mesmo em níveis de detalhes do processo. A figura abaixo mostra o DFD de nível 2 do processo de Solicitação de Lugar. As entidades externas e os estoques de dados neste DFD correspondem aos mostrados no nível superior (ou seja, o diagrama acima). O que o torna diferente é a quebra do processo de Pedido de Lugar no processo de Pedido de Lugar (Online) e Processo de Pedido de Lugar (Offline). Com base neste diagrama, sabemos que um Cliente pode executar a Ordem de Lugar (Online) ao fornecer os detalhes da Ordem, enquanto um corretor pode executar o Pedido de Lugar (Telefone) também fornecendo os detalhes da Ordem em qualquer caso, fazendo com que os detalhes da transação sejam armazenados na loja de dados da Transação E passou para o Stock Exchange Center. Usando estereótipo para modelar um tipo especial de entidade Os valores de estereótipo e etiquetados são tipos de mecanismos de extensibilidade introduzidos pelo Grupo de Gerenciamento de Objetos (OMG). Permite aos designers ampliar o vocabulário da UML para criar novos elementos modelo. Como uma ferramenta de design de software, o Visual Paradigm amplia o suporte de estereótipos a padrões não UML como DFD e ERD. Pegue a plataforma de negociação de valores como exemplo, podemos definir um estereótipo de Terceiro para entidade externa. As entidades externas com o estereótipo atribuído são ditas ser uma espécie de entidade terceirizada. Esteja ciente do nível de detalhes. Neste exemplo do Diagrama de Fluxo de Dados, os detalhes da palavra são usados muitas vezes ao rotular os dados. Nós temos detalhes do cliente, detalhes da transação, etc. E se os escrevamos explicitamente como nome do cliente, endereço de e-mail, trabalho, endereço e número de estoque, valor, preço da oferta. Isso está correto. Bem, não há uma resposta definitiva a esta pergunta, mas tente Faça uma pergunta ao tomar uma decisão. Por que você está desenhando um DFD Na maioria dos casos, Diagrama de fluxo de dados é desenhado na fase inicial do desenvolvimento do sistema, onde muitos detalhes ainda não foram confirmados. O uso de terminologias gerais como detalhes, informações, credenciais certamente deixa espaço para discussão. No entanto, usar termos gerais pode ser um pouco de falta de detalhes e tornar o design perdido sua utilidade. Então, isso depende do propósito do seu projeto. Não descoberto em um Diagrama de fluxo de dados, nos concentramos nas interações entre o sistema e as partes externas, ao invés das comunicações internas entre as interfaces. Portanto, os fluxos de dados entre as interfaces e os armazenamentos de dados usados são considerados fora do escopo e não devem ser mostrados no diagrama. Não misture fluxo de dados e fluxo de processo Alguns designers podem se sentir desconfortáveis quando vêem um conector que se conecta de um armazenamento de dados a um processo, sem ver o passo da solicitação de dados exibida no diagrama de alguma forma. Alguns deles tentarão representar um pedido, adicionando um conector entre um processo e um armazenamento de dados, rotulando um pedido ou solicitação de algo, o que é errado. Tenha em mente que o Diagrama de fluxo de dados foi projetado para representar a troca de informações. Os conectores em um diagrama de fluxo de dados são para representar dados, não para representar fluxo de processo, passo ou qualquer outra coisa. Quando rotulamos um fluxo de dados que termina em uma loja de dados, uma solicitação, isso significa, literalmente, que estamos passando uma solicitação como dados para um armazenamento de dados. Embora este possa ser o caso no nível de implementação, como alguns dos SGBD suportam o uso de funções, que ingerem alguns valores como parâmetros e retornam um resultado, no Diagrama de Fluxo de Dados, tendemos a tratar o armazenamento de dados como um único suporte de dados que não Possui qualquer capacidade de processamento. Se você deseja modelar o fluxo do sistema ou fluxo de processo, use o Diagrama de Atividades UML ou o Diagrama de Processo de Negócios BPMN em vez disso. Se você deseja modelar a estrutura interna do armazenamento de dados, use o Diagrama de Relacionamento de Entidade. Você pode estar interessado em Diagrama de fluxo de dados: Exemplos - Sistema de pedidos de alimentos 16 de fevereiro de 2015 Exibições: 292,129 PDF Link Edição (s) compatível (s): Enterprise, Professional, Standard, Modeling Data Flow Diagram (DFD) fornece uma representação visual do fluxo de informações (Ou seja, dados) dentro de um sistema. Ao desenhar um Diagrama de fluxo de dados, você pode informar as informações fornecidas e entregues a alguém que participe nos processos do sistema, as informações necessárias para completar os processos e as informações necessárias para serem armazenados e acessados. Este artigo descreve e explica Diagrama de fluxo de dados (DFD) usando um sistema de pedidos de alimentos como exemplo. O Sistema de Pedidos de Alimentos Exemplo Contexto DFD Um diagrama de contexto é um diagrama de fluxo de dados que mostra apenas o nível superior, também conhecido como Nível 0. Neste nível, existe apenas um nó de processo visível que representa as funções de um sistema completo em relação a Como ele interage com entidades externas. Alguns dos benefícios de um Diagrama de Contexto são: Mostra a visão geral dos limites de um sistema. Nenhum conhecimento técnico é necessário para entender com a notação simples. Simples de desenhar, alterar e elaborar como sua notação limitada. A figura abaixo mostra um contexto Diagrama de fluxo de dados Que é desenhado para um sistema de pedidos de alimentos. Contém um processo (forma) que representa o sistema para modelar, neste caso, o sistema de pedidos de alimentos. Também mostra os participantes que irão interagir com o sistema, chamados de entidades externas. Neste exemplo, fornecedor. Cozinha . Gerente e Cliente são as entidades que irão interagir com o sistema. Entre o processo e as entidades externas, existem fluxos de dados (conectores) que indicam a existência de troca de informações entre as entidades e o sistema. Contexto DFD é a entrada de um modelo de fluxo de dados. Contém um e um único processo e não mostra qualquer armazenamento de dados. Nível 1 DFD A figura abaixo mostra o DFD de nível 1, que é a decomposição (ou seja, a quebra) do processo do Sistema de Ordem de Alimentos mostrado no contexto DFD. Leia o diagrama e depois apresentamos alguns dos principais conceitos baseados neste diagrama. O exemplo do Diagrama de fluxo de dados do sistema de pedidos de alimentos contém três processos, quatro entidades externas e duas lojas de dados. Com base no diagrama, sabemos que um Cliente pode fazer uma Ordem. O processo Order Food recebe a Ordem. Encaminha para a cozinha. Guarde-o no armazenamento de dados da Ordem e armazene os detalhes de inventário atualizados no armazenamento de dados do Inventário. O processo também entrega uma conta ao cliente. O Gerente pode receber Relatórios através do processo Gerar Relatórios, que leva Detalhes do Inventário e Pedidos como entrada do armazenamento de dados Inventário e Ordem, respectivamente. O gerente também pode iniciar o processo de Inventário de Pedidos ao fornecer uma ordem de Inventário. O processo encaminha o pedido de Inventário para o Fornecedor e armazena os detalhes de Inventário atualizados no armazenamento de dados do Inventário. Diagrama de fluxo de dados Dicas e precauções Os rótulos de processo devem ser frases verbais. As lojas de dados são representadas por substantivos. Um armazenamento de dados deve estar associado a pelo menos um processo. Uma entidade externa deve estar associada a pelo menos um processo. Não deixe que ele seja muito complexo normalmente 5 - 7 Pessoas médias podem gerenciar processos O DFD não é determinista - a numeração não indica necessariamente uma seqüência, é útil na identificação dos processos quando se discute com os usuários. As lojas de dados não devem ser conectadas a uma entidade externa, caso contrário, significaria que você está dando um externo Acesso direto de entidade aos seus arquivos de dados Os fluxos de dados não devem existir entre 2 entidades externas sem passar por um processo. Um processo que possui entradas, mas sem saídas, é considerado um processo de buraco negro. Não misture fluxo de dados e fluxo de processo. Alguns designers podem sentir Desconfortável ao ver um conector que se conecta de um armazenamento de dados a um processo, sem ver o passo da solicitação de dados exibida no diagrama de alguma forma. Alguns deles tentarão representar um pedido, adicionando um conector entre um processo e um armazenamento de dados, rotulando um pedido ou solicitação de algo, o que é errado. Tenha em mente que o Diagrama de fluxo de dados foi projetado para representar a troca de informações. Os conectores em um diagrama de fluxo de dados são para representar dados, não para representar fluxo de processo, passo ou qualquer outra coisa. Quando rotulamos um fluxo de dados que termina em uma loja de dados, uma solicitação, isso significa, literalmente, que estamos passando uma solicitação como dados para um armazenamento de dados. Embora este possa ser o caso no nível de implementação, como alguns dos SGBD suportam o uso de funções, que ingerem alguns valores como parâmetros e retornam um resultado, no Diagrama de Fluxo de Dados, tendemos a tratar o armazenamento de dados como um único suporte de dados que faz Não possuem qualquer capacidade de processamento. Se você deseja modelar o fluxo do sistema ou fluxo de processo, use o Diagrama de Atividades UML ou o Diagrama de Processo de Negócios BPMN em vez disso. Se você deseja modelar a estrutura interna do armazenamento de dados, use o Diagrama de Relacionamento de Entidade. Você pode estar interessado emSlideshare usa cookies para melhorar a funcionalidade e o desempenho, e para lhe fornecer publicidade relevante. Se continuar a navegar no site, você aceita o uso de cookies neste site. Veja o nosso Contrato de Usuário e Política de Privacidade. O Slideshare usa cookies para melhorar a funcionalidade e o desempenho e fornecer publicidade relevante. Se continuar a navegar no site, você aceita o uso de cookies neste site. Consulte nossa Política de Privacidade e Contrato de Usuário para obter detalhes. Explore todos os seus tópicos favoritos no aplicativo SlideShare Obtenha o aplicativo SlideShare para Salvar para mais tarde, mesmo offline Continuar para o site móvel Fazer o upload de login Assinar Duplo toque para diminuir o zoom Um relatório de projeto sobre negociação online Compartilhe este SlideShare LinkedIn Corporation copy 2017
No comments:
Post a Comment