Use Cases
(Casos de Uso)
Use Case
Objetivos



Use Case
Introduzir a necessidade de elicitação de
requisitos
Apresentar várias técnicas de elicitação
Descrever em detalhe a técnica de Use
Case
Uma caso real!





Use Case
O Sistema que queremos deve fazer isto,
isto ..., e nesse caso também isto;
Sim, Sim estou anotando;
Conversei com os usuários e
basicamente este é o Sistema que
teremos que desenvolver;
Sim chefe;
Ótimo, começaremos a especificar os
requisitos imediatamente;
ELICITAÇÃO DE REQUISITOS
MOTIVAÇÃO (Cont. ...)


Use Case
... Quatro Meses Depois ...
Srs. Usuários, após o emprego das mais
modernas técnicas de especificação,
produzimos este documento que descreve
minuciosamente o Sistema;
Ótimo! Bom! Hum! ... é um documento
com 300 páginas e todos estes gráficos,
tabelas. Enfim, vamos analisá-lo e
voltamos a falar;
ELICITAÇÃO DE REQUISITOS
MOTIVAÇÃO (Cont. ...)


Use Case
... Depois de um mês e meio ...
Sr. Analista, nosso pessoal analisou com
cuidado o documento. Tivemos muita
dificuldade e dúvidas em entendê-lo. Mas
o que percebemos é que NÃO FOMOS
CORRETAMENTE ENTENDIDOS!!!
Como não? Tudo que aí está, foi fruto de
nosso entendimento pessoal.
REALMENTE VOCÊS NÃO SABEM O
QUE QUEREM!!!
Elicitação de Requisitos


Use Case
ELICITAR: descobrir, tornar explícito,
obter o máximo de informações para o
conhecimento do objeto em questão
Cabe à elicitação a tarefa de identificar os
fatos que compõem os requisitos do
Sistema, de forma a prover o mais correto e
mais completo entendimento do que é
demandado daquele software
Elicitação de Requisitos:
Dificuldades




Use Case
Usuários podem não ter uma idéia precisa do
sistema por eles requerido;
Usuários têm dificuldades para descreverem seu
conhecimento sobre o domínio do problema;
Usuários e Analistas têm diferentes pontos de vista
do problema (por terem diferentes formações);
Usuários podem antipatizar-se com o novo sistema
e se negarem a participar da elicitação (ou mesmo
fornecer informações errôneas).
Atividades da Elicitação

Entendimento do domínio da aplicação
– O conhecimento do domínio da aplicação é o
conhecimento geral ond eo sistema será
aplicado.

Entendimento do problema
– Os detalhes dos problemas específicos do
problema do cliente onde o sistema será
aplicado deve ser entendido.
Use Case
Atividades da Elicitação

Entendimento do negócio
– Você deve entender como os sistemas
interagem e contribuem de forma geral com os
objetivos de negócio.

Use Case
Entendimento das necessidades e limitações
dos stakeholders do sistema
– Você deve entender, em detalhe, as
necessidades específicas das pessoas que
requerem suporte do sistema no seu trabalho.
Técnicas de elicitação








Use Case

Entrevista
Leitura de documentos
Questionários
Análise de protocolos
Participação ativa dos usuários
Use Cases e Cenários (UML)
Métodos Soft Systems
Observações e análise sociais
Reuso de requisitos
Elicitação de Requisitos



Use Case
O profissional deve selecionar as técnicas a
serem utilizadas e estabelecer de que
maneira elas serão integradas
É importante utilizar uma técnica de
modelagem de apoio para que os fatos
elicitados fiquem corretamente
representados para futuro tratamento
A escolha das técnicas e seu esquema de
integração dependerá do problema e da
equipe participante
Técnicas específicas de
elicitação
Use Case
Entrevistas



Use Case
O engenheiro de requisitos ou analista
discute o sistema com diferentes
stakeholders e obtêm um entendimento dos
requisitos.
Vantagens: contato direto com o usuário e
validação imediata
Desvantagens: conhecimento tácito e
diferenças de cultura
Entrevistas: tipos



