Casos de Uso e Cenários
Engenharia de Requisitos
UFPE - Centro de Informática
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
1
Roteiro
1.
2.
3.
4.
5.
6.
7.
8.
Introdução
Casos de Uso
Cenários
Estudo de Caso
Boas práticas
Casos de uso ágeis
Teoria e Prática
Conclusão
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
2
Casos de uso detalham desejos dos usuários
finais, não as tarefas dos programadores
• 1980’s: Vamos escrever requisitos como características!
 Usuários não entendem...
pressão do usuário para escrever como casos de uso.
• 1990’s: Vamos escrever requisitos em casos de uso!
 Programadores trabalham de acordo com
características, não casos de uso...
Pressão do programador para escrever como
características.
• 2000: Então vamos escrever requisitos como
características!
 FDD e estórias de usuário do XP...
Perde-se novamente a experiência do usuário final.
Pêndulo das características vs. casos de uso
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
3
Definição de Caso de Uso
• Um caso de uso é uma descrição narrativa de uma
seqüência de eventos que ocorre quando um ator
(agente externo) usa um sistema para realizar uma
tarefa[Jacobson 92]
• Uma unidade coerente de funcionalidade provida por
um sistema, manifestada por uma seqüê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.
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
4
Objetivos dos Casos de Uso
• Descrever a funcionalidade do sistema (Requisitos
Funcionais)
• Mapear o escopo do sistema, onde explicita a fronteira
do sistema.
• Facilitar a comunicação com usuário do sistema.
• Gerenciar o projeto.
• O RUP o utiliza para guiar todo processo de
desenvolvimento
• Mostram apenas o que o sistema faz, e não como.
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
5
Caso de uso: representação gráfica
Uma elipse com o nome do caso de uso no centro
Nome = Verbo + Substantivo (indicação de ação)
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
6
Ponte entre Requisitos e Análise
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
7
Ator
• Constituem as entidades que interagem com o
ambiente do sistema
o Pessoas ou outros sistemas (de hardware ou
software) que interagem com o sistema em
desenvolvimento
• Definem um papel particular (uma mesma entidade
pode desempenhar diferentes papéis)
• São sempre externos ao sistema
• O sistema será descrito através de vários casos de uso
que são executados por um número de atores
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
8
Ator: representação gráfica
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
9
Diagramas de Caso de Uso
• Introduzida por Jacobson em 1994 para visualização dos
casos de uso
• Esse diagrama é parte da UML
• Mostram um conjunto de casos de uso, atores e seus
relacionamentos
• Indicam a forma como o sistema interage com as
entidades externas
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
10
Diagrama de Caso de Uso : representação gráfica
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
11
Como encontrar atores?
•
•
•
•
•
•
Quem usa o sistema?
Quem instala/mantém o sistema?
Quem inicia/desliga o sistema?
Que outros sistemas usam o sistema?
Quem recebe informação do sistema?
Quem provê informação ao sistema?
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
12
Como encontrar casos de uso?
• 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 desses eventos?
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
13
Fluxo de Eventos
• Especifica o comportamento de um caso de uso
• É uma seqüência de comandos declarativos que
descreve as etapas de execução de um Caso de Uso
• Permanece focado no domínio do problema e não em
sua solução
• Pode conter testes condicionais e iterações
• Contém informações relativas:
 Às condições de início e término do caso de uso
 Quais os atores interessados no sistema
 Como o caso de uso interage com esses atores
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
14
Fluxo de Eventos
• O fluxo de eventos de um caso de uso é composto por:
 Um Fluxo Básico - descreve a funcionalidade
principal do caso de uso, quando nenhum desvio é
tomado
 Zero ou Mais Fluxos Alternativos - descrevem
