Diagrama de

Casos de Uso
UML

PROF. Ms. J FLÁVIO VASCONCELOS ALVES

 ASSUNTOS AULA 2

1) Diagrama de Casos de Uso

2
 DIAGRAMA DE CASO DE USO

O diagrama de casos de uso procura

possibilitar a compreensão do
comportamento externo do sistema (em
termos de funcionalidades oferecidas
por ele) por qualquer pessoa com
algum conhecimento sobre o problema
enfocado, tentando apresentar o
sistema por intermédio de uma
perspectiva dos usuários.
3

(GUEDES, 2018)
 QUANDO USAR O USE CASE

Esse diagrama costuma ser utilizado,

sobretudo, no início da modelagem do
sistema, principalmente nas etapas de
elicitação e análise de requisitos,
embora venha a ser consultado e
possivelmente modificado durante todo
o processo de engenharia e sirva de
base para a modelagem de outros
diagramas.
4

(GUEDES, 2018)
 QUANDO USAR O USE CASE

Esse diagrama costuma ser utilizado,

sobretudo, no início da modelagem do
sistema, principalmente nas etapas de
elicitação e análise de requisitos,
embora venha a ser consultado e
possivelmente modificado durante todo
o processo de engenharia e sirva de
base para a modelagem de outros
diagramas.
5

(GUEDES, 2018)
 OBJETIVO DO USE CASE

Esse diagrama tem por objetivo

apresentar uma visão externa geral das
funcionalidades que o sistema deverá
oferecer aos usuários, sem se
preocupar em profundidade com a
questão de como tais funcionalidades
serão implementadas.

(GUEDES, 2018)
 IDENTIFICAR REQUISITOS FUNCIONAIS

O diagrama de casos de uso é de grande

auxílio para a identificação e compreensão
dos requisitos funcionais do sistema,
ajudando a especificar, visualizar e
documentar as funções e serviços do
software desejados pelos clientes e
stakeholders (usuários com conhecimento
sobre como a informação é gerida e
modificada em determinados setores da
empresa e que possuem interesse no
software).
7

(GUEDES, 2018)
 IDENTIFICAR OS USUÁRIOS

O diagrama de casos de uso tenta

identificar os tipos de usuários que
interagirão com o sistema, quais papéis
eles assumirão e quais funções um
usuário específico poderá requisitar.

(GUEDES, 2018)
 USE CASE e ANALISE DE REQUISITOS

Casos de uso são de interesse especial na

engenharia de requisitos, uma vez que se
mostraram valiosos para elicitar, documentar e
analisar requisitos, sobretudo os funcionais, ou
seja, que identificam as funções que devem ser
fornecidas pelo software.
Além disso, casos de uso também permitem a
rastreabilidade de requisitos, ou seja, qual a
origem de um requisito e por que foi
considerado importante nas fases de projeto,
implementação e verificação e validação.
9

(GUEDES, 2018)
 REUNIÕES INICIAIS c/ STAKEHOLDERS

O diagrama de casos de uso pode e deve ser

apresentado durante as reuniões iniciais com os
stakeholders para ilustrar as funcionalidades e o
comportamento do sistema de informação, facilitar
a compreensão dos stakeholders do que se
pretende desenvolver e auxiliar na identificação de
possíveis falhas de especificação, verificando se
os requisitos do sistema foram bem
compreendidos. É bastante útil e recomendável
que um diagrama de casos de uso seja
apresentado aos clientes com um protótipo, o que
permitirá que um complemente o outro.
10

(GUEDES, 2018)
ATOR

11
 ATORES

Os atores costumam representar os papéis

desempenhados pelos diversos usuários que
poderão utilizar os serviços e funções do sistema.
Um ator pode representar algum hardware especial
ou mesmo outro software que interaja com o
sistema, como no caso de um sistema integrado, por
exemplo.
Um ator pode ser qualquer elemento externo que
interaja com o software, porém, na maioria das
vezes, um ator representará uma pessoa que
utilizará o sistema.
Esse elemento recebe o nome de ator porque um
usuário pode representar mais de um papel no
sistema.
12