Use Case
Entrevistas fechadas. O engenheiro de
requisitos busca respostas para um conjunto
de questões pré-definidas
Entrevistas abertas. Não há uma agenda prédefinida e o engenheiro de requisitos
discute, de forma aberta, o que o
stakeholders quer do sistema.
Tutorial: o cliente está no comando - aula
Essencial das entrevistas



Use Case
Entrevistadores devem estar de “cabeça aberta” e
não fazer a entrevista com noções pré-concebidas
sobre o que é necessário
Informar aos stakeholders o ponto inicial da
discussão. Isto pode ser uma questão, uma
proposta de requisitos ou um sistema existente
Entrevistadores devem estar cientes da política
organizacional - muitos requisitos reais podem não
serem discutidos devido as implicações políticas
Leitura de Documentos




Use Case
Abstrações
Vocabulário da aplicação
Vantagens: facilidade de acesso e volume de
informações
Desvantagens: dispersão das informações e
volume de trabalho
Questionários





Use Case
Quando existe conhecimento sobre o problema e
grande número de clientes
Dão idéia definida sobre como certos aspectos
universo de informação/software são percebidos
Possibilitam análises estatísticas
Vantagens: padronização das perguntas e
tratamento estatístico das respostas
Desvantagens: limitação do universo de respostas
e pouca iteração
Análise de Protocolos




Use Case
Consiste em analisar o trabalho de
determinada pessoa através de verbalização
Objetivo: estabelecer a racionalidade
utilizada na execução de tarefas
Vantagens: possibilidade de elicitar fatos não
facilmente observáveis e permitir melhor
entendimento dos fatos
Desvantagens: desempenho do entrevistado e
“o que se diz é diferente do que se faz”
Participação Ativa dos
Usuários




Use Case

Incorporação dos usuários ao grupo de
desenvolvimento
Os usuários precisam aprender as linguagens
de modelagem utilizadas para ler as
descrições e criticá-las
Integração dos usuários com os
desenvolvedore na modelagem do sistema
Vantagens: envolvimento dos clientes e
usuários
Desvantagens: treinamento dos usuários e
falsa impressão da eficácia do sistema
Diagramas de Use Cases



Use Case
Servem facilitam o entendimento de um
sistema mostrando a sua “visão externa”
São usados para modelar o contexto de um
sistema, subsistema ou classe
São uma das maneiras mais comuns de
documentar os requisitos do sistema
– Delimitam o Sistema
– Definem a funcionalidade do sistema
Use Case



Use Case
É uma forma específica de uso do sistema
através da execução de alguma
funcionalidade do sistema.
Use Cases descrevem o que acontece dentro
do sistema.
Ajudam muito na comunicação entre
clientes e os desenvolvedores.
Caso de Uso

Use Case
Uma unidade coerente de funcionalidade
provida por uma classificador (um sistema,
subsistema ou classe) manifestado por uma
sequência de mensagens trocadas entre o
sistema e um ou mais usuários externos
(representados como atores), junto com as
ações executadas pelo sistema.
Use cases



Use Case
Um use case é a especificação de sequências
de ações que um sistema, subsistema, ou
classe pode realizar, interagindo com um dos
atores
Descrição de um conjunto de sequências de
ações, incluindo variantes, que o sistema
executa para produzir um resultado
observável para um ator.
Use cases podem incluir sequências
alternativas, ou sequências excepcionais (de
erro)
Use Case: Representação
gráfica

A coleção de use cases deverá especificar
todas as formas existentes de uso do
sistema.
Matricular aluno
Use Case
Solicitar
histórico
Verificar
pré-requisitos
Use Case



Use Case
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 Case inclue:


Uma linha de comportamento normal em
resposta a um pedido do usuário
Possíveis variantes da sequência normal,
tais como:
– sequências alternativas,
– comportamento excepcional e
– tratamento de erro.
Use Case
Atores



