Casos de Uso

1
Slides extraídos do livro:
Princípios de Análise e
Projeto Orientados a
Objetos com UML
Eduardo Bezerra

Editora CAMPUS
Com adaptações feitas pelo professor

2
Antes de fazer, decida
o que você quer
fazer.

3
Introdução
 O modelo de casos de uso é uma
representação
 das funcionalidades externamente observáveis do
sistema
 e dos elementos externos ao sistema que
interagem com o mesmo.

 O modelo de casos de uso modela os

requisitos funcionais do sistema.

4
 Introdução
 O diagrama da UML utilizado na modelagem
de casos de uso é o diagrama de casos de
uso.
 Técnica de modelagem idealizada por Ivar
Jacobson, na década de 1970.
 Mais tarde, incorporada ao método
Objectory.
 Posteriormente, a notação de casos de uso
foi adicionada à UML.

5
Introdução
O modelo de casos de uso força os
desenvolvedores a moldar o sistema de
acordo com o usuário.

6
Componentes do modelo
 O modelo de casos de uso de um sistema é
composto de:
 Casos de uso
 Atores
 Relacionamentos entre os elementos anteriores
 Relacionamentos podem ser de:
 Generalização
 Associação

7
Casos de uso
 Um caso de uso
 é a especificação de uma seqüência de interações
entre um sistema e os agentes externos.
 é uma seqüência de ações que um sistema
executa para produzir um resultado de valor
observável por um ator
 Define parte da funcionalidade de um sistema
 sem revelar a estrutura e o comportamento
internos deste sistema.
 Um modelo de casos de uso típico é formado
de vários casos de uso.
8
Casos de uso

Um caso de uso representa quem

faz o que (interage) com o sistema,
sem considerar o comportamento
interno do sistema.

9
Descrições narrativas
 Cada caso de uso é definido através da
descrição narrativa das interações que
ocorrem entre o(s) elemento(s) externo(s) e o
sistema.

10
Exemplo de descrição contínua
 O Cliente chega ao caixa eletrônico e insere
seu cartão. O Sistema requisita a senha do
Cliente. Após o Cliente fornecer sua senha e
esta ser validada, o Sistema exibe as opções
de operações possíveis. O Cliente opta por
realizar um saque. Então o Sistema requisita
o total a ser sacado. O Sistema fornece a
quantia desejada e imprime o recibo para o
Cliente.

11
Exemplo de descrição numerada
1. 1. Cliente insere seu cartão no caixa
eletrônico.
2. 2. Sistema apresenta solicitação de senha.
3. 3. Cliente digita senha.
4. 4. Sistema exibe menu de operações
disponíveis.
5. 5. Cliente indica que deseja realizar um
saque.
6. 6. Sistema requisita quantia a ser sacada.
7. 7. Cliente retira a quantia e recibo.
12
 Exemplo de descrição numerada

Cliente Sistema
Insere seu cartão no caixa
eletrônico. Apresenta solicitação de senha.

Digita senha. Exibe operações disponíveis.

Solicita realização de saque. Requisita quantia a ser sacada.

Retira a quantia e o recibo.

13
Detalhamento
 O grau de detalhamento a ser utilizado na
descrição de um caso de uso também pode
variar.
 Um caso de uso sucinto descreve as interações
sem muitos detalhes.

 Um caso de uso expandido descreve as

interações em detalhes.

14
Cenários
 Um caso de uso tem diversas maneiras de
ser realizado.
 Um cenário é a descrição de uma das
maneiras pelas quais um caso de um pode
ser realizado.
 Um cenário também é chamado de instância
de um caso de uso.
 Normalmente há diversos cenários para um
mesmo um caso de uso.

15
Cenário Principal
 Descreve um seqüência de ações que serão executadas considerando que nada de
errado ocorrerá durante a a execução da seqüência.

 É o cenário perfeito

16
 Cenário Principal
Trecho do caso de uso
“Emitir Saldo em um terminal de caixa eletrônico”
Ator: Correntista
1. O sistema faz a leitura do cartão magnético.
2. O sistema solicita a digitação da senha.O correntista informa sua
senha.
3. O sistema valida a senha, verificando se é a mesma senha que
está associada ao correntista.
4. O correntista seleciona a opção de saldo
5. O sistema questiona o tipo de saldo: conta corrente, poupança,
investimentos
6. O sistema processa e mostra o saldo solicitado pelo cliente
etc 17
Cenários
 O mundo não é perfeito, muito menos as
