Você está na página 1de 8

Universidade Federal do Rio Grande Centro de Cincias Computacionais Engenharia de Computao

Sistemas de Informao e Programao I

Diagrama de Fluxo de Dados


1 Introduo
Dentre as tcnicas estruturadas para anlise orientada a processos, o Diagrama de Fluxo de Dados (DFD) , com certeza, a mais clssica e a mais utilizada. A histria da Anlise Estruturada, como Metodologia de Desenvolvimento de Sistemas, se confunde com a do Diagrama de Fluxo de Dados, pois esta tcnica caracteriza todo o desenvolvimento estruturado de sistemas. Este texto apresenta os conceitos e notaes relativos ao Diagrama de Fluxo de Dados, principalmente na viso dos grandes autores relacionados Anlise Estruturada: Tom DeMarco; Chris Gane & Trish Sarson; e Eduard Yourdon.

2 Consideraes iniciais
O Diagrama de Fluxo de Dados uma ferramenta para modelagem de fluxo de dados, por meio da representao de processos que utilizam e geram dados. Tom DeMarco, um dos primeiros autores sobre Diagrama de Fluxo de Dados, define o DFD como sendo uma representao em rede de um sistema (...) que (...) pode ser automatizado, manual ou misto. O Diagrama de Fluxo de Dados retrata o sistema em termos de suas partes componentes, com todas as interfaces entre os componentes indicadas" (Anlise Estruturada e Especificao de Sistemas, Ed. Campus, 1989). Edward Yourdon, define o DFD como uma ferramenta de modelagem que nos permite imaginar um sistema como uma rede de processos funcionais, interligados por dutos e tanques de armazenamento de dados (Anlise Estruturada Moderna, Ed. Campus, 1990). O DFD um dos principais componentes da chamada especificao estruturada. No ciclo de vida estruturado, a fase de anlise do sistema consiste em transformar os requisitos do usurio em especificao estruturada. Os requisitos do sistema incluem as necessidades do usurio (o que ele precisa do sistema para que seus objetivos sejam atingidos) e o ambiente do sistema (como o sistema funciona, seus problemas e suas oportunidades). Os requisitos do sistema so obtidos pelo analista de sistemas atravs de tcnicas de levantamento de dados, das quais a mais utilizada e aplicada na maioria dos casos a entrevista. O analista de sistemas entrevista os usurios do sistema para compreender os seus requisitos e os documenta, ainda que de forma textual, para que estes requisitos sirvam de base para uma das principais tarefas do ciclo de vida do desenvolvimento do software que a anlise. Na anlise, os requisitos so transformados
1

em especificao estruturada, que composta basicamente pelo Diagrama de Fluxo de Dados, pelo Dicionrio de Dados, pelo Diagrama Entidade-Relacionamento, pelo Diagrama de Descrio de Entidades e pelas Especificaes de Processos (em Portugus Estruturado, Tabela de Deciso ou rvore de Deciso). A especificao estruturada a documentao da anlise feita pelo analista ou grupo de analistas junto com os usurios, onde o sistema visto em termos conceituais e funcionais (e, s vezes, at em termos fsicos do sistema atual), e todos os componentes, que precisam ser conhecidos e representados sem ambigidade, omisso ou redundncia, so modelados para que o projeto do sistema possa ser feito. O DFD possui apenas quatro elementos que so necessrios e suficientes para modelar o sistema em termos conceituais e funcionais. Estes elementos so: Entidade externa (chamada assim por Gane & Sarson e chamada de terminador, por Yourdon, ou por ponto terminal, por Martin & McClure, ou ainda de fontes e destinos de dados, por DeMarco): de onde partem ou para onde chegam os dados (origem e destino); Fluxo de dados: indicam os dados e o caminho por onde percorrem no sistema; Processo ou funo: ponto de processamento dos dados (tratamento, alterao ou manuseio de dados); Depsito de dados (assim chamado por Gane & Sarson e Martin & McClure e chamada de depsito, por Yourdon, ou arquivo, por DeMarco): indica qualquer tipo de armazenamento de dados. A representao atravs de um DFD feita em nveis ou camadas, partindo-se sempre de uma viso mais global para a viso mais detalhada ou especfica. Esta abordagem chamada de top-down. As vantagens de utilizar o Diagrama de Fluxo de Dados para modelagem de sistemas so vrias, dentre elas podemos citar: Representar o sistema atravs de um DFD uma maneira sistemtica de definio e especificao; DFD uma especificao que possui algum formalismo, tal como proposto nos princpios da Engenharia de Software; DFD permite registrar as necessidades e preferncias do usurio; DFD permite uma viso grfica do problema, evitando as ambigidades, redundncias e omisses prprias de uma especificao narrativa; A utilizao do DFD permite que o mesmo instrumento de anlise sirva tambm de documentao; uso de DFD facilita o controle de projeto.

