REA- Diagramas de Casos de Uso da UML

1. 1
Diagramas da UML
Diagrama de casos de uso
Esta é uma Licença de Cultura Livre! https://creativecommons.org/licenses/by-sa/4.0/

2. 2
Introdução – Diagrama de Caso de Uso
O diagrama de caso de uso procura por meio de uma linguagem
simples, possibilitar a compreensão do comportamento externo do sistema
(em termos de funcionalidades oferecidas por ele) por qualquer pessoa,
tentando apresentar o sistema por intermédio de uma perspectiva do
usuário.
 É o diagrama mais abstrato, e portanto o mais flexível e informal.
 Costuma ser usado sobretudo no inicio da modelagem, principalmente nas
etapas de levantamento e analise de requisitos.
 Serve de base para os demais diagramas que são criados posteriormente.
 Apresenta uma visão externa geral das funcionalidades do sistema.
 Não se preocupa como as funcionalidades serão implementadas.
 Útil para identificar e compreender os requisitos do sistema, ajudando a
especificar, visualizar e documentar as características, funções e serviços do
sistema desejados pelos usuários.
 Tenta identificar que usuários vão interagir com o sistema.
 É bastante útil e recomendável que um diagrama de caso de uso seja
apresentado aos clientes junto com um protótipo.

3. 3
Componentes do diagrama – Atores
• O diagrama de caso de uso concentra-se em dois
itens principais: atores e casos de uso.
• Os atores representam papéis desempenhados pelos
diversos usuários que poderão utilizar, de alguma
maneira, os serviços e funções do sistema.
• Eventualmente um ator pode representar um
hardware especial ou mesmo outro software que
interaja com o sistema.
• Os atores são representados por símbolos de
“bonecos magros”, contendo uma breve descrição
logo abaixo do seu símbolo que identifica o papel
que o ator em questão assume dentro do diagrama.

4. Para identificar os atores que vão participar do modelo devemos
fazer as seguintes perguntas:
 Quem ou como o sistema é iniciado?
 Quem fornecerá, usará, ou excluirá informações do sistema?
 Quem está interessado nas funcionalidades ou serviços fornecido pelo
sistema?
 Quem dará suporte e manutenção ao sistema?
 Quais são os recursos externos do sistema?
 Quais outros sistemas precisarão interagir com o sistema em
desenvolvimento?
4
Identificando atores

5. 5
Exemplo de Atores
Figura: Exemplos de atores
 Os atores Gerente, Funcionário
e Cliente representam usuários
de um sistema.
 O ator sistema integrado
representa um software que
interage de alguma forma com
o sistema.
 O ator medidor de radiação
representa um hardware
externo que envia informações
para o sistema.

6. 6
Componentes do diagrama – Casos de Uso
 Os casos de uso são utilizados para capturar os requisitos do
sistema, ou seja, referem-se aos serviços, tarefas ou
funcionalidades identificados como necessários ao software e que
podem ser utilizados de alguma maneira pelos atores que
interagem com o sistema, sendo usados para expressar e
documentar os comportamentos pretendidos para as funções
deste.
 Podem ser classificados em casos de uso primários ou secundários.
 Caso de Uso Primário: quando refere a um processo importante,
que enfoca um dos requisitos funcionais do software (realizar um
saque, emitir um extrato em um sistema bancário).
 Caso de Uso Secundário: quando se refere a um processo
periférico, como a manutenção (edição) de um cadastro.

7. 7
 Os casos de uso são representados por elipses
contendo dentro de si um texto que descreve a que
funcionalidade o caso de uso se refere. Em geral a
descrição deve ser sucinta.
 Os casos de uso costumam ser documentados,
fornecendo instruções em linhas gerais de como será
o seu funcionamento, quais atividades deverão ser
executadas, qual evento forçara sua execução, quais
atores poderão utilizá-los e quais suas possíveis
restrições, entre outras.
Componentes do diagrama – Casos de Uso

8. 8
Exemplos de Caso de Uso
Figura: Exemplos de caso de uso

9. Entender como a organização trabalha e como este sistema de
informações pode ser incorporado nos processos pode dar uma ideia do
ambiente do sistema. A melhor maneira de encontrar casos de uso é
considerar o que cada ator requisita do sistema. Para cada ator, pergunte:
 Quais são os objetivos que o ator tentará alcançar com o sistema?
 Quais são as tarefas primárias que o ator quer que o sistema execute?
 O ator vai criar, armazenar, alterar, excluir ou ler dados do sistema?
 O ator terá que informar o sistema sobre mudanças externas?
 O ator executará a inicialização ou desligamento do sistema?
 O ator precisa ser informado sobre certas ocorrências, tais como