Use Case
O sistema será descrito através de vários use
cases que são executados por um número de
atores
Atores constituem as entidades do ambiente
do sistema
São pessoas ou outros subsistemas que
interagem com o sistema em
desenvolvimento
Atores
<<Agente>>
Coordenador
Secretária
Sistema de controle
de pre-requisitos
Use Case
Professora
Estudante
Atores: Especialização

É possível definir tipos gerais de
atores e especializá-los usando o
relacionamento de especialização
Cliente
Use Case
ClienteEspecial
Diagramas de Use Case

Use Case
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 Case
Sistema de controle
de pre-requisitos
Exemplo (máquina de reciclar)
Use Case
Um sistema de software é desenvolvido para controlar um
máquina para reciclar garrafas, latas e gradeados.
– A máquina poderá ser usado por vários usuários ao
mesmo tempo.
– Cada usuário poderá retornar os três tipos de ítem 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ários.
– 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).
Use Case
– 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.
Atores



Use Case
Primeiro é preciso identificar os usuários do
sistema, que serão chamados de atores.
Um ator é um tipo ou categoria de usuário.
Um ator poderá representar um pessoa ou
outro sistema interagindo com o sistema a
ser desenvolvido.
Atores e seus papéis




Use Case
Uma pessoa pode instanciar (fazer o papel)
de diferentes atores
Atores definem os papéis que os usuários
podem fazer
Atores modelam qualquer coisa que precise
trocar informações com o sistema.
Atores podem modelar usuários humanos
mas também podem modelar outros
sistemas que se comunicam o sistema em
desenvolvimento
Identificação de Atores



Atores são externos ao sistema
Para a identificação de todos os atores
de um sistema poderá ser necessário
várias iterações.
Diretrizes:
– Pergunte a você próprio por que o
sistema está sendo desenvolvido?
– Quem serão as pessoas que o sistema
ajudará?
Use Case
Identificação de Atores

Diretrizes:
– Quais serão os outros sistemas que precisarão
interagir com o novo sistema?
– Agentes que usam o sistema diretamente (ou
seu trabalho diários) são chamados de Atores
Principais
– Agentes principais estão associados com uma
ou mais tarefas do sistema
Use Case
Identificação de Atores


Atores que estão relacionados com a
supervisão e manutenção do sistema são
chamados de agentes secundários
Atores do sistema de reciclagem :
– O cliente
– O operador

Use Case
Eles são entidades do ambiente do sistema,
que interagem com ele.
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 Case
Papéis


Use Case
Atores além de pessoas ou subsistemas,
podem ser papéis desempenhados por uma
mesma pessoa, ou subsistema.
No exemplo, ocasionalmente o operador
poderá depositar suas próprias garrafas na
máquina. Neste caso ele atuará no papel de
cliente.
Use Cases do Sistema de
Reciclagem



Use Case
Após identificação dos agentes 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 Case
Primeiro passo, examinar os requisitos
do ponto de vista dos usuários.
Perguntas úteis;
– Quais são as principais tarefas de cada
ator?
– O ator precisa ler/escrever/modificar
alguma informação do sistema?
– O ator precisará informar ao sistema as
mudanças ocorridas no exterior?
– O ator quer ser informado sobre
mudanças inesperadas?
Use Cases do Sistema de
Reciclagem

Cliente
– Deve ser capaz de retornar items (latas,
garrafas). O use case será Retornar item .
– Este use case deverá incluir todos os
eventos até o recibo ser emitido.
Use Case
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 Case
Descrições do Use case

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 Case
Descrições do Use case

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á inciado pelo operador para modificar a
informação do item no sistema. Ele será capaz
de alterar o valor a ser pago pelo item.
Use Case
Diagrama de Use Case
Gerar Relatório
Retornar Item
Cliente
Use Case
Mudar Item
Operador
Expressão de variantes de
use case

Nem sempre é óbvio decidir se uma
funcionalidade corresponde a um novo
use cases. As 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 Case
Expressão de variantes de
use case

Fluxo principal de eventos
– Descreva a sequência normal de eventos de um
use case.

Fluxo excepcional de eventos
– Descreva as variações dos cursos básicos de
eventos (ex. Erros).
Use Case
Expressão de variantes

