Módulo 2B

29/04/2021 UNIP - Universidade Paulista : DisciplinaOnline - Sistemas de conteúdo online para Alunos.
MÓDULO II
Modelagem de Casos de Uso
Descrição sucinta de um caso de uso
Todo caso de uso precisa ter uma descrição sucinta, ou seja, sintetizada. O
objetivo desta descrição é oferecer ao leitor (leigo em informática) uma visão do
que o caso de uso faz, ou seja, qual é o resultado que ele produz. Obviamente,
esta descrição jamais deverá abordar aspectos relacionados à solução de
implementação.
A forma de descrever sucintamente o caso de uso deverá ser de modo que, ao ler
a descrição de todos os casos de uso, o cliente possa concluir que tudo que ele
pediu para que o sistema faça, está registrado no conjunto dessas descrições.
A abordagem deve ser orientada ao negócio e não à tecnologia. Aspectos

relacionados a requisitos não-funcionais e restrições, devem ser abordados em
uma outra seção da descrição do caso de uso, mas nunca na sua descrição
sucinta.
Toda e qualquer descrição deverá ter as seguintes características:
• Simplicidade.
• Clareza.
• Precisão.
• Consistência.
• Não redundante.
• Não ambígua.
https://online.unip.br/imprimir/imprimirconteudo 1/16
O caso de uso acima “Emite extrato pela ATM” está descrito de duas formas:
1. Permite o solicitante de extrato na ATM obter extrato impresso para um

período indicado das suas contas de depósito que ele possui no banco.
2. Permite o solicitante de extrato na ATM obter um extrato impresso para um

período indicado de qualquer uma das contas de depósito que ele possui.
No que se refere à ambigüidade, pode-se concluir o seguinte:
• A primeira descrição é ambígua, porque permite a interpretação de que, de

uma única vez, o sistema irá imprimir um extrato contendo todas as contas que o
solicitante possui.
• A segunda descrição é mais exata, porque restringe um extrato para cada

conta de cada vez.
Cuidados ao modelar casos de uso
• Um caso de uso não corresponde a uma função no DFD (Diagrama de Fluxo

de Dados).
• Não existe decomposição funcional em modelagem de casos de uso, ou seja,

um caso de uso não pode ser decomposto em vários casos de uso, como ocorre
na decomposição de funções de negócio em um diagrama de atividades.
• No termo “macro caso de uso” não faz sentido porque não existe
decomposição funcional de casos de uso.
• Detalhar um caso de uso não significa decomposição funcional. Significa

descrever o caso de uso em um nível de detalhes bem maior, indicando os fluxos
de eventos, pré e pós-condições, fluxos alternativos e pontos de extensão.
• Um caso de uso SEMPRE tem sua execução disparada por um Ator ou por
um outro caso de uso (incluide, extend ou generalização). Um caso de uso nunca
é iniciado espontaneamente, sozinho. .
Descrição detalhada de casos de uso
Todo caso de uso deve ter uma descrição detalhada. Este tipo de descrição é de
importância vital para o projeto de desenvolvimento do sistema, pois oferece os
detalhes para a elaboração do Modelo de Análise, Modelo de Design, Modelo de
Implementação, captura de requisitos não-funcionais, regras de negócio e

restrições que o projeto deve contemplar.
Os itens que compõem uma descrição detalhada de um caso de uso são:
· Fluxo de eventos.
· Pré-condição.
· Pós-condição.
· Requisitos especiais.
· Requisitos não funcionais.
· Regras de negócio.
Fluxo de Eventos
Fluxo de eventos descreve o diálogo entre o ator e o sistema para produzir o

resultado esperado pelo ator. Cada ação executada pelo ator ou pelo sistema
chama-se evento. O fluxo de eventos é a seqüência desses eventos.
Exemplo:
Um caso de uso de saque de valores em uma ATM poderia ter o seguinte fluxo de
eventos:
1. O caso de uso inicia quando o ator insere o cartão de débito na leitora de

cartões.
2. O sistema verifica que o cartão é válido.
3. O sistema solicita a identificação do usuário e sua senha.
4. O ator informa os dados solicitados.
5. O sistema verifica que a identificação e a senha informada pelo ator é válida.
6. A leitora de cartões devolve o cartão de débito ao ator.
7. O sistema disponibiliza uma lista de operações para que o ator possa

