Use Cases
(Casos de Uso)
Use Cases
Use cases



Use Cases
Um use case é a especificação de seqüências
de ações que um sistema, subsistema, ou
classe pode realizar, interagindo com um dos
atores
Descrição de um conjunto de seqüências de
ações, incluindo variantes, que o sistema
executa para produzir um resultado
observável por um ator
Use cases podem incluir seqüências normais,
seqüências alternativas, ou seqüências
excepcionais (de erro)
Use cases



Use Cases
Mostra apenas o que o sistema faz, e não
como.
Captura o comportamento pretendido para
um sistema, sem a necessidade de
especificar como esse comportamento será
implementado.
Diagramas de interação podem ser usados
para especificar com um use case será
implementado (ou realizado).
Use cases: Utilidades

Use Cases são usados:
–
–
–
–
–
–
Use Cases
nas fases de análise de requisitos;
contribuem para os planos de testes ;
para criação do guia do usuário do sistema;
para validar os requisitos;
na criação do cronograma do projeto;
ajuda no planejamento do que cada versão deve
conter.
Use cases: Representação
gráfica

A coleção de use cases deverá especificar
todas as formas existentes de uso do
sistema.
Matricular aluno
Use Cases
Solicitar
histórico
Verificar
pré-requisitos
Use Cases: Especificação

Use Cases:
–
–
–
–
Breve Descrição
Pré condições
Pós condições
Fluxo de eventos:
• Um fluxo normal
• Diversos fluxos alternativos:
– variantes regulares
– casos incomuns
• Fluxo excepcionais para manipular situações de erro
Use Cases
Pacotes de Use Cases


Use Cases
Servem para agrupar
use cases relacionados
Se o número de atores
ou use cases for muito
grande, você pode
dividi-los em pacotes
de use cases.
Maneiras de Agrupar em
Pacotes




Use Cases
casos de uso que interagem com o mesmo ator;
casos de uso com funcionalidades correlatas;
casos de uso envolvidos com um determinado
processo;
casos de uso que devem ser oferecidos em
conjunto pelo sistema, isto é, se um deles for
implementado, todos os outros devem ser
implementados também.
Atores




Use Cases

O sistema será descrito através de vários use
cases que são executados por um número de
atores
Qualquer coisa que possui interface com o
sistema em desenvolvimento
São pessoas ou outros subsistemas que
interagem com o sistema em
desenvolvimento
Definem um papel particular
São sempre externos ao sistema
Atores e papéis


Use Cases
A diferença entre um ator e um usuário de
um sistema é que um ator representa uma
classe particular de usuários em vez de um
usuário real.
Um mesmo usuário pode desempenhar
diferentes papéis.
Atores
<<Ator>>
Coordenador
Secretária
Sistema de controle
de pre-requisitos
Use Cases
Professora
Estudante
Atores: Especialização

É possível definir tipos gerais de
atores e especializá-los usando o
relacionamento de especialização
Cliente
Use Cases
ClienteEspecial
Diagramas de Use Case

Use Cases
Uma associação entre um ator e um use
case indica que há uma comunicação,
possivelmente com envio e recepção de
mensagens
Diagramas de Use cases
Solicitar
histórico
<<estende>>
Histórico do
semestre atual
<<estende>>
Solicitar histórico de
do curso
Estudante
<<inclui>>
Matricular
aluno
Verificar
dependências
Secretária
Use Cases
Sistema de controle
de pré-requisitos
Exemplo (máquina de reciclar)
Use Cases
Um sistema de software é desenvolvido para controlar um
máquina para reciclar garrafas, latas e engradados.
– A máquina poderá ser usado por vários usuários ao
mesmo tempo.
– Cada usuário poderá retornar os três tipos de item na
mesma ocasião.
– O sistema deverá ser capaz de distinguir entre diferentes
tipos e tamanhos de garrafas e latas.
– O sistema deve registar o número e tipo de itens colocado
por cada usuário.
– Quando solicitado, o sistema deverá ser capaz de
imprimir um recibo com: o número de itens depositados,
o valor dos item devolvidos, e o valor pago ao usuário.
Exemplo (máquina de reciclar)
Iniciar
Lata
Engradado
Use Cases
Recibo
Garrafa
Exemplo (máquina de reciclar).
Use Cases
– O sistema também será usado por um operador.
O operador precisa de uma impressão diária
com os itens depositados durante o dia. A
listagem de incluir um número para cada item.
– O operador do sistema também precisa de uma
operação para modificar a informação de itens
armazenada no sistema. Por exemplo, o valores
dos itens depositados.
– Quando um item ficar preso no sistema, o
sistema deve alertar o operador ligando um
alarme.
Encontrando Atores