(GUEDES, 2018)
 ATORES com mais de 1 papel

Por exemplo, um usuário pode se logar em um

software com um nível de permissões menor,
sendo capaz de utilizar poucas funções do
sistema, ou pode se logar com um nível de
permissão mais alto e utilizar mais recursos, ou
pode ainda se logar como administrador e ter
acesso a todas ou à maioria das funcionalidades
do sistema.
Em cada situação, o papel representado pelo
usuário será diferente, por isso o ator não
representa um usuário propriamente dito, mas sim
um papel que pode vir a ser desempenhado por
um ou mais usuários. 13

(GUEDES, 2018)
 ATORES como representar

Os atores são representados por símbolos de

“bonecos magros”, contendo uma breve descrição logo
abaixo de seu símbolo que identifica o papel que o ator
em questão assume dentro do diagrama.
14

(GUEDES, 2018)
 ESTERIÓTIPO

Os atores que representam o hardware externo

e o sistema integrado possuem também a
palavra “system” entre sinais de ‘<’ e ‘>’.
Isto é chamado estereótipo e serve para
destacar um componente ou associação,
atribuindo-lhe características especiais em
relação a seus iguais. Nesse caso específico, o
estereótipo “<<system>>” serve para tornar
explícito que os atores em questão referem-se
a atores não humanos, ou seja, sistemas de
software ou hardware.
15

(GUEDES, 2018)
 COMO IDENTIFICAR os ATORES ?

Algumas perguntas podem ser úteis para identificar

candidatos a atores, como:
• Que tipos de usuários poderão utilizar o
sistema?
• Quais usuários estão interessados ou utilizarão
quais funcionalidades e serviços do software?
• Quem fornecerá informações ao sistema?
• Quem utilizará as informações do sistema?
• Quem poderá alterar ou mesmo excluir
informações do sistema?
• Existe algum outro software que interagirá com o
sistema?
• Existe algum hardware especial (como um robô,
por exemplo) que interagirá com o software? 16

(GUEDES, 2018)
 CANDIDATOS A ATORES

Os candidatos a atores devem ser

listados e deve-se tentar atribuir
responsabilidades e objetivos a cada
um deles, ou seja, metas que cada ator
poderia desejar atingir ao utilizar o
software.
Atores para os quais não é possível
atribuir um objetivo dificilmente serão
atores verdadeiros e deverão ser
eliminados. 17

(GUEDES, 2018)
CASOS
DE USO

18
 CASOS DE USO

Os casos de uso são utilizados para capturar os

requisitos funcionais do sistema, ou seja,
referem-se a 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.
Assim, casos de uso expressam e documentam
os comportamentos pretendidos para as
funções do software.

19

(GUEDES, 2018)
 CASOS DE USO REPRESENTAÇÃO

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. Na verdade,
não existe um limite determinado para o texto que
possa estar contido dentro da elipse, mas, em geral, a
descrição de um caso de uso costuma ser bastante
sucinta. O texto contido em um caso de uso costuma
iniciar com um verbo denotando a ação que será
realizada quando de sua execução. 20

(GUEDES, 2018)
 CLASSIFICAÇÃO DE CASOS DE USO

Casos de uso podem ser classificados em

casos de uso primários ou secundários.
Um caso de uso é considerado primário quando
se refere a um processo importante, que enfoca
um dos requisitos funcionais do software, como
realizar um saque ou emitir um extrato em um
sistema de controle bancário.
Já um caso de uso secundário se refere a um
processo periférico, como a manutenção de um
cadastro ou a emissão de um relatório simples.

21

(GUEDES, 2018)
 DOCUMENTAÇÃO DE CASOS DE USO

A documentação de um caso de uso fornece

instruções em linhas gerais de como será
seu funcionamento, quais atores poderão
utilizá-lo, quais atividades deverão ser
executadas pelos atores e pelo sistema, qual
evento forçará sua execução e quais suas
possíveis restrições, entre outras
informações.

22

