Análise Estruturada 4
Diagrama de entidades relacionamentos (abordado anteriormente) 
Stock
N 1
Prod_Enc
1 N
Fornecedor Movimento
Prod_Forn
Encomenda
N
1
11
N N
 
 
Diagrama de Fluxo de Dados (DFD) 
Ferramenta de modelação gráfica, da análise estruturada, que permite 
representar um sistema como uma rede de actividades ligadas por canais e 
armazéns de dados. 
 
É uma das ferramentas mais usadas quando as actividades do sistema a modelar 
são mais complexas do que os dados que o sistema manipula. 
⇒ dá-nos uma só visão do sistema, a visão orientada por funções ou actividades 
 
A modelação funcional de um sistema permite responder a questões que podem 
ser formuladas de diferentes formas: 
• Que funções têm de ser desempenhadas pelo sistema? Que interacções 
existem entre essas funções? 
• Que transformações tem de ser efectuadas pelo sistema? Que entradas são 
transformadas em saídas? 
• Que tipo de trabalho executa o sistema? Onde obtém informação para 
executar este trabalho? Onde é que a entrega de resultados se processa? 
Análise Estruturada 5
Componentes de um DFD 
Produção
1
Verificar e
actualizar
saídas
Guia de saída
Requisição
MovimentoStock 
 
 
• Terminadores ou 
Entidades Externas 
 
 
Categorias lógicas de coisas ou pessoas fora dos limites do sistema 
considerado, mas que interagem com ele. Representam uma origem ou 
destino de dados. 
Tipicamente são indivíduos, grupos de pessoas, departamentos ou divisões da 
organização, sistemas externos ou organizações externas. 
 
Exemplos: 
Produção (Departamento da organização, mas que não pertence ao sistema, 
supondo que o sistema a modelar engloba somente, por exemplo, 
a gestão de stocks) 
Fornecedor (Um fornecedor interage com o sistema através do envio de guias 
de remessa e facturas, mas está fora do controlo do sistema) 
Análise Estruturada 6
 
• Depósito 
de dados 
 
 
 
Colecções ou elementos de dados que o sistema necessita de armazenar. 
Cada depósito de dados tem um nome que deve sugerir o respectivo 
conteúdo. 
 
Exemplos: 
Stock (Dados de stock de produtos a armazenar) 
Fornecedor (Dados de fornecedores a armazenar) 
 
 
• Fluxo 
de dados 
 
Canal por onde circula informação. Representa movimentação de itens de 
dados de uma parte do sistema para outra, ao contrário dos depósitos de 
dados que representam dados estáticos. 
O nome de um fluxo deve permitir associar imediatamente o respectivo 
conteúdo. 
 
Exemplos: 
Requisição (Conjunto de dados que descrevem um pedido de um ou vários 
produtos ao armazém) 
Encomenda (Conjunto de dados que descrevem uma encomenda) 
 
Análise Estruturada 7
 
• Processos 
 
1.1.
 
 
 
Os processos são centros transformadores de fluxos de entrada em fluxos de 
saída. Representam actividades ou componentes funcionais do sistema a 
modelar. 
Os processos devem ser numerados e devem ter um nome. Os nomes a 
atribuir aos processos devem sugerir a tarefa que esse processo desempenha. 
 
Exemplo: 
Verificar e actualizar saídas 
(Processo que transforma o fluxo de entrada “Requisição” no fluxo de saída 
“Guia_de_saída”, através da verificação e actualização das existências em 
“Stock” e do registo da saída em “Movimento”, para cada produto contido no 
fluxo “Requisição”.) 
 
Note-se que a actualização das existências em “Stock” e o registo da saída em 
“Movimento” só ocorrem se o produto existir no stock. Contudo, este aspecto 
é um detalhe a descrever na especificação interna do processo. 
Análise Estruturada 8
Exemplo de DFD 
Sistema de Gestão de stock (simplificado) 
Produção
1
Verificar e
actualizar
saídas
Movimento
Stock
2
Registar
produto
3
Registar
entradas
4
Encomendar
produtos
Prod_Forn
 Encomenda
 Prod_Enc
