dfd - diagrama de fluxo de dados

DFD – Diagramas de Fluxo de Dados

J. Valente de Oliveira

http://w3.ualg.pt/~jvolivei/ep/ep.html 20-10-2000 / EP / DFD - 1

Modelação funcional: Diagramas de Fluxo de Dados � Diagrama de fluxo de dados é uma das mais usadas

ferramentas (e há mais tempo) de modelação funcional de sistemas.

� Sinónimos:

- DFD

- Diagramas de bolhas (ou bolas);

- Modelo de processos (ou de funções)

- Diagrama de fluxo de trabalho

� Um DFD pode ser entendido como uma rede que ilustra como

circulam os dados no interior de um sistema.




DFD típico: Sistema de Reservas de Hotel Um cliente efectua uma reserva num hotel através de uma agência. Depois de verificada a disponibili dade do hotel escolhido é atribuído um quarto, calcula-se a conta, emitido um voucher ao cliente e informado o hotel da reserva.




Componentes de um DFD Os DFD baseiam-se no princípio de que a funcionalidade de um sistema pode ser representada como uma rede que combina 4 componentes fundamentais; a saber:

Processos (ou bolhas ou bolas) Transforma os fluxos de entrada em fluxos de saída. Cada processo tem um nome e um número único. Arquivos Reservatórios ou contentores para os dados existentes no sistema (e.g., ficheiros, pastas de documentos, bases de dados). Cada arquivo tem um nome único.

��

��




Componentes de um DFD (cont.)

Entidades exteriores Fornecem entradas ao sistemas (fontes) ou recebem dados do sistema (terminadores). Existem fora da fronteira do sistema.

Fluxo de dados Modelam a passagem de dados. A seta indica o sentido do fluxo e tem o nome do fluxo associado.

� ��

��




Diversidade de notações Notação Processos Arquivos Entidades Yourdon/ DeMarco SSADM Gane/ Sarson Aktas

!

"$# % &('() & * &(+,% -�% .0/2143()�&(#