3 Smbolos do DFD
A notao do DFD grfica e utiliza um smbolo para cada um dos quatro elementos que compem o diagrama. A figura 2.1 mostra estes smbolos nas duas verses mais utilizadas para se desenhar Diagramas de Fluxo de Dados. Por uma questo de padronizao, a notao a ser utilizada na disciplina Anlise de Sistemas I a proposta por Yourdon e DeMarco. Na realidade, as duas notaes atendem sintaxe do DFD, no havendo, portanto, uma que seja melhor do que a outra. A notao proposta por Gane & Sarson mais difcil de fazer mo durante os primeiros momentos de

definio, mas, em compensao, mais fcil de ser feito no computador. A notao de Yourdon e DeMarco facilmente feita mo e mais difcil de ser computadorizada.

Figura 1 Smbolos do Diagrama de Fluxo de Dados. As entidades externas so, geralmente, categorias lgicas de coisas ou pessoas que representam uma fonte ou destino para as transaes. Exemplos: cliente, empregado, fornecedor, contribuinte, segurado, etc. Elas tambm podem ser uma fonte ou destino especfico, como: Departamento de Contas, Receita Federal, Escritrio do Presidente, etc. Quando o sistema enfocado recebe dados de um outro sistema ou fornece dados a ele, aquele outro sistema considerado entidade externa. Ao identificar alguma coisa ou sistema como entidade externa, estar sendo afirmado, implicitamente, que esta entidade est fora dos limites do sistema considerado. O fluxo de dados pode ser considerado como um tubo por onde passam pacotes de dados. Os fluxos de dados so os nicos elementos de ligao de um DFD. Isto significa que os outros elementos podem ligar-se entre si, a no ser que seja atravs de um fluxo de dados. Quando mais de um elemento de dados tem a mesma origem e o mesmo destino, eles podem ser representados por um nico fluxo de dados, separandose seus nomes pelo conector +. Por exemplo, se um cliente deve apresentar, a um sistema de vendas, seu nome e seu nmero do RG, esta representao pode ser feita num nico fluxo de dados, com o nome nome do cliente + rg. Os processos so definidos atravs de um identificador e um nome significativo. O identificador geralmente um nmero, que tem como nico propsito identificar o processo. Isto significa que o nmero atribudo como identificador no deve se repetir e no indica ordem ou seqncia de execuo. No h razo para associar significados a nmeros de processos, pois alguns deles sero subdivididos em dois ou mais processos (o que significa que novos nmeros surgiro) ou que vrios processos sero agrupados em um nico (significando que alguns nmeros desaparecero), no decorrer do trabalho de anlise. A partir do momento em que o processo recebe a identificao, esta no deve ser modificada, exceto para desmembramentos ou agrupamentos, pois serve como referncia para os fluxos de dados e para decomposio do processo em nveis inferiores. A descrio da funo deve ser um sentena imperativa, constituda por um verbo ativo no infinitivo seguido de um objeto direto. Esta sentena deve ser a mais simples possvel, como: extrair vendas mensais; dar entrada de detalhes do novo cliente, averiguar se cliente tem crdito, etc. Deve ser observado que, nestas frases, o sujeito indeterminado. No momento em que um sujeito for introduzido, h um compromisso fsico sobre o desempenho da funo, o que pode ser til quando estuda-se um sistema