Use Cases
Quem usa o sistema?
Quem instala/mantém o sistema?
Quem inicia/desliga o sistema?
Que outros sistemas interagem com o
sistema?
Quem recebe informação do sistema?
Quem provê informação ao sistema?
Encontrando Atores (cont.)

Atores do sistema de reciclagem:
– O cliente
– O operador

Use Cases
No exemplo, ocasionalmente o operador
poderá depositar suas próprias garrafas na
máquina. Neste caso ele atuará no papel de
cliente.
Interação dos Atores

O cliente interage com sistema:
– depositando itens na máquina
– recebendo um recibo da máquina

O operador interagem com sistema:
– Recebendo os relatórios diários dos depósitos
realizados
– Mantendo o banco de dados de itens
Use Cases
Use Cases do Sistema de
Reciclagem



Use Cases
Após identificação dos atores, o próximo
passo é a identificação dos use cases.
Os atores são fundamentais para a
descoberta dos use cases. Cada ator irá
executar vários use cases no sistema.
Cada use case será um curso completo de
eventos iniciados pelo ator e especificará
as interações que ocorrerão entre o ator e o
sistema.
Identificação de use cases


Use Cases
Primeiro passo, examinar os requisitos
do ponto de vista dos usuários.
Perguntas úteis;
– Que funções o ator vai querer do sistema?
– O sistema armazena informações? Que
informações atores irão criar, ler, atualizar ou
apagar?
– O sistema precisa notificar o ator sobre
mudanças no seu estado interno?
– Existe algum evento externo que o sistema
precisa saber? Que ator informa o sistema destes
eventos?
Identificação de use cases

Workshop de casos de uso
–
–
–
–
–
–
–
–
–
Use Cases
não pode ter muita gente
pessoas com diferentes perfis
presença de um facilitador
aceite todo tipo de sugestão e filtre depois!
evite pensar em detalhes
os casos de uso levantados devem estar claros para todos!
principalmente o valor que estes agregam ao usuário
consulte todos!
dê sugestões
Identificação de use cases

Reuniões
– conversas com usuários

Storyboarding
– simulação através de desenhos das interfaces
Use Cases
Identificação de use cases


Use Cases
Casos de uso não precisam ser descritos
todos de uma vez: o processo deve ser
iterativo
Casos de uso devem ser priorizados
Use Cases do Sistema de
Reciclagem

Cliente
– Deve ser capaz de retornar itens (latas,
garrafas). O use case será Retornar item .
– Este use case deverá incluir todos os
eventos até o recibo ser emitido.
Use Cases
Use Cases do Sistema de
Reciclagem

Operador
– Deve ser capaz de receber um relatório diário
de todos os itens depositados. Use case Gerar
relatório.
– Deve ser também capaz de modificar
informações do sistema, por exemplo o valor de
cada item depositado. Use case, Mudar item.
Use Cases
Especificações dos Use cases