Cenário Perfeito: transações de um sistema. Então, como
podemos representar as exceções?

É impossível tudo
ocorrer sem
problemas !

Desenvolver os
Cenários Alternativos !
18
Cenários Alternativos
 Permite uma seqüência diferente de eventos
em relação ao cenário principal
 Para cada um destes cenários atípicos será
definido o fluxo de eventos correspondente.
 São os casos onde podem ocorrer exceções,
erros ou qualquer outra ação possível e
diferente.

19
Cenários Alternativos
 1. O sistema faz a leitura do cartão magnético

 Alternativa: Problemas na leitura do cartão

magnético
 1a) Se o sistema não conseguir ler os dados
do cartão magnético, tentar novamente por,
no máximo, mais duas vezes. Caso persista
o problema, encerrar o caso de uso.

20
Atores
 Elemento externo que interage com o sistema.
 “externo”: atores não fazem parte do sistema.
 “interage”: um ator troca informações com o sistema.
 Casos de uso representam uma seqüência de
interações entre o sistema e o ator.
 no sentido de troca de informações entre eles.
 Normalmente um agente externo inicia a
seqüência de interações como o sistema, ou um
evento acontece para que o sistema responda.

21
Atores
 Categorias de atores:
 pessoas (Empregado, Cliente,
Gerente, Almoxarife, Vendedor, etc);
 organizações (Empresa Fornecedora,
Agência de Impostos, Administradora
de Cartões, etc);
 outros sistemas (Sistema de
Cobrança, Sistema de Estoque de
Produtos, etc).
 equipamentos (Leitora de Código de
Barras, Sensor, etc.)

22
Atores
 Um ator corresponde a um papel
representado em relação ao sistema.

 O mesmo indivíduo pode ser o Cliente que

compra mercadorias e o Vendedor que processa
vendas.

 Uma pessoa pode representar o papel de

Funcionário de uma instituição bancária que
realiza a manutenção de um caixa eletrônico, mas
também pode ser o Cliente do banco que realiza o
saque de uma quantia.

23
Atores
 O nome dado a um ator deve lembrar o seu
papel, ao invés de lembrar quem o
representa.

 Um ator pode participar de muitos casos de

uso.

 Um caso de uso pode envolver vários atores

24
Identificação dos elementos
do modelo de casos de uso
25
Identificação dos elementos do modelo
de casos de uso
 Os atores e os casos de uso são identificados
a partir de informações coletadas na fase de
levantamento de requisitos do sistema.
 Durante esta fase, os analistas devem identificar as
atividades do negócio relevantes ao sistema a ser
construído.
 Não há uma regra geral que indique quantos
casos de uso são necessários para descrever
completamente um sistema.
 A quantidade de casos de uso a ser utilizada
depende completamente da complexidade do
sistema.
26
Identificação de atores
 Fontes e os destinos das informações a serem
processadas são atores em potencial.
 uma vez que um ator é todo elemento externo que interage
com o sistema.
 O analista deve identificar:
 as áreas da empresa que serão afetadas ou utilizarão o
sistema.
 fontes de informações a serem processadas e os destinos
das informações geradas pelo sistema.

27
Identificação de atores
 Perguntas úteis:
 Que órgãos, empresas ou pessoas irão utilizar o
sistema?
 Que outros sistemas irão se comunicar com o
sistema a ser construído?
 Alguém deve ser informado de alguma ocorrência
no sistema?
 Quem está interessado em um certo requisito
funcional do sistema?
 O desenvolvedor deve ainda continuar a
pensar sobre atores quando passar para a
identificação dos casos de uso.

28
Identificação de casos de uso
 A partir da lista (inicial) de atores, deve-se
passar à identificação dos casos de uso.

 Nessa identificação, pode-se distinguir entre

dois tipos de casos de uso
 Primário: representa os objetivos dos atores.
 Secundário: aquele que não traz benefício direto
para os atores, mas que é necessário para que
sistema funcione adequadamente.

29
Casos de uso primários
 Perguntas úteis:
 Quais são as necessidades e objetivos de cada ator