indisponibilidade de um recurso de rede, no sistema?
9
Encontrando casos de uso

10. 10
 A documentação de um caso de uso costuma descrever, por
meio de uma linguagem bastante simples, informações como
a função em linhas gerais do caso de uso, quais atores
interagem com ele, quais etapas devem ser executadas pelo
ator e pelo sistema para que o caso de uso execute sua
função, quais parâmetros devem ser fornecidos, que
restrições e validações o caso de uso deve ter.
 O formato de documentação de um caso de uso da UML é
bastante flexível, não sendo recomendável a utilização de
pseudocódigos. Os formatos propostos são: a descrição
contínua, a descrição numerada e a narrativa fragmentada.
Documentação de Caso de Uso

11. 11
Estes caso de uso inicia quando 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 cliente fornece o valor da quantidade que deseja
sacar. O sistema fornece a quantia desejada e imprime o recibo
para o cliente. O cliente retira a quantia e o recibo, e o caso de
uso termina.
Formato – Descrição Contínua
Caso de uso: REALIZAR SAQUE em um caixa eletrônico

12. 12
1) Cliente insere seu cartão no caixa eletrônico
2) Sistema apresenta solicitação de senha
3) Cliente digita senha
4) Sistema valida a senha e exibe menu de operações disponíveis
5) Cliente indica que deseja realizar um saque
6) Sistema requisita o valor da quantia a ser sacada
7) Cliente fornece o valor da quantia que deseja sacar
8) Sistema fornece a quantia desejada e imprime o recibo
9) Cliente retira a quantia e o recibo, e o caso de uso termina
Formato – Descrição Numerada
Caso de uso: REALIZAR SAQUE em um caixa eletrônico

13. 13
Formato – Narrativa Fragmentada
CLIENTE SISTEMA
Inseri seu cartão no caixa
eletrônico
Apresenta a solicitação da
senha
Digita a senha Valida a senha e exibe menu
de opções
Solicita realização de saque Requisita a quantia a ser
sacada
Fornece o valor da quantia que
deseja
Fornece a quantia desejada e
imprime o recibo para o
clienteRetira a quantia e o recibo
Caso de uso: REALIZAR SAQUE em um caixa eletrônico

14. 14
Documentação Caso de uso
Exemplo utilizando
Narrativa Fragmentada
Nome do Caso de Uso Abrir Conta
Ator principal Cliente
Atores secundários Funcionário
Resumo Esse caso de uso descreve as etapas percorridas por um cliente
para abrir uma conta corrente.
Pré-condições O pedido de abertura precisa ter siso previamente aprovado
Pós-condições É necessário realizar um depósito inicial
Fluxo Principal
Ações do Ator Ações do Sistema
1. Solicitar Abertura de conta
2. Consultar cliente por seu CPF ou CNPJ
3. Informar a senha da conta
4. Abrir conta
5. Fornecer valor a ser depositado
6. Registrar depósito
7. Emitir cartão da conta
Restrições/Validações 1. Para abrir uma conta corrente é preciso ser maior de idade
2. O valor mínimo de depósito é R$ 5,00
3. O cliente precisa fornecer algum comprovante de residência
Fluxo Alternativo – Manutenção do Cadastro do Cliente
Ações do Ator Ações do Sistema
1. Se for necessário, Executar caso de uso Manter Cliente
Fluxo de Exceção – Cliente menor de idade
Ações do Ator Ações do Sistema
1. Comunicar ao cliente que este não possui idade mínima
2. Recusar o pedido
Figura: Caso de Uso – Abrir Conta

15. 15
Exemplo 2 para Documentação Caso de uso
<<< Página 01 >>>
<<< Página 02 >>>
<<< Página 03 >>>

16. 16
Associações
 As associações representam as interações e os relacionamentos entre os
atores que fazem parte do diagrama, entre os atores e os casos de uso, ou
o relacionamento entre os casos de uso e outros casos de uso. Os
relacionamentos entre os casos de uso recebem nomes especiais como
(inclusão = include, extensão = extend e generalização).
 Uma associação entre um ator e um caso de uso demonstra que o ator
