O que é o DFD Simulator

O DFD Simulator desenha diagramas de fluxo de dados e executa esses diagramas: você vê os dados percorrerem o sistema, formarem filas e serem gravados. ^[1] É um único arquivo HTML, que funciona no navegador, sem instalação nem conta.

Abrir o DFD Simulator →

Um diagrama parado mostra a estrutura, mas não mostra o que acontece quando o sistema recebe trabalho. Simular responde a perguntas como: para onde vai um pedido recusado, qual processo forma fila e o que muda ao dobrar a capacidade.

Como o app trata os seus dados

• Nada sai do seu computador. O arquivo bloqueia conexões de rede.
• O modelo fica no navegador. Ele é guardado automaticamente e reaparece ao reabrir o app. Para ter uma cópia própria, salve em JSON.
• Modelos não executam código. As regras passam por um interpretador próprio, então abrir um modelo recebido de outra pessoa não roda JavaScript.

Os elementos de um DFD

Um DFD tem quatro elementos, e o app desenha cada um em duas notações. ^{[3] [4] [5]} Para a teoria, veja o tutorial de análise e projeto de sistemas. ^[2]

Processo

Transforma dados. Tem nome com verbo, como “Validar pedido”, e um número.

Entidade externa

Algo fora do sistema, que envia ou recebe dados: cliente, banco, outro sistema.

Depósito de dados

Onde os dados ficam guardados entre um processo e outro. Tem número com a letra D.

Fluxo de dados

O caminho de um dado. A seta indica o sentido e o nome diz o que passa.

Todo fluxo precisa ter um processo em uma das pontas. Por isso, o app recusa ligar duas entidades, dois depósitos ou uma entidade a um depósito.

Seu primeiro DFD: uma pizzaria

Em cerca de 15 minutos, você vai construir e simular uma pizzaria. O cliente faz um pedido, o sistema calcula o valor, grava o pedido e avisa a cozinha.

1. Crie os elementos

1. Se o app abrir com outro modelo, use Arquivo ▾ → Novo modelo.
2. Arraste da paleta para o diagrama: Entidade externa à esquerda, Processo no centro, Depósito de dados acima do processo e outra Entidade externa à direita.
3. Dê um duplo clique em cada elemento e renomeie, confirmando com Enter: Cliente, Registrar pedido, Pedidos e Cozinha.

2. Ligue os fluxos

Passe o mouse sobre um elemento: surgem pontos na borda. Arraste um ponto até o elemento de destino. O cursor vai para o campo Nome do novo fluxo; digite e pressione Tab.

1. Cliente para Registrar pedido: pedido.
2. Registrar pedido para Pedidos: pedido registrado.
3. Registrar pedido para Cozinha: comanda.

3. Descreva o comportamento

Clique em um elemento e preencha o painel Propriedades, à direita.

1. Em Cliente, preencha Dados gerados com as duas linhas abaixo, Emitir a cada com 2 e Limite de emissões com 5.

   id = seq
   qty = randint(1, 3)

2. Em Registrar pedido, preencha Regras com a linha abaixo. Cada pizza custa 40.

   total = qty * 40

3. Clique no fluxo comanda e preencha Campos que passam com id, qty. A cozinha não precisa ver o valor.

4. Verifique o modelo

Abra a aba Verificar. Ela mostra um alerta: o depósito Pedidos recebe dados, mas ninguém os lê. Alertas não impedem a simulação; o passo 7 resolve este.

5. Simule

1. Clique em ▶ Simular. Os dados saem do cliente e percorrem os fluxos.
2. Ao terminar, o status mostra Concluída: nada mais agendado, perto de t = 11.
3. Abra a aba Depósitos, no painel de baixo. Pedidos tem 5 registros, com id, qty e total.
4. Clique em Cozinha. Em Último dado recebido aparecem só id e qty: o fluxo filtrou os campos.

6. Acrescente uma decisão

1. Clique em ■ Editar para voltar ao desenho.
2. Crie a entidade Gerente e ligue Registrar pedido a ela com o fluxo pedido grande.
3. Nesse fluxo, preencha Condição com total >= 100. A linha fica tracejada, o que indica um fluxo condicional.
4. Simule de novo. Gerente recebe 2 dos 5 pedidos, os de valor 120. Com a mesma semente, os valores se repetem.

7. Leia o depósito e resolva o alerta

1. Volte a editar e crie a entidade Caixa e o processo Consultar pedido.
2. Crie três fluxos: Caixa para Consultar pedido (consulta), Pedidos para Consultar pedido (dados do pedido) e Consultar pedido para Caixa (pedido consultado).
3. Em Caixa, preencha Dados gerados com id = randint(1, 5) e deixe Emitir a cada em 0.
4. No fluxo dados do pedido, preencha Filtro de leitura com id == in.id e Nome nas regras com order.
5. Em Consultar pedido, preencha Regras com found = exists(order). A aba Verificar agora mostra Nenhum problema encontrado.
6. Simule. Depois de Concluída, clique em Caixa: ela emite uma consulta, e Último dado recebido traz found: true.

Você usou emissão automática e manual, regras, condição, filtro de campos, gravação e leitura. O restante do tutorial detalha cada recurso.

A interface

A tela tem uma barra superior e três colunas: elementos à esquerda, diagrama no centro e propriedades à direita. Durante a simulação, surge um painel de resultados abaixo do diagrama.

Barra superior

Caminho dos níveis, desfazer e refazer, menu Arquivo ▾, ▶ Simular, idioma, ajuda e tema.

Elementos

A paleta. Arraste para o diagrama, ou clique para colocar no centro da vista.

Neste diagrama

Lista dos elementos e fluxos do nível aberto. Clicar seleciona o item.

Propriedades

Campos do item selecionado. Sem seleção, mostra Nome, Notação, Semente aleatória e Tempo máximo do modelo.

Verificar

Problemas do modelo. Clicar em um deles leva ao elemento.

Desenhar e organizar

Dois fluxos entre os mesmos elementos se curvam sozinhos para não ficarem sobrepostos.

Propriedades de cada elemento

Processo

Regras

Calculam campos do dado. Veja a próxima seção.

Duração

Quanto tempo o processo leva. Aceita expressão, como random(1, 3).

Capacidade

Quantos dados atende ao mesmo tempo. O excedente espera na fila.

Limite da fila

Quantos dados podem esperar. Quem chega com a fila cheia é rejeitado. 0 é sem limite.

Prioridade

Expressão que escolhe o próximo da fila: o menor valor vai primeiro. Vazio segue a ordem de chegada.

Entradas

Executa a cada entrada atende cada dado que chega. Espera todas as entradas aguarda um dado de cada fluxo e combina os campos.

Intervalo automático

Para processos sem fluxo de dados de entrada: ele dispara sozinho nesse intervalo. Se lê depósitos, só dispara quando há registro, e o registro lido vira o dado.

Pausar a simulação aqui

Ponto de parada: pausa quando um dado chega. Só quando limita a uma condição, como total > 100. Depósitos e entidades também têm.

Entidade externa

Dados gerados

Os campos de cada emissão. seq é o número da emissão.

Emitir a cada

Intervalo entre emissões. Aceita expressão: exponential(2) gera chegadas irregulares, com média de 2. Com 0, a entidade só emite ao receber um clique durante a simulação.

Limite de emissões

Total de emissões automáticas. 0 é sem limite, e aí a simulação só para quando você pausar.

Primeira emissão em

Instante da primeira emissão automática.

Depósito de dados

Campo-chave

Identifica o registro em atualizações e exclusões.

Registros iniciais (JSON)

Lista de objetos carregada no início, como [{"id": 1, "stock": 10}].

Fluxo de dados

Os campos mudam conforme a origem e o destino do fluxo.

Se mais de uma condição for verdadeira, cada fluxo recebe uma cópia do dado. Se nenhuma for verdadeira e não houver else, o dado é descartado e o registro mostra o motivo.

Regras e expressões

Regras têm uma atribuição por linha, no formato campo = expressão, e são aplicadas em ordem: uma linha pode usar o resultado da anterior. Linhas iniciadas com # ou // são comentários.

# preço vem do depósito lido
price = products.price
total = round(qty * price, 2)
ok = exists(products) && products.stock >= qty

Campo inexistente vale null, e ler um campo de null também dá null. Divisão por zero dá null. Quando a leitura não encontra registro, o nome dele vale null; por isso use exists.

Níveis e subdiagramas

Um processo complexo pode ser detalhado em outro diagrama, com numeração hierárquica: o processo 2 se abre em 2.1, 2.2 e assim por diante.

1. Selecione o processo e clique em Detalhar em subdiagrama.
2. Os fluxos do processo pai aparecem como elementos tracejados: à esquerda as entradas e à direita as saídas.
3. Crie os processos internos e ligue-os a esses elementos.

Os níveis ficam balanceados porque os elementos tracejados vêm do pai. Um fluxo criado no pai surge no subdiagrama; um fluxo excluído no pai some, junto com as ligações. Para mudar o nome, edite o fluxo no pai.

• Com subdiagrama, o processo pai perde regras e duração: a lógica passa a ser a dos processos internos.
• O marcador ⊞ no processo abre o subdiagrama.
• Remover subdiagrama apaga o nível e os que estiverem abaixo dele. Ctrl+Z desfaz.

Na simulação, o dado entra pelo elemento tracejado, passa pelos processos internos e sai pelo fluxo correspondente do pai. Ao ver o nível superior, um número azul no processo indica quantos dados estão dentro dele.

Verificar o modelo

A aba Verificar revisa o modelo inteiro, em todos os níveis, e o número nela mostra quantos problemas há. Só erros de ligação proibida, expressão e JSON impedem a simulação.

Simular

▶ Simular executa uma cópia do modelo, em tempo simulado. Cada dado segue o ciclo abaixo:

Controles

O desenho fica bloqueado durante a simulação. Ainda é possível abrir subdiagramas e mover a vista, arrastando o fundo.

O que aparece no diagrama

Emitir e pausar

• Entidade sem intervalo emite ao receber um clique. Em qualquer entidade, o botão Emitir agora das propriedades funciona.
• Marque Pausar a simulação aqui em um elemento para parar quando um dado chegar a ele. O status mostra onde parou.
• A simulação termina sozinha quando não há mais nada agendado.

Semente aleatória

random e randint seguem a Semente aleatória do modelo. Com a mesma semente, o resultado se repete, o que permite comparar cenários mudando uma coisa de cada vez. Troque a semente para ver outra sequência.

Cada elemento tem a sua própria sequência de sorteios, definida pela posição dele no diagrama. Assim, mudar a capacidade de um processo não altera as chegadas nem as durações dos outros.

Ler os resultados

O painel abaixo do diagrama tem seis abas, e cada uma responde a uma pergunta.

Registro

O que aconteceu e quando. Só problemas filtra descartes e erros, e Baixar CSV exporta. Clicar em uma linha leva ao elemento.

Estatísticas

Como o sistema se saiu e onde está o gargalo.

Filas

Como cada fila cresceu e diminuiu ao longo do tempo, em gráfico ou tabela.

Cenários

Quanto o resultado varia entre rodadas e o que mudou em relação a uma referência.

Depósitos

O que ficou gravado, em tabelas com até 200 registros cada.

Dados em trânsito

Onde está cada dado agora.

Emitidos

Dados que entraram no sistema.

Entregues e Gravados

Chegadas a entidades e gravações em depósitos. Um dado pode gerar várias, porque cada fluxo recebe uma cópia.

Descartados

Dados sem condição verdadeira, ou parados em processo sem saída ou fluxo sem ligação no subdiagrama. O ideal é zero, salvo se for intencional.

Rejeitados

Dados recusados porque a fila estava cheia.

Tempo médio do início à entrega

Da emissão até a chegada a uma entidade.

Mediana e 95% entregues em até

Metade das entregas leva até a mediana, e 95% levam até o segundo valor. Mostram o que a média esconde.

Dados no sistema (média)

Quantos dados, em média, estavam circulando ou esperando.

Entregas por unidade de tempo

Total de entregas dividido pelo instante da última entrega.

Fila máx. e Espera média

Maior fila formada e tempo médio na fila.

Ocupação

Parte do tempo em que a capacidade esteve em uso.

Quando há fila, o resumo aponta o processo de maior ocupação entre os que formaram fila. É o primeiro candidato a gargalo.

Experimentos com os exemplos

Os três exemplos ficam em Arquivo ▾ e na tela inicial. Estes experimentos usam a semente 1, que é a padrão.

Encontrar um gargalo

Abra Gargalo de atendimento e simule: chega um chamado a cada 1 unidade de tempo, mas atender leva cerca de 2. A aba Filas mostra a fila subindo até 13. Uma rodada, porém, é só um sorteio. Para saber o que é regra e o que é acaso, repita.

1. Abra a aba Cenários, deixe Rodadas em 30 e clique em Repetir com outras sementes.
2. Clique em Guardar como referência.
3. Clique em ■ Editar, selecione Atender, mude Capacidade para 2 e clique em ▶ Simular.
4. Na aba Cenários, clique em Repetir com outras sementes de novo. A tabela compara os dois cenários.

Dobrar a capacidade do gargalo reduziu a espera média de 12,23 para 0,37, e a coluna Leitura marca diferença clara, porque as margens não se sobrepõem. Quando elas se sobrepõem, a leitura é dentro da variação: o resultado não mostra que um cenário é melhor. Mudar a capacidade de Triagem não teria esse efeito, porque ela não forma fila.

Provocar uma atualização perdida

Abra Empréstimo de biblioteca. Com Emitir a cada em 4, são 5 empréstimos e o acervo cai de 5 exemplares para 0. Agora mude o valor em Leitor para 2 e simule: são 6 empréstimos de um acervo de apenas 5 exemplares.

A causa está nos tempos: uma solicitação lê o acervo antes de a anterior gravar a baixa. É uma atualização perdida, um problema clássico de concorrência. ^[6] O simulador não corrige isso; ele torna o problema visível.

Acompanhar um pedido por dois níveis

Abra Processamento de pedidos e simule: dos 8 pedidos, 7 são aprovados. Pausar e abrir Faturar pedido mostra os dados nos processos 2.1 e 2.2. Depois, em Gerência, use Emitir agora para consultar uma venda gravada.