existente para denotar o departamento, ou o programa, que desempenha uma funo. De forma semelhante, quando a anlise est completa e o projeto fsico do novo sistema est sendo desenvolvido, conveniente observar como a funo ser fisicamente desempenhada. Os depsitos de dados indicam armazenamento, sem o compromisso quanto ao aspecto fsico (se em computador, arquivo de uma sala, ou uma gaveta, por exemplo). Durante a anlise, so detectados certos lugares onde haver dados armazenados entre processos. Quando um processo armazena dados, a seta do fluxo de dados aponta para o depsito de dados; por outro lado, quando um processo efetua acesso a dados armazenados em um depsito (em forma de leitura), a representao feita com a seta do fluxo de dados apontada para o processo e o nome do fluxo de dados englobando o grupo de elementos de dados que est sendo recuperado pelo processo.

4 Sintaxe do DFD
Ao se desenhar um Diagrama de Fluxo de Dados, algumas regras devem ser seguidas para que sejam vlidas as especificaes geradas pelo grfico. Estas regras so as seguintes: 1. Todos os objetos do DFD devem ter identificadores. Entende-se por objetos do DFD as entidades externas, os processos e os depsitos de dados. Cada entidade externa deve ter um identificador representado por uma letra minscula no canto superior esquerdo do smbolo (na notao de Yourdon e DeMarco, o identificador de entidade externa pode ser omitido). Os processos so identificados por nmeros, de acordo com o nvel de detalhamento que representam. Os depsitos de dados so identificados apenas pela notao de Gane & Sarson e os identificadores devem respeitar o formato Dx, onde x um nmero seqencial usado para identificar o depsito. 2. Todos os objetos e fluxos de dados do DFD devem ter nome. Os quatro elementos do DFD devem ter nomes significativos. Os nomes dos fluxos de dados devem ser escritos com todas as letras em minsculo. Os nomes dos processos devem comear com letra maiscula e as demais letras minsculas. As entidades externas devem ter seus nomes escritos com todas as letras em maisculo ou pela primeira em maisculo e as demais em minsculo. Os nomes das entidades externas geralmente so representados no singular. Os depsitos de dados tm seus nomes representando plural ou coletivo e devem comear com letra maiscula e as demais em minsculo (em algumas notaes, aceita-se utilizar todas as letras maisculas para nome de depsito de dados). 3. Todos os processos devem ter pelo menos um fluxo de dados de entrada e um de sada. Os processos representam funes que so executadas sobre dados de entrada, transformando-os em dados de sada. Neste sentido, no possvel ter em um DFD processos do tipo gerao espontnea, onde no h nenhum fluxo de dados de entrada e um ou mais de sada. Tambm no permitido processo do tipo buraco negro, que consiste em um ou mais fluxos de dados de entrada, sem gerar nenhum dado de sada. 4. Todos os fluxos de dados devem ter uma origem e um destino. Cada fluxo de dados deve ser gerado por um processo, entidade externa ou depsito de dados. Igualmente, todos os fluxos de dados devem ser usados por um processo, entidade externa ou depsito de dados. Portanto, no permitido, no DFD, um fluxo de dados que comece no

