Escolha a pergunta do desenho
Um diagrama precisa responder a uma pergunta. A arquitetura mostra partes e relações; a sequência mostra quem faz o quê ao longo do tempo; um fluxo destaca etapas e decisões; uma máquina de estados descreve situações permitidas e transições.
Não coloque todos esses objetivos em um único desenho. Para explicar um atendimento, comece pelo fluxo do pedido. Para investigar uma demora, uma sequência entre cliente, aplicação e armazenamento pode ser mais adequada. A escolha determina o que entra e o que fica fora.
Por que aprender
Um desenho bonito com finalidade confusa não ajuda a decidir. Uma pergunta clara permite avaliar se o diagrama explicou o problema ou apenas reorganizou palavras.
✓ Fazer
Mostrar o caminho de erro.
✗ Evitar
Desenhar componentes só porque são comuns.
Conceitos-chave
Liste apenas elementos confirmados
Antes de desenhar, liste participantes, entradas, saídas e lugares onde os dados ficam. Relacione cada elemento a uma evidência do projeto ou a uma hipótese identificada. Se você ainda não sabe onde um arquivo é salvo, não desenhe um banco de dados por hábito.
Use nomes que o público reconhece. “Recepção”, “lista de pedidos” e “conferência” podem explicar melhor um processo de negócio que nomes internos de funções. Quando um nome técnico for necessário, apresente também sua função em linguagem comum.
Por que aprender
A lista evita que o assistente complete a arquitetura com componentes plausíveis, mas inexistentes. Ela também estabelece um vocabulário que pode ser revisado antes de mexer no desenho.
Um caminho para aplicar
- Defina a pergunta e liste os elementos confirmados.
- Desenhe relações com verbos e decisões.
- Percorra dois casos e ajuste a legibilidade.
Conceitos-chave
Dê significado às conexões
Uma linha entre caixas pode significar envio, leitura, dependência ou ordem. Rotule a conexão quando isso não estiver evidente. Use a mesma convenção ao longo do desenho e inclua uma legenda curta quando houver mais de um tipo.
No exemplo, “validar” não é o mesmo que “salvar”. A conferência pode rejeitar um pedido antes de ele entrar na lista. Mostrar essa decisão evita que o leitor entenda que toda entrada é aceita. O caminho de erro merece tanta clareza quanto o caminho feliz.
Por que aprender
As conexões carregam boa parte do significado. Sem rótulos e decisões, o leitor pode interpretar causalidade onde existe apenas uma relação de consulta.
flowchart TD
A[Receber pedido] --> B{Tarefa e contato presentes?}
B -- Sim --> C[Registrar na lista]
B -- Não --> D[Pedir complemento]
D --> A
C --> E[Conferir entrega]
E --> F[Concluir]
Conceitos-chave
Mantenha uma fonte editável
Salve o diagrama em um formato que permita mudanças, além da imagem de apresentação. Uma descrição Mermaid, um SVG ou o arquivo nativo da ferramenta serve como base de manutenção. Um PNG sozinho é útil para mostrar, mas trabalhoso para corrigir.
Registre a versão do processo representado. Se uma etapa muda, confira quais conexões deixam de fazer sentido. Não atualize apenas o nome da caixa: a alteração pode exigir um novo caminho, uma validação ou um estado intermediário.
Por que aprender
A fonte editável reduz o custo de manter a documentação alinhada ao sistema. Ela também torna possível revisar o diagrama como parte de uma mudança de código.
✓ Fazer
Guardar o arquivo editável junto da imagem.
✗ Evitar
Usar uma seta sem saber o que ela significa.
Conceitos-chave
Teste a compreensão de outra pessoa
Peça a alguém para percorrer um caso normal e outro com erro usando apenas o desenho. Observe em quais pontos a pessoa precisa adivinhar. Uma seta pequena, um nome abstrato ou uma etapa ausente costuma aparecer nessa leitura.
Faça também uma conferência visual: textos legíveis, contraste suficiente e conexões sem cruzamentos desnecessários. Em telas pequenas, prefira um diagrama mais simples a uma imagem enorme reduzida até os rótulos ficarem ilegíveis.
Por que aprender
O teste mede a função comunicativa do mapa. Você verifica se o leitor entende a ordem e as condições, em vez de avaliar somente a estética.
| Critério | Evidência esperada |
|---|---|
| Fidelidade | O desenho corresponde ao enunciado. |
| Exceção | Pedido incompleto tem caminho explícito. |
| Manutenção | Existe uma representação editável. |
Conceitos-chave
Prática: desenhe o pedido incompleto
Represente um pedido que chega à oficina. Se tiver tarefa e contato, entra na lista. Se faltar um desses dados, volta para complementação. Depois da conferência final, pode ser marcado como concluído.
Escreva a descrição do fluxo, gere o desenho na ferramenta de sua escolha e compare os caminhos com o enunciado. Não acrescente pagamento, inteligência artificial ou banco de dados se esses elementos não forem necessários para responder à pergunta do exercício.
Por que aprender
A prática ensina a conter o escopo do desenho e a representar exceções. O resultado será reaproveitado na documentação dos projetos finais.
Seu exercício
Crie um fluxo para o pedido descrito no tópico. Identifique a decisão, o retorno e a saída. Explique como o desenho se comporta quando o contato está ausente.
Baixar ficha da práticaConferir resposta comentada
Decisão: tarefa e contato estão presentes? Se não, pedir complemento e voltar ao recebimento. Se sim, registrar, conferir a entrega e concluir. O contato ausente impede o avanço para registro, sem apagar o pedido recebido. A imagem e sua fonte devem mostrar o mesmo caminho.
Cheque sua compreensão
Você não sabe onde o sistema guarda dados. Como representar isso?
Conceitos-chave
O que fica deste módulo
Um mapa de fluxo editável acompanhado de uma explicação simples.
- ✓ O desenho corresponde ao enunciado.
- ✓ Pedido incompleto tem caminho explícito.
- ✓ Existe uma representação editável.
O progresso registra sua leitura. A prática fica concluída quando você confere a entrega.