!(5* &(+6% - % .0/1(34)�&7#.0# % &('4)�&78 "$# % &('() &

! 9 ! "$# % &('7)�&48

* &(+,% -�% .0/2143()�&(#

* &(+,% -�% .0/2143()�&(#!(5

":# % &7'()�&(8

"$# % &('() &(8 ":# % &('() &

":# % &('() &




Convenções adicionais ;

O cruzamento de linhas de fluxos deve ser minimizado. ;Quando o cruzamento for inevitável, fazer o seguinte:

;

O mesmo arquivo poderá ser desenhado mais do que uma vez.

;

A mesma entidade poderá ser desenhada mais do que uma vez. Exemplos:

":# % &('() & ":# % &('() & "$# % &('()�&OU

< 3() &(# < 3() &(#*

"$# % &('()�&*

< 3() &(#**

< 3() &(#**




Convenções adicionais (cont.) =

Operadores lógicos:

* - conjunção (a e b); > - ou exclusivo (a ou alternativamente b);

O - ou inclusivo (a ou b ou ambos)

?A@CBED FHGHFJILK:MON GHFP

*

>

F �� Q��

R�S��UT�� V��

?H@(BED F�GAFWNX@(IYK�MON GAF




Decomposição (“L evelling” ) Z

DFD de sistemas pequenos são normalmente fáceis de construir.

[Para sistemas não triviais, o número excessivo de processos levanta problemas de interpretação e desvaloriza os méritos dos DFD.

[

Em sistemas de alguma complexidade, os DFD são organizados em níveis.

[Um DFD de um dado nível da hierarquia contém uma explicação funcional mais detalhada de um processo na hierarquia superior.

[A decomposição consiste na subdivisão de um DFD de alto nível numa hieraquia de DFD.




Convenções de decomposição \

Cada processo num dado nível pode ser expandido (explodido) para se tornar num novo DFD;

\

Cada processo de um nível inferior está relacionado com o nível superior e é identificado por um número composto (e.g., 2.1.3);

\

Todos os fluxos de dados que entram e saem do nível superior devem aparecer no nível inferior (validação vertical);

\

Os arquivos aparecem no nível em que são necessários e em todos os níveis subsequentes;

\

Em cada DFD, o limite superior recomendado para o número de processos é 7 ] 2.

^

Processos que, pela sua simplicidade, não são expandidos são denominados processos primitivos ou primitivas funcionais;

^

Os processos primitivos são descritos usando um método de especificação de processos.




Regras e heurísticas de projecto As regras básicas de projecto são dados por vários autores, cf. (DeMarco, 78), (Gane e Sarson,79), (Aktas, 87), (Gore e Stubbe, 88). As regras de projecto mais importantes são: 1. Estabelecer o contexto do DFD identificando todas as entidades

externas do sistema. Sugestão: Escrever as fontes à esquerda e os terminadores à direita.

2. Identificar todas as saídas e entradas do sistema. Desenhar o

diagrama de contexto. 3. Seleccionar um ponto de partida para o projecto. Começar a

desenhar os fluxos que são necessários para ir desde uma entrada até uma saída, partindo:

- da entrada para a saída; - da saída para a entrada; - ou partindo do centro.

4. Dar nomes ilucidativos a todos os fluxos de dados e arquivos;




Regras de projecto (cont.) 5. Rotular todos os processos com verbos operacionais que

relacionem as entradas com os fluxos de saída; 6. Omiti r os detalhes de programação como verificações de erros,

inicializações e finalizações; 7. Não incluir controlo ou fluxo de controlo; 8. Tentar planear o número de níveis. Não incluir demasiada

informação num DFD; 9. Evitar cruzar fluxos de dados. Usar entidades e arquivos

duplicados, se necessário;




Regras de projecto (cont.) 10. Rever a consistência do DFD. Refazer, se necessário.

Validação ver tical: os fluxos que entrem e saem de um processo, devem entrar / sair no DFD que resulta da explosão desse processo. Validação hor izontal: todo o que entra num processo é utili zado e tudo o que sai desse processo foi produzido.

11. Verificar, preferencialmente com o utili zador, se o DFD

representa o sistema. Refazer, se necessário. 12. Depois de estabelecido um DFD explodir cada processo, se

necessário. Repetir a decomposição até obter o detalhe suficiente.




Despiste de incorrecções em DFD _

Processos com nomes ambíguos revelam falta de conhecimento sobre o sistema (ex. manipulação de entrada, gera saída);

_

Fluxos de dados com nomes como “ items de entrada” , ou “vários dados” revelam um conhecimento pobre do sistema;

_

Cruzamento de fluxos indicam que é potencialmente necessário decompor o DFD;

_

Primitivas funcionais com grande número de entradas e saídas indicam a necessidade de decompor o DFD;

_

DFD complexos significam fracasso.




Erros frequentes

Os DFD não são fluxogramas;

Os fluxos de dados devem manter a sua semântica, i.e., não se (sub)dividem;

Não existem ciclos iterativos entre processos;

Os processos não são activados por sinais de entrada;

Os fluxos de dados não podem começar em fontes e acabar em terminadores;

Não é válido ter múltiplos fluxos da mesma origem para o mesmo destino;

Não são permitidos processos apenas com entradas;

Processos só com saídas são suspeitos e a maior parte das vezes incorretos. Uma excepção: gerador de números aleatórios;




Dúvidas frequentes 1. Como se sabe quantos níveis deve ter um DFD?

2. Que número de níveis necessita a modelação de um sistema

típico?

Complexidade do sistema Nº médio de níveis simples 2 a 3 média 3 a 6

elevada 5 a 8 O número de processos cresce exponencialmente com o nível: a�b c DedAf�?7gYgLdAgh@HiHjk@AlXI�?HMnmpoq@ b G:? c DedAf�?7gLgYdAgLrEsnt:svuxwyoq@�l I�?HM0zv{(u

O número suficiente para qualquer DFD do último nível não ultrapassar a dúzia de processos.

O número suficiente para que os processos do último nível tenha uma especificação suficientemente simples.




Exemplo: Nº de processo / DFD = 7 (constante)

Nível Nº de processos 0 7 1 49 2 343 3 2 401 4 16 807 5 117 649 6 823 543 7 5 764 801 8 40 353 607

3. Todas as partes do DFD devem ser expandidas com o mesmo

detalhe?

4. Como apresentar os vários níveis ao utilizador?

Não. Cada parte deve ser expandida apenas com o detalhe necessário. Por existir o processo 3.4.5 não é necessário que exista o 3.2.1.

Utili zadores diferentes estarão interessados em níveis diferentes. Para mostrar todos os níveis, começar do geral e detalhar de seguida.




Razões clássicas para usar DFD, cf. (Aktas, 1987) 1. Ajudam o analista a:

- Resumir a informação acerca de como funciona o sistema; - Compreender os componentes principais do sistema e a

definir funções reutili záveis; - Compreender as interdependências entre subsistemas; - Desenvolver eficientemente uma aplicação

2. Um DFD é uma boa ferramenta de comunicação entre

utili zadores e analistas. Esta comunicação é reconhecida como vital.

3. Permite obter uma melhor estimativa dos recursos envolvidos no

projecto global, em função dos recursos envolvidos em cada um dos processos.




Especificação de Processos |

Em geral, o detalhamento de um processo é feito por explosão.

|Os processos primitivos são detalhados usando um dos muitos métodos para especificação de processos.

|

Alguns exemplos:

- Subconjuntos do Português; - Pseudo-código; - Tabelas de decisão; - Árvores de decisão;

- Pré-pós condições; - Fluxogramas; - Diagramas de Nassi-Shneiderman




Subconjuntos do Português e Pseudo-código

} O Português narrativo não deve ser usado para especificação; } O Português compacto lembra o Português narrativo mas é

estruturalmente equivalente ao Português estruturado.

O Português compacto é útil para apresentar lógica moderadamente complexa desde que se tenha a certeza que não surgem ambiguidades e quando a comunicação com o utili zador é importante.

} O Português estruturado é um subconjunto do Português de

onde se procura eliminar a ambiguidade.

~��T��T�� T��T�� T��T��T��T��Q��




Português Compacto

��T��T�� n�:��Q��Tn��Q��T��n�� Q��Q��Tn��nQ��n�� U��nQ�� T�� Q�� T��Q��Q�� T�� R ¡ ��¢��£�U�� £Q��¤ �� ¥��¦��§�¤��U��¨Q��T��n �� R � ��n�:��Q��©��TH�v��ª«�S �� Q��¥Q��U�¤¬¥¦��Q��®��T��¦��n�

¯�°�±«²�³�´�µ·¶«²�¸�±«¹�º»² ¼½´µ�¾�¸�°�¿�±«°À�� Q�� Á �� ÁÀ�� Q�� Á � �� Q�� R�Á�� À��¢Q�� R�Á �� R��Â

��Ã� ¡ T�¦��Ä��U�:��Q��U��HQ��T��




Português Estruturado Å

É um dos métodos de especificação mais usados;ÅÉ um subconjunto do Português que omite

- adjectivos;- advérbios;- frases compostas ou complexas;- todos os modos verbais excepto imperativo ou infinitivo;- a maioria dos sinais de pontuação.

ÅPretende ser conciso, preciso e eliminar tanto quanto possível ambiguidades. ÅAs convenções utili zadas ficam ao critério de quem as utili za.

ÅEm geral, o Português estruturado resulta numa linguagem com um conjunto limitado de frases cujas palavras são as geralmente aceites em projecto e programação estruturada.

Isto é, possui as estruturas que permitem a especificação de qualquer algoritmo: acções elementares, sequências, selecções e iterações.




Português Estruturado (cont.)

Acções elementares Acções primitivas ou básicas que indicam o que deve ser feito. São expressas como expressões imperativas (ou infinitivas). Æ�Ç È ��T� �v��

Sequências Encadeamento de uma ou mais acções elementares.

Selecções Permitem seleccionar exactamente uma alternativa de um conjunto de alternativas. São habitualmente representadas na forma: ¡ � ÉÊ��Q� ��Ë��ÌÍ��Ë�� ÉÊ��Î��Ï�� Ì¡ ��Ë�� ÉÊ��Î��Ï�� R ÌÐ�� ¡ �





Selecções (cont.) � �� Ñ T��Q�� ÉÒ��Q� ��Ë�� Ì ��Ë�� ÉÊ��Î��Ï�� ÌÑ T��Q�� ÉÒ��Q� ��Ë�� R Ì ��Ë�� ÉÊ��Î��Ï�� R Ì��Ñ T��Q�� ÉÒ��Q� ��Ë��Ì �� Ë�� ÉÊ��Î��Ï��·��ÌÐ�� I terações Define uma repetição limitada de uma sequência de acções.

Í��T�� ÉÊ��Q� ��Ë��Ì ��V ÉÒ��Î��Ï��Ì ou

Ó �� ÉÊ��Î��Ï��ÌS��¬ ÉÊ��Q� ��Ë��Ì





Vantagens É suficientemente preciso e conciso, permitindo uma leitura razoável para especificações de reduzida complexidade. O vocabulário é flexível e adaptável.

Desvantagens Não é um método de especificação formal. Um processo complexo pode ter uma especificação de várias páginas.

Ô D dHf�?CgYgCdWÕ�F�M f�iAM F�Ö:Õ�d�@7B,FHÖH×Êf�iAj¨iAM FAG�FB6d�B6F:M mÙØ:ÚÛ2ÜÊÔÊÜ$ÝÞÜd P BEß�j à c DeáAâ�NXj�d à ã:i(F�DeB6d:Úä Ü BEN c d�ÖAã i(F�D B6d mÙå ä iHN BE?Cæc Dx?(çYd mÙèAéä Ü avêÒë c Dx?(çYd m�{7Ø�ÚB6dHB6F�M m B6d�B6F:M z c Dx?7çLd ì @7dHÖHG�N FHg�Ú× Ý�í B6dHGHdHgCÖ�dAgYÖ�ã:i(F:DeB6dHgCÖ c DedHf�?7gLgCFHGAd�g�Ús Üïî ëñð îòÜ B6dHB6F�M




Pseudo-código ó

É mais restrito do que o Português estruturado e inclui alguns detalhes de implementação.

ó

A fronteira entre Português estruturado e Pseudo-código é difusa.

O Português estruturado está mais próximo do Português narrativo e o Pseudo-código está mais próximo das linguagens de programação.

Ô D dHf�?CgYgCdWÕ�F�M f�iAM F�Ö:Õ�d�@7B,FHÖH×Êf�iAj¨iAM FAG�F¢o MXN gCB,FAÖ�G:?(ÖHã�i7F�D B6dAg uB6d�B6F:M mÙØ:ÚÛ2ÜÊÔÊÜ$ÝÞÜã:i(F:D6B6d m·d P BEß�j à c DeáAâ�NXj�d à ã:i(F D B6d�o MXN gCB,FHÖHG:?CÖAã�i7F�D B6dAg uôÚä Ü ã:i(F�DeB6d:õOBEN c d mÙå ä iHN Bö?(æc Dx?(çYd mÙèAéä Ü avêÒë c Dx?(çYd m�{7Ø�ÚB6dHB6F�M m B6d�B6F:M z c Dx?7çLd ì ã:i(F�DeB6d:õ�@7dHÖHG�N FAg�Ú× Ý�í·÷ NOjJo MXN gCB�FAÖHG�?(ÖAã�i7F�D B,dAg uôÚs Üïî ëñð îòÜ B6dHB6F�M




Tabelas de decisão ø

As tabelas de decisão são uma representação de acções com a indicação das condições em que devem ser efectuadas.

øUma tabela de decisão tem 4 quadrantes:

��ù� ��Ï�� n��

��Ï�� ù��Ï�� ù��Ï��

Lista de todos as condições possíveis que surgem dentro de um processo; ��Ï��

li sta de todas as acções possíveis que podem surgir dentro do processo; ��n��

li sta das diferentes combinações de condições possíveis. ù��Ï��v�

indicadores das acções a executar




Tabelas de decisão (cont.) ú

Existem 3 variantes:

- Entradas limitadas; - Entradas estendidas; - Entradas mistas

Tabelas de decisão com entradas limitadas Só admitem indicadores binários no quadrante das regras. Exemplo: Processo Valida Encomenda

1 2 3 4 Crédito suficiente S N N N Pronto pagamento - S N N Acordo especial - - S N Aceita encomenda x x x Rejeita encomenda x

Uma das vantagens deste tipo de tabela é que facilit am uma verificação de completude.




Tabelas de decisão (cont.)

Tabelas com entradas estendidas Admitem valores múltiplos no quadrante das regras.

1 2 3 4 Crédito aprovado N S S S Quandidade - 0-24 25-50 51-100 % desconto 0 5 10 Aceita encomenda x x x Rejeita encomenda x

Tabelas com entradas mistas Admitem valores múltiplos no quadrante das decisões

1 2 3 Empregado assalariado N N S Horas trabalhadas > 40 S S - Pagamento horas

extras a dobrar

ordinário ordinário




Algumas vantagens das tabelas de decisão û

As alternativas são mostradas lado a lado; û

Mostram o relacionamento causa/efeito; û

Facilitam a verificação da consistência e da completude. Utili dade û

São úteis na descrição de processos que produzem acções baseadas em decisões complexas;

ûSão úteis na análise de regras complexas e processos de tomada de decisão.




Árvores de decisão As árvores de decisão são uma alternativa gráfica às tabelas de decisão. As árvores de decisão lêm-se da esquerda para a direita, começando da raiz, de onde saem todos ramos. Os pontos de derivação representam uma decisão acerca de uma condição.




Pré/Pós Condições ü

Uma forma de dizer qual é a transformação efectuada pelo processo sem explicitar o algoritmo utili zado.

ü

Utili dade:

1. Quando o utili zador tem dificuldade em descrever o algoritmo que utili za;

2. Quando o analista quer deixar a escolha do algoritmo para

uma fase posterior.

ÔÒý ß à fLd:þ(ÿ�� ç��Hd� fLd�þ7ÿ�� ç��Cg ã�i�� Hj ÿ� g�� ý�� ÿ�Hg��þ��7g�ÿ�d c ý dAf��(gYgYdJfYd�j��(ç�� ý��Ô áHg à fYd:þCÿ� ç��d� fLd�þ7ÿ�� ç��Cg ã�i��ÿ�� Hj g�� ý�� ÿ��Hg�� c áAg d c ý dHf��(gYgYd�� ý j�� þ�� ý �




Fluxogramas !

Os fluxograms representam lógica procedimental de forma não estruturada.

!Componentes essenciais:

Terminador: Decisão: Entrada/Saída: Processamento: Conector:

Ponte de ligação:




Diagramas de Nassi-Shneiderman "

Os diagramas de Nassi-Shneiderman foram introduzidos como fluxogramas estruturados.

"Componentes essenciais:

Sequência: Decisão: Repetição:

# ×ÒfCç�$AdW{�%# ×ÒfCç�$Ad¨è�%

# ×ÒfCç�$AdW{�% # ×ÒfYç�$Ad¨è�%

# Õvd�&�'�( ç�$Ad�% ä (Oj a $Hd

ÛnÜÒÔÊÜ$ÝÞÜ × Ý�í # Õvd&)'�( ç�$Hd�%

*+*+*# ×ÒfCç�$Ad,&�%

# ×ÒfCç�$AdW{�%




Conclusões - Apresentou-se o DFD como ferramenta de modelação

funcional. - Apresentaram-se as regras de construção e salientaram-se os

méritos e defeitos dos DFD. - Apresentaram-se alguns métodos de especificação de processos

primitivos. Estas técnicas são úteis também noutros contextos. - Dos métodos apresentados, salientam-se o Português

estruturado, as tabelas e árvores de decisão. - Português estruturado poderá ser vantajoso quando a

especificação apresenta combinações de repetições ou iterações.




Conclusões (cont.) . As tabelas de decisão poderão ser vantajosas quando:

a) Existem combinações complexas de condições, acções ou

regras, ou

b) é necessário um método que ajude na detecção de redundâncias e contradições;

. As árvores de decisão poderão ser vantajosas quando:

a) A sequência de condições e acções é crítica;

b) Nem todas as condições são relevantes para todas as acções.




Referências

I. T. Hawryszkiewycz, Introduction to Systems Analysis and Design (third edition), Prentice Hall , 1994. Kenneth E. Kendall and Julie E. Kendall, Systems Analysis and Design, Prentice Hall International Editions, (Englewood Cli ffs, 1992) P. Layzell and P. Loucopoulos, Systems Analysis and Development (third edition) Chartwell-Brat Student Text, 1989 Edward Yourdon, Modern Structured Analysis, Prentice Hall International Editions (Englewood Cliffs, 1989)

dfd - diagrama de fluxo de dados

Documents