Use Case Retornar item
Fluxo principal de eventos:
• Será iniciado pelo cliente quando ele/ela
retornar os itens. O sistema manterá uma
contagem atualizada dos tipos de itens e seus
valores diários.
• Quando o cliente depositar os seus itens, ele/ela
irá pressionar o botão recibo para obter o recibo.
O recibo impresso irá listar os itens depositados,
seus totais e o valor a ser pago ao cliente.
Use Cases
Especificações dos Use cases

Use Case Gerar relatório
Fluxo principal de eventos:
• Será iniciado pelo operador quando ele precisar
da listagem dos itens retornados no dia. O
sistema imprimirá o tipo, quantidade de cada
item e o total.

Use case Mudar item
Fluxo principal de eventos
• Será iniciado pelo operador para modificar a
informação do item no sistema. Ele será capaz
de alterar o valor a ser pago pelo item.
Use Cases
Diagrama de Use Case
Gerar Relatório
Retornar Item
Cliente
Use Cases
Mudar Item
Operador
Expressão de variantes de
use cases

Nem sempre é óbvio decidir se uma
funcionalidade corresponde a um novo
use cases. Às vezes trata-se de uma
variação de um mesmo use case
– Se as diferenças forem pequenas elas
podem ser descritas através de variantes de
um mesmo use case
– Se as diferenças são grandes elas devem ser
descritas como use cases separados.
Use Cases
Expressão de variantes

Use Cases
Use Case Retornar item
Fluxo principal de eventos:
• …...
• Quando o cliente depositar os seus itens, ele/ela irá
pressionar o botão recibo para obter o recibo. O recibo
impresso irá listar os itens depositados, seus totais e o
valor a ser pago ao cliente.
Fluxo excepcional de eventos
• Quando o cliente retorna um item ele é medido pelo
sistema. A medição é usada para determinar que tipo de
lata, garrafa ou gradeado foi depositado. Se aceito o
total do cliente será incrementado. Se não for aceito,
apresentar mensagem ´NÃO É VALIDA´.
Adição de detalhes

Use Case Retornar item
Fluxo principal de eventos:
• Quando o cliente depositar os seus itens,
ele/ela irá pressionar o botão recibo para
obter o recibo. O recibo impresso irá listar :
nome do item
número de itens retornados
valor do item
total para este item
Soma total a ser paga ao cliente
Use Cases
Organizando Use Cases



Use Cases
Generalização
Inclusão
Extensão
Generalização de Use Case




Use Cases
Relaciona um Use Case especializado a um
mais geral
O filho herda os atributos, operações e
seqüências de comportamento dos pais
O filho pode adicionar e redefinir o
comportamento do pai
O filho pode substituir o pai em qualquer
lugar que ele aparece
Generalização de Use Case


Use Cases
O use case filho pode adicionar
comportamento incremental através da
inserção de seqüências adicionais de ações
em pontos arbitrários da seqüência do pai
Pode modificar alguma das operações e
seqüências herdadas (cuidado!!)
Generalização de Use Cases



Use Cases
É possível abstrair comportamentos de
use cases. Normalmente a similaridade
entre use cases é identificada após a
construção do use case.
Os use cases Checar password e Scan
de retina ambos servem para validar o
usuário.
Identificar um use case abstrato
Validar usuário para realizar esta
validação.
Generalização
Validar usuário
Checar password
Use Cases
Scan da retina
Inclusão de use cases



Use Cases
O use case base incorpora explicitamente o
comportamento de outro use case no local
especificado na base.
O use case incluído nunca estará sozinho,
somente será instanciado de um use case
base que o incluirá.
Usado para evitar a descrição do mesmo
fluxo de eventos várias vezes.
Inclusão
Sessão de ATM
<<inclui>>
Identificar
Cliente
Use Cases
use case base
(cliente)
<<inclui>>
Validar Conta
use case incluído
(servidor)
Use Case: Sessão de ATM
mostre anúncio do dia
inclui Identificar Cliente
inclui Validar Conta
imprimir cabeçalho do recibo
log out
Use Case de Inclusão: Identificar Cliente
pegue o nome do cliente
inclui Verificar Identidade
if falha de verificação then abort a sessão
obtenha número da conta do cliente
Use Cases
Use Case de Inclusão: Validar Conta
estabeleça conexão com banco de dados de contas
obtenha status e limite da conta
Inclusão de Use Case:
Definição