em relação ao sistema?
 Que informações o sistema deve produzir?
 O sistema deve realizar alguma ação que ocorre
regularmente no tempo?
 Para cada requisito funcional, existe um (ou mais)
caso(s) de uso para atendê-lo?
 Outras técnicas de identificação:
 Caso de uso que precede a outro caso de uso.
 Caso de uso relacionado a uma condição interna.
 Caso de uso que sucede a outro caso de uso.
 Caso de uso temporal.

30
Casos de uso secundários
 Estes se encaixam nas seguintes categorias:
 Manutenção de cadastros.
 Manutenção de usuários.
 Manutenção de informações provenientes de
outros sistemas.
 Importante: Um sistema de software não
existe para cadastrar informações, nem
tampouco para gerenciar os seus usuários.
 O objetivo principal é produzir algo de valor para o
ambiente no qual ele está implantado.
31
Casos de Uso

Trabalhando com um caso real

Sistema de Contas a Pagar

32
Casos de Uso

No levantamento Desejo um pequeno sistema que

controle minhas contas a pagar.
de dados ... Deve emitir relatórios gerais ou
por tipo de conta, para contas
vencidas e a vencer.
No futuro, gostaria de total
integração desse sistema com
um conjunto de outros sistemas
que vou pedir, além de
exportação e importação de
arquivos para Palm.

33
Casos de Uso

Pensando nos Casos de Uso ...

Quais são os atores ?

Micro-Empresário Secretária

34
Casos de Uso

Existe relacionamento
entre os atores?

herda de

Micro-Empresário Secretária

Veremos isto com mais calma nas próximas aulas 35

Casos de Uso

Quais as responsabilidades
de cada ator ?
* Secretária:
- Relatório de contas a vencer
- Relatório de contas vencidas
- Cadastrar tipo de conta

36
Casos de Uso

Quais as responsabilidades
de cada ator ?
* Micro-empresário:
todas as tarefas da Secretária +
- Lançar conta a pagar
- Registrar pagamento de conta
- Emitir extrato de lançamentos por período

37
 Casos de Uso
 Descrição dos Casos de Uso

. Cenário Principal
fluxo perfeito, no qual nada ocorre de errado

. Cenários Alternativos
alternativas do fluxo ; exceções

38
 Casos de Uso
Caso de Uso Lançar Conta a Pagar
. Cenário Principal
Ator: Micro-empresário
1. O usuário informa um tipo de conta.
2. O sistema busca e exibe a descrição do tipo de
conta.
3. O usuário informa:
3.1. data de vencimento
3.2. descrição da conta
3.3. valor total a pagar
3.4. valor parcial a pagar 39
 Casos de Uso
. Cenários Alternativos
... 2. O sistema busca e exibe a descrição
do tipo de conta ...

Tipo de
Relacionamento
entre Casos de Uso
Tipo de Conta Inexistente
3a. Se o tipo de conta não existir, carregar a
consulta de tipos de contas. Extends (Consultar
tipos de contas).
40
 Exercícios

41
Exercício
 Caso de uso
 Escreva um caso de uso que mostre uma
solicitação de reserva em um restaurante.

42
 Caso de Uso:

 Ator:

 Cenário principal
 1....

 Cenários Alternativos

43
Diagrama de casos de uso

44
Diagrama de casos de uso (DCU)
 Representa graficamente os atores, casos de
uso e relacionamentos entre os elementos.
 Tem o objetivo de ilustrar em um nível alto de
abstração quais elementos externos
interagem com que funcionalidades do
sistema.
 Uma espécie de “diagrama de contexto”.
 Apresenta os elementos externos de um sistema
e as maneiras segundo as quais eles as utilizam.
 Todo diagrama de casos de uso tem pelo
menos um ator

45
Relacionamentos
 Casos de uso e atores não existem sozinhos.
Pode haver relacionamentos entre eles.

 A UML define diversos tipos de

relacionamentos no modelo de casos de uso:
 Comunicação
 Associação
 Inclusão
 Extensão
 Generalização
 VEREMOS MAIS ADIANTE

46
Notação
 A notação para um ator em um DCU é a
figura de um boneco
 com o nome do ator definido abaixo desta figura.
 Cada caso de uso é representado por uma
elipse.
 O nome do caso de uso é posicionado abaixo ou