desvios pré-definidos do fluxo básico
• Esses fluxos podem ser especificados através de:
 Descrição textual informal
 Texto semi-formal (através de pré-, pós-condições e
invariantes)
 Pseudo-código
 Ou uma combinação destes
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
15
Exemplo (Fluxo Básico do caso de uso Comprar
Produtos)
Descrito em pseudo-código:
1.
O cliente chega ao ponto de vendas com os produtos da compra
2.
Para cada produto trazido pelo cliente:
a) O atendente registra o código e a quantidade do produto
b) O sistema determina o preço do produto e o adiciona à
compra
3. O atendente finaliza a compra
4.
O sistema calcula e apresenta o total
5. O atendente informa ao cliente sobre o total da compra e
pergunta qual a forma de pagamento
6. Se (dinheiro) forma de pagamento = “dinheiro”
7. O atendente registra a quantia recebida
8. O sistema mostra o troco e gera o recibo
9. O atendente deposita o dinheiro, devolve o troco e entrega o
recibo de compra
10. O sistema registra o final da transação
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
16
Exemplo (Fluxos Alternativos de Eventos)
Descrições textuais:
1. No passo 2 do fluxo básico, pode haver um produto
com um código inválido. Nesse caso, o sistema
avisará que o código fornecido é inválido e pede que
o atendente registre o próximo produto. Vá para o
passo 2 do fluxo básico.
2. No passo 6, o cliente pode escolher pagar com cartão
de crédito ou débito.Neste caso, o atendente passa o
cartão e o cliente digita a senha.Se houver, vá para o
passo 6 do fluxo básico.
3. A qualquer momento, o atendente pode cancelar a
transação. Nesse caso, as informações referentes à
compra são descartadas.
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
17
Cenários
• Em UML significa um caminho através de um caso de
uso.
• Uma instância de um caso de uso
• Seqüência de passos que descreve uma interação
• Exemplo (Sacar dinheiro):
 Saque com sucesso
 Tentativa de saque MAS senha incorreta
 Tentativa de saque MAS saldo insuficiente
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
18
Casos de Uso x Cenários
• Um caso de Uso não é um cenário, mas pode
encapsular um conjunto de cenários
• Cada cenário é uma instância de um caso de uso
• Para cada caso de uso temos, no mínimo, um cenário
para o fluxo normal (cenário principal) e outros para
cada fluxo excepcional (cenários secundários).
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
19
Formato de Documentação de Casos de Uso
• Não existe um padrão comum na indústria ou na
literatura para sua formatação
• Deve-se incluir informações que facilitem a
comunicação entre os clientes e a equipe de
desenvolvimento do sistema
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
20
Formato de Documentação de Casos de Uso
(Modelo mais usado)
•
•
•
•
•
•
•
Nome do Caso de Uso
Breve descrição
Ator (principal)
Prioridade (ex: Essencial, Importante, Desejável)
Pré-Condições
Pós-Condições
Fluxo de eventos:
 Fluxo de evento principal
 Fluxos secundários: alternativos e de exceção
• Requisitos Não-Funcionais Específicos
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
21
Relacionamento entre casos de uso
• Os casos de uso podem ser organizados por meio de
relacionamentos
• A UML disponibiliza três tipos:
 generalização
 inclusão
 extensão
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
22
Generalização
• É um relacionamento de generalização/especialização
• Os casos de uso especializados herdam a estrutura do
caso de uso generalizado
• O supertipo contém cenários mais especializado,
particular a cada um deles
• Os subtipos contém cenários mais especializados,
particular a cada um deles
• Os cenários comuns a mais de um caso de uso é adaptado
em um caso de uso generalizado
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
23
Generalização
• Quando usar?
Quando você estiver descrevendo comportamentos
semelhantes entrecasos de uso, mas algum deles faz
um pouco mais que o outro.
Exemplo:
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
24
Inclusão
• Um caso de uso incorpora explicitamente o
comportamento de outro caso de uso, evitando assim
repetições de descrição de fluxos.
• O cenário comum a mais de um caso de uso é captado em
um outro
 concentra o serviço em um caso de uso base a ser
utilizados por outros
 evita-se descrever a mesma seqüência de passos a
vários casos de uso
• Utiliza o estereótipo <<include>> para expressar esse tipo
de relacionamento
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
25
Inclusão
• Quando usar?
Quando houver repetição entre casos de uso e você
desejar evitar esta repetição
Exemplo:
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
26
Extensão
• É usado para descrever cenários opcionais de um caso
de uso
 os casos de uso descrevem cenários que sempre