escolher.
8. O ator escolhe a opção saque.
9. O sistema disponibiliza opções de saques com valores pré-definidos

juntamente com um campo alternativo para que o ator informe qualquer outro
valor diferente das opções pré-definidas.
10. O ator escolhe uma opção de valores disponibilizados.
11. O sistema verifica que a conta corrente do cliente possui saldo suficiente para
que o saque seja efetuado.
12. O sistema efetua o débito do valor sacado na conta corrente do cliente.
13. O sistema separa as cédulas totalizando o valor solicitado.
14. O sistema entrega as cédulas separadas para o cliente.
15. O sistema disponibiliza a tela inicial.
16. O caso de uso encerra quando o ator retira as cédulas disponibilizadas.
Cada passo numerado é um evento. Um evento pode ser realizado pelo ator ou
pelo sistema. Não pode existir um evento que envolva ações do ator e do sistema
ao mesmo tempo. Note que o caso de uso inicia dizendo que “o caso de uso inicia
quando...”. Note também que o caso de uso termina dizendo que “o caso de uso
encerra quando...”. Essa forma de descrever não é obrigatória, porém é
recomendável porque define claramente quando o caso de uso inicia e termina.
Em outras palavras define exatamente o escopo do caso de uso. Isso é importante
para definir as pré e pós-condições existentes para que o caso de uso inicie e
termine respectivamente.
O fluxo de eventos deve ser descrito de forma clara, simples, precisa e não
ambígua. Observe que a descrição acima não referencia como o sistema faz para
executar suas ações. Não cita nome de tabela de banco de dados, não cita nome
de componentes, não cita elementos de design nem de implementação. Descreve
unicamente o que o sistema faz sem entrar em detalhes de como cada ação é
executada.
A forma de descrever um caso de uso deve sempre ser voltada para um público
leigo em tecnologia, mas especialista no negócio. Por isso a linguagem deve usar
um vocabulário adequado para este público.
Existem dois tipos de fluxos de eventos.
· Fluxo básico
· Fluxo alternativo
O fluxo básico é aquele mais provável de ocorrer. Ao descrevê-lo deve-ser

sempre seguir um caminho de sucesso, ou seja, um fluxo que faça com que tudo
ocorra bem até o encerramento do caso de uso. No nosso exemplo acima, o
cartão é válido, a senha fornecida pelo ator é válida, a conta corrente do cliente
tem saldo e ATM possui cédulas suficientes para entregar o valor sacado pelo ator.
Nada de errado pode ocorrer no fluxo básico.
Fluxos alternativos são variações permitidas pelo negócio que fazem com que o
fluxo de eventos sofra alterações. Por exemplo, o saldo da conta corrente não
possui fundos suficientes para a efetivação do saque. Neste caso, é necessário que
o analista preveja como deve ser o comportamento do caso de uso para suportar
esta variação. O fluxo alternativo é um sub-fluxo, ou seja, é um conjunto de
eventos que descreve uma variação do comportamento do caso de uso para dar
suporte a algum fato que venha ocorrer ao longo do fluxo de eventos. Neste caso,
este fato foi a insuficiência de saldo na conta corrente para que o sistema
realizasse o saque.
A figura acima mostra o fluxo básico (seta em azul) e um conjunto de fluxos

alternativos (curvas em vermelho). Note que existem fluxos alternativos que
retornam ao fluxo básico e fluxos alternativos que encerram o caso de uso. Um
fluxo alternativo que encerra um caso de uso pode também ser de sucesso, ou
pode ser de insucesso, ou seja, encerra o caso de uso sem que o objetivo
esperado pelo ator seja alcançado. Esses fluxos alternativos podem também
serem chamados de fluxos de exceção.
Um fluxo alternativo tem duas partes:
• Uma referência (FA-n) definida no fluxo que originou o fluxo alternativo.

Exemplo de referência: FA-1, FA-2, FA-n.
• A descrição do fluxo alternativo deverá ter:
– Um cabeçalho com a indicação da referência (FA-n) e uma descrição do fato

ou variação do negócio que causou a mudança do comportamento do caso de uso.
– Fluxo de eventos a ser executado como conseqüência da ocorrência do fato.
– Observações:
• O fluxo alternativo tem seus eventos numerados independentemente do

