UML
Unified Modeling Language
Professor: André Gustavo Bastos Lima
Diagramas de Casos de Uso
Professor: André Gustavo Bastos Lima
DEFINIÇÃO DE CASO DE USO
Segundo o RUP:
“Um Caso de Uso é a relação de uma seqüência de
ações que um sistema executa produzindo um
resultado de valor observável para um ator
específico.”
UML - DIAGRAMA DE CASOS DE USO
Aluno
<<extend>>
Consultar Disponibilidade
Atualizar Financeiro
<<include>>
Inscrever em Curso
UML - DIAGRAMA DE CASOS DE USO






Visão de alto nível (perspectiva externa e dos atores);
O mais informal do diagramas da UML;
Representa o conjunto de atores, casos de uso, seus
relacionamentos e responsabilidades;
Ajuda a capturar os requisitos funcionais do sistema;
É importante para a organização e modelagem de
comportamentos do sistema (representação dinâmica);
A sua documentação é essencial (outros diagramas da
UML, como de atividades e de seqüência, mais formais e
precisos, podem ser usados nessa documentação).
UML - DIAGRAMA DE CASOS DE USO




São as ações dos usuários com começo, meio e fim;
Pode ser simples ou complexo, ter alguns parágrafos ou várias
páginas (ou diagramas) em sua documentação;
As funcionalidades do sistema podem ser rastreadas para
casos de uso;
São exemplos: Sacar Dinheiro, Comprar Produtos, Abrir
Conta, Pagar Título Bancário etc.
ANATOMIA DO CASO DE USO
Descrição
Pré-condição
Fluxo Básico
Fluxo Alternativo 1
Fluxo Alternativo n
Pontos de Extensão
Pós-condição
DESCRIÇÃO

Apresenta uma breve descrição do objetivo do caso
de uso.
Descrição
Este caso de uso descreve o procedimento de
saque de dinheiro em um caixa eletrônico.
PRÉ-CONDIÇÃO
É o estado do sistema requerido antes do caso de
uso ser iniciado;
 Pode ser omitido (usar apenas quando relevante);
 Deve ser um estado de valor mensurável;
 A Pré-condição é uma restrição para o início do caso
de uso, não o evento que inicia o caso de uso.

Pré-Condição
Cliente identificado corretamente.
PÓS-CONDIÇÃO
Uma pós-condição é o estado no qual o sistema deve
estar ao final do caso de uso;
 Pode ser omitido, usar apenas quando adicionar
valor;
 Deve ser um estado de valor mensurável;

Pós-Condição
Cartão devolvido ao cliente.
CENÁRIOS

É o diálogo ator-sistema detalhando a execução do
caso de uso.
 Fluxo Básico

Fluxo onde tudo dá certo.
 Fluxos alternativos
Variações na execução do fluxo básico;
 Erros (exceções) que podem ocorrer no fluxo básico (em
alguns processos são chamados de fluxos de exceção).

FLUXO BÁSICO
Fluxo Básico
1. O Cliente informa a opção de Saque.
2. O Sistema solicita o valor do saque.
3. O Cliente informa o valor e confirma a operação.
4. O Sistema verifica o valor informado.
5. O Sistema verifica o saldo do cliente .[A1]
6. O Sistema debita o valor sacado do saldo do cliente.[A2]
7. O Sistema entrega o dinheiro.
8. Fim do caso de uso.
FLUXO ALTERNATIVO
Fluxos Alternativos
A1. Valor informado inválido
1. No passo 4 do fluxo básico o sistema verificou que o valor
informado é inválido.
2. O sistema informa que o valor é inválido.
3. O sistema informa as regras para valores válidos.
4. O caso de uso volta para o passo 2 do fluxo básico.
A2. Saldo insuficiente
1. No passo 5 do fluxo básico o Sistema verificou que o
cliente não possui saldo.
2. O Sistema informa o saldo disponível.
3. O caso de uso volta para o passo 8 do fluxo básico.
O QUE UM CASO DE USO NÃO CONTÉM
O
caso de uso descreve a funcionalidade do
sistema de uma perspectiva orientada a
tarefa (passos).
O




Caso de uso não contém:
Detalhes da interface de usuário;
Objetivos de performace;
Detalhes da arquitetura da aplicação;
Requisitos não funcionais.
O QUE UM CASO DE USO NÃO CONTÉM
 Exemplos:
“... O sistema exibe um DBGrid com os...”
 “... A resposta deverá ser retornada em menos de
10 segs...”
 “... O sistema inicia uma conexão com o servidor
de aplicação...”
 “... O usuário deverá entrar com os códigos
através da caneta ótica ....”

COMO ENCONTRAR CASOS DE USO





Identifique as interações do usuário (concentre-se nos objetivos
do usuário):
 “Sacar dinheiro...”
 “Transferir dinheiro entre contas...”
 “Cadastrar contas de débito automático...”