Use Cases
Inclusão da seqüência de comportamento do
use case servidor na seqüência de interação
do use case cliente, sob controle do use
case cliente, no local que o cliente
especifica sua descrição
Inclusão de use case



Use Cases
Descreve uma seqüência adicional de
comportamento que será inserida na
instância de use case que está executando o
use case base
O mesmo use case de inclusão pode ser
inserido em múltiplos use cases base
A inclusão representa comportamento
encapsulado que potencialmente poderá ser
reusado em outros use cases base
Extensão de use case


Use Cases
A extensão de um use case base por um
use case de extensão especifica como o
comportamento definido pelo use case de
extensão pode ser inserido no
comportamento do use case base.
O use case de extensão modifica
incrementalmente o use case base de
uma forma modular
Extensão de use case


Use Cases
Exemplo:
quando um item ficar preso o sistema
deverá emitir um alarme
Isto poderá ser descrito como um use case
que estende o use case Retornar item
Extensão de use case
Retornar item
<<estende>>
Item preso
Quando um item ficar preso o alarme é ativado
para chamar o operador.
Quando operador remover o item preso o alarme
é desligado e o cliente poderá continuar a retornar itens.
Use Cases
Extensão de use case

Usado para :
– Modelar partes opcionais de use cases
– Modelar cursos alternativos e complexos que
raramente ocorrem, como Item Preso
– Modelar sub-cursos que são executados
somente em certos casos
Use Cases
Extensão de use case


Use Cases
Para modelar a situação onde vários
diferentes use cases podem ser inseridos em
um use case (pontos de extensão)
O use case base implicitamente incorpora o
comportamento do use case na localização
especificada.
Extensão: Pontos de Extensão
Fazer Pedido
Pontos de extensão
set prioridade
Fazer Pedido Urgente
<<estende>>
(set prioridade)
<<inclui>>
Validar
usuário
Use Case Fazer Pedido
Use Cases
Fluxo principal de eventos: inclui (Validar usuário).
Receber do usuário os itens do pedido. (set prioridade).
Submeter o pedido para processamento.
Extensão: Pontos de Extensão
Sessão de ATM
pontos de extensão
transação possível
detalhes do recibo
Use Cases
Use Case: Sessão de ATM
mostre anúncio do dia
inclui Identificar Cliente
inclui Validar Conta
(transação possível) < ------ ponto de extensão
imprimir cabeçalho do recibo
(detalhes do recibo) < -------- ponto de extensão
log out
Extensão: Pontos de Extensão


Use Cases
Cada ponto de extensão precisa ser definido
no use case base.
Quando a execução da instância do use
case alcança o local do use case
referenciado pelo ponto de extensão e a
condição da extensão é satisfeita, a
execução é transferida para a seqüência do
segmento de extensão. Quanto terminada, o
controle volta para o use case original
Extensão de use case:
Avançado


Use Cases
O relacionamento de extensão pode ter uma
condição, uma expressão em termos de
atributos do use case base, ou a ocorrência
de eventos tais como a recepção de um
sinal
Os efeitos da do use case de extensão são
adicionados aos efeitos do use case base
quando da sua instanciação
Agenda
Desmarcar
compromisso
Alterar
compromisso
<<inclui>>
<<inclui>>
Mostrar agenda
diária
<<inclui>>
<<inclui>>
Entrar no
sistema
<<inclui>>
<<inclui>>
<<inclui>>
Marcar
compromisso
Mostrar
calendário anual
Programador
Marcar reunião
Gerente
Use Cases
Alocar tarefas
Verificar agendas dos
programadores
Verificar
permissões
<<inclui>>
Mostrar
calendário
mensal
Autenticar
usuário
Celular
Re alizar cham ada
te le fônica
<<estende>>
Re alizar cham ada
tipo "confe rê ncia"
Re de ce lular
Re ce be r cham ada
te le fônica
Ve rificar lis ta de
cham adas
Us uário
Telefone Celular
Use Cases
Dicas: Modelando o Contexto
do Sistema