nada e v para algum objeto do DFD, bem como um fluxo de dados que seja gerado por um objeto do DFD e vai para o nada. 5. Todos os fluxos de dados devem comear ou terminar num processo. No deve existir, no DFD, ligao entre dois depsitos de dados ou duas entidades externas ou, ainda, entre um depsito de dados e uma entidade externa, sem que haja um processo no meio para fazer esta ligao. Isto ocorre em funo de que as aes do DFD so, todas elas, executadas pelos processos. Um fluxo de dados no tem a capacidade de mover-se sozinho no sistema. H sempre a necessidade de um processo envi-lo para algum lugar ou peg-lo de algum lugar. possvel, porm, haver um fluxo de dados cuja origem seja um processo e o destino, outro processo. 6. Todos os fluxos de dados devem ter uma nica seta direcional. Um fluxo de dados caracteriza-se por uma nica origem e um nico destino. Portanto, nos casos em que a interface entre um objeto qualquer e um processo seja um mesmo dado que entra e que sai do processo, este dado deve ser representado em dois fluxos de dados, um em cada sentido. 7. Todos os objetos e fluxos de dados devem ter nomes significativos. Nome significativo quer dizer um nome relevante para o sistema. Como regras para a formao de nomes, deve-se respeitar: para entidade externa, o nome deve estar no singular; para depsito de dados, o nome deve estar no plural; para fluxo de dados, o nome no deve indicar ao, no contendo verbo em seu incio; para processo, o nome deve representar ao, comeando, portanto, com verbo. Os processos devem ter seu nome formado por verbo no infinitivo + objeto de direto. 8. Todos os depsitos de dados devem representar objetos de interesse para o sistema. Depsitos de dados somente de leitura ou somente de escrita devem ser bem avaliados, pois podem significar algum armazenamento de dados fora do contexto do sistema. 9. A duplicao de smbolos e o cruzamento deve ser evitado. O desenho do DFD deve ser feito de forma a evitar a necessidade de representar um mesmo objeto duas vezes ou cruzar linhas para fazer as ligaes entre os objetos. Quando no for possvel, deve-se minimizar o uso destes recursos e, assim mesmo, tomar algumas providncias. Se for necessrio duplicar uma entidade externa, deve-se marc-la com uma linha inclinada no canto inferior direito (formando uma espcie de tringulo na extremidade inferior direita do smbolo da entidade), para cada repetio. Se for necessrio duplicar um depsito de dados, na notao de Gane & Sarson, deve-se acrescentar uma linha vertical entre o identificador e o nome do depsito para cada repetio que ocorrer. No caso de haver cruzamento de linhas (fluxos de dados), deve-se usar a estratgia de fazer um arco no cruzamento, como se um fluxo estivesse passando por cima do outro, ou uma fenda, deixando um pequeno espao em branco nas proximidades do cruzamento, dando a impresso de que o fluxo de dados est passando por baixo do outro.

5 Nveis de representao do DFD Tcnicas de fracionamento da complexidade e expanso


Um DFD pode ser desenhado em vrios nveis, dependendo da complexidade e grau de detalhamento do sistema. Pelo menos dois nveis ocorrem em qualquer sistema: o Diagrama de Contexto e o DFD nvel 0.

Primeiramente, o sistema modelado em termos de suas entradas e sadas de dados e as origens e destinos destes dados. Esta modelagem chamada de Diagrama de Contexto e representa o sistema como sendo um nico processo que troca informaes com as entidades externas, sem representar os depsitos de dados do sistema. Em seguida, feita uma decomposio do Diagrama de Contexto em um DFD que mantm a coerncia com o Diagrama de Contexto, ou seja, mantm as mesmas entradas e sadas e as mesmas origens e destinos de cada dado. Porm, neste novo nvel, chamado de DFD nvel 0, acrescentado o detalhamento dos processos, que operam sobre os fluxos de dados, e os depsitos de dados, que representam o armazenamento de dados. Neste nvel, novos fluxos de dados intermedirios podem surgir, desde que mantenha a coerncia com o Diagrama de Contexto. Os depsitos de dados so criados, no DFD nvel 0, sempre que dados so armazenados para uso posterior ou quando no h seqncia imediata na execuo de dois processos, onde um gera uma informao que usada pelo segundo. O detalhamento de processos do DFD nvel 0 se d no nvel 1. Ao DFD nvel aplica-se as mesmas regras do DFD nvel 0. Porm, sua representao restringe-se ao detalhamento de um determinado processo daquele diagrama, apresentando coerncia com o contexto daquel nvel, ou seja, mesmas relaes de entrada e sada e origens e destinos de dados representados no nvel 0. O detalhamento de processos do DFD nvel 1 se d no nvel 2, da mesma forma. E assim sucessivamente, toda vez que um processo necessitar de detalhamento, este feito no nvel seguinte. importante destacar que, no Diagrama de Contexto, o nico processo representado significa o sistema em foco. Portanto, no aplica-se, a este diagrama, a necessidade de que o processo tenha um identificador e de que o nome seja formado por verbo, pois o nome do processo representado no Diagrama de Contexto o nome do prprio sistema. A aplicao dessas tcnicas de nivelamento permite um fracionamento da complexidade de sistemas grandes, bem como a expanso da compreenso de sistemas que so construdos na abordagem top-down, uma vez que possvel ir detalhando cada vez mais o funcionamento do sistema, tendo como ponto de partida uma viso geral das principais funes do mesmo. importante ter em mente que cada processo no nvel superior do DFD de um sistema pode ser expandido ou explodido para tornar-se um novo diagrama. Cada processo no nvel inferior tem que se relacionar com o processo de nvel superior. dado um nmero de identificao ao processo de nveis mais baixos, onde este nmero um valor decimal do processo de nvel superior, isto , o processo 4, do DFD nvel 0, decomposto em 4.1, 4.2, 4.3, etc., no DFD nvel 1, e, se for necessrio um maior detalhamento, o processo 4.2, por exemplo, pode ser decomposto nos processos 4.2.1, 4.2.2, etc., no DFD nvel 2, e assim por diante. A maneira mais clara de representar o processo de expanso desenhar DFDs de menor nvel dentro da divisa que representa o smbolo do processo de nvel superior. bvio que todos os fluxos de dados que entram e saem do processo de maior nvel devem entrar e sair da divisa. Os depsitos de dados s so mostrados dentro da divisa quando so criados e processos apenas por este processo.