utiliza, de alguma maneira, a funcionalidade representada.
 A associação é representada por uma linha ligando o ator ao caso de uso,
podendo ocorrer de aparecerem setas nas extremidades, indicando o
sentido das informações. Se a linha não tiver setas indica o fluxo de
informações nas duas direções.
A figura ilustra o ator Cliente utilizando
a funcionalidade de Abrir Conta representada
pelo caso de uso, e que a informação trafega nas
duas direções. Associação entre um Ator e um Caso de Uso

17. 17
Associação do tipo – Generalização
 O relacionamento de generalização/especialização é uma
forma de associação entre casos de uso na qual existem dois
ou mais casos de uso com características semelhantes,
apresentando pequenas diferenças entre si. Quando tal
situação ocorre, costuma-se definir um caso de uso geral que
descreve as características compartilhadas por todos os casos
de uso envolvidos, cuja documentação conterá apenas as
características especificas de cada um.
 Utilizamos neste caso o conceito de herança nos casos de uso
especializados.
 É representada por uma linha com uma seta mais grossa que
indica qual é o caso de uso geral (para o qual a seta aponta).

18. 18
Exemplos - Generalização
Entre casos de uso
Como podemos perceber, existe 3 opções de abertura de
conta muito semelhantes entre si: abertura de conta
comum, abertura de conta especial e abertura de conta
poupança, cada uma representada por um caso de uso
diferente. Cada caso de uso tem restrições e validações
próprias.
Entre atores
O relacionamento de generalização/especialização
também pode ser aplicado sobre atores. O exemplo
mostra o ator geral pessoa e dois atores especializados
Pessoa Física e Pessoa Jurídica.

19. 19
Associação do tipo – Inclusão
 A associação de inclusão costuma ser utilizada
quando existe um cenário, situação ou rotina comum
a mais de um caso de uso.
 O relacionamento de inclusão indicam uma
obrigatoriedade, ou seja, quando um determinado
caso de uso tem um relacionamento de inclusão com
outro, a execução do primeiro OBRIGA também a
execução do segundo.
 Pode ser comparado a chamada de uma Rotina ou
Função, muito utilizado nas linguagens de
programação.
 Representado por uma linha tracejada

20. 20
Exemplo 1 – Inclusão (registrar movimento)
Percebemos que sempre que um saque ou um deposito ocorrer deve ser registrado para
fins de histórico bancário. Como essas rotinas são semelhantes, diferenciando somente
pelo tipo de movimento, colocou-se uma rotina registro em um caso de uso a parte,
chamado Registrar Movimento. Esse caso será executado obrigatoriamente sempre que
os casos de uso Realizar Deposito ou Realizar Saque forem utilizados.

21. 21
Exemplo 2 – Inclusão (livraria virtual)
A figura mostra parte de uma modelagem para uma livraria virtual, onde o cliente pode
logar-se, adicionar livros ao carrinho de compras, visualizar o conteúdo do carrinho e
concluir o pedido. Nesse exemplo o cliente pode solicitar a visualização de seu carrinho
de compras sempre que quiser, no entanto, no momento em que decidir concluir o
pedido, obrigatoriamente deverá verificar ainda uma vez os livros por ele escolhidos e
fornecer a ultima confirmação.

22. 22
Exemplo 3 – Inclusão (fornecer identificação)
A figura mostra que os casos de uso Obter Extrato, Realizar Saque e Realizar
Transferências tem uma sequencia de interações em comum: a utilizada para autenticar
o cliente do banco que está representada pelo caso de uso Fornecer Identificação.

23. 23
Associação do tipo – Extensão
 Associações de extensão são utilizadas para
descrever cenários OPCIONAIS de um caso de uso.
Os casos de uso estendidos descrevem cenários que
apenas ocorrerão em uma situação especifica se
determinada condição for satisfeita.
 Indicam a necessidade de um teste para determinar
se é necessário executar também o caso de uso
estendido ou não.
 Representado por uma linha tracejada

24. 24
Exemplo – Extensão (formulário de login)
Figura: Formulário de Login
O formulário ao lado
mostra o login onde o
cliente deverá
informar login e senha
válidos para acessar o
software. Contudo se
ele estiver acessando o
site pela 1ª vez, existe
o caso de uso
autoregistrar que é
chamado a partir do
Realizar Login.
Figura: Caso de uso – Realizar login com extensão

