O modelo de casos de usoé o principal resultado da fase de análise de requisitos. Diagramas de casos de uso são utilizados para representar de forma panorâmica os requisitos funcionais de um sistema do ponto de vista do usuário.



DEFINIÇÃO

É um diagrama utilizado na análise de requisitos com objetivos claros:
- Compreender o problema.

- Delimitar o sistema (quem está no entorno).

- Definir as funcionalidades oferecidas ao usuário (não há preocupação com a implementação).



Diagrama de casos de uso é uma ferramenta de comunicação entre clientes, usuários e desenvolvedores para discutirem e definirem as funcionalidades que devem ser realizadas pelo sistema.



Os elementos básicos de um diagrama de casos de uso são: atores, casos de uso e relações entre os mesmos.



ATORES

Representam papéis desempenhados por usuários ou qualquer outra entidade externa ao sistema (ex. hardware, outros sistemas);
Podem iniciar casos de uso; Podem prover e/ou receber informações dos casos de uso

CASOS DE USO
A coleção de casos de uso representa todos os modos de execução do sistema do ponto de vista do usuário. Um caso de uso é uma seqüência de ações que produz um resultado significativo (com valor) para um ator.



Descrição

Não há descrição padrão definida pela UML. Em geral o diagrama é bastante informal e sua estruturação (relação entre casos) não deve ser levada ao extremo.
Os casos de uso são descritos normalmente pelos seguintes elementos:
- Nome;

- Descrição;

- Requisitos (requirements): são os requisitos funcionais providos pelo caso de uso;

- Restrições (constraints), tais como pré e pós-condições e condições invariantes:
Pré-condições: define o que deve ser verdadeiro para que o caso de uso seja iniciado.
Pós-condições: o que se torna verdadeiro pela execução do caso de uso.
Invariantes: condições que são verdadeiras durante a execução do caso de uso.

- Fluxos de eventos: descrição de interações entre atores e sistema que ocorrem durante a execução do caso de uso;

outras informações: data, autor, etc..



Fluxo de Eventos

Um fluxo de evento descreve i) como o sistema e os atores colaboram para produzir algo de valor aos atores e ii) o que pode impedir sua obtenção. Um fluxo descreve um caminho entre muitos possíveis visto que um caso de uso pode ser executado de vários modos.
Há fluxos primários ou básicos (fluxo normal de eventos) e alternativos (o que fazer se…)
Fluxos documentam as responsabilidades, ou seja, como as responsabilidades especificadas nos casos de uso são divididas entre sistema e atores.



Fluxo Básico

Um fluxo básico representa o que ocorre normalmente quando o caso de uso é executado.
A descrição do fluxo básico deve conter:

- Ator e o evento que o mesmo dispara para iniciar o caso;

- A interação normal (sem tratamento de exceções) entre ator e sistema;

- Descrição de como o caso termina.



Subfluxo

Um fluxo de eventos pode ser decomposto em subfluxos para melhorar a legibilidade. No entanto, é interessante evitar muitas decomposições, pois o fluxo ficará muito fragmentado e seu entendimento dificultado. Um subfluxo deve ser atômico, isto é, ou é executado na sua totalidade ou não é executado. Para referenciar um subfluxo a partir de outro fluxo usar a notação: executar <nome subfluxo>.



Pontos de extensão

São pontos precisos num fluxo de eventos que servem para inserir comportamentos adicionais. Pontos de extensão podem ser privados ou públicos. São privados se visíveis somente dentro do caso onde foram definidos ou públicos se visíveis nos casos que estendem o caso onde foram definidos.



Fluxo Alternativo

Um fluxo alternativo apresenta um comportamento opcional, de outra forma, que não é parte do comportamento normal de um caso de uso. Fluxos alternativos são utilizados para representar tratamento de exceções ou um comportamento alternativo complexo que tornaria o fluxo básico muito
longo ou de difícil compreensão.
Fluxos alternativos sempre são dependentes da existência de uma condição que ocorre em um ponto de extensão de outro fluxo de eventos. Há três tipos de fluxos alternativos:
1. Específico: iniciam num ponto de extensão.
2. Regional: podem ocorrer entre dois pontos de extensão.
3. Geral: podem ocorrer em qualquer ponto do caso de uso.



Diagrama de atividade

Um diagrama de atividade pode ser empregado para representar os fluxos de eventos de um caso de uso. Sua utilização não suprime a descrição textual, pelo contrário, ele deve ser visto como uma ilustração simplificada da descrição textual.

Cenários
Cenários são instâncias de execução dos casos de uso. Os fluxos alternativos representam as possibilidades de execução de um caso de uso.
Cenários são importantes para definir casos de teste e para desenvolvedores pensarem sobre como o
sistema será utilizado.



Realizações de Casos de Uso

Um caso de uso pode ser realizado (projetado e implementado) de diferentes modos. Em UML há uma representação para realização de caso de uso como ilustra a figura abaixo. O intuito dessa representação é fazer uma ponte entre as descrições do sistema utilizadas pelas pessoas envolvidas na sua construção.