Fornecedor 
Fornecedor 
 Fornecedor
 Fornecedor
Guia de saída
Requisição Novo produto
Diálogo
fornecimento
EncomendaGuia de remessa
Análise Estruturada 9
Aspectos importantes relativamente a terminadores 
A identificação e delimitação do sistema a modelar pressupõe a separação entre 
os elementos que são parte integrante do sistema e os elementos exteriores ao 
sistema. Contudo, elementos considerados exteriores comunicam com o sistema, 
sendo então necessário representar estes elementos, o que é feito através de 
terminadores. Assim sendo, podemos referir os seguintes aspectos: 
• Os terminadores não pertencem ao sistema a modelar. Fluxos que ligam 
terminadores a processos representam interface entre o sistema e o ambiente; 
• O analista não pode alterar o conteúdo, a organização ou procedimentos 
internos associados a terminadores, pois estes estão fora do seu controlo; 
• Relacionamentos existentes entre terminadores não são representados pois 
não fazem parte do sistema. Se estes relacionamentos são essenciais para 
sistema a modelar, então “os terminadores não são terminadores”, mas sim 
partes integrantes do sistema a modelar; 
• As ligações mais usuais entre os terminadores e o sistema a modelar são 
fluxos de dados. Contudo, um terminador pode ser outro sistema, com o qual 
é necessário comunicar, através de um depósito de dados externo. Neste caso, 
pode utilizar-se uma representação como a exemplificada seguidamente. 
 
Exemplo: Modelação de um sistema de gestão da produção. 
Sistema de gestão comercial: sistema já implementado, com o qual se 
comunica através do depósito de dados Encomenda 
Gestão
Comercial
1
Elaborar 
plano de 
produção
Encomenda
... ...
Análise Estruturada 10
Aspectos importantes relativamente a fluxos e depósitos de 
dados 
Os Fluxos de dados: 
• têm uma direcção que indica o sentido em que circulam; 
• têm como origens e destinos todos os outros elementos de um DFD; 
• têm um nome, que representa o significado dos dados que circulam, devendo 
este ser único e sugestivo. 
 
Fluxos de diálogo 
São fluxos especiais com 2 direcções e 2 nomes que permitem representar dois 
fluxos de dados do tipo pergunta e resposta. (Exemplo: Diálogo fornecimento) 
 
Algumas questões a que DFD não responde: 
• Fluxos de entrada num processo representam pedidos de informação a outra 
parte do sistema, ou pedidos de leitura ao utilizador, ou envio de informação 
por outra parte do sistema por iniciativa da parte emissora? 
• Fluxos de saída num processo representam pedidos de informação de outra 
parte do sistema, ou envio de informação para outra parte do sistema por 
iniciativa do processo? 
• Quantos itens de dados existem em cada fluxo de dados? 
• Em que sequência chegam as entradas? 
• Em que sequência são produzidas as saídas? 
• Quantas ocorrências de cada fluxo de dados de entrada são necessários para 
produzir uma saída? 
 
Estas questões envolvem detalhes a especificar na modelação interna dos 
processos. 
Análise Estruturada 11
Fluxos de dados ligados a depósitos de dados são interpretadas como operações 
sobre os dados do depósito. Estas operações podem ser de dois tipos, consoante 
o sentido dos fluxos: 
 
• Operação de leitura não destrutiva 
(leitura ou consulta) 
 
• Operação de alteração do depósito 
(alteração, inserção ou remoção) 
 
