Introdução
- Diagrama de caso de uso é uma ferramenta regimentada pelas normas da UML. Basicamente A linguagem regulamenta uma série de diagramas que vem para facilitar a criação do modelo do projeto, problema inerente das soluções criadas sob o paradigma de orientação ao objeto. * É uma ferramenta para comunicar funções de alto nível do escopo com o escopo do sistema, em outras palavras é um diagrama simples que basicamente mostra o sistema pelos olhos do usuário.
- Dada a sua simplicidade é excelente para intermediar a comunicação entre o projetista do sistema e o usuário, cliente ou stakeholder.
- É importante ressaltar que todos os diagramas são ferramentas para auxiliar na criação de um bom projeto.
- Quem trabalha ou pelo menos se aventurou em programação sabe que muitos erros de projeto poderiam ser evitados se fosse obedecido o procedimento descrito tanto aqui quanto em toda a normatização UML.
- Tarefa essa que não é fácil uma vez que normalmente se começa um projeto pela parte que deveria ser a última, a codificação.
Constituição
- Para que o diagrama cumpra seu propósito de facilitar a comunicação entre diferentes níveis de conhecimento técnico, nada mais justo de ele ter uma estrutura relativamente simples. Há neste tipo de diagrama, alguns elementos básicos, a saber:
- Ator :
- Representa um usuário do sistema. Pode ser uma pessoa, um equipamento ou um outro sistema, desde que esteja fora do sistema em análise.
- É mandatório que um ator seja relacionado com componentes , classes ou casos de uso
- Salvo a exceção de herança entre atores.
- Caso de uso :
- Nada mais do que a representação de uma função do sistema.
- Trata-se exclusivamente de uma representação de uma ação pretendida, ou uma função executada pelo sistema, como imprimir boleto, executar ação, salvar.
- O Diagrama de Casos de Uso mostra o aspecto visual e exige que seja feito um detalhamento a parte dos procedimentos e parämetros de cada caso.
Documentação de Casos de Uso
- A documentação do caso de uso descreve, de maneira tão simples quando o próprio diagrama, a o sistema em questão. Detalha:
- O que cada função faz
- Como os atores interagem com o os casos
- Os parâmetros que devem ser fornecidos aos casos
- Suas restrições e validações.
- Tem por característica ser um documento de formato flexível por não possuir uma definição fixada pela normatização UML.
- Essa característica auxilia muito pois o designer pode faze-la da maneira que achar mais adequada para o projeto, podendo até mesmo conter pseudocódigos(portugol, ou o próprio algorítimo do código).
- A principal necessidade que a documentação deve atender é que ela deve ser escrita em uma linguagem tão simples que tanto o programador quanto o cliente (leia-se leigo em programação) possa interpretar de forma clara.
Diagrama de Casos de USo
Ator
- Um ator representa uma entidade (um humano, um dispositivo de hardware ou mesmo outro sistema) que interage com um sistema
- Por interação entende-se a troca de mensagens entre um ator e o sistema
- Atores estão fora do sistema, isto é, não são entidades componentes do sistema
- Atores podem ser conectados aos casos de uso somente por associações
- Uma associação entre um caso de uso e um ator significa um canal de comunicação entre ambos, onde cada um pode enviar ou receber mensagens, estabelecendo uma interação
Representação

- O seguinte questionário pode ser usado para identificar os atores do sistema:
- Quem usará as funções principais do sistema?
- Quem precisará do sistema para executar suas tarefas diárias?
- Quem manterá e administrará o sistema?
- Quais os equipamentos que o sistema controlará?
- Com quais outros sistemas o sistema precisará interagir?
- Quem tem interesse nos resultados que o sistema produz?
Generalização de atores
- Generalização: Relacionamento entre um ator “pai” e um ator “filho”, indicando que o primeiro representa um conceito mais geral que o segundo.

- Atores em um sistema

- Caso de Uso
- Descreve uma seqüência de ações - incluindo suas variantes - que o sistema deve executar com o objetivo de produzir como resultado algo de valor para o atendimento das necessidades de um ator
- Um caso de uso:
- Deve ser iniciado por um ator, embora haja exceções
- Descreve uma funcionalidade completa do sistema conforme percebida por um ator
- Gera como resultado algo de valor tangível para um ator (usuário)
- Expressam os requisitos do sistema
- Nome:
- Um caso de uso deve ter como nome uma frase representando uma ação (comportamento) significativa para o vocabulário do sistema em processo de modelagem
- Representação:

Especificando casos de uso
- Nomeando casos de uso:
- Enfatize que um caso de uso é um processo: nomeie-o iniciando por um verbo.
- Descrição:
- A especificação de um caso de uso pode ser feita através da descrição de seqüências de eventos em formato de texto
- Descreve como o ator e o caso de uso interagem
- Concentra-se no comportamento externo do sistema, ignorando os procedimentos a serem executados internamente pelo mesmo através de sua implementação.
- Deve ser considerado:
- como e quando o caso de uso inicia e termina
- quando o caso de uso interage com um ator envolvido
- a seqüência padrão
- as seqüências alternativas ou de exceção.
- A especificação inclui:
| Detalhamento do | caso de uso |
|---|---|
| Identificação do Caso de Uso: | Permite fazer referencia a outros documentos relacionados com o modelo de caso de uso. Ex: CS01 |
| Nome do Caso de Uso | Nome que aparece no diagrama de caso de uso |
| Sumário | Pequena descrição do caso de uso. |
| Ator | Nome do ator que inicia o caso de uso. |
| Pré-condições | Define que hipóteses são assumidas como verdadeiras para que o caso de uso tenha início. Ex: "O cliente deve ser identificado no sistema" |
| Pós-condições | Estado que o sistema alcança após o caso de uso ter sido realizado. |
| Seqüência de Eventos | Corresponde a sequencia de passos para o fluxo principal, descrevendo o que normalmente acontece quando o caso de uso é realizado. |
| Ações Numeradas a partir de 1 | Coluna Esquerda: ator <----> Coluna da direita: Sistema |
| Seqüências Alternativas | Descreve oque acontece quando o ator faz uma escolha alternativa, diferente da descrita no fluxo principal, para alcançar seu objetivo ou quando algo de inesperado ocorre na interação entre o ator e o caso de uso. |
| Requisitos Não-Funcionais | Situações externas ao sistema que darão suporte à aplicação ou definem métricas de execução |
- Exemplo:

Exemplo:
Identificação do Caso de Uso: UC1 Nome do Caso de Uso: Sacar dinheiro no caixa eletrônico Sumário: Este caso permite que o usuáro saque dinheiro no Caixa Eletrônico por meio do cartão magnético Ator: Cliente Pré-condições: Cliente possui cartão do banco e senha e possui saldo Pós-condições: Lançada a transação na conta do Cliente, atualizado o saldo da conta corrente e liberado o dinheiro
Seqüência de Eventos ' '
| Ação do Ator | Resposta do Sistema |
|---|---|
| 1. Cliente insere o cartão do banco no Caixa Eletrônico | 2. O sistema lê dados do cartão e valida e pede a senha |
| 3. O Cliente digita a senha | 4. O sistema valida a conta corrente e a senha do cliente, autorizando a operação e solicita valor |
| 5. O Cliente digita o valor do saque | 6. O sistema autoriza o saque e lança o débito no histórico da CC do Cliente |
| . | 7. O sistema libera o dinheiro e atualiza o saldo |
Seqüências Alternativas
| 2a. | Cliente Inválido |
|---|---|
| Ação do Ator | Ação do Sistema |
| . | 1. O sistema não reconhece a conta corrente e senha do Cliente como válida e retorna msg de erro |
| , | 2. A operação é cancelada |
| 6a . | Fundos Insuficientes |
|---|---|
| Ação do Ator | Ação do Sistema |
| . | 1. O sistema não autoriza o valor solicitado para saque pelo Cliente |
| . | 2. A operação é cancelada |
Requisitos Não-Funcionais
- Resposta do sistema deve ocorrer em no máximo 30 seg em 90 % dos casos.
- Deve ser colocada uma câmera na parte superior da cabine
- Deve haver mecanismo de leitura biométrica
- O dispositivo de entrega de dinheiro deve conter tinta vermelha em caso de arrombamento e tem que ter sistema especial de abertura
- A comunicação do caixa com a Central deve ser feita em link dedicado com redundância
- A tela deve ter capacidade touchscreen
- O sistema operacional deve ser proprietário
- O padrão de letras deve ter tamanho suficiente para leitura visual crítica
- Quando o mecanismo entregar o dinheiro deverá enviar aviso para o sistema
- Descobrindo atores e casos de uso
- Lista Ator-Objetivos
Ator Objetivos
Cliente Retirar dinheiro de sua conta-corrente
Consultar conta-corrente
Que outros casos???
???
Caixa Processar depósito de uma conta-corrente
Processar pagamento de contas
Processar retirada de talões de cheque
Retirar dinheiro para um cliente de sua conta-corrente
Mais ???
Generalização expressa com modificações

Identificação do Caso de Uso: UC5
Nome do Caso de Uso: Receber pagamento
Ator: Caixa
Pré-condições: O Caixa é identificado e autenticado
Pós-condições:O pagamento recebido é registrado no sistema associado ao Caixa
Seqüência de Eventos
Ação do Ator Resposta do Sistema
1. Este caso começa quando o Caixa registra o
documento de cobrança a ser pago
2. O sistema valida a aceitação do documento
de cobrança a ser pago
3. O Caixa informa a opção desejada:
3.1. Se pagamento em dinheiro,
ver subseção Receber pagamento em dinheiro
3.2. Se pagamento em cheque,
ver subseção Receber pagamento em cheque
4. O sistema registra o pagamento
5. O sistema imprime o comprovante.
Subseção: Receber pagamento em cheque
1. O Caixa recebe o cheque, verifica assinatura
e o registra no sistema
2. O sistema valida os dados do cheque
Subseção: Receber pagamento em dinheiro
1. O Caixa registra o valor em dinheiro recebido
2. Sistema informa troco a ser repassado ao cliente