dentro da elipse.
 Um relacionamento de comunicação é
representado por um segmento de reta
ligando ator e caso de uso.
 Pode-se também representar a fronteira do
sistema em um diagrama de casos de uso.
47
Relacionamentos de Comunicação
 É a relação de um ator com o caso de uso
com o qual ele está interagindo.

 É representada por uma linha sólida que

conecta o símbolo de ator ao símbolo de
caso de uso.

48
Exemplo (Notação)
Ator
Caso deuso

Reservar Livro

Usuário
Relacionamento
decomunicação

49
 Exemplo (Notação)

 Ator: é alguém ou alguma coisa que interage com

o sistema
 Um ator é representado graficamente por um ícone de
um “homenzinho” (stickman)

50
Exemplo (Notação)
Sistema de Vendas de
Livros por Correio

Vendedor

Realizar Pedido

Cliente

Empresa Transportadora

51
Relacionamentos
 Casos de uso e atores não existem sozinhos.
Pode haver relacionamentos entre eles.

 A UML define diversos tipos de

relacionamentos no modelo de casos de uso:
 Comunicação
 Associação
 Inclusão
 Extensão
 Generalização

52
Relacionamentos de Comunicação
 É a relação de um ator com o caso de uso
com o qual ele está interagindo.

 É representada por uma linha sólida que

conecta o símbolo de ator ao símbolo de
caso de uso.

53
Relacionamento de Inclusão
 É uma simples relação de inclusão, ou seja, os
cenários ou situações possíveis detalhados em um
caso de uso estão incluídos em outro caso de uso.

 Quando dois ou mais casos de uso têm

comportamento comum - uma seqüência comum
de interações - esse comportamento pode ser
modelado ou descrito em um caso de uso separado,
que é utilizado por outros casos.

54
Relacionamento de Inclusão
 Na elaboração de um sistema é comum que
a mesma funcionalidade do sistema seja
acessada por vários casos de uso.

 Por exemplo, a funcionalidade de “Validar

Cliente” pode ser acessada quando:
 um novo cliente estiver sendo cadastrado;
 um novo pedido estiver sendo feito; ou
 uma consulta dos pedidos de um cliente for
solicitada, etc.
55
Relacionamento de Inclusão
 Esta relação serve para evitar a repetição
deste caso de uso nos outros casos de uso,
onde é necessário também “Validar Cliente”.

 Podemos ler da seguinte maneira: o caso de

uso “Consultar pedidos de um cliente” usa o
caso de uso “Validar Cliente”.

 Além disso, o roteiro de um caso de uso pode

ser alterado por outro caso de uso.
56
Relacionamento de Inclusão
 Este conceito não é novo, podendo ser
comparado ao conceito de sub-rotina ou
subprograma e estas são algumas
características das relações de uso:
 Aparecem como funcionalidade comum ao invés
de especificar vários casos de uso;
 Os casos <<include>> usados são casos de uso
por si só, isto é, existem primariamente como um
caso de uso;
 O caso de uso <<include>> é usado sempre que o
caso de uso principal é executado. Isto faz a
diferença com as extensões, que são opcionais.
57
 Criar Pedido

<<inclui>>

Validar Pedido
Cliente
<<inclui>>

Alterar Pedido

58
Relacionamento de extensão
 Utilizado para modelar situações onde
diferentes seqüências de interações podem
ser inseridas em um caso de uso.

 Sejam A e B dois casos de uso.

 Um relacionamento de extensão de A para B
indica que um ou mais dos cenários de B podem
incluir o comportamento especificado por A.
 Neste caso, diz-se que B estende A.
 O caso de uso A é chamado de estendido e o
caso de uso B de extensor.

59
Relacionamento de extensão
 Cada uma das diferentes seqüências representa
um comportamento opcional, que só ocorre sob
certas condições ou cuja realização depende da
escolha do ator.
 Quando um ator opta por executar a seqüência de
interações definida no extensor, este é executado.
 Após a sua execução, o fluxo de interações volta ao caso
de uso estendido, recomeçando logo após o ponto em
que o extensor foi inserido.
 Importante: não necessariamente o
comportamento definido pelo caso de uso extensor
é realizado.

60
Relacionamento de extensão
 Exemplo: considere um processador de