Sendo o significado de um fluxo de dados ligado a um depósitos de dados mais 
simples de interpretar, em que casos se pode omitir o nome de um fluxo? 
Existem 2 “teorias”: 
• Fluxos de dados ligados a depósitos de dados não precisam de nome; 
• Fluxos de dados cujo conteúdo coincide com uma instância completa de 
um depósitos de dados não necessitam de nome. 
 
 
A partirdo sentido de um fluxo de dados ligado a um depósito de dados 
podemos representar dois tipos de operações. Contudo, considerando uma 
operação de consulta, os casos possíveis de existência de um fluxo de dados 
são: 
• Consulta de uma instância completa; 
• Consulta de um conjunto de instâncias completas que obedecem a um 
critério; 
• Consulta de uma parte de uma instância; 
• Consulta de uma parte de um conjunto de instâncias que obedecem a um 
critério. 
Análise Estruturada 12
∴ Nem todas as questões têm resposta pela simples observação de um fluxo de 
dados. 
⇒ para conhecer todos os detalhes relacionados com um fluxo de dados é 
necessário examinar a especificação interna do processo ao qual o fluxo está 
ligado. Só existe uma certeza, um depósito de dados é um elemento passivo, 
logo, os dados não circulam de um depósitos através de um fluxo, a não ser 
que um processo os requisite. 
 
Exemplos de representação de operações sobre depósitos de dados: 
Operação Representação 
Inserção ou 
remoção de um 
cliente. 
Cliente 
Consulta do Nº de 
telefone de um 
cliente a partir do 
seu código. 
Cliente 
Nºtelefone
Cliente 
Alteração do Nº de 
telefone de um 
cliente a partir do 
seu código. 
Cliente 
Nºtelefone
Cliente
#Cliente
Nºtelefone
Cliente
 
 
Questão: Um depósitos de dados existe devido a requisito especificado por 
utilizador ou devido a aspecto conveniente de implementação ? 
⇒ Um depósito de dados existe devido a desfasamento temporal na necessidade 
dos dados por dois ou mais processos que ocorrem em instantes diferentes. 
Análise Estruturada 13
Hierarquia ou existência de vários níveis de detalhe em 
DFD´s 
Os DFD´s analisados até ao momento modelam sistemas simples ou foram 
apresentados parcialmente. Os sistemas reais a modelar são maiores e mais 
complexos. 
 
Questão: Como representar sistemas com muitos processos, sem abdicar da 
ausência de complexidade num DFD? 
 
A solução consiste em organizar um DFD em sucessivos níveis de refinamento, 
de forma a que cada nível proporcione mais detalhes acerca de uma parte do 
nível acima. Esta característica é única nos DFD e proporciona um mecanismo 
muito útil para representar vários níveis de detalhe. 
 
Cada processo num DFD pode, ou não, estar expandido num DFD de nível 
inferior, o que permite distinguir dois tipos de processos: 
• Processos não primitivos 
Processos cujo detalhe é descrito utilizando um novo DFD de nível 
inferior. O DFD de nível inferior terá o mesmo número e nome do processo 
correspondente do nível superior. 
• Processos Primitivos 
Não originam novos DFD´s, sendo objecto de uma descrição utilizando 
uma linguagem apropriada. Esta descrição especifica a forma de 
transformação de fluxos de entrada em fluxos de saída e não deve 
ultrapassar um página. 
Análise Estruturada 14
Diagrama de fluxo de dados com múltiplos níveis 
Diagrama 0
1. 2.
Diagrama de contexto
Sistema
3.
Diagrama 3
3.1.
3.3.
3.2.
 
Visão muito geral do sistema: 
• Possui um só processo que representa 
todo o sistema como uma caixa preta; 
• Mostra interacção entre sistema e 
terminadores (fluxos e depósitos 
externos) 
 
Visão global do sistema: 
• Mostra os principais processos do 
sistema; 
• Visualiza fluxos e depósitos de dados 
partilhados por processos; 
• Mostra ainda a interacção entre 
sistema e terminadores. 
 
 
Detalhe do processo 3 do Diagrama 0 
(Os terminadores podem ser novamente 
incluídos nos diagramas de nível inferior, 
pois, essa redundância conduz a maior 
clareza na leitura do diagrama) 
 