fluxo do qual se origina.
• Em alguns casos o Fluxo Alternativo não retorna ao Fluxo Básico, seguindo

em frente até se finalizar (com ou sem sucesso) o Caso de Uso.
• Fim do fluxo de eventos apontando para o ponto de retorno a partir do qual

o controle do fluxo continua.
• Os fluxos de exceção usam como referência: FE-1, FE-2 e FE-n.
Como fazer para identificar fluxos alternativos
Depois de definir o fluxo básico (cenário principal), volte em cada evento e faça as
seguintes perguntas:
· Variações de negócio que podem ocorrer (raros ou freqüentes).
· Algo pode acontecer errado.
· Algum recurso que pode falhar.
· Onde o processo pode ser cancelado pelo ator.
A resposta a essa pergunta sobre variação prevista pelo negócio deverá ser uma
regra de negócio. Uma regra negócio é uma condição que altera o comportamento
de um fluxo de eventos. Essa alteração corresponde a uma mudança no
seqüenciamento dos eventos, ou seja, uma mudança no controle do fluxo de
eventos.
Diretrizes para descrever um fluxo de eventos
• Descreva como o caso de uso começa e termina. Exemplos:
– O caso de uso inicia quando...
– O caso de uso termina quando ...
• Cada evento deve descrever sucintamente a ação que é executada pelo ator
ou pelo sistema.
• Cada evento do fluxo deverá ter sua descrição iniciando com “O ator...” ou
“O sistema...”.
• Cada evento deve ser enumerado.
• Liste os dados (campos) que são trocados entre o ator e o caso de uso.
• A descrição dos metadados desses dados (campos da tela) serão descritos

em um artefato chamado “Encenação do Caso de Uso”.
• Evite o máximo possível descrever detalhes físicos das telas.
– São permitidos termos como hyperlink, campos, botão, telas e opção de

menú (não deve dizer onde se encontra o menu na tela).
– Não especifique soluções de navegabilidade.
– Não especifique a distribuição de campos nas telas.
– Não especifique a seqüência de preenchimento dos campos a não ser que o

preenchimento de um campo cause uma reação do sistema para mostrar uma
lista de valores a ser usada no próximo passo do caso de uso.
– Substitua a expressão “verifica se...” por “verifica que...”. O termo “verifica

se” sugere uma um resultado da verificação, o qual pode não ser de sucesso e
requisitar um tratamento dentro do fluxo principal. Isso não é adequado. O
tratamento desse resultado deve ser feito em um fluxo alternativo. Use essa
técnica no fluxo básico e em todos os fluxos alternativos. O uso da expressão
“verifica que” sugere que a ação seguinte é o tratamento do fato verificado.
• Descreva somente os eventos que pertencem ao caso de uso em foco.
• Nunca descreva outros casos de uso que venham a ser incluídos ou que
estendem o caso de uso em foco.
• O texto deverá ser o mais exato (cartesiano) possível.
• Evite terminologias vagas, tais como: "por exemplo", "etc. " e

"informações“.
Cenários
É um caminho formado por um fluxo de eventos ou por um arranjo formado por

um trecho do fluxo básico e um ou mais fluxos alternativos.
A figura a seguir mostra três cenários:
· Cenário principal formado pelo uma linha tracejada em azul.
· Cenário alternativo de sucesso formado por um caminho tracejado de cor

verde.
· Cenário alternativo de exceção formado por um caminho tracejado em

vermelho.
O cenário principal coincide com o fluxo básico de eventos. Este cenário produz o
resultado esperado pelo ator. O cenário alternativo de sucesso é formado por um
trecho inicial (sub-fluxo) do fluxo básico, um fluxo alternativo que executa
algumas ações e retorna a um ponto anterior no fluxo básico e completa todo o
restante do fluxo básico chegando a um fim de sucesso e produzindo o resultado
esperado pelo ator. O cenário alternativo de exceção é formado por um trecho do
fluxo básico, um trecho de um fluxo alternativo e um outro fluxo alternativo que
encerra o caso de uso sem produzir o resultado esperado pelo ator. Por isso é
chamado de fluxo de exceção.
Eventos executados pelo ator e pelo sistema. Um conjunto de eventos forma um