6 Diretrizes para desenhar um DFD


Pode-se considerar resumidamente que os passos envolvidos no projeto de um Diagrama de Fluxo de Dados para um sistema proposto ou j existente so os seguintes: 1. Identificar as entidades externas envolvidas. Isto envolve decidir sobre a fronteira ou divisa preliminar de um sistema. Quando houver dvida, deve-se incluir no sistema a primeira camada externa de sistemas manuais e automatizados, com a qual se ir lidar. Deve-se lembrar que fluxos de dados so criados quando alguma coisa ocorre no mundo externo, isto quando uma pessoa decide comprar algo, quando ocorre um acidente, ou um caminho chega ao ponto de carregamento. Se for possvel, o fluxo de dados deve iniciar-se na fonte bsica dos dados. 2. Desenhar o Diagrama de Contexto, identificando os dados que vm e vo para as entidades externas identificadas. 3. Identificar as entradas e sadas programadas que podem ser esperadas no curso normal dos negcios. medida que a lista aumenta, deve-se procurar descobrir agrupamentos lgicos de entradas e sadas. As entradas e sadas que esto associadas unicamente s condies de erro e exceo devem ser marcadas. 4. Identificar as consultas e os pedidos de informao que possam surgir. Devem ser especificados fluxos de dados que definam a informao dada ao sistema e aquela que diga o que requerido do sistema. 5. Pegar uma grande folha de papel e, comeando no canto esquerdo com a entidade externa que parece ser a principal fonte de entradas, desenhar os fluxos de dados que surgem, os processos logicamente necessrios e os depsitos de dados que paream necessrios. 6. Desenhar o primeiro esboo mo livre e concentrar-se em anotar tudo, exceto erros, excees e decises. 7. Aceitar o fato de que sero necessrios vrios esboos do DFD nvel 0. No deve haver preocupao se o primeiro esboo se parece mais com um novelo. Este pode ser desvencilhado. 8. Quando o primeiro esboo estiver pronto, verificar se todas as entradas e sadas listadas foram includas, exceto aquelas que tratam dos erros e excees. Deve-se observar, no esboo, quaisquer entradas e sadas normais que no puderam ser includas. 9. Produzir um segundo esboo mais claro, lembrando que o objetivo um diagrama com processos nicos e um nmero mnimo de interseces de fluxos de dados. Para minimizar os cruzamentos, primeiramente deve-se duplicar entidades externas, se necessrio. Em seguida, duplica-se os depsitos de dados, se necessrio. E, finalmente, se no houver uma forma de desenhar o diagrama sem que haja interseco de fluxo de dados, deve-se permitir que haja o desenho de cruzamentos. Deve-se verificar se ainda possvel um novo esboo que seja mais claro, alm de verificar, junto lista de entradas e sadas, se h algo que ainda no se tenha conseguido incluir. 10. Rever o segundo esboo com um representante do usurio que esteja disposto a colaborar, ou com algum que conhea a aplicao, explicando que apenas um esboo e anotando qualquer mudana resultante da reviso.

11. Produzir uma expanso de nvel inferior para cada processo definido no segundo esboo. Deve-se resolver o tratamento dos erros e excees e, se necessrio, incorporar as modificaes no diagrama de nvel superior. Observao: se houver disponibilidade de ferramenta automatizada para desenhar o DFD, todas as verses podem ser feitas por meio da ferramenta.