A numeração de cada diagrama sugere assim o respectivo grau de detalhe. 
Contudo, a numeração não indica qualquer tipo de sequência entre a 
informação. A numeração é efectuada para identificação e estruturação de 
níveis. 
Análise Estruturada 15
Principais características dos DFD´s 
• Não modelam aspectos como o sincronismo e sequenciação 
Os DFD´s são um modo de representação de fluxo de dados e processos 
assíncronos. Por outro lado, não representam a sequência de chegada de 
fluxos, nem a sequência em que são produzidas as saídas. Assim, o modelo 
das actividades fica “livre” de complexidade extra, tornando-o mais fácil de 
elaborar e manter. A este nível só interessa identificar processos e dados que 
circulam entre estes. 
 
• Não especificam o funcionamento interno dos processos 
As componentes de um DFD dizem-nos como é um processo sem definir 
como este funciona. A especificação interna do processo, o suporte textual 
para as actividades de mais baixo nível, define o que as actividades devem 
fazer. 
 
• Não são fluxogramas 
As decisões são tomadas dentro dos processos e nunca são representadas nos 
DFD´s; 
 
• Estruturam-se em vários níveis de detalhe 
Os DFD´s dão uma visão do sistema do geral para o particular. A sucessão de 
vários diagramas sugere essa estruturação. 
 
• São ferramentas de modelação lógica 
Os DFD´s permitem representar aspectos lógicos, não físicos. A sua 
elaboração deve ser independente da tecnologia de implementação, devendo 
ignorar-se aspectos que são dependentes de restrições físicas de 
implementação. O modelo lógico também se designa por modelo essencial, 
ou seja, a essência do sistema. 
Análise Estruturada 16
Regras para a estruturação dos DFD´s 
Os DFD´s devem respeitar algumas regras, a saber: 
• Número máximo de objectos 
Um DFD não deve ter mais do que 7 (+/- 2) processos (número de objectos 
que a mente humana é capaz de abarcar simultaneamente). Este número faz 
com que cada DFD caiba numa folha com formato A4. 
 
• Consistência entre os vários níveis de detalhe 
Cada DFD deve estar equilibrado em relação ao processo que o originou, ou 
seja, o conjunto de fluxos de entrada e saída desse DFD, deve ser equivalente 
ao conjunto de fluxos de entrada e saída do processo que lhe deu origem. 
 
• Consistência entre as várias ferramentas de modelação 
As várias ferramentas de modelação têm de ser consistentes e compatíveis 
entre si. A consistência entre DFD´s e DER´s é assegurada garantindo que 
cada depósito de dados de um DFD corresponde a uma das entidades do 
DER. 
 
• Representação de depósitos de dados acedidos por vários processos 
Num DFD não é necessário representar depósitos de dados que apenas são 
relevantes no interior de cada um dos seus processos. Como corolário poderá 
dizer-se que, se um depósito de dados é utilizado por mais do que um 
processo do mesmo DFD, então esse depósito deve ser representado. 
 
• Dimensão máxima da especificação de um processo primitivo 
A especificação de um processo primitivo não deve ultrapassar uma página. 
Se a especificação do processo possui uma dimensão superior a uma página, 
significa que este é complexo e que não é primitivo, e que é necessário 
detalhar o processo num DFD de nível inferior. 
Análise Estruturada 17
Sugestões para a construção de DFD´s 
Escolher nomes sugestivos para processos, fluxos, depósitos e terminadores. 
• Não usar nomes de pessoas, mas sim a designação do papel que 
representam; 
• Não usar nomes de mecanismos, dispositivos ou meios físicos usados para 
transportar dados. Exemplo: Em vez de “Telefonema” usar “Pedido” e em 
vez de “Operador de entrada de dados” usar “Cliente”, ou seja a origem; 
• A política utilizada para dar nomes a processos consiste em utilizar um 
verbo e um objecto, ou seja, a actividade e o objecto associado. Não se 
deve usar, contudo, nomes ambíguos do tipo: processar dados, tratar 
entradas e funções variadas. 
 