fluxo ou sub-fluxo de eventos. Um ou mais fluxos (ou sub-fluixos) de eventos
formam um cenário. Um conjunto de cenários forma um caso de uso. Desta forma
conclui-se que um cenário é uma instância de um caso de uso. Quando um ator
executa um caso de uso ele está, na verdade, executando um cenário de um caso
de uso. Este cenário executado pelo ator irá produzir um resultado esperado por
ele. Este cenário poderá ser o principal ou um alternativo. Assim, cada cenário de
sucesso pode produzir um mesmo resultado ou pode produzir resultados
diferentes. Por isso, sempre que estiver descrevendo um cenário, tenha em mente
o resultado que é esperado pelo ator que o está executando.
Pré-Condição
É uma garantia dada pelo sistema que é verdadeira antes de permitir o início do
sistema. É o estado em que o sistema deve se encontrar do ponto de vista do ator
que permite o início do caso de uso. Se a pré-condição não for satisfeita o caso de
uso não poderá ser iniciado. Devido ao fato do sistema garantir que o caso de uso
não inicia sem que seja satisfeita, a pré-condição não é verificada se é satisfeita
após o início do caso de uso. No caso de uso de saque de valores na ATM, as pré-
condições são as seguintes:
· A ATM esteja em perfeito funcionamento, com sua tela inicial disponível;
· A conexão com o sistema de conta corrente do banco em perfeito

funcionamento.
· O ator deverá portar um cartão de débito.
Sem que essas condições estejam satisfeitas não será possível iniciar o caso de
uso. O fato do cartão de débito ser válido não chega a ser uma pré-condição,
porque é possível iniciar o caso de uso sem que seja válido. Note que a validação
do cartão já é um passo do fluxo de eventos, conforme demonstrado no fluxo a
seguir:
1. O caso de uso inicia quando o ator insere o cartão de débito na leitora de

cartões.
2. O sistema verifica que o cartão é válido.
3. O sistema solicita a identificação do usuário e sua senha.
4. O ator informa os dados solicitados.
5. O sistema verifica que a identificação e a senha informada pelo ator é válida.
6. Etc.
A pré-condição estabelece o limite anterior do fluxo de eventos do caso de uso. A

pré-condição não poderá ser o primeiro passo do caso de uso. O primeiro passo
deverá ser uma conseqüência da pré-condição, mas nunca ser a própria pré-
condição, porque é ela que restringe o início do caso de uso.
A figura acima mostra uma abstração didática onde a pré-condição se posiciona

antes do início do caso de uso. Todas as pré-condições são verificadas pelo
sistema antes do início do caso de uso. O sistema garante que as pré-condições

foram atendidas.
Pós-Condição
É o estado em que o sistema deverá ficar após a conclusão do caso de uso. Este
estado deverá ser percebido pelo ator. No caso de uso de saque acima referido, a
pós-condição é o dinheiro ter sido entregue ao ator e o saldo da conta corrente ter
sido debitado do valor correspondente ao saque.
Note que todo o comportamento do caso de uso está orientado para a realização
deste objetivo, ou seja, entregar o valor solicitado ao ator e proceder o devido
débito na conta corrente do cliente. Com isso, verifica-se que as pós-condições
descrevem os objetivos do caso de uso, ou seja, descrevem o resultado de valor
desejado pelo ator ao executar o caso de uso.
Com isso conclui-se que seria uma boa prática que o analista, antes de descrever
os fluxos de eventos, ele se preocupasse em definir as pós-condições. Com isso os
fluxos de eventos seriam claramente descritos de forma a mostrar o que é feito
para o alcance desses objetivos.
Os fluxos de eventos produzem as pós-condições. Todos os possíveis cenários do

caso de uso trabalham para que as pós-condições sejam alcançadas. Por isso é
necessário investigar se os fluxos alternativos que encerram casos de uso
compõem cenários que produzem pós-condições diferentes do que é produzido
pelo cenário principal. Assim, toda descrição de pós-condição deve ter uma
indicação de qual cenário a produziu. Isso é muito importante para a definição dos
casos de teste. Cada cenário deverá ter um caso de teste. Para tal será necessário
que se saiba o que o cenário irá produzir.
A pós-condição não é o evento que encerra um cenário de caso de uso.