(GUEDES, 2018)
 COMO IDENTIFICAR OS CASOS DE USO p1

È necessário determinar as funcionalidades

necessárias ao software, ou seja, todas as
funções e serviços que correspondem aos
requisitos funcionais declarados pelos
stakeholders como necessários ao sistema.
1) uma maneira de auxiliar a identificação
das funcionalidades é verificar a lista dos
atores que comporão o sistema e quais os
objetivos de cada ator;

23

(GUEDES, 2018)
 COMO IDENTIFICAR OS CASOS DE USO p2

2) verificar a lista de requisitos

funcionais estabelecidos nas
conversações com os stakeholders e
se cada um deles possui um (ou até
mais) caso de uso especificando seu
comportamento e, obviamente, qual
ator ou atores pode(m) utilizá-lo;

24

(GUEDES, 2018)
 ASSOCIAÇÃO

As associações representam interações ou

relacionamentos entre os atores e os casos de uso
que fazem parte do diagrama ou os
relacionamentos entre os casos de uso e outros
casos de uso.
Os relacionamentos entre casos de uso recebem
nomes especiais, como inclusão, extensão e
generalização

25

(GUEDES, 2018)
 GENERALIZAÇÃO/ESPECIALIZAÇÃO p1

Este relacionamento aplica os princípios de

herança da orientação a objetos, permitindo que os
passos descritos em um caso de uso sejam
herdados por outros casos de uso que
especializam o caso de uso original chamado
geral.

26

(GUEDES, 2018)
 GENERALIZAÇÃO/ESPECIALIZAÇÃO p2

Também pode ser aplicado sobre atores.Um

exemplo de generalização/especialização entre
atores em que existe um ator geral chamado
Pessoa e dois atores especializados chamados,
respectivamente, Pessoa Física e Pessoa Jurídica.

27

(GUEDES, 2018)
 ASSOCIAÇÃO DE 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. Quando isso
ocorre, a documentação dessa rotina é colocada
em um caso de uso específico para que outros
casos de uso utilizem esse serviço.
Uma associação de inclusão é representada por
uma linha tracejada contendo uma seta em uma de
suas extremidades, a qual aponta para o caso de
uso incluído no caso de uso posicionado na outra
extremidade da linha. As associações de inclusão
costumam apresentar também um estereótipo que
contém o texto “include. 28

(GUEDES, 2018)
 ASSOCIAÇÃO DE INCLUSÃO p1

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. Quando isso
ocorre, a documentação dessa rotina é colocada
em um caso de uso específico para que outros
casos de uso utilizem esse serviço.
Uma associação de inclusão é representada por
uma linha tracejada contendo uma seta em uma de
suas extremidades, a qual aponta para o caso de
uso incluído no caso de uso posicionado na outra
extremidade da linha. As associações de inclusão
costumam apresentar também um estereótipo que
contém o texto “include. 29

(GUEDES, 2018)
 ASSOCIAÇÃO DE INCLUSÃO p2

Percebemos que, sempre que um saque ou

depósito ocorrer, deverá ser registrado para fins de
histórico bancário.
30

(GUEDES, 2018)
 ASSOCIAÇÃO DE EXTENSÃO p1

São utilizadas para descrever cenários opcionais

que podem ser estendidos pelos comportamentos
de outros casos de uso.
Os casos de uso estendidos descrevem cenários
que apenas serão executados em situações
específicas quando determinadas condições forem
satisfeitas.
As associações de extensão têm uma
representação semelhante às de inclusão, sendo
também representadas por uma linha tracejada,
diferenciando-se pelo fato de a seta apontar para o
caso de uso que utiliza o caso de uso estendido e
por haver um estereótipo contendo o texto “extend”
31

(GUEDES, 2018)
ASSOCIAÇÃO DE EXTENSÃO p3

32

(GUEDES, 2018)
 ASSOCIAÇÃO DE EXTENSÃO p2

O cliente informará um nome-login e uma senha

