Diagrama de fluxo de dados

Content

História

A notação DFD baseia -se na teoria dos gráficos, originalmente usada na pesquisa operacional para modelar o fluxo de trabalho nas organizações. O DFD se originou do diagrama de atividades usado na metodologia estruturada de análise e técnica de projeto no final da década de 1970. Os popularizadores do DFD incluem Edward Yourdon, Larry Constantine, Tom DeMarco, Chris Gane e Trish Sarson.

Os diagramas de fluxo de dados (DFD) rapidamente se tornaram uma maneira popular de visualizar as principais etapas e dados envolvidos nos processos do sistema de software. Os DFDs eram geralmente usados ​​para mostrar fluxo de dados em um sistema de computador, embora, em teoria, fossem aplicados à modelagem de processos de negócios. Os DFDs foram úteis para documentar os principais fluxos de dados ou explorar um novo design de alto nível em termos de fluxo de dados.

Componentes DFD

Diagrama de fluxo de dados - notação YourDon/DeMarco

O DFD consiste em processos, fluxos, armazéns e terminadores. Existem várias maneiras de visualizar esses componentes DFD.

Processo

O processo (função, transformação) faz parte de um sistema que transforma as entradas em saídas. O símbolo de um processo é um círculo, um oval, um retângulo ou um retângulo com cantos arredondados (de acordo com o tipo de notação). O processo é nomeado em uma palavra, uma frase curta ou uma frase que é claramente expressar sua essência.

Fluxo de dados

O fluxo de dados (Flow, Dataflow) mostra a transferência de informações (às vezes também material) de uma parte do sistema para outra. O símbolo do fluxo é a seta. O fluxo deve ter um nome que determine quais informações (ou qual material) estão sendo movidas. Exceções são fluxos onde fica claro quais informações são transferidas através das entidades vinculadas a esses fluxos. As mudanças de material são modeladas em sistemas que não são meramente informativos. O fluxo deve transmitir apenas um tipo de informação (material). A seta mostra a direção do fluxo (também pode ser bidirecional se as informações de/para a entidade forem logicamente dependentes - por exemplo, perguntas e respostas). Fluxos Link Processos, armazéns e terminadores.

Armazém

O armazém (armazenamento de dados, armazenamento de dados, arquivo, banco de dados) é usado para armazenar dados para uso posterior. O símbolo da loja são duas linhas horizontais, o outro modo de visão é mostrado na notação DFD. O nome do armazém é um substantivo plural (por exemplo, ordens) - deriva dos fluxos de entrada e saída do armazém. O armazém não precisa ser apenas um arquivo de dados, mas também pode ser, por exemplo, uma pasta com documentos, um gabinete de arquivamento ou um conjunto de discos ópticos. Portanto, ver o armazém em um DFD é independente da implementação. O fluxo do armazém geralmente representa a leitura dos dados armazenados no armazém, e o fluxo para o armazém geralmente expressa entrada ou atualização de dados (às vezes também excluindo dados). O armazém é representado por duas linhas paralelas entre as quais o nome da memória está localizado (pode ser modelado como um nó Buffer UML).

o Exterminador do Futuro

O Terminator é uma entidade externa que se comunica com o sistema e fica fora do sistema. Pode ser, por exemplo, várias organizações (por exemplo, um banco), grupos de pessoas (por exemplo, clientes), autoridades (por exemplo, um escritório tributário) ou um departamento (por exemplo, um departamento de resistência humana) da mesma organização, que não pertence para o sistema modelo. O Terminator pode ser outro sistema com o qual o sistema modelado se comunica.

Regras para criar DFD