textos. Considere que um dos casos de uso
deste sistema seja Editar Documento.
 No cenário principal deste caso de uso, o ator
abre o documento, modifica-o, salva as
modificações e fecha o documento.

 Mas, em outro cenário, o ator pode desejar que o

sistema faça uma verificação ortográfica no
documento.

 Em outro, o ele pode querer realizar a substituição

de um fragmento de texto por outro.

61
Relacionamento de extensão
 Interações de Substituir Texto:
1. Em qualquer momento durante Editar Documento,
o ator pode optar por substituir um fragmento de
texto por outro.
2. O ator fornece o texto a ser substituído e o texto
substituto.
3. O ator define os parâmetros de substituição
(substituir somente palavras completas ou
ocorrências dentro de palavras; substituir no
documento todo ou somente na parte selecionada;
ignorar ou considerar letras maiúsculas e
minúsculas).
4. O sistema substitui todas as ocorrências
encontradas no texto.
62
 Solicitar cartão de crédito
C liente

<<exte nd>>

So licita r s egu ro d e vida

63
Relacionamentos entre casos de uso

«extends»

C a
C a d a s
«include»

D Ve
F u n c i o 64
Relacionamento de generalização
 Relacionamento no qual o reuso é mais
evidente.
 Este relacionamento permite que um caso de
uso (ou um ator) herde características de um
caso de uso (ator) mais genérico.
 O caso de uso (ator) herdeiro pode
especializar o comportamento do caso de
uso (ator) base.

 Resumo: Pode existir entre dois casos de uso

ou entre dois atores.

65
Relacionamento de generalização
 Vantagem: comportamento do caso de uso
original é reutilizado pelos casos de uso
herdeiros.
 Somente o comportamento que não faz sentido ou
é diferente para um herdeiro precisa ser
redefinido.

66
Relacionamento de generalização
 A generalização entre atores significa que o
herdeiro possui o mesmo comportamento que
o ator do qual ele herda.
 Além disso, o ator herdeiro pode participar em
casos de uso em que o ator do qual ele herda
não participa.
 Um exemplo: considere uma biblioteca na qual
pode haver alunos e professores como
usuários.
 Ambos podem realizar empréstimos de títulos de
livros e reservas de exemplares.
 No entanto, somente o professor pode requisitar a
compra de títulos de livros à biblioteca.
67
 Relacionamento de generalização -
Resumo
 Relacionamentos:
 Generalização entre casos de uso: significa que um caso de uso
filho herda o comportamento e o significado do caso de uso pai
 O caso de uso filho deverá acrescentar ou sobrescrever o

comportamento do caso de uso pai

• A generalização é
representada graficamente
por uma linha sólida com um
triângulo numa das
extremidades
•O triângulo aponta para o 68

caso de uso pai

Notação
 Os relacionamentos de inclusão, extensão e herança são
representados por uma seta direcionada de um caso de uso
para outro.

 A seta (tracejada) de um relacionamento de inclusão recebe o

estereótipo <<inclui>>.

 A seta (tracejada) de um relacionamento de inclusão recebe o

estereótipo <<estende>>.

 A seta (sólida) de um relacionamento de herança não recebe

estereótipo.

69
Notação
Obter Extrato
«inclui»

«inclui»
Fornecer
Realizar Saque
Identificação

«inclui»
Cliente

Realizar
Transferência

70
Notação

«estende» Substituir Texto

Editar Documento
«estende»
Escritor
Corrigir Ortografia

71
Generalização - Atores
Notação
Reservar Livro

Devolver Livro
Usuário

Solicitar Compra
de Título

Professor

72
 Generalização - Atores
Notação
 Atores podem ter relacionamentos de
generalização entre eles (uma vez que
representam classes)

Cliente

Cliente especial Cliente regular

73
Notação

Realizar Pagamento

Cliente

Realizar Pagamento Realizar Pagamento

com Cartão de Crédito com Dinheiro

74
 Desenvolva um diagrama de casos de uso
para o problema a seguir:
 Quando um cliente compra um eletrodoméstico
ele se dirige ao caixa da loja para efetuar o
pagamento do que foi comprado. O cliente pode
pagar à vista, no crediário da loja ou com cartão
de crédito. Para qualquer forma de pagamento a
loja realiza uma consulta no SPC para depois
emitir a NF de venda.

75
76