Não desenharDFD’s complexos 
• Desenhar DFD com poucos objectos, para facilitar a sua leitura; 
• Minimizar cruzamentos entre fluxos de dados, da seguinte forma: 
1º redesenhar o diagrama distribuindo objectos da forma mais favorável; 
2º se necessário, duplicar terminadores (assinalar com traço na diagonal); 
3º se necessário, duplicar os depósitos de dados ( “ ); 
4º permitir o cruzamento de fluxos de dados, desde que não exista 
nenhuma estrutura que reduza as intersecções. 
• Para simplificar diagramas de contexto, cuja elaboração pressupõe a 
representação de todas as interacções com o exterior, quando estes 
apresentam uma leitura difícil: 
∗ consolidar fluxos de dados com terminadores comuns; 
∗ desenhar diagramas de contexto diferentes para grupos com interesses 
diferentes, omitindo aspectos não relevantes para cada grupo. 
Análise Estruturada 18
Assegurar alguma consistência entre profundidade dos níveis de detalhe 
das várias partes do sistema. 
Se o processo 2 requer 3 níveis de detalhe (por exemplo 2., 2.1. e 2.1.1.) os 
restantes processos 1, 3, etc. também devem ter 3 níveis de detalhe? 
Não, mas se, por exemplo, o processo 2 é primitivo e o processo 3 possui 7 
níveis de detalhe, podemos concluir que o sistema não foi bem organizado. 
 
Redesenhar o DFD as vezes que forem necessárias. 
A construção de um DFD é um processo iterativo. Assim sendo, um DFD 
deve ser redesenhado várias vezes, de forma a garantir: 
∗ a modelação adequada do sistema em estudo; 
∗ correcção técnica; 
∗ estética agradável; 
∗ consistência interna e em relação a outros modelos utilizados, como DER, 
DTE, DD e especificação de processos. 
 
Concentrar a elaboração do DFD na política subjacente que tem de ser 
levada a cabo e não nos procedimentos usados para sustentar essa política, 
ou seja, na essência do sistema. 
Análise Estruturada 19
Extensão de DFD´s para modelar sistemas em tempo real 
Sistemas em tempo real 
Sistemas que controlam o ambiente através da recepção de dados, seu 
processamento e devolução de resultados em tempo suficientemente curto, de 
forma a afectar o ambiente no momento. 
 
 
Sistemas em tempo real VS Sistemas on-line 
Os sistemas em tempo real distinguem-se dos sistemas on-line pela necessidade 
de um tempo de resposta menor. Por outro lado, ao contrário dos sistemas on-
line que normalmente interagem com pessoas, os sistemas em tempo real 
também interagem com o ambiente, reagindo e captando dados, e/ou 
controlando o ambiente. 
Exemplos: Sistemas de aquisição de dados de alta velocidade, sistemas de 
controlo de processos, etc. 
 
Devido a necessidade de tratar sinais e interrupções do ambiente, bem como, de 
controlar e sincronizar actividades, para estes sistemas necessitamos de 
modelar: 
• Fluxos de controlo 
• Processos de controlo 
 
Fluxo de controlo 
Representa um canal que transporta um sinal binário, que é enviado de um 
processo para outro, ou de um terminador para um processo, com o intuito de 
activar um processo que se encontra suspenso. 
Análise Estruturada 20
Processo de controlo (supervisor ou executivo) 
É um processo supervisor cuja única função é coordenar e sincronizar as 
actividades de outros processos de um DFD. 
As suas saídas e entradas consistem somente em fluxos de controlo. As saídas 
são usadas para “acordar” outros processos. As entradas significam que outro 
processo terminou a sua tarefa, ou que surgiu uma situação extraordinária que 
deve ser notificada ao processo. 
 
 
Representação de fluxos e processos de controlo 
Os fluxos e processos de controlo são representados num DFD a tracejado. 
 
 
Processo normal VS processo de controlo 
Um processo normal, que possui um fluxo de controlo de entrada, depois de 
acordado comporta-se como um processo normal. O comportamento de um 
processo de controlo é diferente, sendo modelado por um diagrama de transição 
de estados, que mostra os vários estados que o sistema pode ter e as 
circunstâncias que levam à alteração de estado. 
 
 
Exemplo: 
 
Sinal X ⇒ activar processo 2
 
Sinal Y ⇒ activar processo 3 
1
2 3
P.C.
X
Y