Os nomes das entidades devem ser compreensíveis sem mais comentários. O DFD é um sistema criado por analistas com base em entrevistas com usuários do sistema. É determinado para os desenvolvedores do sistema, por um lado, o empreiteiro do projeto, por outro, para que os nomes das entidades sejam adaptados para usuários ou profissionais de domínio do modelo ou amador. Os nomes das entidades devem ser gerais (independentes, por exemplo, indivíduos específicos que realizam a atividade), mas devem especificar claramente a entidade. Os processos devem ser numerados para mapeamento e encaminhamento mais fáceis para processos específicos. A numeração é aleatória, no entanto, é necessário manter a consistência em todos os níveis de DFD (consulte a hierarquia DFD). O DFD deve ser claro, pois o número máximo de processos em um DFD é recomendado de 6 a 9, o mínimo é 3 processos em um DFD. A exceção é o chamado diagrama contextual, onde o único processo simboliza o sistema modelo e todos os terminadores com os quais o sistema se comunica.

Consistência do DFD

O DFD deve ser consistente com outros modelos do diagrama de relacionamento do sistema - entidade, diagrama de transição de estado, dicionário de dados e modelos de especificação de processos. Cada processo deve ter seu nome, entradas e saídas. Cada fluxo deve ter seu nome (exceção veja o fluxo). Cada armazenamento de dados deve ter fluxo de entrada e saída. Os fluxos de entrada e saída não precisam ser exibidos em um DFD - mas eles devem existir em outro DFD descrevendo o mesmo sistema. Uma exceção é o armazém do lado de fora do sistema (armazenamento externo) com o qual o sistema se comunica.

Hierarquia DFD

Para tornar o DFD mais transparente (ou seja, não muitos processos), os DFDs de vários níveis podem ser criados. Os DFDs que estão em um nível superior são menos detalhados (agregado DFD mais detalhado em níveis mais baixos). O DFD contextual é o mais alto da hierarquia (ver regras de criação do DFD). O chamado nível zero é seguido pelo DFD 0, começando com a numeração do processo (por exemplo, processo 1, processo 2). Na próxima, o chamado primeiro nível - DFD 1 - a numeração continua. Por exemplo. O processo 1 é dividido nos três primeiros níveis do DFD, que são numerados 1,1, 1,2 e 1,3. Da mesma forma, os processos no segundo nível (DFD 2) são numerados, por exemplo, 2.1.1, 2.1.2, 2.1.3 e 2.1.4. O número de níveis depende do tamanho do sistema modelo. Os processos DFD 0 podem não ter o mesmo número de níveis de decomposição. O DFD 0 contém as funções do sistema mais importantes (agregadas). O nível mais baixo deve incluir processos que possibilitem criar uma especificação de processo para aproximadamente uma página A4. Se a mini-especificação for mais longa, é apropriado criar um nível adicional para o processo em que será decomposto em vários processos. Para uma visão geral clara de toda a hierarquia do DFD, um diagrama vertical (seção transversal) pode ser criado. O armazém é exibido no nível mais alto, onde é usado pela primeira vez e também em todos os níveis mais baixos.

Veja também

Activity diagramBusiness Process Model and NotationControl-flow diagramData islandDataflowDirected acyclic graphDrakon-chartFunctional flow block diagramFunction modelIDEF0PipelineStructured analysis and design techniqueStructure chartSystem context diagramValue-stream mappingWorkflowList of graphical methods

Bibliografia

Scott W. Ambler. The Object Primer 3rd Edition Agile Model Driven Development with UML 2Schmidt, G., Methode und Techniken der Organisation. 13. Aufl., Gießen 2003Stahlknecht, P., Hasenkamp, U.: Einführung in die Wirtschaftsinformatik. 12. Aufl., Berlin 2012Gane, Chris; Sarson, Trish. Structured Systems Analysis: Tools and Techniques. New York: Improved Systems Technologies, 1977. ISBN 978-0930196004. P. 373Demarco, Tom. Structured Analysis and System Specification. New York: Yourdon Press, 1979. ISBN 978-0138543808. P. 352.Yourdon, Edward. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. New York: Yourdon Press, 1979. ISBN 978-0138544713. P. 473.Page-Jones, Meilir. Practical Guide to Structured Systems Design. New York: Yourdon Press, 1988. ISBN 978-8120314825. P. 384.Yourdon, Edward. Modern Structured Analysis. New York: Yourdon Press, 1988. ISBN 978-0135986240. P. 688.