25. 25
Exemplo 2 – Extensão (encerrar conta)
Um caso de uso pode ter
muitos relacionamentos de
extensão. Nesse exemplo,
um cliente dirige-se ao
funcionário do banco e
solicita o encerramento de
uma determinada conta.
Sabemos que para encerrar
uma conta o saldo deve ser
igual a zero, então poderá
ser chamado o caso realizar
saque (conta com saldo
positivo) ou realizar depósito
(conta com saldo negativo).
Neste caso os casos de uso
serão chamados se as
condições associadas a eles
forem verdadeiras e
também somente um deles.
Figura: Caso de uso – Encerrando uma conta

26. 26
Restrições em Associações de Extensão
 As RESTRIÇÕES são compostas por um texto entre chaves e
utilizadas para definir validações, consistências, condições,
etc. que devem ser aplicadas a um determinado componente
ou situação. São as regras de negócio.
 Podemos acrescentar uma restrição à associação de extensão
por meio de uma nota explicativa, determinando a condição
para que o caso de uso seja executado.
Figura: Caso de uso – Realizar login com restrição

27. 27
Comunicação Extensão Inclusão Generalização
CASO DE USO E
CASO DE USO
X X X
ATOR E ATOR
X
CASO DE USO
E ATOR
X
Resumo – Associações
Tabela: Possibilidades de relacionamento entre os elementos do diagrama de Casos de Uso
Comunicação: significa que o ator interage (troca informações) como o sistema através de um caso de uso.
Extensão: significa que no relacionamento de A para B, um ou mais cenários em B podem acontecer.
Inclusão: significa que no relacionamento de A para B, sempre que A for executado B também será.
Generalização: significa que existe herança entre casos de usos ou entre atores. Base e herdeiro.

28. 28
Resumo – associação de Inclusão e Exclusão
Temos as funcionalidades (casos de uso) A e B, imaginamos que ambos estão
relacionados. Vamos aos exemplos para cada situação.
A-----------include----------->B
INCLUDE: Uso obrigatório, toda vez que o caso de uso A for executado,
obrigatoriamente o B também deverá ser executado.
Ex.: cadastro de pessoa física para financiamento. Durante o cadastramento o caso
de uso (Cadastrar Pessoa) obrigatoriamente deverá ser consultado o CPF para liberar
o crédito, é aonde entra o caso de uso (Consultar Restritivos).
A<----------extend------------B
EXTENDS: Facultativo, ao executar o caso de uso A, não se torna obrigatório a
execução do caso de uso B.
Ex.: dar desconto em para uma compra em dinheiro.
Na execução do caso de uso (Controlar Venda) posso ou não dar desconto, caso eu
queira das desconto executo o caso de uso (Definir Desconto).

29. 29
Atividades
Questões a ponderar
 Qual a principal função dos diagramas de casos de uso?
 Na UML, a representação gráfica de um caso de uso contém que informações?
 Qual a importância da descrição dos casos de uso?
Atividade prática
Utilizando o software Astah Community*, desenvolva um diagrama de casos de uso para um
sistema de leilão via internet, de acordo com os seguintes requisitos.
 Existem diversos participantes em cada leilão, interessados em adquirir os itens
ofertados. Os participantes devem se registrar via internet, antes de o leilão iniciar.
 Durante o leilão são ofertados cada um dos itens que estão arrolados.
 Um participante pode realizar quantos lances quiser durante a realização do leilão,
mas não é obrigado a realizar lance nenhum. Antes de poder fazer quaisquer ofertas,
ele precisa realizar o login no sistema.
 Sempre que um lance suplantar o lance anterior, o sistema deve anunciá-lo,
declarando qual o vencedor quando os lances encerrarem.
* Astah Community disponível em: http://astah.net/editions/community. Acesso dia 20/5/2019.

30. 30
Referências Bibliográficas
 Bezerra, Eduardo – Princípios de análise e projeto de sistemas com UML. 3º Edição. Rio de
Janeiro. Editora Elseiver, 2015.
 Guedes, Gillianes T. A. – UML 2: uma abordagem prática. São Paulo. Editora Novatec, 2009.
 Góes, Wilson Moraes – Aprenda UML por meio de Estudos de Casos. São Paulo. Editora
Novatec, 2004.