Salvar, abrir e exportar

Prompts de IA

Uma IA ajuda a levantar quem envia e recebe cada dado, a montar o primeiro diagrama, a escrever regras e a ler filas e gargalos. Ela também erra com segurança: inventa fluxos, chuta tempos e explica números que não leu. Trate a saída como rascunho de um colega apressado. Para escrever prompts melhores, veja o tutorial de prompts.

Antes de colar: diagramas e registros podem conter nomes, valores e regras sigilosas. Troque por dados fictícios e siga a política da sua organização para uso de IA. O app não envia nada para a rede, mas o serviço de IA recebe o que você colar nele.

Troque os trechos entre colchetes e cole na ferramenta de IA que você usa. Os prompts seguem a ordem do trabalho, mas cada um funciona sozinho.

1. Entrevistar antes de desenhar

Faz a IA descobrir o que falta, em vez de supor. É o melhor começo quando o sistema ainda está na cabeça das pessoas.

Você é um analista de sistemas experiente em diagramas de fluxo de dados.
Quero modelar este sistema: [descreva em poucas frases].

Antes de propor qualquer diagrama, me entreviste:
- Faça uma pergunta por vez e espere minha resposta.
- Cubra: quem envia e quem recebe dados de fora do sistema, o que cada dado contém, o que cada processo faz com ele, o que precisa ficar guardado, quem lê o que foi guardado, as condições que mudam o caminho, os erros e recusas, o volume de chegada e quanto tempo cada processo leva.
- Pergunte principalmente sobre o que dá errado, não só sobre o caminho feliz.
- Não invente respostas. Se eu não souber, registre como pendência.

Ao final, entregue tabelas de: entidades externas; processos (nome com verbo, entradas, saídas, regra, duração, capacidade); depósitos (campos e chave); fluxos (origem, destino, nome, campos, condição); e a lista de pendências.

2. Transformar um texto em elementos

Para requisitos, atas e procedimentos. Pede a origem de cada item, o que facilita conferir.

A partir do texto abaixo, extraia os elementos de um diagrama de fluxo de dados.

Texto:
[cole os requisitos, a ata ou o procedimento]

Entregue:
1. Entidades externas, processos e depósitos, cada um com o trecho do texto que o sustenta.
2. Fluxos: origem, destino, nome e campos. Todo fluxo precisa ter um processo em uma das pontas.
3. Regras e condições citadas, e em qual processo ou fluxo cada uma se aplica.
4. Lacunas: dados que aparecem sem origem, dados guardados que ninguém lê, processos sem entrada ou sem saída, e contradições.
5. Perguntas para esclarecer cada lacuna.

Não preencha lacunas por conta própria. O que não estiver no texto vai para as perguntas.

3. Gerar o modelo em JSON

Transforma o que você reuniu em um arquivo que o app abre, em vez de desenhar elemento por elemento. Gera só o nível principal; depois, detalhe no app os processos que precisarem.

Gere um modelo em JSON para o DFD Simulator, a partir das informações no fim.

Responda só com o JSON, sem comentários e sem cercas de código.

Formato:
- Raiz: "name", "notation" ("yd" ou "gs"), "seed" e "diagrams". Gere só "diagrams.root", com "id": "root", "parent": null, "nodes" e "flows". Não gere subdiagramas.
- Elemento: "id", "type" (entity, process ou store), "name", "x", "y" e, se fizer sentido, "desc".
- entity: "gen" (campos, um por linha, separados por \n; seq é o número da emissão), "interval" (número ou expressão, em texto; 0 só emite por clique), "limit" e "start".
- process: "k" (número único), "rules" (campo = expressão, um por linha), "duration" (expressão, em texto), "capacity" e "queueLimit" (0 é sem limite).
- store: "k" (número único), "key" (campo-chave) e "initial" (texto com uma lista JSON de objetos).
- Fluxo: "id", "from", "to", "name" e, conforme o caso:
  - saindo de processo: "guard" (condição; "else" vale quando nenhuma outra é verdadeira) e "fields" (campos que passam, separados por vírgula);
  - para depósito: "op" (insert, upsert ou delete);
  - vindo de depósito: "filter" (como id == in.id), "alias" (nome nas regras), "readAll" e "consume";
  - em qualquer um: "transit" (tempo de trânsito).

Regras:
- Todo elemento e todo fluxo precisa de "id". Todo fluxo precisa ter um processo em uma das pontas.
- Posições: x de 120 a 1300 e y de 70 a 600, com ao menos 240 de distância na horizontal e 150 na vertical. Entidades nas laterais, processos no centro e depósitos acima ou abaixo deles.
- Expressões aceitam + - * / %, comparações, and, or, not, condição ? a : b, round, floor, ceil, min, max, abs, exists, coalesce, if, count, sum, avg, random(a, b), randint(a, b), exponential(média), normal(média, desvio), chance(p) e pick(a, b). Use ponto no decimal. Não use outras funções.
- Uma condição não enxerga o registro lido: grave o resultado em um campo nas regras e use esse campo.
- Use os mesmos nomes de campo em todos os elementos, porque o app não avisa quando um nome está errado.
- Dê um "limit" maior que 0 às entidades com "interval", para a simulação terminar.
- Em "desc", diga se os tempos foram informados por mim ou são hipótese sua. Não invente fontes.

Exemplo do formato:
{
  "name": "Pizzaria",
  "notation": "yd",
  "seed": 1,
  "diagrams": {"root": {"id": "root", "parent": null,
    "nodes": [
      {"id": "c", "type": "entity", "name": "Cliente", "x": 120, "y": 240, "gen": "id = seq\nqty = randint(1, 3)", "interval": "3", "limit": 6},
      {"id": "p", "type": "process", "name": "Registrar pedido", "x": 400, "y": 240, "k": 1, "rules": "total = qty * 40", "duration": "2", "capacity": 1},
      {"id": "d", "type": "store", "name": "Pedidos", "x": 400, "y": 70, "k": 1, "key": "id"},
      {"id": "k", "type": "entity", "name": "Cozinha", "x": 680, "y": 240}
    ],
    "flows": [
      {"id": "f1", "from": "c", "to": "p", "name": "pedido"},
      {"id": "f2", "from": "p", "to": "d", "name": "pedido registrado"},
      {"id": "f3", "from": "p", "to": "k", "name": "comanda", "fields": "id, qty"}
    ]
  }}
}

Informações:
[cole o resultado do prompt 1 ou 2, ou descreva o sistema]

4. Estimar tempos e capacidades

Filas dependem de tempos. Este prompt deixa claro o que é hipótese e devolve expressões que o app aceita.

Preciso de tempos iniciais para simular este sistema. Não tenho medições.

Sistema:
[cole as tabelas ou o JSON do modelo]
Unidade de tempo: [escolha uma só para todo o modelo]

Para cada entidade e processo, entregue uma tabela com: mínimo, mais provável, máximo, em que você se baseou, como eu mediria o valor real e sua confiança (baixa, média ou alta).

Regras:
- Tudo é hipótese até eu confirmar. Diga isso claramente.
- Não cite estudos ou números de mercado que você não possa indicar com precisão. Sem base, diga "sem base" e dê só a faixa.
- Devolva o texto exato para os campos do app, usando só random(a, b), exponential(média) ou normal(média, desvio): Emitir a cada (entidade), Duração, Capacidade e Limite da fila (processo), Tempo de trânsito (fluxo).
- Para cada processo, compare o tempo que ele leva com o intervalo de chegada, considerando a capacidade, e aponte onde deve formar fila.
- Aponte as 3 estimativas que mais podem mudar o resultado e que eu deveria medir primeiro.

5. Revisar o diagrama

Procura o que a aba Verificar não vê: dados que saem de um processo sem nunca terem entrado, e fluxos que faltam.

Revise este diagrama de fluxo de dados como um analista de sistemas experiente.

Modelo:
[cole o JSON ou as tabelas]

Procure:
- Processos que produzem dados que não recebem: campos que saem sem entrar nem serem calculados.
- Dados recebidos que nenhum processo usa.
- Depósitos gravados que ninguém lê, ou lidos sem nada gravar, e leituras cujo filtro não acha o registro.
- Fluxos que faltam: erros, recusas, respostas à entidade de origem.
- Condições que deixam o dado sem saída, e fluxos sem else onde deveria haver um.
- Fluxos com nome vago, processos sem verbo e campos com nomes diferentes para o mesmo dado.
- Leituras e gravações do mesmo registro por processos simultâneos, que podem causar atualização perdida.

Entregue uma tabela com: elemento, problema, por que importa, sugestão e gravidade (alta, média ou baixa). Não reescreva o modelo. Não confirme que está certo só porque não achou problemas: diga o que não dá para avaliar sem mais dados.

6. Escrever regras e condições

Devolve o texto dos campos, respeitando o que cada um enxerga. Uma condição, por exemplo, não vê o registro lido.

Escreva regras e condições para o DFD Simulator.

Modelo:
[cole o JSON ou descreva os elementos e os campos]
O que preciso que aconteça:
[descreva em linguagem comum]

Para cada campo, entregue o texto exato e onde colar: Dados gerados (entidade), Regras e Duração (processo), Condição e Campos que passam (fluxo que sai do processo), Filtro de leitura e Nome nas regras (fluxo vindo de depósito).

Regras:
- Regras e dados gerados têm uma atribuição por linha, campo = expressão, e cada linha pode usar a anterior.
- Dados gerados enxergam seq, t e as linhas anteriores. Regras e duração enxergam os campos do dado, os registros lidos pelo Nome nas regras e t. Condição enxerga os campos do dado que sai e t. Filtro enxerga os campos do registro, in.campo e t.
- Uma condição não enxerga o registro lido: grave o resultado em um campo, como ok = exists(produto).
- Se mais de uma condição for verdadeira, cada fluxo recebe uma cópia. Se nenhuma for e não houver else, o dado é descartado: diga como tratar esse caso.
- Use só funções que existem: round, floor, ceil, abs, min, max, exists, coalesce, if, count, sum, avg, minof, maxof, len, upper, lower, concat, contains, random, randint, exponential, normal, chance e pick.
- Campo inexistente vale null, sem erro: confira os nomes e aponte os que você supôs.
- Dê um exemplo de dado de entrada e o resultado esperado, para eu conferir na simulação.

7. Ler os resultados da simulação

Depois de repetir as rodadas, copie as tabelas e cole no prompt, com o modelo.

Ajude-me a interpretar esta simulação. Os números vêm de um modelo, não de medições.

Modelo:
[cole o JSON ou descreva os elementos]
Resultados:
[cole as tabelas das abas Estatísticas e Cenários, informando quantas rodadas foram]

Entregue:
1. O que os resultados dizem, em até 5 frases, comparando média, mediana e 95%.
2. O provável gargalo, com fila máxima, espera média e ocupação, e por que os outros processos não são.
3. O que os descartados e rejeitados indicam.
4. O que é padrão e o que pode ser acaso: use a margem e a faixa entre menor e maior. Com uma rodada só, diga que ainda não dá para concluir.
5. O que eu não posso concluir: hipóteses frágeis e limitações do modelo.

Regras:
- Use só números que estão nas tabelas, sem criar novos. Se faltar um dado, diga que falta.
- Separe o que foi calculado da sua interpretação. Não afirme causas no mundo real: apresente como hipótese a confirmar.

8. Planejar os próximos cenários

Transforma o diagnóstico em uma lista curta de testes, para comparar com a referência uma mudança por vez.

Com base nesta simulação, planeje os próximos cenários.

Modelo:
[cole o JSON ou descreva os elementos]
Resultados:
[cole as tabelas das abas Estatísticas e Cenários]
Objetivo: [por exemplo, entregar 95% em até 10 unidades de tempo]
Restrições: [o que não pode mudar]

Proponha até 5 alternativas e, para cada uma, entregue:
- O que muda no modelo: o elemento, o campo (Capacidade, Duração, Limite da fila, Emitir a cada, Condição ou um fluxo novo) e o valor exato.
- O efeito esperado, como hipótese, e a medida que o confirmaria.
- O que seria preciso para fazer a mudança no mundo real, e o risco.

Regras:
- Cada alternativa muda uma coisa só, para o efeito ser atribuível.
- Comece pelo gargalo. Avise quando aliviar um processo pode só mover a fila para o seguinte.
- Não prometa ganhos em números: o resultado sai da simulação.

Termine com o passo a passo no app: repetir 30 rodadas, guardar como referência, voltar a editar, fazer a mudança, simular, repetir e ler a coluna Leitura. Inclua uma tabela vazia para eu preencher: alternativa, medida, referência, atual e leitura.

Como abrir o JSON gerado no prompt 3

1. Copie a resposta da IA para um editor de texto e salve com a extensão .json, por exemplo sistema.json.
2. No app, use Arquivo ▾ → Abrir modelo (.json)…, ou arraste o arquivo para a janela. Se já houver um modelo, confirme a substituição; salve antes o que quiser manter.
3. Clique em Ajustar e arraste o que ficar mal posicionado: o app não organiza o diagrama sozinho.
4. Abra a aba Verificar e confira cada item.

Como levar os resultados para a IA

O app não gera relatório da simulação. Para os prompts 7 e 8, selecione com o mouse a tabela da aba Estatísticas ou Cenários, copie e cole no prompt. Em Registro, Baixar CSV exporta os eventos.

Atalhos de teclado

Limitações e solução de problemas

Limitações

• Tempo sem unidade: uma unidade de tempo pode ser um segundo ou um dia, desde que todo o modelo use a mesma.
• Margem de erro: a margem de 95% é uma aproximação, que supõe rodadas independentes. Use pelo menos 30 rodadas antes de tirar conclusões.
• Depósitos sem transação: cada gravação é imediata, e duas leituras simultâneas enxergam o mesmo valor.
• Copiar e colar: subdiagramas não são copiados.
• Navegadores: o app foi testado no Chromium. O uso em outros navegadores e em celular não foi testado.

Problemas comuns

Revisão rápida

Tente responder antes de abrir cada pergunta.

Referências