Freqüentemente o ultimo passo de um cenário está diretamente associado à pós-
condição que ele produz, mas isso não significa que o ultimo passo seja a própria
pós-condição.
A figura abaixo mostra um abstração didática que ilustra as pós-condições.
Note que a pós-condição descreve o estado em que o sistema ficou após a

execução de um cenário do caso de uso. Note ainda que cada cenário que finaliza
o caso de uso pode produzir sua própria pós-condição.
Exemplo:
• Caso de Uso:
– Sacar valores em uma ATM.
• Pós-Condições:
– Cenário principal:
• O saldo da conta sacada está atualizada com o novo saldo.
• A transação registrada.
• Os valores (cédulas) entregues ao cliente.
• O cartão de débito devolvido ao cliente.
• A ATM retornou à tela inicial (menu principal).
– Cenário alternativo (cartão inválido).
• Os valores deverão ter sido entregues ao cliente.
• Mensagem de cartão inválido.
– Cenário de não identificação do cliente.
• Mensagem de identificação ou senha do cliente inválida.
– Cenário de saldo insuficiente.
• Mensagem de saldo insuficiente.
Requisitos especiais
Requisitos especiais são observações que necessitam ser informadas a cerca dos
eventos de um caso de uso. Um requisito especial sempre está relacionado a pelo
menos um evento do caso de uso. Oferece uma característica adicional sobre os
eventos do caso de uso em foco.
Requisito Não-Funcional
São características de qualidade que o caso de uso deverá atender. Nem todo
requisito não-funcional está associado a casos de uso, mas esta seção tratará
somente de associar os requisitos não-funcionais que deverão ser realizados pelo
caso de uso em foco. Os requisitos não-funcionais geralmente são descritos em
outro documento que não é a descrição do caso de uso. É nesse documento que
cada requisitos será descrito. Por isso não há a necessidade de descrever
novamente os requisitos não-funcionais na descrição do caso de uso. Basta
referenciar que o caso de uso deverá realizar tais requisitos não-funcionais.

Requisitos serão descritos em uma seção específica para isso.
Regras de negócio
É uma condição que define um comportamento em particular para o sistema. Essa

condição normalmente é definida:
· Por uma política da empresa (norma interna).
· Pelo governo (portarias, decretos, etc.).
· Como uma restrição imposta pelo negócio ou sistema.
· Exemplo de regra de negócio:
– Todo débito em conta-corrente incide cobrança de CPMF.
As Regras de Negócio não devem ser descritas diretamente na descrição do caso

de uso porque ela pode ser realizada por mais de um caso de uso. Nesta hipótese
seria necessária a repetição da descrição da regra de negócio em cada caso de
uso que a realizar. O ideal será a criação de um documento que centralize a
descrição de todos as regras de negócio. Na descrição do caso de uso basta incluir
uma referência da regra de negócio junto ao evento que o realiza.
Exercício 1:
Com base nos cenários e fluxos de eventos de casos de uso, assinale a alternativa errada:
A)
O fluxo básico de um caso de uso é uma seqüência de eventos executados por um

ator e pelo sistema formando um cenário de sucesso.
B)
Todo caso de uso possui um cenário principal o qual coincide com o fluxo básico.
C)
Um caso de uso é uma abstração formada por uma coleção de cenários.
D)
Um cenário é um caminho formado por uma seqüencia de eventos que sempre

leva a um caso de sucesso.
E)
Um cenário é uma seqüência de eventos que ilustra um comportamento do sistema.
F)
Todo caso de uso precisa de um ator que o inicie.
O aluno respondeu e acertou. Alternativa(D)
Comentários:
Essa disciplina não é ED ou você não o fez comentários
Exercício 2:
A descrição de um caso de uso inclui a descrição de ﬂuxos de eventos. Com base nisso, assinale a alterna va
errada:
A)
Um evento é um passo que pode ser executado por um ator ou pelo sistema.
B)
O primeiro passo de um caso de uso deve coincidir com a pré-condição desse caso de uso.
C)
As pós-condições que de um caso de uso são diretamente relacionados aos

objetivos desse caso de uso.
D)
As pré e pós-condições ajudam a definir o escopo de um caso de uso.
E)
Nenhuma das alternativas
O aluno respondeu e acertou. Alternativa(B)
Comentários:
Essa disciplina não é ED ou você não o fez comentários