acontecerão no sistema
 os casos de uso estendidos ocorrerão em uma
situação específica
 concentra-se essa seqüência em um caso de uso
público
• Utiliza o estereótipo <<extend>>para expressar esse tipo
de relacionamento
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
27
Extensão
• Quando usar?
Quando quiser descrever uma variação do comportamento
normal.
•
partes opcionais de casos de uso
• cursos alternativos e complexos que raramente ocorrem
Exemplo:
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
28
Fluxo de Requisitos no RUP
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
29
Atividades e Responsáveis
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
30
Localizar Atores e Casos de Uso
• Objetivos
 Delimitar o sistema
 Destacar os atores que irão interagir com o
sistema
 Destacar os casos de uso do sistema
 Definir glossário com os principais termos
• Processo
 Identificar os Atores
 Identificar Casos de Uso
 Descrever Caso de Uso de forma resumida
 Criar Diagramas de Caso de Uso
 Descrever os diagramas (Descrição Analítica)
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
31
Priorizar os Casos de uso
• Objetivos
 Definir em quais iterações os Casos de Uso serão
desenvolvidos
 Definir quais Casos de Uso participarão da visão
arquitetural do Modelo de Caso de Uso
• Processo
 Identificar os Casos de Usos com mais riscos e os
mais significantes
 Alimentar a Visão Arquitetural dos diagramas de
Caso de Uso, com os casos de usos mais importantes
 Alocar os Casos de Uso as iterações definindo suas
prioridades dentro de cada uma delas.
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
32
Detalhar Casos de Uso
• Objetivos
 Descrever o fluxo de eventos de cada caso de uso
• Processo
 Entrevistar os usuários (atores) que estão
relacionados com cada um dos casos de uso
 Descrever detalhadamente os passos que compõem
o fluxo de evento do use case (Cada passo deve ter
um objetivo claro)
 Revisar o detalhamento do caso de uso com os
usuários
 Refinar a descrição dos casos de uso
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
33
Estruturar o Modelo de Caso de Uso
• Objetivos
 Otimizar o modelo de caso de uso
• Processo
 Identificar descrições de funcionalidades comuns.
– Extrair tais funcionalidades e criar um use case mais
específico que possa ser usado pelos demais <<include>>.
 Reuso de use cases
– Herança(<<Generalization>>) ou Factoring(<<include>>)
entre casos de uso.
 Identificar descrições de funcionalidades adicionais ou
opcionais.
 Extrair as extensões adicionais ou opcionais para um use
case mais específico <<extend>> Ex:Condições, Erros,
Alternativas
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
34
Valor dos casos de uso
• A lista de objetivos permite aos executivos:
 Pequenos sumários sobre contribuições do sistema
 Planejamento do projeto (prioridades e tempos)
• O cenário principal provê a todos:
 Acordo com as responsabilidades do sistema
• Fluxos alternativos das condições oferece aos programadores:
 Lista de coisas que os programadores precisam ficar atentos
 Lista de coisas que os analistas precisam investigar
• Controle de fluxos alternativos permite a equipe de
desenvolvimento:
 Avaliar (complexas) regras e decisões de negócios
• O caso de uso completo permite a equipe de desenvolvimento:
 Avaliar completude da funcionalidade requisitada
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
35
Casos de uso (pontos fortes e fracos)
Pontos fortes
• Casos de uso permitem escrever os requisitos
funcionais de forma fácil de ler.
2. Permitem avaliar necessidades de requisitos nãofuncionais e definição de calendário do projeto.
Pontos fracos
1. Casos de uso mostram apenas requisitos funcionais.
2. Planejamento não pode ser feito somente com casos
de uso.
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
36
Bons casos de uso ...
• Comunicam em uma linguagem entendível independente
de especialidades
• Descrevem aquilo que o sistema fará
 Contrato com todos os stakeholders sobre o