Use Case
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 Case
Organizando Use Cases



Use Case
Generalização
Inclusão
Extensão
Generalização de Use Case




Use Case
Relaciona um Use Case especializado a um
mais geral
O filho herda os atributos, operações e
sequê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 Case
O use case filho pode adicionar
comportamento incremental através da
inserção de sequências adicionais de ações
em pontos arbitrários da sequência do pai
Pode modificar alguma das operações e
sequências herdadas (cuidado!!)
Relacionamentos de inclusão e extensão do
use case filho também modificam o use case
do pai
Generalização de Use Cases



Use Case
É possível abstrair comportamentos de
use cases. Nomalmente 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
Use Case
Checar password
Scan da retina
Inclusão de use cases



Use Case
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
<<inclue>>
Identificar
Cliente
Use Case
use case base
(cliente)
<<inclue>>
Validar Conta
use case incluído
(servidor)
Use Case: Sessão de ATM
mostre anúncio do dia
inclue Identificar Cliente
inclue Validar Conta
imprimir cabeçalho do recibo
log out
Use Case de Inclusão: Identificar Cliente
pegue o nome do cliente
inclue Verificar Identidade
if falha de verificação then abort a sessão
obtenha número da conta do cliente
Use Case
Use Case de Inclusão: Validar Conta
estabeleça conexão com banco de dados de contas
otenha status e limite da conta
Inclusão de Use Case : Def.

Use Case
Inclusão da sequência de comportamento do
use case servidor na sequê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 Case
Descreve uma sequência adicional de
comportamento que será inserida na
instância de use case que está executando o
use base base
O mesmo use case de inclusão pode ser
inserido em múltiplos use case base
A inclusão representa comportamento
encapsulado que potencialmente poderá ser
reusado em outros use case base
Inclusão de use case:
Avançado




Use Case
O use case base (cliente) não poderá acessar os
atributos do use case de inclusão (servidor)
O use case de inclusão (servidor) poderá acessar
atributos e operações use case base (cliente), para
obter valores e comunicar resultados
Os valores dos atributos do use case de inclusão
(servidor) não persistem entre execuções
A inclusão é executada apenas uma vez
Extensão de use case


Use Case
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 Case
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 Case
Extensão de use case

Usado para modelar extensão de outros
use cases completos:
– Para modelar partes opcionais de use cases
– Para modelar cursos alternativos e
complexos que raramente ocorrem, como
Item Preso
– Para modelar sub-cursos que são executados
somente em certos casos
Use Case
Extensão de use case


Use Case
Para modelar 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)
<<inclue>>
Validar
usuário
Use Case Fazer Pedido
Use Case
Fluxo principal de eventos: inclue (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
abortável
Use Case
Use Case: Sessão de ATM
mostre anúncio do dia
----inclue Identificar Cliente
! uma região <abortável>
inclue Validar Conta
!
(ponto de extensão aqui) < --!---- < transação possível>
imprimir cabeçalho do recibo -!
(outro ponto de extensão) < -------- <detalhes do recibo>
log out
Extensão de use case:
Avançado


Use Case
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 sequência do
segmento de extensão. Quanto terminada, o
controle volta para o use case original
Extensão de use case:
Avançado


Use Case
A extensão implicitamente modifica o
comportamento do use case base
Os efeitos da do use case de extensão são
adicionados aos efeitos do use case base
quando da sua instanciação
Extensão de use case:
Avançado



Use Case
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
Se não há condição se assume que ela é
verdadeira
A extensão poder ser executada mais de
uma vez, se a condição permanecer
verdadeira
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 Case
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 Case
Dicas: Modelando o Contexto
do Sistema

Use Case
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 Case
Organize os atores que são similares em
uma hierarquia de generalização /
especialização.
Quando ajudar a compreensão, faça um
esterió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 Case

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
De um nome aos comportamentos comuns
(Usecase)
Fatore comportamentos comuns em novos
use cases que serão usados por outros
Dicas: Modelando Requisitos
do Sistema



Use Case
Fatore comportamento variante em novos
use cases que estendem a 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).