Módulo 2B

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Módulo 2B

Enviado por

Direitos autorais:

Formatos disponíveis

29/04/2021 UNIP - Universidade Paulista : DisciplinaOnline - Sistemas de conteúdo online para Alunos.

Modelagem de Casos de Uso

Descrição sucinta de um caso de uso

A abordagem deve ser orientada ao negócio e não à tecnologia. Aspectos

Toda e qualquer descrição deverá ter as seguintes características:

1. Permite o solicitante de extrato na ATM obter extrato impresso para um

2. Permite o solicitante de extrato na ATM obter um extrato impresso para um

No que se refere à ambigüidade, pode-se concluir o seguinte:

• A primeira descrição é ambígua, porque permite a interpretação de que, de

• A segunda descrição é mais exata, porque restringe um extrato para cada

Cuidados ao modelar casos de uso

• Um caso de uso não corresponde a uma função no DFD (Diagrama de Fluxo

• Não existe decomposição funcional em modelagem de casos de uso, ou seja,

• Detalhar um caso de uso não significa decomposição funcional. Significa

Descrição detalhada de casos de uso

Implementação, captura de requisitos não-funcionais, regras de negócio e

Os itens que compõem uma descrição detalhada de um caso de uso são:

· Requisitos não funcionais.

Fluxo de eventos descreve o diálogo entre o ator e o sistema para produzir o

1. O caso de uso inicia quando o ator insere o cartão de débito na leitora de

2. O sistema verifica que o cartão é válido.

3. O sistema solicita a identificação do usuário e sua senha.

4. O ator informa os dados solicitados.

5. O sistema verifica que a identificação e a senha informada pelo ator é válida.

6. A leitora de cartões devolve o cartão de débito ao ator.

7. O sistema disponibiliza uma lista de operações para que o ator possa

8. O ator escolhe a opção saque.

9. O sistema disponibiliza opções de saques com valores pré-definidos

10. O ator escolhe uma opção de valores disponibilizados.

12. O sistema efetua o débito do valor sacado na conta corrente do cliente.

13. O sistema separa as cédulas totalizando o valor solicitado.

14. O sistema entrega as cédulas separadas para o cliente.

15. O sistema disponibiliza a tela inicial.

16. O caso de uso encerra quando o ator retira as cédulas disponibilizadas.

Existem dois tipos de fluxos de eventos.

O fluxo básico é aquele mais provável de ocorrer. Ao descrevê-lo deve-ser

A figura acima mostra o fluxo básico (seta em azul) e um conjunto de fluxos

Um fluxo alternativo tem duas partes:

• Uma referência (FA-n) definida no fluxo que originou o fluxo alternativo.

• A descrição do fluxo alternativo deverá ter:

– Um cabeçalho com a indicação da referência (FA-n) e uma descrição do fato

– Fluxo de eventos a ser executado como conseqüência da ocorrência do fato.

• O fluxo alternativo tem seus eventos numerados independentemente do

• Em alguns casos o Fluxo Alternativo não retorna ao Fluxo Básico, seguindo

• Fim do fluxo de eventos apontando para o ponto de retorno a partir do qual

• Os fluxos de exceção usam como referência: FE-1, FE-2 e FE-n.

Como fazer para identificar fluxos alternativos

· Variações de negócio que podem ocorrer (raros ou freqüentes).

· Algo pode acontecer errado.

· Algum recurso que pode falhar.

· Onde o processo pode ser cancelado pelo ator.

Diretrizes para descrever um fluxo de eventos

• Descreva como o caso de uso começa e termina. Exemplos:

– O caso de uso inicia quando...

– O caso de uso termina quando ...

• Cada evento deve ser enumerado.

• A descrição dos metadados desses dados (campos da tela) serão descritos

• Evite o máximo possível descrever detalhes físicos das telas.

– São permitidos termos como hyperlink, campos, botão, telas e opção de

– Não especifique soluções de navegabilidade.

– Não especifique a distribuição de campos nas telas.

– Não especifique a seqüência de preenchimento dos campos a não ser que o

– Substitua a expressão “verifica se...” por “verifica que...”. O termo “verifica

• Descreva somente os eventos que pertencem ao caso de uso em foco.