válidos e lhe será permitido acessar o software.
Contudo, pode acontecer de o cliente estar
acessando a esse formulário pela primeira vez e
não possuir cadastro no sistema.
Ao prever essa possibilidade, o formulário permite
que o cliente se registre, apresentando-lhe a opção
de pressionar o botão “Autorregistrar” para se
cadastrar no sistema. Obviamente, o cliente só
fará isso na primeira vez.

33

(GUEDES, 2018)
 RESTRIÇÕES EM ASSOCIAÇÃO DE EXTENSÃO
p2
Restrições são compostas de 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.

34

(GUEDES, 2018)
RESTRIÇÕES EM ASSOCIAÇÃO DE EXTENSÃO
p2

35

(GUEDES, 2018)
 RESTRIÇÕES EM ASSOCIAÇÃO DE EXTENSÃO
p2
Restrições são compostas de 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.

36

(GUEDES, 2018)
 MULTIPLICIDADE

Restrições são compostas de 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.

37

(GUEDES, 2018)
 MULTIPLICIDADE p1

Restrições são compostas de 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.

38

(GUEDES, 2018)
 MULTIPLICIDADE p2

Percebemos que um ator Sócio utiliza o

caso de uso Cadastrar Sócio somente
uma vez, enquanto o ator Funcionário
pode utilizá-lo muitas vezes.
Da mesma forma, percebemos que
esse caso de uso só pode ser utilizado
por um sócio e um funcionário por vez.

39

(GUEDES, 2018)
 ESTERIÓTIPO

Poderíamos querer deixar bem claro que o caso de

uso Abrir Conta refere-se a um processo.
Assim, poderíamos atribuir-lhe o estereótipo
<<process>>, cujo objetivo é deixar explícito que o
caso de uso em questão refere-se a um processo.
Esse tipo de estereótipo é apresentado na parte
superior do componente, acima da descrição de
seu nome.

40

(GUEDES, 2018)
 FRONTEIRA DO SISTEMA

Uma fronteira permite identificar um

subsistema ou mesmo um sistema completo,
além de destacar o que está contido no
sistema e o que não está.

41

(GUEDES, 2018)
SISTEMA de CONTROLE BANCÁRIO

42

(GUEDES, 2018)
 SISTEMA DE TELEFONE CELULAR p1

• O celular oferece o serviço de realizar chamadas, no

qual o usuário deve informar um telefone para que o celular
ligue. O celular deve registrar as últimas chamadas.
• Semelhante ao serviço de chamadas, o telefone
oferece o serviço de mensagens, em que o usuário deve
informar o número de telefone para o qual deseja enviar a
mensagem. O celular deve igualmente registrar as últimas
mensagens.
• O aparelho oferece o serviço de agenda, por meio do
qual é possível cadastrar os diversos contatos do usuário.
Cada contato armazena o nome do contato e seu telefone.
Caso o usuário consulte um telefone já existente, ele
poderá ligar para esse contato ou enviar uma mensagem.
O sistema deve guardar as últimas ligações feitas, bem
como as últimas mensagens enviadas. 43

(GUEDES, 2018)
 SISTEMA DE TELEFONE CELULAR p2

• O celular oferece também o serviço de recebimento

de chamadas. O sistema deve avisar o recebimento de
uma chamada por meio do toque de uma música e o
usuário pode aceitar a chamada ou não. As últimas
ligações também devem ser gravadas.
• Da mesma forma, o sistema deve oferecer o serviço
de recebimento de mensagens, devendo também registrar
as últimas mensagens recebidas.
• O celular oferece ainda o serviço de despertador, no
qual o usuário pode cadastrar e/ou ativar um ou mais
horários para despertar.
• O sistema oferece o serviço de tons, no qual o
usuário pode selecionar, entre muitas músicas possíveis, a
que mais lhe agrada para avisá-lo do recebimento de uma
chamada ou mensagem, ou para despertá-lo.. 44

(GUEDES, 2018)
SISTEMA DE TELEFONE CELULAR p3

45

(GUEDES, 2018)
 MODIFICANDO DONO ou GRUPO

OBRIGADO !!!
@profjsflavioalves
ZAP 9750-2901

46