Explicação

Um caso de uso descreve as interações entre um ou mais Ator e o sistema para gerar um resultado de valor observável para o ator iniciador.

A funcionalidade de um sistema é definida por vários casos de uso, cada qual representa uma meta específica (para obter o resultado de valor observável) para um ator em particular.

Em um caixa automático mostrado na figura 1, o Cliente Bancário pode retirar dinheiro de uma conta, transferir fundos entre contas ou depositar fundos em uma conta. Estas ações correspondem aos objetivos específicos que o ator tem ao usar o sistema.

Figura 1: Exemplo de caso de uso de caixa automático (ATM).

Cada caso de uso está associado a uma meta de um dos atores. A coleção de casos de uso constitui todas as formas possíveis de usar o sistema. Você deve poder determinar o objetivo de um caso de uso simplesmente observando seu nome.

Um caso de uso descreve as interações entre os atores e o sistema na forma de um diálogo entre eles, estruturado da seguinte forma:

1. O ator <<faz algo>>
2. O sistema <<faz algo em resposta>>
3. O ator <<faz algo a mais>>
4. O sistema...
   

Cada diálogo com esta forma é chamado de "Fluxo de Eventos".

Pelo motivo de existirem muitos fluxos de eventos possíveis para se alcançar a meta (por exemplo, o fluxo pode ser diferente dependendo das entradas específicas feitas pelo ator), e existem situações onde a meta não pode ser alcançada (por exemplo, uma conexão de rede necessária estar indisponível), cada caso de uso conterá vários fluxos, sendo um "Fluxo Básico de Eventos" e muitos "Fluxos Alternativos".

O Fluxo Básico de Eventos especifica as interações entre os atores e o sistema para o caso ideal, onde tudo ocorre como o planejado, e a meta do ator (o resultado de valor observável) é alcançada. O fluxo básico representa a principal capacidade fornecida pelo sistema para o caso de uso.

Como o nome sugere, os Fluxos Alternativos especificam interações alternativas com a mesma meta.

Intimamente relacionado com o caso de uso está o conceito de cenário. Um cenário é um fluxo de eventos específico, para um conjunto específico de entradas para o sistema, estados do sistema e estados do ambiente do sistema. Os cenários estão intimamente relacionados com os casos de teste.

Propriedades dos Casos de Uso

Nome

Cada caso de uso deve ter um nome que descreva claramente sua principal meta. O nome pode ser grande o bastante para que possa ser compreendido. Normalmente o nome é uma frase verbal, por exemplo: Retirar Dinheiro.
Nota: Dois casos de uso não podem ter o mesmo nome.

Descrição Resumida

A descrição resumida do caso de uso deve refletir sua finalidade.

Fluxo de Eventos - Conteúdo

O fluxo de eventos deve descrever as interações entre os atores e o sistema o bastante claro para que um leigo compreenda facilmente. O fluxo de eventos deve representar o que o sistema faz, e não como o sistema será projetado para executar o comportamento desejado.

Siga estas diretrizes para descrever o fluxo de eventos:

• Descreva como o caso de uso começa e termina.
• Descreva quais dados são trocados entre o ator e o caso de uso.
• Não descreva os detalhes da interface de usuário, a menos que seja necessário para compreender o comportamento do sistema. Especificar muito cedo os detalhes da interface de usuário irá limitar as opções do design.
• Descreva o fluxo de eventos, não somente a funcionalidade. Para reforçar isto, comece cada ação com "quando o ator…".
• Evite terminologia vaga.
• Detalhe o fluxo de eventos. Especifique o que acontece e quando, para cada ação. Lembre-se que este texto será usado para identificar os casos de teste.

Se você usou determinados termos em outros casos de uso, tenha certeza de usar exatamente os mesmos termos neste caso de uso, e que o significado dos termos seja consistente. Para controlar termos comuns, ponha-os em um Glossário.

Fluxo de Eventos - Estrutura