1. Giovani Perotto Mesquita, “DFD Simulator”, aplicativo em um único arquivo HTML, giovanipm.github.io/dfd-simulator.html.
2. Giovani Perotto Mesquita, “Análise e projeto de sistemas”, tutorial deste site, giovanipm.github.io/AnaliseProjetoSistemas.html.
3. Wikipedia (em inglês), “Data-flow diagram”, acesso em 30/10/2026, en.wikipedia.org/wiki/Data-flow_diagram.
4. Tom DeMarco, Structured Analysis and System Specification, livro, Prentice-Hall, 1979, ISBN 978-0-13-854380-8.
5. Chris Gane, Trish Sarson, Structured Systems Analysis: Tools and Techniques, livro, Prentice-Hall, 1979, ISBN 978-0-13-854547-5.
6. Wikipedia (em inglês), “Concurrency control”, acesso em 30/10/2026, en.wikipedia.org/wiki/Concurrency_control.

What DFD Simulator is

DFD Simulator draws data flow diagrams and runs them: you watch data move through the system, form queues and get stored. ^[1] It is a single HTML file that works in the browser, with no installation or account.

Open DFD Simulator →

A static diagram shows the structure, but not what happens when the system receives work. Simulating answers questions such as: where does a refused order go, which process forms a queue and what changes when capacity doubles.

How the app handles your data

• Nothing leaves your computer. The file blocks network connections.
• The model stays in the browser. It is kept automatically and comes back when you reopen the app. For a copy of your own, save it as JSON.
• Models do not run code. Rules go through a dedicated interpreter, so opening a model from someone else does not run JavaScript.

The elements of a DFD

A DFD has four elements, and the app draws each one in two notations. ^{[3] [4] [5]} For the theory, see the systems analysis and design tutorial. ^[2]

Process

Transforms data. Its name has a verb, such as “Validate order”, and it has a number.

External entity

Something outside the system that sends or receives data: a customer, a bank, another system.

Data store

Where data is kept between one process and another. Its number has the letter D.

Data flow

The path of a data item. The arrow shows the direction and the name says what passes.

Every flow needs a process at one of its ends. That is why the app refuses to connect two entities, two stores, or an entity to a store.

Your first DFD: a pizzeria

In about 15 minutes, you will build and simulate a pizzeria. The customer places an order, and the system calculates the amount, stores the order and tells the kitchen.

1. Create the elements

1. If the app opens with another model, use File ▾ → New model.
2. Drag from the palette onto the diagram: External entity on the left, Process in the centre, Data store above the process and another External entity on the right.
3. Double-click each element and rename it, confirming with Enter: Customer, Register order, Orders and Kitchen.

2. Connect the flows

Hover over an element: dots appear on its edge. Drag a dot to the destination element. The cursor moves to the Name field of the new flow; type and press Tab.

1. Customer to Register order: order.
2. Register order to Orders: registered order.
3. Register order to Kitchen: ticket.

3. Describe the behaviour

Click an element and fill in the Properties panel on the right.

1. In Customer, fill Generated data with the two lines below, Emit every with 2 and Emission limit with 5.

   id = seq
   qty = randint(1, 3)

2. In Register order, fill Rules with the line below. Each pizza costs 40.

   total = qty * 40

3. Click the ticket flow and fill Fields passed with id, qty. The kitchen does not need to see the amount.

4. Check the model

Open the Check tab. It shows a warning: the Orders store receives data, but nothing reads it. Warnings do not prevent the simulation; step 7 resolves this one.

5. Simulate

1. Click ▶ Simulate. The data leaves the customer and travels along the flows.
2. When it ends, the status shows Finished: nothing else scheduled, near t = 11.
3. Open the Stores tab in the lower panel. Orders has 5 records, with id, qty and total.
4. Click Kitchen. Under Last data received you see only id and qty: the flow filtered the fields.

6. Add a decision

1. Click ■ Edit to return to the drawing.
2. Create the Manager entity and connect Register order to it with the large order flow.
3. On that flow, fill Condition with total >= 100. The line becomes dashed, which marks a conditional flow.
4. Simulate again. Manager receives 2 of the 5 orders, those with an amount of 120. With the same seed, the values repeat.

7. Read the store and resolve the warning

1. Return to editing and create the Cashier entity and the Look up order process.
2. Create three flows: Cashier to Look up order (query), Orders to Look up order (order data) and Look up order to Cashier (order found).
3. In Cashier, fill Generated data with id = randint(1, 5) and leave Emit every at 0.
4. On the order data flow, fill Read filter with id == in.id and Name in rules with order.
5. In Look up order, fill Rules with found = exists(order). The Check tab now shows No problems found.
6. Simulate. After Finished, click Cashier: it emits a query, and Last data received shows found: true.

You have used automatic and manual emission, rules, a condition, field filtering, writing and reading. The rest of this tutorial details each feature.

The interface

The screen has a top bar and three columns: elements on the left, the diagram in the centre and properties on the right. During a simulation, a results panel appears below the diagram.

Top bar

Level path, undo and redo, the File ▾ menu, ▶ Simulate, language, help and theme.

Elements

The palette. Drag onto the diagram, or click to place in the centre of the view.

In this diagram

List of the elements and flows of the open level. Clicking selects the item.

Properties

Fields of the selected item. With no selection, it shows the model's Name, Notation, Random seed and Maximum time.

Check

Problems in the model. Clicking one takes you to the element.

Drawing and arranging

Two flows between the same elements curve by themselves so they do not overlap.

Properties of each element

Process

Rules

Calculate fields of the data. See the next section.

Duration

How long the process takes. Accepts an expression, such as random(1, 3).

Capacity

How many data items it serves at once. The excess waits in the queue.

Queue limit

How many items can wait. Items arriving at a full queue are rejected. 0 is no limit.

Priority

An expression that picks the next in the queue: the lowest value goes first. Empty follows arrival order.

Inputs

Runs on each input serves each item that arrives. Waits for all inputs holds until one item from each flow arrives and merges the fields.

Automatic interval

For processes with no input data flow: it fires by itself at this interval. If it reads stores, it fires only when there is a record, and the record read becomes the data.

Pause the simulation here

A breakpoint: pauses when a data item arrives. Only when limits it to a condition, such as total > 100. Stores and entities have it too.

External entity

Generated data

The fields of each emission. seq is the emission number.

Emit every

Interval between emissions. Accepts an expression: exponential(2) produces irregular arrivals, averaging 2. With 0, the entity emits only when clicked during the simulation.

Emission limit

Total automatic emissions. 0 is no limit, and then the simulation stops only when you pause it.

First emission at

Instant of the first automatic emission.

Data store

Key field

Identifies the record in updates and deletions.

Initial records (JSON)

List of objects loaded at the start, such as [{"id": 1, "stock": 10}].

Data flow

The fields change according to the flow's source and destination.

If more than one condition is true, each flow receives a copy of the data. If none is true and there is no else, the data is dropped and the log shows why.

Rules and expressions

Rules have one assignment per line, in the form field = expression, and they apply in order: a line can use the result of the previous one. Lines starting with # or // are comments.

# the price comes from the store read
price = products.price
total = round(qty * price, 2)
ok = exists(products) && products.stock >= qty

A missing field is null, and reading a field of null also gives null. Division by zero gives null. When a read finds no record, its name is null; that is why you use exists.

Levels and sub-diagrams

A complex process can be detailed in another diagram, with hierarchical numbering: process 2 opens into 2.1, 2.2 and so on.

1. Select the process and click Detail in a sub-diagram.
2. The parent process's flows appear as dashed elements: inputs on the left and outputs on the right.
3. Create the inner processes and connect them to those elements.

The levels stay balanced because the dashed elements come from the parent. A flow created in the parent appears in the sub-diagram; a flow deleted in the parent disappears, along with its connections. To change the name, edit the flow in the parent.

• With a sub-diagram, the parent process loses its rules and duration: the logic becomes that of the inner processes.
• The ⊞ marker on the process opens the sub-diagram.
• Remove sub-diagram deletes the level and those below it. Ctrl+Z undoes it.

In the simulation, the data enters through the dashed element, goes through the inner processes and leaves on the matching flow of the parent. When viewing the upper level, a blue number on the process shows how many data items are inside it.

Checking the model

The Check tab reviews the whole model, at all levels, and the number on it shows how many problems there are. Only forbidden connections and expression and JSON errors prevent the simulation.

Simulating

▶ Simulate runs a copy of the model, in simulated time. Each data item follows the cycle below:

Controls

The drawing is locked during the simulation. You can still open sub-diagrams and pan the view by dragging the background.

What appears on the diagram

Emitting and pausing

• An entity with no interval emits when clicked. On any entity, the Emit now button in the properties works.
• Tick Pause the simulation here on an element to stop when a data item reaches it. The status shows where it stopped.
• The simulation ends by itself when nothing else is scheduled.

Random seed

random and randint follow the model's Random seed. With the same seed, the result repeats, which lets you compare scenarios by changing one thing at a time. Change the seed to see another sequence.

Each element has its own sequence of draws, set by its position in the diagram. So changing one process's capacity does not alter arrivals or the durations of other processes.

Reading the results

The panel below the diagram has six tabs, and each one answers a question.

Log

What happened and when. Problems only filters drops and errors, and Download CSV exports. Clicking a line takes you to the element.

Statistics

How the system performed and where the bottleneck is.

Queues

How each queue grew and shrank over time, as a chart or a table.

Scenarios

How much the result varies between runs and what changed against a baseline.

Stores

What was stored, in tables of up to 200 records each.

Data in transit

Where each data item is now.

Emitted

Data items that entered the system.

Delivered and Stored

Arrivals at entities and writes to stores. One item can generate several, because each flow receives a copy.

Dropped

Items with no true condition, or stopped at a process with no output or a flow with no connection in the sub-diagram. Ideally zero, unless intentional.

Rejected

Data items refused because the queue was full.

Average time from start to delivery

From emission to arrival at an entity.

Median and 95% delivered within

Half of the deliveries take up to the median, and 95% up to the second value. They show what the average hides.

Data in the system (average)

How many data items, on average, were moving or waiting.

Deliveries per time unit

Total deliveries divided by the instant of the last delivery.

Max queue and Avg wait

Largest queue formed and average time in the queue.

Utilisation

Share of time the capacity was in use.

When there is a queue, the summary points to the process with the highest utilisation among those that formed one. It is the first bottleneck candidate.

Experiments with the samples

The three samples are under File ▾ and on the start screen. These experiments use seed 1, the default.

Finding a bottleneck

Open Service bottleneck and simulate: one ticket arrives every 1 time unit, but serving takes about 2. The Queues tab shows the queue climbing to 13. One run, however, is only one draw. To tell the rule from chance, repeat it.

1. Open the Scenarios tab, leave Runs at 30 and click Repeat with other seeds.
2. Click Save as baseline.
3. Click ■ Edit, select Serve, change Capacity to 2 and click ▶ Simulate.
4. On the Scenarios tab, click Repeat with other seeds again. The table compares the two scenarios.

Doubling the bottleneck's capacity cut the average wait from 12.23 to 0.37, and the Reading column shows clear difference, because the margins do not overlap. When they overlap, the reading is within the variation: the result does not show that one scenario is better. Changing the capacity of Triage would not have that effect, because it forms no queue.

Provoking a lost update

Open Library loan. With Emit every at 4, there are 5 loans and the collection drops from 5 copies to 0. Now change the value in Reader to 2 and simulate: there are 6 loans from a collection of only 5 copies.

The cause lies in the timing: a request reads the collection before the previous one writes its update. This is a lost update, a classic concurrency problem. ^[6] The simulator does not fix it; it makes the problem visible.

Following an order through two levels

Open Order processing and simulate: of the 8 orders, 7 are approved. Pausing and opening Invoice order shows the data in processes 2.1 and 2.2. Then, on Management, use Emit now to look up a stored sale.

Saving, opening and exporting

AI prompts

An AI helps you find out who sends and receives each piece of data, build the first diagram, write rules and read queues and bottlenecks. It also makes confident mistakes: it invents flows, guesses times and explains numbers it has not read. Treat its output as a draft from a colleague in a hurry. To write better prompts, see the prompt tutorial.

Before pasting: diagrams and records may contain confidential names, figures and rules. Replace them with made-up data and follow your organization's AI policy. The app sends nothing over the network, but the AI service receives whatever you paste into it.

Replace the parts in brackets and paste into the AI tool you use. The prompts follow the order of the work, but each one works on its own.

1. Interview before drawing

Makes the AI find out what is missing instead of assuming. It is the best start when the system is still in people's heads.

You are a systems analyst experienced with data flow diagrams.
I want to model this system: [describe in a few sentences].

Before proposing any diagram, interview me:
- Ask one question at a time and wait for my answer.
- Cover: who sends and receives data from outside the system, what each piece of data contains, what each process does with it, what must be kept, who reads what was kept, the conditions that change the path, the errors and refusals, the arrival volume and how long each process takes.
- Ask mainly about what goes wrong, not just the happy path.
- Do not invent answers. If I do not know, record it as an open item.

At the end, deliver tables of: external entities; processes (name with a verb, inputs, outputs, rule, duration, capacity); stores (fields and key); flows (source, target, name, fields, condition); and the list of open items.

2. Turn a text into elements

For requirements, minutes and procedures. It asks for the source of each item, which makes checking easier.

From the text below, extract the elements of a data flow diagram.

Text:
[paste the requirements, minutes or procedure]

Deliver:
1. External entities, processes and stores, each with the passage of the text that supports it.
2. Flows: source, target, name and fields. Every flow must have a process at one end.
3. Rules and conditions mentioned, and which process or flow each one applies to.
4. Gaps: data appearing with no source, stored data nobody reads, processes with no input or no output, and contradictions.
5. Questions to clarify each gap.

Do not fill gaps on your own. Whatever is not in the text goes to the questions.

3. Generate the model as JSON

Turns what you gathered into a file the app opens, instead of drawing element by element. It generates only the main level; then detail in the app the processes that need it.

Generate a model as JSON for DFD Simulator, from the information at the end.

Answer with the JSON only, no comments and no code fences.

