Introdução
Antes de discutir banco de dados ou framework, é útil perguntar: quem precisa fazer o quê com o sistema? O diagrama de casos de uso organiza essa conversa em torno dos objetivos dos usuários e das fronteiras da solução.
Ele não é um desenho de telas. Um caso de uso representa uma interação com resultado relevante, como solicitar cadastro, aprovar documento ou consultar relatório.
Elementos principais
Atores
Atores são papéis externos que interagem com o sistema. Podem ser pessoas, outros sistemas ou dispositivos. “Pessoa atendente” é um papel; o nome de alguém específico geralmente não é necessário.
Casos de uso
São objetivos expressos com verbos e resultado, como “Registrar membro” ou “Emitir relatório”. Evite transformar cada clique em um caso de uso separado.
Fronteira
O retângulo do sistema ajuda a mostrar o que está dentro da responsabilidade da solução e o que permanece fora dela.
Relacionamentos
Linhas indicam participação. Relações como include e extend podem representar reutilização ou comportamento opcional, mas só devem ser usadas quando acrescentarem clareza.
Como construir um diagrama útil
- Defina o objetivo do modelo e o escopo do sistema.
- Liste papéis externos que interagem com a solução.
- Para cada papel, pergunte qual resultado ele busca.
- Nomeie casos de uso com linguagem do domínio.
- Revise o desenho com as pessoas que conhecem o processo.
Depois, cada caso de uso pode receber uma descrição textual com fluxo principal, alternativas, pré-condições e resultado esperado. O desenho é a porta de entrada; os detalhes ficam em outros artefatos.
Exemplo: cadastro de membro
Considere os atores “Atendente” e “Pessoa solicitante”. A pessoa solicitante pode “Enviar pré-cadastro”. O atendente pode “Revisar pré-cadastro”, “Confirmar cadastro” e “Consultar membro”. Um serviço de notificações pode ser outro ator se estiver fora do sistema e participar do envio de mensagens.
O diagrama não precisa afirmar como a tela será construída. Ele registra os objetivos e ajuda a perguntar o que acontece quando dados estão incompletos ou a solicitação é recusada.
O exemplo em um diagrama
O diagrama mostra objetivos, não telas. “Enviar pré-cadastro” representa uma interação que pode envolver várias telas ou etapas internas. Para aprofundar a linguagem visual, consulte O que é UML?.
Descrição detalhada de um caso de uso
Um diagrama deve ser acompanhado de texto quando o fluxo tiver regras relevantes. Para “Enviar pré-cadastro”, uma descrição pode conter:
- Ator principal: pessoa solicitante;
- Pré-condição: formulário de pré-cadastro disponível;
- Fluxo principal: informar dados pessoais e de contato, revisar as informações e enviar o pedido;
- Alternativas: dado obrigatório ausente ou inválido, ou pré-cadastro já existente para a mesma pessoa;
- Pós-condição: pré-cadastro registrado como pendente e disponível para revisão do atendente;
- Critérios de aceitação: não criar duplicidade, explicar o que precisa ser corrigido e preservar o registro da solicitação.
Esse formato aproxima o modelo dos requisitos e oferece material para análise, desenvolvimento e testes. Os critérios de aceitação seguem a lógica explicada no artigo sobre histórias de usuário e critérios de aceitação.
O que o diagrama não resolve sozinho
Casos de uso não detalham arquitetura, algoritmo, modelo completo de dados, aparência final ou todos os requisitos não funcionais. Eles precisam ser combinados com entrevistas, regras, protótipos, modelos e critérios de teste.
Dois diagramas costumam complementar bem os casos de uso: o diagrama de classes, que mostra quais conceitos e dados existem, e o diagrama de sequência, que detalha passo a passo como um caso de uso acontece entre os participantes.
Quando o desenho fica cheio de linhas e exceções, pode ser melhor dividir o sistema em contextos ou complementar a explicação com um fluxo de atividade.
Conclusão
O diagrama de casos de uso é uma forma acessível de alinhar objetivos e fronteiras. Como parte da UML, ele funciona melhor quando serve a uma conversa real e é revisado por quem conhece o processo. Para aprofundar, veja a introdução à UML e o material oficial da OMG.