Descreva as funções que o usuário deseja do sistema;
Descreva as funções que criam, lêem, atualizam e excluem
informações;
Descreva como os atores são notificados sobre alterações de
estado do sistema;
Descreva como o Ator necessitará informar ao sistema eventos
ocorridos.
NOMEANDO OS CASOS DE USO
Nomeie o caso de uso com uma frase que especifique o
objetivo do ator.
 Utilize verbos concretos, “fortes”, ao invés de verbos
genéricos e fracos, exemplos:

Verbos fortes: criar, calcular, migrar, receber, arquivar,
registrar e ativar.
 Verbos fracos: controlar, gerenciar, administrar, organizar
e processar.


Seja explícito. Utilize termos específicos, exemplos:
Termos fracos: dado e sistema.
 Termos fortes: pagamento e conta.

NOMEANDO OS CASOS DE USO
Bons nomes
Nomes Ruins

Depositar Dinheiro;

Controle de Saque;

Gravar
Movimentação
Bancária;
Transferir Valores
entre Contas
Correntes.

Controle de Saldo;

Transferência
Bancária.

DEFINIÇÃO DE ATOR
É qualquer coisa que interage com o
sistema;
 Pode ser um usuário, um hardware
externo ou outro sistema;
 Representa uma classe de usuários;
 Algo sobre o qual não temos controle.

DEFINIÇÃO DE ATOR (CONT.)

Várias pessoas podem ser representadas por um único ator
Bruno
é um cliente
Correntista
Caixa
Ana Lúcia
é uma cliente
Eletrônico
Saque de Conta
Corrente
DEFINIÇÃO DE ATOR (CONT.)

Uma pessoa pode atuar como mais de um ator.
Fulano
é um cliente
Correntista
Caixa
Eletrônico
Fulano também
é responsável
pelo
abastecimento
da máquina
Técnico responsável
DEFINIÇÃO DE ATOR (CONT.)

Ator Primário:


Estimula o sistema a reagir.
Ator Secundário:

Responde às solicitações do sistema.
Caso de uso
Ator Primário
Ator Secundário
NOMEANDO ATORES
Agrupe os indivíduos segundo a utilização do
sistema;
 Identifique os papéis que eles assumem ao utilizar
o sistema;
 Cada papel é um ator em potencial;
 Use nomes comuns para um sistema existente (do
ponto de vista do usuário), não invente um nome
novo;

NOMEANDO ATORES
Nomes ruins

INSS
Recepcionista
IN
Cadastrar
Títulos

Auditor
MEC
3
Bons nomes
MODELO DE CASOS DE USO
Sacar
Dinheiro
Correntista
Depositar
Dinheiro
Pagar
Título
Técnico do Suporte
Abastecer
Numerário
COMUNICAÇÃO

Os relacionamentos de associação entre Atores e
classes de Casos de Uso são usados para indicar
que o ator participa e se comunica com o sistema
conforme descrito no Caso de Uso;

A seta indica quem inicia a comunicação;

Setas não demonstram fluxo;

Setas duplas não são utilizadas.
COMUNICAÇÃO

Seta do Ator para o caso de uso:
Ator dispara o caso de uso;
 Ator estimula o sistema;
 Ator principal.

Consultar
Saldo
Correntista
COMUNICAÇÃO

Seta do Caso de Uso para o Ator:
Sistema solicita informações;
 Sistema espera uma ação do ator;
 Ator secundário.

Consultar
Saldo
Correntista
Sistema Mainframe
FATORAÇÃO DE CASOS DE USO

Existem três tipos de relacionamento de fatoração:
Inclusão – Include;
 Extensão – Extend;
 Generalização.


Objetivos:
Descrição de procedimentos obrigatórios;
 Descrição de procedimentos opcionais;
 Especialização de comportamento.

INCLUSÃO (INCLUDE)

Características:

A execução do caso de uso incluído é obrigatória;

O caso de uso base depende do resultado retornado
pelo caso de uso incluído;

A inclusão é na essência um encapsulamento.
EXTENSÃO (EXTEND)
 Características:

Representa uma fatoração implícita;

A execução do caso de uso de extensão é
opcional;

O caso de uso de extensão é inserido no caso de
uso base em locais específicos chamados “Pontos
de extensão”;
GENERALIZAÇÃO
 Utilizado
para:

Destacar o comportamento comum a mais de um
caso de uso, mas com algumas particularidades
adicionais;

Demonstrar
formas
mais
específicas
comportamento do um caso de uso.
de
GENERALIZAÇÃO
 Características:

Relacionamento é-um entre um caso de uso base
(pai) com um ou mais casos de uso filhos;

Semelhante a generalização/herança de classes;

O filho herda toda a estrutura, comportamento e
relacionamentos do pai;

O filho é totalmente dependente da estrutura do
pai.
GENERALIZAÇÃO - EXEMPLO
No caso de uso “Cobrança de Penalti”, podem ser
representados a cobrança de penalti em tempo
regulamentar e como desempate. Esses dois casos de
uso têm muito do seu comportamento em comum, mas
com algumas particularidades, como a reposição da
bola em jogo ou não.
GENERALIZAÇÃO - EXEMPLO
Cobrança
de Penalti
Cobrança de
Penalti em tempo
regulamentar
Cobrança de
Penalti em
desempate