Diagrama de Atividades: o que é, como funciona e como criar

Introdução

Muitos requisitos descrevem processos: “a pessoa preenche o formulário, o sistema confere os dados e, se estiver tudo certo, salva o cadastro”. Em texto, frases assim parecem claras. Mas basta perguntar “e se os dados estiverem errados?” para perceber que o fluxo tem caminhos que ninguém escreveu.

O diagrama de atividades ajuda a enxergar esses caminhos. Neste artigo, você vai conhecer seus elementos, ver como representar decisões e tarefas paralelas, acompanhar um exemplo completo de cadastro e entender como ele se conecta a requisitos, casos de uso, sequência, classes e código.

O que é um Diagrama de Atividades?

Um diagrama de atividades é uma representação visual de um fluxo de trabalho. Ele mostra a ordem das ações, os pontos de decisão, os caminhos alternativos e, quando necessário, as tarefas que acontecem ao mesmo tempo. Lembra um fluxograma, mas segue a notação padronizada da UML.

Ele serve para:

• entender um processo antes de automatizá-lo;
• descobrir caminhos de erro e exceções esquecidos;
• mostrar quem é responsável por cada etapa;
• conversar com pessoas não técnicas usando um desenho simples.

Relação entre UML e Diagrama de Atividades

A UML reúne diagramas estruturais, que mostram como o sistema é organizado, e comportamentais, que mostram o que acontece quando ele funciona. O diagrama de atividades é comportamental: sua pergunta central é “como este processo flui?”.

Ele pode descrever tanto um processo de negócio, como o atendimento de uma secretaria, quanto a lógica interna de uma funcionalidade. Por usar símbolos padronizados, o mesmo desenho pode ser lido por analistas, desenvolvedores e pessoas da área de negócio.

Principais elementos

Poucos símbolos bastam para ler a maioria dos diagramas de atividades:

Na UML, ação é um passo simples e indivisível, como “Salvar cadastro”. Atividade é o comportamento completo, que pode reunir muitas ações. Na prática, e em diagramas para iniciantes, é comum chamar cada retângulo de “atividade” sem prejuízo para o entendimento.

Repare que decisão e merge usam o mesmo losango. A diferença está nas setas: na decisão, entra um caminho e saem vários; no merge, entram vários e sai um.

Fluxos sequenciais, condicionais e paralelos

Fluxo sequencial

É o caso mais simples: uma ação depois da outra, ligadas por setas. “Salvar cadastro” e depois “Confirmar cadastro” formam um fluxo sequencial.

Fluxo condicional

Acontece quando o processo depende de uma resposta. Do losango de decisão saem dois ou mais caminhos, cada um com uma guarda, como [sim] e [não]. As guardas precisam cobrir todas as possibilidades e não podem ser verdadeiras ao mesmo tempo; caso contrário, o leitor não sabe qual caminho seguir. Quando os caminhos alternativos voltam a um ponto comum, um merge os reúne.

Fluxo paralelo

Algumas tarefas podem acontecer ao mesmo tempo porque não dependem uma da outra. O fork abre esses caminhos paralelos, e o join espera que todos terminem antes de o fluxo continuar. O exemplo a seguir é hipotético e serve apenas para mostrar a notação:

Como interpretar um Diagrama de Atividades

Para ler qualquer diagrama de atividades, siga este roteiro:

1. Encontre o nó inicial, o círculo preenchido.
2. Siga as setas, uma ação de cada vez.
3. Em cada losango, leia as guardas e escolha um caminho para acompanhar.
4. Volte depois e percorra os outros caminhos, principalmente os de erro.
5. Observe as raias para saber quem executa cada ação.
6. Confirme que todo caminho chega a um nó final ou volta para um ponto anterior.

Se algum caminho “para no meio” sem chegar a lugar nenhum, você encontrou uma lacuna no processo, e isso é exatamente o tipo de problema que o diagrama deve revelar.

Exemplo completo: cadastro de membro

O exemplo abaixo usa o contexto de um cadastro de membros. É um cenário didático, com duas raias: Usuário, que preenche e corrige os dados, e Sistema, que valida, salva e confirma.

Passo a passo do fluxo

1. Início e Preencher dados: o usuário começa o processo informando nome, contato e demais dados pedidos.
2. Merge e Validar dados: os dados chegam ao sistema por um merge, ponto que recebe tanto o primeiro envio quanto as correções. Em seguida, o sistema confere se as informações obrigatórias estão presentes e no formato esperado.
3. Dados válidos?: é a decisão. Cada caminho tem sua guarda.
4. [não] Informar erro e Corrigir dados: o sistema explica o problema e o usuário corrige. O fluxo volta ao merge e passa por uma nova validação.
5. [sim] Salvar cadastro e Confirmar cadastro: com os dados válidos, o sistema grava o cadastro e informa que ele foi concluído.
6. Fim: o processo termina no nó final.

Repare que o caminho de erro não termina direto no fim: ele volta para a validação. Isso evita que dados incorretos sejam aceitos só porque o usuário tentou corrigir. O tema lembra um sistema de gestão de membros, como o SIGM, mas é usado aqui apenas como contexto educacional; o diagrama não descreve o funcionamento interno de nenhum sistema real.