Use Cases
Identifique os atores que cercam o sistema
– Quais grupos precisam de ajuda do sistema para
executarem suas tarefas
– Quais os grupos necessários para executarem as
funções do sistema
– Quais grupos interagem com hardware externo
ou outros sistemas de software
– Quais grupos executam funções secundárias
de administração e manutenção
Dicas: Modelando o Contexto
do Sistema



Use Cases
Organize os atores que são similares em
uma hierarquia de generalização /
especialização.
Quando ajudar a compreensão, faça um
estereótipo para o ator
Use os atores no diagrama de use cases e
especifique os caminhos de comunicação
entre atores e use cases do sistema.
Dicas: Modelando Requisitos
do Sistema



Use Cases

Estabeleça o contexto do sistema através da
identificação dos atores que o cercam
Para cada ator, considere o comportamento
que eles esperam o requerem que o sistema
produza
Dê um nome aos comportamentos comuns
(Use cases)
Fatore comportamentos comuns em novos
use cases que serão usados por outros
Dicas: Modelando Requisitos
do Sistema



Use Cases
Fatore comportamento variante em novos
use cases que estendem o fluxo principal de
eventos
Modele os use cases, atores e seus
relacionamentos através de diagramas de
use case
Adorne os use cases com notas que
descrevem requisitos não funcionais
(algumas destes se aplicam ao sistema como
um todo).
Checklist: Nomeação de
Atores e Use Case




Use Cases
Devem ser únicos!
– cuidado ao definir novos nomes!
Os nomes devem ser intuitivos e descritivos.
Tanto os usuários como os patrocinadores do
software têm um entendimento comum?
Nomes de atores
– devem descrever claramente o papel do ator
Nomes de casos de uso
– devem indicar o resultado do caso de uso
– use quantas palavras for necessário!
Checklist: Atores




Use Cases
Todos os atores foram identificados?
Cada ator está envolvido com pelo menos
um use case?
Cada ator desempenha um papel? Algum
deveria ser fundido com outro ou ser
dividido em dois?
Existem dois ou mais atores
desempenhando o mesmo papel em relação
a um use case?
Checklist: Use Cases





Use Cases
Cada use case está envolvido com pelo
menos um ator?
Os use cases são independentes uns dos
outros?
Algum dos use case têm comportamento
ou fluxo de eventos muito similares?
Os use cases têm nomes únicos, intuitivos
e explicativos de modo que não podem ser
confundidos em um estágio posterior?
Os patrocinadores e usuários entendem os
nomes e descrições dos use cases?
Checklist: Modelo de Use
Cases




Use Cases
O modelo de use cases está fácil de se
entender?
Estudando o modelo de use cases, você
pode ter uma idéia clara das funções do
sistema e como elas estão relacionadas?
O modelo de use cases contém algum
comportamento supérfluo?
A divisão em pacotes do modelo de use
cases está apropriada?
Checklist: Especificação de
Use Case








Use Cases
Está claro quem deseja executar um use case?
A finalidade de cada use case está clara?
A descrição breve dá uma idéia clara do significado do
use case?
Está claro como e quando os fluxos de eventos de cada
use case começam e terminam?
A seqüência de comunicação entre um ator e um use case
está de acordo com as expectativas do usuário?
As interações e trocas de informação entre os atores e o
sistema estão claras?
Existe algum use case demasiadamente complexo?
Os fluxos de eventos (básicos e alternativos) estão
modelados de forma clara?