Format:
- Root: "name", "notation" ("yd" or "gs"), "seed" and "diagrams". Generate only "diagrams.root", with "id": "root", "parent": null, "nodes" and "flows". Do not generate subdiagrams.
- Element: "id", "type" (entity, process or store), "name", "x", "y" and, where it makes sense, "desc".
- entity: "gen" (fields, one per line, separated by \n; seq is the emission number), "interval" (a number or expression, as text; 0 emits only on click), "limit" and "start".
- process: "k" (unique number), "rules" (field = expression, one per line), "duration" (expression, as text), "capacity" and "queueLimit" (0 is no limit).
- store: "k" (unique number), "key" (key field) and "initial" (text with a JSON list of objects).
- Flow: "id", "from", "to", "name" and, depending on the case:
  - leaving a process: "guard" (condition; "else" applies when no other is true) and "fields" (fields passed, separated by commas);
  - to a store: "op" (insert, upsert or delete);
  - from a store: "filter" (such as id == in.id), "alias" (name in rules), "readAll" and "consume";
  - on any flow: "transit" (transit time).

Rules:
- Every element and every flow needs an "id". Every flow must have a process at one end.
- Positions: x from 120 to 1300 and y from 70 to 600, at least 240 apart horizontally and 150 vertically. Entities on the sides, processes in the center and stores above or below them.
- Expressions accept + - * / %, comparisons, and, or, not, condition ? a : b, round, floor, ceil, min, max, abs, exists, coalesce, if, count, sum, avg, random(a, b), randint(a, b), exponential(mean), normal(mean, sd), chance(p) and pick(a, b). Use a point for decimals. Do not use other functions.
- A condition does not see the record read: write the result to a field in the rules and use that field.
- Use the same field names in all elements, because the app gives no warning when a name is wrong.
- Give entities with an "interval" a "limit" above 0, so the simulation ends.
- In "desc", say whether the times came from me or are your assumption. Do not invent sources.

Format example:
{
  "name": "Pizzeria",
  "notation": "yd",
  "seed": 1,
  "diagrams": {"root": {"id": "root", "parent": null,
    "nodes": [
      {"id": "c", "type": "entity", "name": "Customer", "x": 120, "y": 240, "gen": "id = seq\nqty = randint(1, 3)", "interval": "3", "limit": 6},
      {"id": "p", "type": "process", "name": "Register order", "x": 400, "y": 240, "k": 1, "rules": "total = qty * 40", "duration": "2", "capacity": 1},
      {"id": "d", "type": "store", "name": "Orders", "x": 400, "y": 70, "k": 1, "key": "id"},
      {"id": "k", "type": "entity", "name": "Kitchen", "x": 680, "y": 240}
    ],
    "flows": [
      {"id": "f1", "from": "c", "to": "p", "name": "order"},
      {"id": "f2", "from": "p", "to": "d", "name": "registered order"},
      {"id": "f3", "from": "p", "to": "k", "name": "kitchen ticket", "fields": "id, qty"}
    ]
  }}
}

Information:
[paste the result of prompt 1 or 2, or describe the system]

4. Estimate times and capacities

Queues depend on times. This prompt makes clear what is an assumption and returns expressions the app accepts.

I need initial times to simulate this system. I have no measurements.

System:
[paste the tables or the model JSON]
Time unit: [choose one for the whole model]

For each entity and process, deliver a table with: minimum, most likely, maximum, what you based it on, how I would measure the real value and your confidence (low, medium or high).

Rules:
- Everything is an assumption until I confirm it. Say so clearly.
- Do not cite studies or market figures you cannot point to precisely. With no basis, say "no basis" and give only the range.
- Return the exact text for the app's fields, using only random(a, b), exponential(mean) or normal(mean, sd): Emit every (entity), Duration, Capacity and Queue limit (process), Transit time (flow).
- For each process, compare the time it takes with the arrival interval, considering the capacity, and point out where a queue should form.
- Point out the 3 estimates most likely to change the result, which I should measure first.

5. Review the diagram

Looks for what the Check tab cannot see: data leaving a process without ever coming in, and missing flows.

Review this data flow diagram as an experienced systems analyst.

Model:
[paste the JSON or the tables]

Look for:
- Processes producing data they do not receive: fields going out without coming in or being calculated.
- Data received that no process uses.
- Stores written that nobody reads, or read with nothing writing them, and reads whose filter does not find the record.
- Missing flows: errors, refusals, replies to the source entity.
- Conditions that leave data with no way out, and flows with no else where one should be.
- Flows with vague names, processes with no verb and fields with different names for the same data.
- Reads and writes of the same record by simultaneous processes, which can cause a lost update.

Deliver a table with: element, problem, why it matters, suggestion and severity (high, medium or low). Do not rewrite the model. Do not confirm it is right just because you found no problems: say what cannot be assessed without more data.

6. Write rules and conditions

Returns the text for the fields, respecting what each one can see. A condition, for example, does not see the record read.

Write rules and conditions for DFD Simulator.

Model:
[paste the JSON or describe the elements and fields]
What I need to happen:
[describe in plain language]

For each field, deliver the exact text and where to paste it: Generated data (entity), Rules and Duration (process), Condition and Fields passed (flow leaving the process), Read filter and Name in rules (flow from a store).

Rules:
- Rules and generated data have one assignment per line, field = expression, and each line can use the previous one.
- Generated data sees seq, t and the previous lines. Rules and duration see the data fields, the records read through Name in rules and t. A condition sees the fields of the outgoing data and t. A filter sees the record fields, in.field and t.
- A condition does not see the record read: write the result to a field, such as ok = exists(product).
- If more than one condition is true, each flow gets a copy. If none is and there is no else, the data is discarded: say how to handle that case.
- Use only functions that exist: round, floor, ceil, abs, min, max, exists, coalesce, if, count, sum, avg, minof, maxof, len, upper, lower, concat, contains, random, randint, exponential, normal, chance and pick.
- A missing field is null, with no error: check the names and point out those you assumed.
- Give an example of input data and the expected result, so I can check it in the simulation.

7. Read the simulation results

After repeating the runs, copy the tables and paste them into the prompt, with the model.

Help me interpret this simulation. The numbers come from a model, not measurements.

Model:
[paste the JSON or describe the elements]
Results:
[paste the tables from the Statistics and Scenarios tabs, saying how many runs there were]

Deliver:
1. What the results say, in up to 5 sentences, comparing mean, median and 95%.
2. The likely bottleneck, with maximum queue, average wait and utilization, and why the other processes are not.
3. What the discarded and rejected items indicate.
4. What is a pattern and what may be chance: use the margin and the range between lowest and highest. With a single run, say it is too early to conclude.
5. What I cannot conclude: weak assumptions and model limitations.

Rules:
- Use only numbers in the tables, and create no new ones. If a figure is missing, say so.
- Separate what was calculated from your interpretation. Do not assert real-world causes: present them as hypotheses to confirm.

8. Plan the next scenarios

Turns the diagnosis into a short list of tests, to compare with the baseline one change at a time.

Based on this simulation, plan the next scenarios.

Model:
[paste the JSON or describe the elements]
Results:
[paste the tables from the Statistics and Scenarios tabs]
Objective: [for example, deliver 95% within 10 time units]
Constraints: [what cannot change]

Propose up to 5 alternatives and, for each one, deliver:
- What changes in the model: the element, the field (Capacity, Duration, Queue limit, Emit every, Condition or a new flow) and the exact value.
- The expected effect, as a hypothesis, and the measure that would confirm it.
- What the change would take in the real world, and the risk.

Rules:
- Each alternative changes one thing only, so the effect can be attributed.
- Start with the bottleneck. Warn when relieving one process may just move the queue to the next.
- Do not promise gains in numbers: the result comes from the simulation.

End with the steps in the app: repeat 30 runs, save as baseline, go back to editing, make the change, simulate, repeat and read the Reading column. Include an empty table for me to fill in: alternative, measure, baseline, current and reading.

How to open the JSON from prompt 3

1. Copy the AI's answer into a text editor and save it with the .json extension, for example system.json.
2. In the app, use File ▾ → Open model (.json)…, or drag the file onto the window. If there is already a model, confirm the replacement; save first whatever you want to keep.
3. Click Fit and drag whatever is badly placed: the app does not arrange the diagram by itself.
4. Open the Check tab and review each item.

How to take the results to the AI

The app does not generate a simulation report. For prompts 7 and 8, select the table on the Statistics or Scenarios tab with the mouse, copy it and paste it into the prompt. In Log, Download CSV exports the events.

Keyboard shortcuts

Limitations and troubleshooting

Limitations

• Time has no unit: one time unit can be a second or a day, as long as the whole model uses the same one.
• Margin of error: the 95% margin is an approximation that assumes independent runs. Use at least 30 runs before drawing conclusions.
• Stores have no transactions: each write is immediate, and two simultaneous reads see the same value.
• Copy and paste: sub-diagrams are not copied.
• Browsers: the app was tested in Chromium. Use in other browsers and on phones has not been tested.

Common problems

Quick review

Try to answer before opening each question.

References

1. Giovani Perotto Mesquita, “DFD Simulator”, single-file HTML application, giovanipm.github.io/dfd-simulator.html.
2. Giovani Perotto Mesquita, “Systems analysis and design”, tutorial on this site, giovanipm.github.io/AnaliseProjetoSistemas.html.
3. Wikipedia “Data-flow diagram”, accessed on 30 October 2026, en.wikipedia.org/wiki/Data-flow_diagram.
4. Tom DeMarco, Structured Analysis and System Specification, book, Prentice-Hall, 1979, ISBN 978-0-13-854380-8.
5. Chris Gane, Trish Sarson, Structured Systems Analysis: Tools and Techniques, book, Prentice-Hall, 1979, ISBN 978-0-13-854547-5.
6. Wikipedia “Concurrency control”, accessed on 30 October 2026, en.wikipedia.org/wiki/Concurrency_control.

Che cos'è DFD Simulator

DFD Simulator disegna diagrammi di flusso dei dati e li esegue: vedi i dati attraversare il sistema, formare code ed essere archiviati. ^[1] È un unico file HTML che funziona nel browser, senza installazione né account.

Apri DFD Simulator →

Un diagramma statico mostra la struttura, ma non ciò che accade quando il sistema riceve lavoro. La simulazione risponde a domande come: dove va un ordine rifiutato, quale processo forma una coda e che cosa cambia raddoppiando la capacità.

Come l'app tratta i tuoi dati

• Nulla esce dal tuo computer. Il file blocca le connessioni di rete.
• Il modello resta nel browser. Viene conservato automaticamente e ricompare quando riapri l'app. Per averne una copia tua, salvalo in JSON.
• I modelli non eseguono codice. Le regole passano per un interprete dedicato, quindi aprire un modello ricevuto da altri non esegue JavaScript.

Gli elementi di un DFD

Un DFD ha quattro elementi, e l'app disegna ciascuno in due notazioni. ^{[3] [4] [5]} Per la teoria, vedi il tutorial di analisi e progettazione dei sistemi. ^[2]

Processo

Trasforma i dati. Ha un nome con un verbo, come “Convalida ordine”, e un numero.

Entità esterna

Qualcosa fuori dal sistema che invia o riceve dati: un cliente, una banca, un altro sistema.

Archivio dati

Dove i dati restano tra un processo e l'altro. Ha un numero con la lettera D.

Flusso di dati

Il percorso di un dato. La freccia indica la direzione e il nome dice che cosa passa.

Ogni flusso deve avere un processo a una delle estremità. Per questo l'app rifiuta di collegare due entità, due archivi o un'entità a un archivio.

Il tuo primo DFD: una pizzeria

In circa 15 minuti costruirai e simulerai una pizzeria. Il cliente fa un ordine, e il sistema calcola l'importo, registra l'ordine e avvisa la cucina.

1. Crea gli elementi

1. Se l'app si apre con un altro modello, usa File ▾ → Nuovo modello.
2. Trascina dalla tavolozza al diagramma: Entità esterna a sinistra, Processo al centro, Archivio dati sopra il processo e un'altra Entità esterna a destra.
3. Fai doppio clic su ogni elemento e rinominalo, confermando con Invio: Cliente, Registra ordine, Ordini e Cucina.

2. Collega i flussi

Passa il mouse su un elemento: compaiono dei punti sul bordo. Trascina un punto sull'elemento di destinazione. Il cursore passa al campo Nome del nuovo flusso; digita e premi Tab.

1. Cliente a Registra ordine: ordine.
2. Registra ordine a Ordini: ordine registrato.
3. Registra ordine a Cucina: comanda.

3. Descrivi il comportamento

Fai clic su un elemento e compila il pannello Proprietà a destra.

1. In Cliente, compila Dati generati con le due righe qui sotto, Emetti ogni con 2 e Limite di emissioni con 5.

   id = seq
   qty = randint(1, 3)

2. In Registra ordine, compila Regole con la riga qui sotto. Ogni pizza costa 40.

   total = qty * 40

3. Fai clic sul flusso comanda e compila Campi trasmessi con id, qty. La cucina non ha bisogno di vedere l'importo.

4. Verifica il modello

Apri la scheda Verifica. Mostra un avviso: l'archivio Ordini riceve dati, ma nessuno li legge. Gli avvisi non impediscono la simulazione; il passo 7 risolve questo.

5. Simula

1. Fai clic su ▶ Simula. I dati escono dal cliente e percorrono i flussi.
2. Alla fine, lo stato mostra Conclusa: nient'altro in programma, vicino a t = 11.
3. Apri la scheda Archivi nel pannello in basso. Ordini ha 5 record, con id, qty e total.
4. Fai clic su Cucina. In Ultimo dato ricevuto compaiono solo id e qty: il flusso ha filtrato i campi.

6. Aggiungi una decisione

1. Fai clic su ■ Modifica per tornare al disegno.
2. Crea l'entità Direttore e collega Registra ordine a essa con il flusso ordine grande.
3. Su quel flusso, compila Condizione con total >= 100. La linea diventa tratteggiata, il che indica un flusso condizionale.
4. Simula di nuovo. Direttore riceve 2 dei 5 ordini, quelli di importo 120. Con lo stesso seme, i valori si ripetono.