Como criar a partir de um requisito ou caso de uso

Um bom ponto de partida é um requisito ou um caso de uso já descrito. Na Engenharia de Requisitos, um requisito como “o sistema deve permitir cadastrar membros e informar quando algum dado estiver incorreto” já contém o caminho principal e uma exceção. Um roteiro prático:

1. Defina o começo e o fim: o que dispara o processo e qual resultado o encerra.
2. Liste as ações do caminho principal, em ordem, com verbos: preencher, validar, salvar, confirmar.
3. Procure as perguntas: onde o processo precisa decidir algo? Cada pergunta vira um losango com guardas.
4. Desenhe os caminhos alternativos e decida se eles terminam o fluxo ou voltam a um ponto anterior.
5. Identifique tarefas independentes que podem ser representadas com fork e join.
6. Separe responsáveis em raias, se isso ajudar a leitura.
7. Revise com quem conhece o processo, percorrendo cada caminho em voz alta.

Requisitos não funcionais também podem aparecer como perguntas no fluxo, por exemplo “o usuário tem permissão?”. Veja mais sobre essa diferença em requisitos funcionais e não funcionais.

Relação com outros diagramas

Os diagramas da UML não competem entre si; cada um responde a uma pergunta diferente sobre o mesmo sistema:

Um caminho comum é começar pelo diagrama de casos de uso, que define o objetivo “Cadastrar membro”. O diagrama de atividades detalha o fluxo desse objetivo, com decisões e caminhos alternativos. Depois, o diagrama de sequência pode mostrar quais participantes trocam mensagens em um desses caminhos.

Já o diagrama de classes responde a outra pergunta: qual é a estrutura estática do sistema? As ações do fluxo costumam usar os conceitos que ele descreve. “Salvar cadastro”, por exemplo, manipula dados de uma classe como Membro. Se uma ação precisa de uma informação que nenhuma classe possui, vale revisar os dois modelos.

Exemplo em Python

O código abaixo é uma representação didática da lógica do fluxo. Ele não é o código do SIGM nem de nenhum sistema real, e guarda os cadastros em uma lista na memória.

def preencher_dados():
    nome = input("Nome: ")
    email = input("E-mail: ")
    return {"nome": nome, "email": email}


def validar(dados):
    erros = []
    if not dados["nome"].strip():
        erros.append("o nome é obrigatório")
    if "@" not in dados["email"]:
        erros.append("o e-mail parece inválido")
    return erros


cadastros = []

dados = preencher_dados()                # Preencher dados
erros = validar(dados)                   # Validar dados

while erros:                             # Dados válidos? [não]
    print("Corrija:", "; ".join(erros))  # Informar erro
    dados = preencher_dados()            # Corrigir dados
    erros = validar(dados)               # volta ao merge e valida de novo

cadastros.append(dados)                  # [sim] Salvar cadastro
print("Cadastro confirmado para", dados["nome"])  # Confirmar cadastro

Cada comentário aponta a ação correspondente no diagrama. A função validar() representa a ação “Validar dados” e devolve uma lista de erros. O while erros: é a decisão “Dados válidos?”: enquanto houver erros, o programa segue a guarda [não], informa o problema e pede novos dados. A volta para o início do laço corresponde ao merge, que leva de novo à validação. Quando a lista fica vazia, o laço termina e o programa segue a guarda [sim], salvando e confirmando o cadastro.

Essa correspondência mostra por que o diagrama ajuda antes do código: decisões e voltas no desenho viram if, while e chamadas de função no programa.

Erros comuns ao criar Diagramas de Atividades

• Esquecer o caminho de erro e desenhar apenas o cenário ideal.
• Criar decisões sem guardas ou com guardas que se sobrepõem.
• Deixar caminhos sem fim, que não chegam a um nó final nem voltam ao fluxo.
• Usar fork quando as ações dependem uma da outra e, portanto, não são paralelas.
• Abrir um fork e esquecer o join correspondente.
• Colocar detalhes de tela, como “clicar no botão azul”, no lugar de ações do processo.
• Tentar representar o sistema inteiro em um único diagrama.

Quando usar e quando não é necessário

Use um diagrama de atividades quando o processo tem decisões, exceções, voltas ou tarefas paralelas; quando várias pessoas ou setores participam; ou quando é preciso validar um fluxo com a área de negócio antes de implementá-lo. Ele também ajuda a documentar processos que mudam com frequência.

Ele não é necessário para fluxos lineares e curtos, que uma lista numerada já explica, nem para mostrar a estrutura de dados, papel do diagrama de classes. Se o desenho ficar maior do que o problema, divida-o em partes ou volte para um texto simples.

Resumo

O diagrama de atividades é um diagrama comportamental da UML que mostra como um processo flui. Seus principais elementos são nó inicial, ações, decisões com guardas, merge, fork, join, nó final e raias. Com eles, é possível representar fluxos sequenciais, condicionais e paralelos.

Para criar o seu, parta de um requisito ou caso de uso, liste as ações do caminho principal, transforme cada pergunta em uma decisão e desenhe todos os caminhos alternativos até o fim. Usado junto com casos de uso, sequência e classes, ele ajuda a garantir que o processo foi entendido antes de virar código.