comportamento do sistema
• Registram decisões
• Permitem validação de “completude”
• Contextualizam requisitos
• Permitem identificação de itens que precisam ser
pesquisados
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
37
A parte difícil dos casos de uso não é escrever,
mas pensar e concordar.
• ~ 3 dias de construção
 ~ 2 horas de digitação
 O restante pensando e discutindo sobre regras
Perguntas para validação dos casos de uso
1. Cada passo está correto?
2. Existem responsabilidades do sistema entre os passos?
3. Existe algum sistema externo que este sistema deve
usar?
4. Algum outro stakeholders foi desconsiderado?
5. Todos os fluxos alternativos foram pensados?
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
38
Casos de uso ágeis (use cases agile-ly)
• Metodologia desenvolvida por Alistair Cockburn
 Casos de uso
 Metodologia ágil
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
39
Desenvolvimento de software ágil
• Valores:
 Indivíduos e Interações acima de Processos e
Ferramentas.
 Software funcionando acima de Documentação
compreensível.
 Colaboração do cliente acima de Negociações de
contrato.
 Resposta a mudanças acima de Planejamento
exatamente executado.
• Oferecer freqüentemente pequenas partes usáveis de
software ao cliente
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
40
Escrevendo casos de uso ágeis
1. Identifique os atores e seus objetivos
Resultado: lista de atores e casos de uso
Valor: visão geral do sistema (bom para priorização e estimar)
2. Escreva casos de uso simples de acordo com cada objetivo
Resultado: descrições das funcionalidades do sistema
Valor: alinhamento da equipe com as responsabilidades do
sistema
3. Determine as condições que precisam de fluxos alternativos
Resultado: lista de cenários alternativos para estudar quando
necessário
Valor: Permite programadores iniciarem trabalhos
4. Escreva os fluxos alternativos até terminar ou voltar ao fluxo
principal
Resultado: Caso de uso completo
Valor: regras de negócios detalhadas para programadores e
testadores
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
41
Casos de uso ágeis
• Incrementos, just-in-time, comunicação próxima
• Escreve-se conteúdo suficiente para planejar o necessário
 Longo prazo: Nomes dos casos de uso e descrição
 Curto prazo: Casos de uso completos
• Escreve-se conteúdo suficiente para a equipe entender
 Programadores entendem decisões do sistema
 Mostrar casos de uso e sistema para usuários e recebe
feedback
• Ajusta-se forma de trabalho a cada interação adaptando
para cada situação particular
• Sempre questionar quanto gastará para detalhar mais
 Quanto? Quando precisa? Qual a forma mais rápida?
Quem se beneficiará com mais detalhes?
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
42
Casos de uso ágeis
• Escrever pouco, mais claramente (sempre)
Agile use cases
•Text
•No GUI
•No data formats
•3 - 9 steps in main scenario
•Easy to read
•At user’s goal level
•Record of decisions made
Common use cases
•UML use case diagrams
•describing the GUI
•describing data formats
•multiple-page main scenario
•complicated to read
•at program-feature level
•tutorial on the domain
 Mais curto, econômico e fácil de ler
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
43
Casos de uso ágeis
• Escrever menos (as vezes)
 Depende das prioridades e características do projeto
Casos de uso completamente detalhados
Parágrafos descritivos
Pequenas descrições (1-2 frases)
• Reduzir estruturas dos casos de uso (as vezes)
 Não são lidos por compiladores, mas por humanos
 Adapte-os as necessidades da equipe
• Detalhar depois, adiantar o processo (quase sempre)
Casos de uso podem ser escritos
Todos no início
Cada um até o final
ou
ou
just-in-time
com incrementos usáveis
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
44
Animação de Cenários
• Técnica de validação de requisitos
 Combinação de objetivos e cenários
• Modelos e comportamentos da aplicação
 Estados do cenário até alcançar objetivo
• Especificações executadas como um filme
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
45
Animação de cenários
• Interação entre componentes para chegar ao objetivo
©Álvaro Palitot, Everton Marques, Guilherme Carvalho e João Kuae.
46