7. Leggi l'archivio e risolvi l'avviso

1. Torna a modificare e crea l'entità Cassa e il processo Consulta ordine.
2. Crea tre flussi: Cassa a Consulta ordine (richiesta), Ordini a Consulta ordine (dati dell'ordine) e Consulta ordine a Cassa (ordine trovato).
3. In Cassa, compila Dati generati con id = randint(1, 5) e lascia Emetti ogni a 0.
4. Sul flusso dati dell'ordine, compila Filtro di lettura con id == in.id e Nome nelle regole con order.
5. In Consulta ordine, compila Regole con found = exists(order). La scheda Verifica ora mostra Nessun problema trovato.
6. Simula. Dopo Conclusa, fai clic su Cassa: emette una richiesta, e Ultimo dato ricevuto riporta found: true.

Hai usato emissione automatica e manuale, regole, condizione, filtro dei campi, scrittura e lettura. Il resto del tutorial descrive ogni funzione.

L'interfaccia

Lo schermo ha una barra superiore e tre colonne: elementi a sinistra, diagramma al centro e proprietà a destra. Durante la simulazione, compare un pannello dei risultati sotto il diagramma.

Barra superiore

Percorso dei livelli, annulla e ripeti, menu File ▾, ▶ Simula, lingua, guida e tema.

Elementi

La tavolozza. Trascina sul diagramma, o fai clic per posizionare al centro della vista.

In questo diagramma

Elenco di elementi e flussi del livello aperto. Il clic seleziona la voce.

Proprietà

Campi della voce selezionata. Senza selezione, mostra Nome, Notazione, Seme casuale e Tempo massimo del modello.

Verifica

Problemi del modello. Il clic su uno di essi porta all'elemento.

Disegnare e organizzare

Due flussi tra gli stessi elementi si curvano da soli per non sovrapporsi.

Proprietà di ogni elemento

Processo

Regole

Calcolano campi del dato. Vedi la sezione successiva.

Durata

Quanto tempo impiega il processo. Accetta un'espressione, come random(1, 3).

Capacità

Quanti dati serve allo stesso tempo. L'eccedenza attende in coda.

Limite della coda

Quanti dati possono attendere. Chi arriva con la coda piena viene rifiutato. 0 è nessun limite.

Priorità

Espressione che sceglie il prossimo in coda: il valore più basso passa per primo. Vuoto segue l'ordine di arrivo.

Ingressi

Esegue a ogni ingresso serve ogni dato che arriva. Attende tutti gli ingressi aspetta un dato da ogni flusso e unisce i campi.

Intervallo automatico

Per processi senza flussi di dati in ingresso: si attiva da solo a questo intervallo. Se legge archivi, si attiva solo quando c'è un record, e il record letto diventa il dato.

Sospendi la simulazione qui

Punto di arresto: sospende quando arriva un dato. Solo quando lo limita a una condizione, come total > 100. Ce l'hanno anche archivi ed entità.

Entità esterna

Dati generati

I campi di ogni emissione. seq è il numero di emissione.

Emetti ogni

Intervallo tra le emissioni. Accetta un'espressione: exponential(2) genera arrivi irregolari, con media 2. Con 0, l'entità emette solo al clic durante la simulazione.

Limite di emissioni

Totale delle emissioni automatiche. 0 è nessun limite, e allora la simulazione si ferma solo quando la sospendi.

Prima emissione a

Istante della prima emissione automatica.

Archivio dati

Campo chiave

Identifica il record in aggiornamenti ed eliminazioni.

Record iniziali (JSON)

Elenco di oggetti caricato all'inizio, come [{"id": 1, "stock": 10}].

Flusso di dati

I campi cambiano secondo l'origine e la destinazione del flusso.

Se più di una condizione è vera, ogni flusso riceve una copia del dato. Se nessuna è vera e non c'è else, il dato viene scartato e il registro ne indica il motivo.

Regole ed espressioni

Le regole hanno un'assegnazione per riga, nella forma campo = espressione, e si applicano in ordine: una riga può usare il risultato della precedente. Le righe che iniziano con # o // sono commenti.

# il prezzo viene dall'archivio letto
price = products.price
total = round(qty * price, 2)
ok = exists(products) && products.stock >= qty

Un campo inesistente vale null, e leggere un campo di null dà ancora null. La divisione per zero dà null. Quando la lettura non trova un record, il suo nome vale null; per questo si usa exists.

Livelli e sottodiagrammi

Un processo complesso può essere dettagliato in un altro diagramma, con numerazione gerarchica: il processo 2 si apre in 2.1, 2.2 e così via.

1. Seleziona il processo e fai clic su Dettaglia in un sottodiagramma.
2. I flussi del processo padre compaiono come elementi tratteggiati: a sinistra gli ingressi e a destra le uscite.
3. Crea i processi interni e collegali a questi elementi.

I livelli restano bilanciati perché gli elementi tratteggiati vengono dal padre. Un flusso creato nel padre compare nel sottodiagramma; un flusso eliminato nel padre scompare, con i suoi collegamenti. Per cambiare il nome, modifica il flusso nel padre.

• Con un sottodiagramma, il processo padre perde regole e durata: la logica diventa quella dei processi interni.
• L'indicatore ⊞ sul processo apre il sottodiagramma.
• Rimuovi sottodiagramma elimina il livello e quelli sottostanti. Ctrl+Z annulla.

Nella simulazione, il dato entra dall'elemento tratteggiato, passa per i processi interni ed esce sul flusso corrispondente del padre. Guardando il livello superiore, un numero blu sul processo indica quanti dati ci sono al suo interno.

Verificare il modello

La scheda Verifica controlla tutto il modello, a tutti i livelli, e il numero su di essa indica quanti problemi ci sono. Solo i collegamenti vietati e gli errori di espressione e JSON impediscono la simulazione.

Simulare

▶ Simula esegue una copia del modello, in tempo simulato. Ogni dato segue il ciclo qui sotto:

Controlli

Il disegno è bloccato durante la simulazione. Puoi comunque aprire i sottodiagrammi e spostare la vista trascinando lo sfondo.

Che cosa compare sul diagramma

Emettere e sospendere

• Un'entità senza intervallo emette al clic. Su qualsiasi entità, funziona il pulsante Emetti ora nelle proprietà.
• Spunta Sospendi la simulazione qui su un elemento per fermarti quando un dato lo raggiunge. Lo stato mostra dove si è fermata.
• La simulazione termina da sola quando non c'è altro in programma.

Seme casuale

random e randint seguono il Seme casuale del modello. Con lo stesso seme il risultato si ripete, il che permette di confrontare scenari cambiando una cosa alla volta. Cambia il seme per vedere un'altra sequenza.

Ogni elemento ha la propria sequenza di estrazioni, definita dalla sua posizione nel diagramma. Così, cambiare la capacità di un processo non altera gli arrivi né le durate degli altri.

Leggere i risultati

Il pannello sotto il diagramma ha sei schede, e ognuna risponde a una domanda.

Registro

Che cosa è accaduto e quando. Solo problemi filtra scarti ed errori, e Scarica CSV esporta. Il clic su una riga porta all'elemento.

Statistiche

Come si è comportato il sistema e dov'è il collo di bottiglia.

Code

Come ogni coda è cresciuta e diminuita nel tempo, in grafico o tabella.

Scenari

Quanto varia il risultato tra le esecuzioni e che cosa è cambiato rispetto a un riferimento.

Archivi

Che cosa è stato scritto, in tabelle con fino a 200 record ciascuna.

Dati in transito

Dove si trova ora ogni dato.

Emessi

Dati entrati nel sistema.

Consegnati e Archiviati

Arrivi alle entità e scritture negli archivi. Un dato può generarne diversi, perché ogni flusso riceve una copia.

Scartati

Dati senza condizione vera, o fermi su un processo senza uscita o su un flusso senza collegamento nel sottodiagramma. L'ideale è zero, salvo intenzione.

Rifiutati

Dati respinti perché la coda era piena.

Tempo medio dall'inizio alla consegna

Dall'emissione all'arrivo a un'entità.

Mediana e 95% consegnati entro

Metà delle consegne richiede fino alla mediana, e il 95% fino al secondo valore. Mostrano ciò che la media nasconde.

Dati nel sistema (media)

Quanti dati, in media, erano in circolo o in attesa.

Consegne per unità di tempo

Totale delle consegne diviso l'istante dell'ultima consegna.

Coda max e Attesa media

Coda più lunga formata e tempo medio in coda.

Occupazione

Parte del tempo in cui la capacità è stata in uso.

Quando c'è una coda, il riepilogo indica il processo con la massima occupazione tra quelli che l'hanno formata. È il primo candidato a collo di bottiglia.

Esperimenti con gli esempi

I tre esempi si trovano in File ▾ e nella schermata iniziale. Questi esperimenti usano il seme 1, quello predefinito.

Trovare un collo di bottiglia

Apri Collo di bottiglia del servizio e simula: arriva una richiesta ogni 1 unità di tempo, ma servirla richiede circa 2. La scheda Code mostra la coda che sale fino a 13. Una sola esecuzione, però, è una sola estrazione. Per distinguere la regola dal caso, ripeti.

1. Apri la scheda Scenari, lascia Esecuzioni a 30 e fai clic su Ripeti con altri semi.
2. Fai clic su Salva come riferimento.
3. Fai clic su ■ Modifica, seleziona Servi, porta Capacità a 2 e fai clic su ▶ Simula.
4. Nella scheda Scenari, fai di nuovo clic su Ripeti con altri semi. La tabella confronta i due scenari.

Raddoppiare la capacità del collo di bottiglia ha ridotto l'attesa media da 12,23 a 0,37, e la colonna Lettura indica differenza netta, perché i margini non si sovrappongono. Quando si sovrappongono, la lettura è entro la variazione: il risultato non mostra che uno scenario è migliore. Cambiare la capacità di Smistamento non avrebbe questo effetto, perché non forma coda.

Provocare un aggiornamento perso

Apri Prestito in biblioteca. Con Emetti ogni a 4, ci sono 5 prestiti e il catalogo scende da 5 copie a 0. Ora porta il valore in Lettore a 2 e simula: ci sono 6 prestiti da un catalogo di sole 5 copie.

La causa sta nei tempi: una richiesta legge il catalogo prima che la precedente scriva l'aggiornamento. È un aggiornamento perso, un classico problema di concorrenza. ^[6] Il simulatore non lo corregge; lo rende visibile.

Seguire un ordine su due livelli

Apri Elaborazione ordini e simula: degli 8 ordini, 7 sono approvati. Sospendendo e aprendo Fattura ordine vedi i dati nei processi 2.1 e 2.2. Poi, su Direzione, usa Emetti ora per consultare una vendita archiviata.

Salvare, aprire ed esportare

Prompt di IA

Un'IA aiuta a scoprire chi invia e riceve ogni dato, a creare il primo diagramma, a scrivere regole e a leggere code e colli di bottiglia. Sbaglia anche con sicurezza: inventa flussi, tira a indovinare i tempi e spiega numeri che non ha letto. Tratta il risultato come la bozza di un collega di fretta. Per scrivere prompt migliori, vedi il tutorial sui prompt.

Prima di incollare: diagrammi e record possono contenere nomi, valori e regole riservati. Sostituiscili con dati fittizi e segui la politica della tua organizzazione sull'uso dell'IA. L'app non invia nulla in rete, ma il servizio di IA riceve ciò che vi incolli.

Sostituisci le parti tra parentesi quadre e incolla nello strumento di IA che usi. I prompt seguono l'ordine del lavoro, ma ognuno funziona da solo.

1. Intervistare prima di disegnare

Fa scoprire all'IA ciò che manca, invece di supporlo. È l'inizio migliore quando il sistema è ancora nella testa delle persone.

Sei un analista di sistemi esperto di diagrammi di flusso dei dati.
Voglio modellare questo sistema: [descrivilo in poche frasi].

Prima di proporre qualsiasi diagramma, intervistami:
- Fai una domanda alla volta e aspetta la mia risposta.
- Copri: chi invia e riceve dati dall'esterno del sistema, cosa contiene ogni dato, cosa ne fa ogni processo, cosa va conservato, chi legge ciò che è conservato, le condizioni che cambiano il percorso, gli errori e i rifiuti, il volume di arrivo e quanto tempo richiede ogni processo.
- Chiedi soprattutto ciò che va storto, non solo il percorso ideale.
- Non inventare risposte. Se non lo so, registralo come punto aperto.

Alla fine, consegna tabelle di: entità esterne; processi (nome con verbo, ingressi, uscite, regola, durata, capacità); archivi (campi e chiave); flussi (origine, destinazione, nome, campi, condizione); e l'elenco dei punti aperti.

2. Trasformare un testo in elementi

Per requisiti, verbali e procedure. Chiede l'origine di ogni voce, il che facilita il controllo.

Dal testo qui sotto, estrai gli elementi di un diagramma di flusso dei dati.

Testo:
[incolla i requisiti, il verbale o la procedura]

Consegna:
1. Entità esterne, processi e archivi, ciascuno con il brano che lo sostiene.
2. Flussi: origine, destinazione, nome e campi. Ogni flusso deve avere un processo a un'estremità.
3. Regole e condizioni citate, e a quale processo o flusso si applica ciascuna.
4. Lacune: dati che appaiono senza origine, dati conservati che nessuno legge, processi senza ingresso o senza uscita, e contraddizioni.
5. Domande per chiarire ogni lacuna.

Non colmare le lacune da solo. Ciò che non è nel testo va nelle domande.

3. Generare il modello in JSON

Trasforma ciò che hai raccolto in un file che l'app apre, invece di disegnare elemento per elemento. Genera solo il livello principale; poi dettaglia nell'app i processi che lo richiedono.

Genera un modello in JSON per DFD Simulator, dalle informazioni alla fine.

Rispondi solo con il JSON, senza commenti e senza delimitatori di codice.

Formato:
- Radice: "name", "notation" ("yd" o "gs"), "seed" e "diagrams". Genera solo "diagrams.root", con "id": "root", "parent": null, "nodes" e "flows". Non generare sottodiagrammi.
- Elemento: "id", "type" (entity, process o store), "name", "x", "y" e, se ha senso, "desc".
- entity: "gen" (campi, uno per riga, separati da \n; seq è il numero dell'emissione), "interval" (numero o espressione, come testo; 0 emette solo con un clic), "limit" e "start".
- process: "k" (numero unico), "rules" (campo = espressione, una per riga), "duration" (espressione, come testo), "capacity" e "queueLimit" (0 è senza limite).
- store: "k" (numero unico), "key" (campo chiave) e "initial" (testo con un elenco JSON di oggetti).
- Flusso: "id", "from", "to", "name" e, secondo il caso:
  - in uscita da un processo: "guard" (condizione; "else" vale quando nessun'altra è vera) e "fields" (campi trasmessi, separati da virgole);
  - verso un archivio: "op" (insert, upsert o delete);
  - da un archivio: "filter" (come id == in.id), "alias" (nome nelle regole), "readAll" e "consume";
  - su qualsiasi flusso: "transit" (tempo di transito).

Regole:
- Ogni elemento e ogni flusso richiede un "id". Ogni flusso deve avere un processo a un'estremità.
- Posizioni: x da 120 a 1300 e y da 70 a 600, ad almeno 240 di distanza in orizzontale e 150 in verticale. Entità ai lati, processi al centro e archivi sopra o sotto di essi.
- Le espressioni accettano + - * / %, confronti, and, or, not, condizione ? a : b, round, floor, ceil, min, max, abs, exists, coalesce, if, count, sum, avg, random(a, b), randint(a, b), exponential(media), normal(media, dev), chance(p) e pick(a, b). Usa il punto per i decimali. Non usare altre funzioni.
- Una condizione non vede il record letto: scrivi il risultato in un campo nelle regole e usa quel campo.
- Usa gli stessi nomi di campo in tutti gli elementi, perché l'app non avvisa quando un nome è sbagliato.
- Dai un "limit" maggiore di 0 alle entità con "interval", perché la simulazione finisca.
- In "desc", indica se i tempi vengono da me o sono una tua ipotesi. Non inventare fonti.

Esempio del formato:
{
  "name": "Pizzeria",
  "notation": "yd",
  "seed": 1,
  "diagrams": {"root": {"id": "root", "parent": null,
    "nodes": [
      {"id": "c", "type": "entity", "name": "Cliente", "x": 120, "y": 240, "gen": "id = seq\nqty = randint(1, 3)", "interval": "3", "limit": 6},
      {"id": "p", "type": "process", "name": "Registrare ordine", "x": 400, "y": 240, "k": 1, "rules": "total = qty * 40", "duration": "2", "capacity": 1},
      {"id": "d", "type": "store", "name": "Ordini", "x": 400, "y": 70, "k": 1, "key": "id"},
      {"id": "k", "type": "entity", "name": "Cucina", "x": 680, "y": 240}
    ],
    "flows": [
      {"id": "f1", "from": "c", "to": "p", "name": "ordine"},
      {"id": "f2", "from": "p", "to": "d", "name": "ordine registrato"},
      {"id": "f3", "from": "p", "to": "k", "name": "comanda", "fields": "id, qty"}
    ]
  }}
}

Informazioni:
[incolla il risultato del prompt 1 o 2, o descrivi il sistema]

4. Stimare tempi e capacità

Le code dipendono dai tempi. Questo prompt chiarisce cosa è ipotesi e restituisce espressioni che l'app accetta.

Mi servono tempi iniziali per simulare questo sistema. Non ho misure.

Sistema:
[incolla le tabelle o il JSON del modello]
Unità di tempo: [scegline una sola per tutto il modello]

Per ogni entità e processo, consegna una tabella con: minimo, più probabile, massimo, su cosa ti sei basato, come misurerei il valore reale e la tua fiducia (bassa, media o alta).

Regole:
- Tutto è ipotesi finché non lo confermo. Dillo chiaramente.
- Non citare studi o numeri di mercato che non puoi indicare con precisione. Senza base, scrivi "senza base" e dai solo l'intervallo.
- Restituisci il testo esatto per i campi dell'app, usando solo random(a, b), exponential(media) o normal(media, dev): Emetti ogni (entità), Durata, Capacità e Limite della coda (processo), Tempo di transito (flusso).
- Per ogni processo, confronta il tempo che richiede con l'intervallo di arrivo, considerando la capacità, e indica dove dovrebbe formarsi una coda.
- Indica le 3 stime che più possono cambiare il risultato e che dovrei misurare per prime.

5. Rivedere il diagramma

Cerca ciò che la scheda Verifica non vede: dati che escono da un processo senza mai essere entrati, e flussi mancanti.

Rivedi questo diagramma di flusso dei dati come un analista di sistemi esperto.

Modello:
[incolla il JSON o le tabelle]

Cerca:
- Processi che producono dati che non ricevono: campi che escono senza entrare né essere calcolati.
- Dati ricevuti che nessun processo usa.
- Archivi scritti che nessuno legge, o letti senza che nulla li scriva, e letture il cui filtro non trova il record.
- Flussi mancanti: errori, rifiuti, risposte all'entità di origine.
- Condizioni che lasciano il dato senza uscita, e flussi senza else dove dovrebbe esserci.
- Flussi con nomi vaghi, processi senza verbo e campi con nomi diversi per lo stesso dato.
- Letture e scritture dello stesso record da parte di processi simultanei, che possono causare un aggiornamento perso.

Consegna una tabella con: elemento, problema, perché conta, suggerimento e gravità (alta, media o bassa). Non riscrivere il modello. Non confermare che è giusto solo perché non hai trovato problemi: di' cosa non si può valutare senza altri dati.

6. Scrivere regole e condizioni

Restituisce il testo dei campi, rispettando ciò che ognuno vede. Una condizione, ad esempio, non vede il record letto.

Scrivi regole e condizioni per DFD Simulator.

Modello:
[incolla il JSON o descrivi gli elementi e i campi]
Cosa deve succedere:
[descrivilo in linguaggio comune]

Per ogni campo, consegna il testo esatto e dove incollarlo: Dati generati (entità), Regole e Durata (processo), Condizione e Campi trasmessi (flusso in uscita dal processo), Filtro di lettura e Nome nelle regole (flusso da un archivio).

Regole:
- Regole e dati generati hanno un'assegnazione per riga, campo = espressione, e ogni riga può usare la precedente.
- I dati generati vedono seq, t e le righe precedenti. Regole e durata vedono i campi del dato, i record letti tramite Nome nelle regole e t. Una condizione vede i campi del dato in uscita e t. Un filtro vede i campi del record, in.campo e t.
- Una condizione non vede il record letto: scrivi il risultato in un campo, come ok = exists(prodotto).
- Se più di una condizione è vera, ogni flusso riceve una copia. Se nessuna lo è e non c'è else, il dato viene scartato: indica come gestire questo caso.
- Usa solo funzioni esistenti: round, floor, ceil, abs, min, max, exists, coalesce, if, count, sum, avg, minof, maxof, len, upper, lower, concat, contains, random, randint, exponential, normal, chance e pick.
- Un campo inesistente vale null, senza errori: controlla i nomi e indica quelli che hai supposto.
- Dai un esempio di dato in ingresso e il risultato atteso, così posso controllarlo nella simulazione.

7. Leggere i risultati della simulazione

Dopo aver ripetuto le esecuzioni, copia le tabelle e incollale nel prompt, con il modello.

Aiutami a interpretare questa simulazione. I numeri vengono da un modello, non da misure.

Modello:
[incolla il JSON o descrivi gli elementi]
Risultati:
[incolla le tabelle delle schede Statistiche e Scenari, indicando quante esecuzioni sono state fatte]

Consegna:
1. Cosa dicono i risultati, in massimo 5 frasi, confrontando media, mediana e 95%.
2. Il probabile collo di bottiglia, con coda massima, attesa media e occupazione, e perché gli altri processi non lo sono.
3. Cosa indicano gli scartati e i rifiutati.
4. Cosa è regolare e cosa può essere caso: usa il margine e l'intervallo tra minimo e massimo. Con una sola esecuzione, di' che è presto per concludere.
5. Cosa non posso concludere: ipotesi fragili e limiti del modello.

Regole:
- Usa solo numeri presenti nelle tabelle, senza crearne di nuovi. Se manca un dato, dillo.
- Separa ciò che è stato calcolato dalla tua interpretazione. Non affermare cause nel mondo reale: presentale come ipotesi da confermare.

8. Pianificare i prossimi scenari

Trasforma la diagnosi in un breve elenco di prove, per confrontare con il riferimento una modifica alla volta.

In base a questa simulazione, pianifica i prossimi scenari.

Modello:
[incolla il JSON o descrivi gli elementi]
Risultati:
[incolla le tabelle delle schede Statistiche e Scenari]
Obiettivo: [ad esempio, consegnare il 95% entro 10 unità di tempo]
Vincoli: [cosa non può cambiare]

Proponi fino a 5 alternative e, per ognuna, consegna:
- Cosa cambia nel modello: l'elemento, il campo (Capacità, Durata, Limite della coda, Emetti ogni, Condizione o un nuovo flusso) e il valore esatto.
- L'effetto atteso, come ipotesi, e la misura che lo confermerebbe.
- Cosa servirebbe per fare la modifica nel mondo reale, e il rischio.

Regole:
- Ogni alternativa cambia una sola cosa, perché l'effetto sia attribuibile.
- Inizia dal collo di bottiglia. Avvisa quando alleggerire un processo può solo spostare la coda al successivo.
- Non promettere guadagni in numeri: il risultato viene dalla simulazione.

Concludi con i passi nell'app: ripetere 30 esecuzioni, salvare come riferimento, tornare a modificare, fare la modifica, simulare, ripetere e leggere la colonna Lettura. Includi una tabella vuota da compilare: alternativa, misura, riferimento, attuale e lettura.

Come aprire il JSON del prompt 3

1. Copia la risposta dell'IA in un editor di testo e salvala con l'estensione .json, ad esempio sistema.json.
2. Nell'app, usa File ▾ → Apri modello (.json)…, o trascina il file nella finestra. Se c'è già un modello, conferma la sostituzione; salva prima ciò che vuoi conservare.
3. Fai clic su Adatta e trascina ciò che è mal posizionato: l'app non dispone il diagramma da sola.
4. Apri la scheda Verifica e controlla ogni voce.

Come portare i risultati all'IA

L'app non genera un rapporto della simulazione. Per i prompt 7 e 8, seleziona con il mouse la tabella della scheda Statistiche o Scenari, copiala e incollala nel prompt. In Registro, Scarica CSV esporta gli eventi.

Scorciatoie da tastiera

Limiti e risoluzione dei problemi

Limiti

• Tempo senza unità: un'unità di tempo può essere un secondo o un giorno, purché tutto il modello usi la stessa.
• Margine di errore: il margine del 95% è un'approssimazione che presuppone esecuzioni indipendenti. Usa almeno 30 esecuzioni prima di trarre conclusioni.
• Archivi senza transazioni: ogni scrittura è immediata, e due letture simultanee vedono lo stesso valore.
• Copia e incolla: i sottodiagrammi non vengono copiati.
• Browser: l'app è stata provata in Chromium. L'uso in altri browser e su telefono non è stato provato.

Problemi comuni

Ripasso rapido

Prova a rispondere prima di aprire ogni domanda.

Riferimenti

1. Giovani Perotto Mesquita, “DFD Simulator”, applicazione in un unico file HTML, giovanipm.github.io/dfd-simulator.html.
2. Giovani Perotto Mesquita, “Analisi e progettazione dei sistemi”, tutorial di questo sito, giovanipm.github.io/AnaliseProjetoSistemas.html.
3. Wikipedia (in inglese), “Data-flow diagram”, consultato il 30/10/2026, en.wikipedia.org/wiki/Data-flow_diagram.
4. Tom DeMarco, Structured Analysis and System Specification, libro, Prentice-Hall, 1979, ISBN 978-0-13-854380-8.
5. Chris Gane, Trish Sarson, Structured Systems Analysis: Tools and Techniques, libro, Prentice-Hall, 1979, ISBN 978-0-13-854547-5.
6. Wikipedia (in inglese), “Concurrency control”, consultato il 30/10/2026, en.wikipedia.org/wiki/Concurrency_control.

Qué es DFD Simulator

DFD Simulator dibuja diagramas de flujo de datos y los ejecuta: ves los datos recorrer el sistema, formar colas y almacenarse. ^[1] Es un único archivo HTML que funciona en el navegador, sin instalación ni cuenta.

Abrir DFD Simulator →

Un diagrama estático muestra la estructura, pero no lo que ocurre cuando el sistema recibe trabajo. Simular responde a preguntas como: adónde va un pedido rechazado, qué proceso forma cola y qué cambia al duplicar la capacidad.

Cómo trata la aplicación tus datos

• Nada sale de tu ordenador. El archivo bloquea las conexiones de red.
• El modelo queda en el navegador. Se conserva automáticamente y reaparece al volver a abrir la aplicación. Para tener una copia propia, guárdalo en JSON.
• Los modelos no ejecutan código. Las reglas pasan por un intérprete propio, así que abrir un modelo recibido de otra persona no ejecuta JavaScript.

Los elementos de un DFD

Un DFD tiene cuatro elementos, y la aplicación dibuja cada uno en dos notaciones. ^{[3] [4] [5]} Para la teoría, consulta el tutorial de análisis y diseño de sistemas. ^[2]

Proceso

Transforma datos. Tiene un nombre con verbo, como “Validar pedido”, y un número.

Entidad externa

Algo fuera del sistema que envía o recibe datos: un cliente, un banco, otro sistema.

Almacén de datos

Donde los datos quedan guardados entre un proceso y otro. Tiene un número con la letra D.

Flujo de datos

El camino de un dato. La flecha indica el sentido y el nombre dice qué pasa.

Todo flujo necesita un proceso en uno de sus extremos. Por eso la aplicación rechaza conectar dos entidades, dos almacenes o una entidad a un almacén.

Tu primer DFD: una pizzería

En unos 15 minutos, construirás y simularás una pizzería. El cliente hace un pedido, y el sistema calcula el importe, guarda el pedido y avisa a la cocina.

1. Crea los elementos

1. Si la aplicación se abre con otro modelo, usa Archivo ▾ → Nuevo modelo.
2. Arrastra de la paleta al diagrama: Entidad externa a la izquierda, Proceso en el centro, Almacén de datos sobre el proceso y otra Entidad externa a la derecha.
3. Haz doble clic en cada elemento y renómbralo, confirmando con Intro: Cliente, Registrar pedido, Pedidos y Cocina.

2. Conecta los flujos

Pasa el ratón sobre un elemento: aparecen puntos en el borde. Arrastra un punto hasta el elemento de destino. El cursor pasa al campo Nombre del nuevo flujo; escribe y pulsa Tab.

1. Cliente a Registrar pedido: pedido.
2. Registrar pedido a Pedidos: pedido registrado.
3. Registrar pedido a Cocina: comanda.

3. Describe el comportamiento

Haz clic en un elemento y rellena el panel Propiedades, a la derecha.

1. En Cliente, rellena Datos generados con las dos líneas de abajo, Emitir cada con 2 y Límite de emisiones con 5.

   id = seq
   qty = randint(1, 3)

2. En Registrar pedido, rellena Reglas con la línea de abajo. Cada pizza cuesta 40.

   total = qty * 40

3. Haz clic en el flujo comanda y rellena Campos que pasan con id, qty. La cocina no necesita ver el importe.

4. Verifica el modelo

Abre la pestaña Verificar. Muestra un aviso: el almacén Pedidos recibe datos, pero nadie los lee. Los avisos no impiden la simulación; el paso 7 resuelve este.

5. Simula

1. Haz clic en ▶ Simular. Los datos salen del cliente y recorren los flujos.
2. Al terminar, el estado muestra Concluida: nada más programado, cerca de t = 11.
3. Abre la pestaña Almacenes en el panel inferior. Pedidos tiene 5 registros, con id, qty y total.
4. Haz clic en Cocina. En Último dato recibido aparecen solo id y qty: el flujo filtró los campos.

6. Añade una decisión

1. Haz clic en ■ Editar para volver al dibujo.
2. Crea la entidad Gerente y conecta Registrar pedido a ella con el flujo pedido grande.
3. En ese flujo, rellena Condición con total >= 100. La línea pasa a ser discontinua, lo que indica un flujo condicional.
4. Simula de nuevo. Gerente recibe 2 de los 5 pedidos, los de importe 120. Con la misma semilla, los valores se repiten.

7. Lee el almacén y resuelve el aviso

1. Vuelve a editar y crea la entidad Caja y el proceso Consultar pedido.
2. Crea tres flujos: Caja a Consultar pedido (consulta), Pedidos a Consultar pedido (datos del pedido) y Consultar pedido a Caja (pedido consultado).
3. En Caja, rellena Datos generados con id = randint(1, 5) y deja Emitir cada en 0.
4. En el flujo datos del pedido, rellena Filtro de lectura con id == in.id y Nombre en las reglas con order.
5. En Consultar pedido, rellena Reglas con found = exists(order). La pestaña Verificar ahora muestra No se encontraron problemas.
6. Simula. Después de Concluida, haz clic en Caja: emite una consulta, y Último dato recibido trae found: true.

Has usado emisión automática y manual, reglas, condición, filtro de campos, escritura y lectura. El resto del tutorial detalla cada función.

La interfaz

La pantalla tiene una barra superior y tres columnas: elementos a la izquierda, diagrama en el centro y propiedades a la derecha. Durante la simulación, aparece un panel de resultados bajo el diagrama.

Barra superior

Camino de niveles, deshacer y rehacer, menú Archivo ▾, ▶ Simular, idioma, ayuda y tema.

Elementos

La paleta. Arrastra al diagrama, o haz clic para colocar en el centro de la vista.

En este diagrama

Lista de elementos y flujos del nivel abierto. El clic selecciona el elemento.

Propiedades

Campos del elemento seleccionado. Sin selección, muestra Nombre, Notación, Semilla aleatoria y Tiempo máximo del modelo.

Verificar

Problemas del modelo. El clic en uno lleva al elemento.

Dibujar y organizar

Dos flujos entre los mismos elementos se curvan solos para no solaparse.

Propiedades de cada elemento

Proceso

Reglas

Calculan campos del dato. Consulta la sección siguiente.

Duración

Cuánto tarda el proceso. Acepta una expresión, como random(1, 3).

Capacidad

Cuántos datos atiende a la vez. El exceso espera en cola.

Límite de la cola

Cuántos datos pueden esperar. Lo que llega con la cola llena se rechaza. 0 es sin límite.

Prioridad

Expresión que elige el siguiente de la cola: el valor más bajo va primero. Vacío sigue el orden de llegada.

Entradas

Ejecuta en cada entrada atiende cada dato que llega. Espera todas las entradas aguarda un dato de cada flujo y combina los campos.

Intervalo automático

Para procesos sin flujos de datos de entrada: se dispara solo en este intervalo. Si lee almacenes, solo se dispara cuando hay un registro, y el registro leído pasa a ser el dato.

Pausar la simulación aquí

Punto de parada: pausa cuando llega un dato. Solo cuando lo limita a una condición, como total > 100. Almacenes y entidades también lo tienen.

Entidad externa

Datos generados

Los campos de cada emisión. seq es el número de emisión.

Emitir cada

Intervalo entre emisiones. Acepta una expresión: exponential(2) genera llegadas irregulares, con media de 2. Con 0, la entidad solo emite al hacer clic durante la simulación.

Límite de emisiones

Total de emisiones automáticas. 0 es sin límite, y entonces la simulación solo se detiene cuando la pausas.

Primera emisión en

Instante de la primera emisión automática.

Almacén de datos

Campo clave

Identifica el registro en actualizaciones y eliminaciones.

Registros iniciales (JSON)

Lista de objetos cargada al inicio, como [{"id": 1, "stock": 10}].

Flujo de datos

Los campos cambian según el origen y el destino del flujo.

Si más de una condición es verdadera, cada flujo recibe una copia del dato. Si ninguna es verdadera y no hay else, el dato se descarta y el registro indica el motivo.

Reglas y expresiones

Las reglas tienen una asignación por línea, con la forma campo = expresión, y se aplican en orden: una línea puede usar el resultado de la anterior. Las líneas que empiezan por # o // son comentarios.

# el precio viene del almacén leído
price = products.price
total = round(qty * price, 2)
ok = exists(products) && products.stock >= qty

Un campo inexistente vale null, y leer un campo de null también da null. La división por cero da null. Cuando la lectura no encuentra un registro, su nombre vale null; por eso se usa exists.

Niveles y subdiagramas

Un proceso complejo puede detallarse en otro diagrama, con numeración jerárquica: el proceso 2 se abre en 2.1, 2.2 y así sucesivamente.

1. Selecciona el proceso y haz clic en Detallar en un subdiagrama.
2. Los flujos del proceso padre aparecen como elementos discontinuos: a la izquierda las entradas y a la derecha las salidas.
3. Crea los procesos internos y conéctalos a esos elementos.

Los niveles quedan balanceados porque los elementos discontinuos vienen del padre. Un flujo creado en el padre aparece en el subdiagrama; un flujo eliminado en el padre desaparece, junto con sus conexiones. Para cambiar el nombre, edita el flujo en el padre.

• Con subdiagrama, el proceso padre pierde reglas y duración: la lógica pasa a ser la de los procesos internos.
• El marcador ⊞ del proceso abre el subdiagrama.
• Eliminar subdiagrama borra el nivel y los que estén por debajo. Ctrl+Z lo deshace.

En la simulación, el dato entra por el elemento discontinuo, pasa por los procesos internos y sale por el flujo correspondiente del padre. Al ver el nivel superior, un número azul en el proceso indica cuántos datos hay dentro de él.

Verificar el modelo

La pestaña Verificar revisa todo el modelo, en todos los niveles, y el número que muestra indica cuántos problemas hay. Solo las conexiones prohibidas y los errores de expresión y JSON impiden la simulación.

Simular

▶ Simular ejecuta una copia del modelo, en tiempo simulado. Cada dato sigue el ciclo de abajo:

Controles

El dibujo queda bloqueado durante la simulación. Aun así, puedes abrir subdiagramas y mover la vista arrastrando el fondo.

Qué aparece en el diagrama

Emitir y pausar

• Una entidad sin intervalo emite al hacer clic. En cualquier entidad funciona el botón Emitir ahora de las propiedades.
• Marca Pausar la simulación aquí en un elemento para detenerte cuando un dato lo alcance. El estado muestra dónde se detuvo.
• La simulación termina sola cuando no queda nada programado.

Semilla aleatoria

random y randint siguen la Semilla aleatoria del modelo. Con la misma semilla, el resultado se repite, lo que permite comparar escenarios cambiando una cosa cada vez. Cambia la semilla para ver otra secuencia.

Cada elemento tiene su propia secuencia de sorteos, definida por su posición en el diagrama. Así, cambiar la capacidad de un proceso no altera las llegadas ni las duraciones de los demás.

Leer los resultados

El panel bajo el diagrama tiene seis pestañas, y cada una responde a una pregunta.

Registro

Qué ocurrió y cuándo. Solo problemas filtra descartes y errores, y Descargar CSV exporta. El clic en una línea lleva al elemento.

Estadísticas

Cómo se comportó el sistema y dónde está el cuello de botella.

Colas

Cómo creció y disminuyó cada cola a lo largo del tiempo, en gráfico o tabla.

Escenarios

Cuánto varía el resultado entre rondas y qué cambió respecto a una referencia.

Almacenes

Qué quedó guardado, en tablas de hasta 200 registros cada una.

Datos en tránsito

Dónde está ahora cada dato.

Emitidos

Datos que entraron en el sistema.

Entregados y Almacenados

Llegadas a entidades y escrituras en almacenes. Un dato puede generar varias, porque cada flujo recibe una copia.

Descartados

Datos sin condición verdadera, o detenidos en un proceso sin salida o en un flujo sin conexión en el subdiagrama. Lo ideal es cero, salvo que sea intencionado.

Rechazados

Datos rechazados porque la cola estaba llena.

Tiempo medio del inicio a la entrega

De la emisión a la llegada a una entidad.

Mediana y 95% entregados en hasta

La mitad de las entregas tarda hasta la mediana, y el 95% hasta el segundo valor. Muestran lo que la media oculta.

Datos en el sistema (media)

Cuántos datos, de media, estaban circulando o esperando.

Entregas por unidad de tiempo

Total de entregas dividido por el instante de la última entrega.

Cola máx. y Espera media

Mayor cola formada y tiempo medio en cola.

Ocupación

Parte del tiempo en que la capacidad estuvo en uso.

Cuando hay cola, el resumen señala el proceso de mayor ocupación entre los que la formaron. Es el primer candidato a cuello de botella.

Experimentos con los ejemplos

Los tres ejemplos están en Archivo ▾ y en la pantalla inicial. Estos experimentos usan la semilla 1, la predeterminada.

Encontrar un cuello de botella

Abre Cuello de botella de atención y simula: llega un ticket cada 1 unidad de tiempo, pero atenderlo lleva unas 2. La pestaña Colas muestra la cola subiendo hasta 13. Sin embargo, una ronda es solo un sorteo. Para distinguir la regla del azar, repite.

1. Abre la pestaña Escenarios, deja Rondas en 30 y haz clic en Repetir con otras semillas.
2. Haz clic en Guardar como referencia.
3. Haz clic en ■ Editar, selecciona Atender, cambia Capacidad a 2 y haz clic en ▶ Simular.
4. En la pestaña Escenarios, haz clic de nuevo en Repetir con otras semillas. La tabla compara los dos escenarios.

Duplicar la capacidad del cuello de botella redujo la espera media de 12,23 a 0,37, y la columna Lectura indica diferencia clara, porque los márgenes no se solapan. Cuando se solapan, la lectura es dentro de la variación: el resultado no muestra que un escenario sea mejor. Cambiar la capacidad de Triaje no tendría ese efecto, porque no forma cola.

Provocar una actualización perdida

Abre Préstamo de biblioteca. Con Emitir cada en 4, hay 5 préstamos y el fondo baja de 5 ejemplares a 0. Ahora cambia el valor en Lector a 2 y simula: hay 6 préstamos de un fondo de solo 5 ejemplares.

La causa está en los tiempos: una solicitud lee el fondo antes de que la anterior escriba la baja. Es una actualización perdida, un problema clásico de concurrencia. ^[6] El simulador no lo corrige; lo hace visible.

Seguir un pedido por dos niveles

Abre Procesamiento de pedidos y simula: de los 8 pedidos, 7 se aprueban. Al pausar y abrir Facturar pedido se ven los datos en los procesos 2.1 y 2.2. Después, en Gerencia, usa Emitir ahora para consultar una venta almacenada.

Guardar, abrir y exportar

Prompts de IA

Una IA ayuda a descubrir quién envía y recibe cada dato, a montar el primer diagrama, a escribir reglas y a leer colas y cuellos de botella. También se equivoca con seguridad: inventa flujos, adivina tiempos y explica números que no ha leído. Trata el resultado como el borrador de un colega con prisa. Para escribir mejores prompts, mira el tutorial de prompts.

Antes de pegar: los diagramas y registros pueden contener nombres, valores y reglas confidenciales. Cámbialos por datos ficticios y sigue la política de tu organización sobre el uso de IA. La aplicación no envía nada a la red, pero el servicio de IA recibe lo que pegues en él.

Cambia las partes entre corchetes y pega en la herramienta de IA que uses. Los prompts siguen el orden del trabajo, pero cada uno funciona por sí solo.

1. Entrevistar antes de dibujar

Hace que la IA descubra lo que falta, en vez de suponerlo. Es el mejor comienzo cuando el sistema aún está en la cabeza de las personas.

Eres un analista de sistemas con experiencia en diagramas de flujo de datos.
Quiero modelar este sistema: [descríbelo en pocas frases].

Antes de proponer ningún diagrama, entrevístame:
- Haz una pregunta cada vez y espera mi respuesta.
- Cubre: quién envía y recibe datos desde fuera del sistema, qué contiene cada dato, qué hace cada proceso con él, qué debe guardarse, quién lee lo guardado, las condiciones que cambian el camino, los errores y rechazos, el volumen de llegada y cuánto tiempo lleva cada proceso.
- Pregunta sobre todo por lo que sale mal, no solo por el camino feliz.
- No inventes respuestas. Si no lo sé, regístralo como pendiente.

Al final, entrega tablas de: entidades externas; procesos (nombre con verbo, entradas, salidas, regla, duración, capacidad); almacenes (campos y clave); flujos (origen, destino, nombre, campos, condición); y la lista de pendientes.

2. Convertir un texto en elementos

Para requisitos, actas y procedimientos. Pide el origen de cada elemento, lo que facilita comprobarlo.

A partir del texto siguiente, extrae los elementos de un diagrama de flujo de datos.

Texto:
[pega los requisitos, el acta o el procedimiento]

Entrega:
1. Entidades externas, procesos y almacenes, cada uno con el pasaje que lo sustenta.
2. Flujos: origen, destino, nombre y campos. Todo flujo debe tener un proceso en uno de sus extremos.
3. Reglas y condiciones citadas, y a qué proceso o flujo se aplica cada una.
4. Lagunas: datos que aparecen sin origen, datos guardados que nadie lee, procesos sin entrada o sin salida, y contradicciones.
5. Preguntas para aclarar cada laguna.

No rellenes lagunas por tu cuenta. Lo que no esté en el texto va a las preguntas.

3. Generar el modelo en JSON

Convierte lo que reuniste en un archivo que la aplicación abre, en vez de dibujar elemento por elemento. Genera solo el nivel principal; después, detalla en la aplicación los procesos que lo necesiten.

Genera un modelo en JSON para DFD Simulator, a partir de la información del final.

Responde solo con el JSON, sin comentarios y sin marcas de código.

Formato:
- Raíz: "name", "notation" ("yd" o "gs"), "seed" y "diagrams". Genera solo "diagrams.root", con "id": "root", "parent": null, "nodes" y "flows". No generes subdiagramas.
- Elemento: "id", "type" (entity, process o store), "name", "x", "y" y, si tiene sentido, "desc".
- entity: "gen" (campos, uno por línea, separados por \n; seq es el número de la emisión), "interval" (número o expresión, como texto; 0 solo emite con un clic), "limit" y "start".
- process: "k" (número único), "rules" (campo = expresión, una por línea), "duration" (expresión, como texto), "capacity" y "queueLimit" (0 es sin límite).
- store: "k" (número único), "key" (campo clave) e "initial" (texto con una lista JSON de objetos).
- Flujo: "id", "from", "to", "name" y, según el caso:
  - saliendo de un proceso: "guard" (condición; "else" vale cuando ninguna otra es verdadera) y "fields" (campos que pasan, separados por comas);
  - hacia un almacén: "op" (insert, upsert o delete);
  - desde un almacén: "filter" (como id == in.id), "alias" (nombre en las reglas), "readAll" y "consume";
  - en cualquier flujo: "transit" (tiempo de tránsito).

Reglas:
- Todo elemento y todo flujo necesita un "id". Todo flujo debe tener un proceso en uno de sus extremos.
- Posiciones: x de 120 a 1300 e y de 70 a 600, con al menos 240 de distancia en horizontal y 150 en vertical. Entidades en los lados, procesos en el centro y almacenes encima o debajo de ellos.
- Las expresiones aceptan + - * / %, comparaciones, and, or, not, condición ? a : b, round, floor, ceil, min, max, abs, exists, coalesce, if, count, sum, avg, random(a, b), randint(a, b), exponential(media), normal(media, desv), chance(p) y pick(a, b). Usa punto para los decimales. No uses otras funciones.
- Una condición no ve el registro leído: graba el resultado en un campo en las reglas y usa ese campo.
- Usa los mismos nombres de campo en todos los elementos, porque la aplicación no avisa cuando un nombre está mal.
- Da un "limit" mayor que 0 a las entidades con "interval", para que la simulación termine.
- En "desc", indica si los tiempos los di yo o son una hipótesis tuya. No inventes fuentes.

Ejemplo del formato:
{
  "name": "Pizzería",
  "notation": "yd",
  "seed": 1,
  "diagrams": {"root": {"id": "root", "parent": null,
    "nodes": [
      {"id": "c", "type": "entity", "name": "Cliente", "x": 120, "y": 240, "gen": "id = seq\nqty = randint(1, 3)", "interval": "3", "limit": 6},
      {"id": "p", "type": "process", "name": "Registrar pedido", "x": 400, "y": 240, "k": 1, "rules": "total = qty * 40", "duration": "2", "capacity": 1},
      {"id": "d", "type": "store", "name": "Pedidos", "x": 400, "y": 70, "k": 1, "key": "id"},
      {"id": "k", "type": "entity", "name": "Cocina", "x": 680, "y": 240}
    ],
    "flows": [
      {"id": "f1", "from": "c", "to": "p", "name": "pedido"},
      {"id": "f2", "from": "p", "to": "d", "name": "pedido registrado"},
      {"id": "f3", "from": "p", "to": "k", "name": "comanda", "fields": "id, qty"}
    ]
  }}
}

Información:
[pega el resultado del prompt 1 o 2, o describe el sistema]

4. Estimar tiempos y capacidades

Las colas dependen de los tiempos. Este prompt deja claro qué es hipótesis y devuelve expresiones que la aplicación acepta.

Necesito tiempos iniciales para simular este sistema. No tengo mediciones.

Sistema:
[pega las tablas o el JSON del modelo]
Unidad de tiempo: [elige una sola para todo el modelo]

Para cada entidad y proceso, entrega una tabla con: mínimo, más probable, máximo, en qué te basaste, cómo mediría el valor real y tu confianza (baja, media o alta).

Reglas:
- Todo es hipótesis hasta que yo lo confirme. Dilo claramente.
- No cites estudios ni cifras de mercado que no puedas indicar con precisión. Sin base, di "sin base" y da solo el rango.
- Devuelve el texto exacto para los campos de la aplicación, usando solo random(a, b), exponential(media) o normal(media, desv): Emitir cada (entidad), Duración, Capacidad y Límite de la cola (proceso), Tiempo de tránsito (flujo).
- Para cada proceso, compara el tiempo que lleva con el intervalo de llegada, considerando la capacidad, y señala dónde debería formarse una cola.
- Señala las 3 estimaciones que más pueden cambiar el resultado y que debería medir primero.

5. Revisar el diagrama

Busca lo que la pestaña Verificar no ve: datos que salen de un proceso sin haber entrado nunca, y flujos que faltan.

Revisa este diagrama de flujo de datos como un analista de sistemas experimentado.

Modelo:
[pega el JSON o las tablas]

Busca:
- Procesos que producen datos que no reciben: campos que salen sin entrar ni calcularse.
- Datos recibidos que ningún proceso usa.
- Almacenes escritos que nadie lee, o leídos sin que nada los escriba, y lecturas cuyo filtro no encuentra el registro.
- Flujos que faltan: errores, rechazos, respuestas a la entidad de origen.
- Condiciones que dejan el dato sin salida, y flujos sin else donde debería haberlo.
- Flujos con nombres vagos, procesos sin verbo y campos con nombres distintos para el mismo dato.
- Lecturas y escrituras del mismo registro por procesos simultáneos, que pueden causar una actualización perdida.

Entrega una tabla con: elemento, problema, por qué importa, sugerencia y gravedad (alta, media o baja). No reescribas el modelo. No confirmes que está bien solo porque no hallaste problemas: di qué no se puede evaluar sin más datos.

6. Escribir reglas y condiciones

Devuelve el texto de los campos, respetando lo que cada uno ve. Una condición, por ejemplo, no ve el registro leído.

Escribe reglas y condiciones para DFD Simulator.

Modelo:
[pega el JSON o describe los elementos y campos]
Lo que necesito que ocurra:
[descríbelo en lenguaje común]

Para cada campo, entrega el texto exacto y dónde pegarlo: Datos generados (entidad), Reglas y Duración (proceso), Condición y Campos que pasan (flujo que sale del proceso), Filtro de lectura y Nombre en las reglas (flujo desde un almacén).

Reglas:
- Las reglas y los datos generados tienen una asignación por línea, campo = expresión, y cada línea puede usar la anterior.
- Los datos generados ven seq, t y las líneas anteriores. Las reglas y la duración ven los campos del dato, los registros leídos por Nombre en las reglas y t. Una condición ve los campos del dato que sale y t. Un filtro ve los campos del registro, in.campo y t.
- Una condición no ve el registro leído: graba el resultado en un campo, como ok = exists(producto).
- Si más de una condición es verdadera, cada flujo recibe una copia. Si ninguna lo es y no hay else, el dato se descarta: di cómo tratar ese caso.
- Usa solo funciones que existen: round, floor, ceil, abs, min, max, exists, coalesce, if, count, sum, avg, minof, maxof, len, upper, lower, concat, contains, random, randint, exponential, normal, chance y pick.
- Un campo inexistente vale null, sin error: revisa los nombres y señala los que supusiste.
- Da un ejemplo de dato de entrada y el resultado esperado, para que lo compruebe en la simulación.

7. Leer los resultados de la simulación

Después de repetir las rondas, copia las tablas y pégalas en el prompt, con el modelo.

Ayúdame a interpretar esta simulación. Los números vienen de un modelo, no de mediciones.

Modelo:
[pega el JSON o describe los elementos]
Resultados:
[pega las tablas de las pestañas Estadísticas y Escenarios, indicando cuántas rondas hubo]

Entrega:
1. Qué dicen los resultados, en hasta 5 frases, comparando media, mediana y 95%.
2. El probable cuello de botella, con cola máxima, espera media y ocupación, y por qué los otros procesos no lo son.
3. Qué indican los descartados y rechazados.
4. Qué es patrón y qué puede ser azar: usa el margen y el rango entre menor y mayor. Con una sola ronda, di que aún no se puede concluir.
5. Qué no puedo concluir: hipótesis frágiles y limitaciones del modelo.

Reglas:
- Usa solo números que estén en las tablas, sin crear otros. Si falta un dato, dilo.
- Separa lo calculado de tu interpretación. No afirmes causas en el mundo real: preséntalas como hipótesis por confirmar.

8. Planificar los próximos escenarios

Convierte el diagnóstico en una lista corta de pruebas, para comparar con la referencia un cambio cada vez.

Con base en esta simulación, planifica los próximos escenarios.

Modelo:
[pega el JSON o describe los elementos]
Resultados:
[pega las tablas de las pestañas Estadísticas y Escenarios]
Objetivo: [por ejemplo, entregar el 95% en hasta 10 unidades de tiempo]
Restricciones: [lo que no puede cambiar]

Propón hasta 5 alternativas y, para cada una, entrega:
- Qué cambia en el modelo: el elemento, el campo (Capacidad, Duración, Límite de la cola, Emitir cada, Condición o un flujo nuevo) y el valor exacto.
- El efecto esperado, como hipótesis, y la medida que lo confirmaría.
- Qué haría falta para hacer el cambio en el mundo real, y el riesgo.

Reglas:
- Cada alternativa cambia una sola cosa, para que el efecto sea atribuible.
- Empieza por el cuello de botella. Avisa cuando aliviar un proceso pueda solo mover la cola al siguiente.
- No prometas ganancias en números: el resultado sale de la simulación.

Termina con los pasos en la aplicación: repetir 30 rondas, guardar como referencia, volver a editar, hacer el cambio, simular, repetir y leer la columna Lectura. Incluye una tabla vacía para rellenar: alternativa, medida, referencia, actual y lectura.

Cómo abrir el JSON del prompt 3

1. Copia la respuesta de la IA en un editor de texto y guárdala con la extensión .json, por ejemplo sistema.json.
2. En la aplicación, usa Archivo ▾ → Abrir modelo (.json)…, o arrastra el archivo a la ventana. Si ya hay un modelo, confirma la sustitución; guarda antes lo que quieras conservar.
3. Haz clic en Ajustar y arrastra lo que quede mal colocado: la aplicación no organiza el diagrama sola.
4. Abre la pestaña Verificar y revisa cada elemento.

Cómo llevar los resultados a la IA

La aplicación no genera un informe de la simulación. Para los prompts 7 y 8, selecciona con el ratón la tabla de la pestaña Estadísticas o Escenarios, cópiala y pégala en el prompt. En Registro, Descargar CSV exporta los eventos.

Atajos de teclado

Limitaciones y solución de problemas

Limitaciones

• Tiempo sin unidad: una unidad de tiempo puede ser un segundo o un día, siempre que todo el modelo use la misma.
• Margen de error: el margen del 95% es una aproximación que supone rondas independientes. Usa al menos 30 rondas antes de sacar conclusiones.
• Almacenes sin transacciones: cada escritura es inmediata, y dos lecturas simultáneas ven el mismo valor.
• Copiar y pegar: los subdiagramas no se copian.
• Navegadores: la aplicación se ha probado en Chromium. El uso en otros navegadores y en móviles no se ha probado.

Problemas comunes

Repaso rápido

Intenta responder antes de abrir cada pregunta.

Referencias

1. Giovani Perotto Mesquita, “DFD Simulator”, aplicación en un único archivo HTML, giovanipm.github.io/dfd-simulator.html.
2. Giovani Perotto Mesquita, “Análisis y diseño de sistemas”, tutorial de este sitio, giovanipm.github.io/AnaliseProjetoSistemas.html.
3. Wikipedia (en inglés), “Data-flow diagram”, consultado el 30/10/2026, en.wikipedia.org/wiki/Data-flow_diagram.
4. Tom DeMarco, Structured Analysis and System Specification, libro, Prentice-Hall, 1979, ISBN 978-0-13-854380-8.
5. Chris Gane, Trish Sarson, Structured Systems Analysis: Tools and Techniques, libro, Prentice-Hall, 1979, ISBN 978-0-13-854547-5.
6. Wikipedia (en inglés), “Concurrency control”, consultado el 30/10/2026, en.wikipedia.org/wiki/Concurrency_control.