As duas principais partes do fluxo de eventos são o fluxo básico de eventos e os fluxos alternativos de eventos. O fluxo básico de eventos deve cobrir o que "normalmente" acontece quando o caso de uso é executado. Os fluxos alternativos de eventos cobrem o comportamento de caráter opcional ou excepcional com relação ao comportamento normal, e também variações do comportamento normal. Você pode pensar nos fluxos alternativos de eventos como desvios do fluxo básico de eventos, alguns deles retornarão ao fluxo básico de eventos e outros terminarão a execução do caso de uso.

A seta reta na figura 2 representa o fluxo básico de eventos, e as curvas representam trajetos alternativos em relação ao normal. Alguns trajetos alternativos retornam ao fluxo básico de eventos e outros terminam o caso de uso.

Figura 2: Estrutura típica do fluxo de eventos de um caso de uso

Para esclarecer onde um fluxo alternativo de eventos se encaixa na estrutura, você necessita descrever, para cada desvio no fluxo básico de eventos, o seguinte:

• Onde pode ser inserido o fluxo alternativo no fluxo básico de eventos.
• A condição que deve ser atendida para que o comportamento alternativo inicie.
• Como e onde o fluxo básico de eventos continua, ou como o caso de uso termina.

Pode ser tentador, se o fluxo alternativo de eventos for muito simples, descrevê-lo apenas na seção do fluxo básico de eventos (usando alguma construção informal "se-então-senão"). Isto deve ser evitado. Muitas alternativas tornarão o comportamento normal difícil de ser entendido. Também, incluir trajetos alternativos na seção do fluxo básico de eventos tornará o texto mais parecido com pseudo-código e mais difícil de ler.

Os fluxos básico e alternativos podem ser estruturados em sub-fluxos. Ao fazer isto, sua principal meta deve ser a legibilidade do texto. Um sub-fluxo deve ser um segmento do comportamento do caso de uso que tem uma finalidade clara e seja "atômico", no sentido de que ou são feitas todas as ações descritas ou nenhuma delas.

Requisitos Especiais

Na seção de Requisitos Especiais de um caso de uso, você descreve todos os requisitos do caso de uso que não estão cobertos pelo fluxo de eventos. Estes são normalmente os requisitos não-funcionais que influenciarão o modelo de design. Veja também a discussão sobre requisitos não-funcionais em Concept: Requisitos.

Precondições e Pós-condições

Uma precondição é o estado do sistema e de seus arredores que é necessário para que o caso de uso possa ser iniciado. As Pós-Condições são os estados que o sistema pode ficar depois do caso de uso terminar. Pode ser útil usar os conceitos precondição e pós-condição para esclarecer como o fluxo de eventos começa e termina. Entretanto, use-os somente se as pessoas que irão ler a descrição do caso de uso concordarem que seja útil. A Figura 3 mostra um exemplo.

Figura 3: Ilustração das precondições e pós-condições resultantes

Exemplos

Uma precondição para o caso de uso Retirar Dinheiro da máquina ATM: O cliente ter um cartão pessoal que caiba no leitor de cartão, ter sido emitido um número PIN e estar registrado no sistema bancário.

Uma pós-condição para o caso de uso Retirar Dinheiro da máquina ATM: Ao final do caso de uso, todas as contas e registros de transação são atualizados, a comunicação com o sistema bancário é reinicializada e o cartão é devolvido ao cliente.

Nível de detalhe necessário em casos de uso

Normalmente existirão casos de uso em seu modelo que serão tão simples que não necessitarão de uma descrição estruturada e detalhada do caso de uso (isto é, uma descrição do tipo passo-a-passo será suficiente). Os critérios para tomar esta decisão são que não haja desacordo entre leitores diferentes sobre o que o caso de uso significa, e que os designers e testadores fiquem confortáveis com o nível de detalhe fornecido pelo formato passo-a-passo. Como exemplo, temos os casos de uso que descrevem simples entradas ou saídas de dados do sistema.

Para mais informações sobre possíveis formatos e nível de detalhe para cada caso de uso veja, Guideline: Formatos de Casos de Uso.

Exemplo Caso de Uso

Para um exemplo de uma especificação completa de caso de uso veja Example: Especificação de Caso de Uso.