:s

L1ML -1550

=­
=-
~
-
<:
""~

=- :li:
i
...z
a;

3.1. Conceitos e Componentes do

~ ~
'~
<:

~
>
li:
11­
...
li
Diagrama de Casos de USO
:E

~
Bloco de Construção do Aprendizado

=-
li

s
ir
~

=- .
15
o
'"
o

:11I
;li

=­:11

:11

=­
=­:11
:iI
:11
:.w
:11
INSTITUTO INFNET ·115
d
 UML-1550

oi
c
-
E

!:i
o
.«
Coisas da UML
o­
«
o
:>
c
w
tu • A UML define "coisas" • Estereótipo:

z
(things) que podem ser
L
lL
~

~ -
a:
on, usadas em vários -<-<aetor><=­ ~
cn
oc diagramas: Usuário
«
ii:w
tn
w
a:.
o
.«
tn

• Estereótipos: são extensões

de elementos do modelo.
Usuário

• Anotação:

I~

tn

o
• Anotações: textos que
l::
w
a: podem ser colocados em o usuário deve~
C
tn
o
qualquer parte do diagrama estar logado
tn para usar esta
oc e que contém informações
oI­ opção.
adicionais sobre o diagrama.

116

A UML define "coisas" que podem ser usadas para aumentar a clareza e significado dos
diagramas:
Estereótipos
Os estereótipos são extensões de elementos do modelo. Podem ser usados para denotar
especializações significativas de classes. Os atores, por exemplo, são tratados pelas ferramentas
de modelagem como classes estereotipadas.
Os estereótipos podem ser indicados através de ícones próprios, ou incluindo-se o nome do
estereótipo em aspas francesas (os caracteres «», representados nos desenhos por« »).
Existem estereótipos pré-definidos e há a possibilidade de criar novo estereótipo para
diferenciação de elementos do modelo, ampliando assim a definição de especificações de maneira
gráfica.

Anotações
As anotações são pequenas caixas que podem ser utilizadas em qualquer ponto de qualquer
diagrama. Elas são preenchidas com informações relevantes ao leitor. Sugere-se que anotações
sejam usadas em casos bem específicos para não poluir demais os diagramas.
Ivar J acobson propõe a divisão das classes deanálise de acordo com estereótipos que foram
incorporados ao padrão oficial da UML. Esses estereótipos são: Entidades ou Entity(tabelas),
Fronteiras ou Boundary(telas) e de Controle ou Control(conexão com banco, gerenciador de
impressão, ...).

INSTITUTO INFNET - 116

::J
UML-155D

=z

~
-­
:i o
<
o­
Casos de USO: Conceitos
«
~j1
:3 .tl.
• Um caso de uso descreve o comportamento do
Z
.L.
~
sistema do ponto de vista do usuário, fornecendo
:t .2 9
uma descrição funcional.
:< • Este diagrama descreve interações do sistema com
:3 ........""
>
o exterior (atores).
<:"" • Novas funcionalidades são agregadas ao contexto
:3
..'" o com a inclusão de novos elementos no diagrama.
'ii
~ • Finalidade:
:t
c
:I lO:
.:;;
'5
- Descrever os requisitos funcionais do sistema - O que o
sistema deve fazer;
- Descrever claramente as responsabilidades que devem
~ ser cumpridas pelo sistema.
117

:3
~ o diagrama de caso de uso descreve as funcionalidades do sistema com suas interações com
o mundo exterior. Representa uma visão de alto nível da funcionalidade do sistema.
No desenvolvimento de novas versões do sistema, novas funcionalidades são agregadas ao
:3 contexto através da inclusão de novos elementos no diagrama.
Tem por finalidade:
:I • Descrever os requisitos funcionais do sistema de maneira consensual entre usuários e
desenvolvedores;
~ • Descrever claramente as responsabilidades que devem ser cumpridas pelo sistema;

=a Também pode ser usado na modelagem de negócio. Esta atividade visa o desenho do
processo, independente da implantação de sistemas, com o objetivo de:
• Mostrar à empresa uma visão do que o mundo externo ganha ao se relacionar com a
:I
empresa.
• Entender e documentar o que a empresa faz.
:­ • Auxiliar no trabalho de reengenharia.
A modelagem de negócios ou comercial abrange um nível maior dentro da empresa do que a
:I
simples modelagem do sistema a ser desenvolvido. Ela é utilizada para mapear os processos da
empresa e mostrar como a mesma funciona.

:11

;ti
INSTITUTO INFNET - 117
d
eb
:
 UML-1550

<i.
'"
:;
o
.« Componentes.
~
U
=>
'"ti;w • Em um diagrama de caso de uso aparecem o

z
L u,
~ ator, gerador de estímulos no sistema, e o

a:
o
Q.

s
'">a:«
w
processo que vai absorver esses estímulos, o
caso de uso propriamente dito.
-
~

'"w
ÇI: l
F
",Y-t'....((~·
10'
t}""
" '-'.. t-,"
"ri/ ~~~Y
o
.«
'"'"o ~ri~ i t: ;',~~' C=~
l::
w
a:
Õ
~ lf
\idJ
(j 9. '1_-------.;
e
de cas:_ :80
_
l~') Ator ~
'"o , 't:
'"o
'"o
I-­

118

Ator - Agente que irá interagir com o sistema

Comunicação, Interação ou Estímulo - Comunicação do ator com o sistema
Caso de Uso - Funcionalidade do sistema

-
~

-
~

-
~

INSTITUTO INFNET - 118

-

=­ UML-1550

:11

<
::
:11 ...
~
'-"
Conceito de Ator­
~
~ Li:
• Ator é um agente que interage com o sistema;
""
Z
.L
~
~
• Um ator é uma classe, não uma instância.
=-
-6 ­
L
lO
>2 • Representa uma regra, um papel e não um usuário
;q
individual do sistema.
.. >

=-
:I:
.u.
.u
:I:
• O nome do ator deve refletir o seu papel.
..
<
:I ::>
:;;
• Exemplos de atores: operador, cliente, gerente,
~ atendente, consultor, sistema financeiro, sistema
s
~ §;:: contábil, tempo, balança eletrônica, sensor de
temperatura.
:I
I 119

:I i

:I Ator é um agente que interage com o sistema, mandando ou recebendo mensagens, trocando
informações com o sistema. Representa o mundo externo, podendo ser pessoas, máquinas,
dispositivos ou outros sistemas - alguns atores típicos são operador, cliente, gerente, computador,
:I impressora, dispositivo de comunicação de rede.
Um ator é uma classe e não uma instância. Representa uma regra, um papel e não um
:I usuário individual do sistema. Um usuário pode desempenhar vários papéis e um papel pode ser
representado por vários usuários. O nome do ator deve refletir o seu papel.

:t
:t
:J

,,
:3

,
-
INSTITUTO INFNET -119
!i
 UML-1550

iiii
iiii

<i.
c
~
o
'<1;
~
o
Atores ..
.­
::>
c
UI

Iii
z
• Um Ator é uma classe com um ícone

u,
~
o:
O
padrão.

<l.
CIJ
O
C

<I;

• Exemplos de atores:
6:UI

~ ~ ~ ~ ~
CIJ
UI
o:
O
'<1;
CIJ
CIJ
O cliente gerente usuário vendedor correntista
m
o:
C

~ ~ ~ ~ ~
CIJ
O
CIJ
O
C
O
t­

robô

-
sistema contábil ba1ança sensor 'WIE!b service
;:

120

-
~

Em UML, um ator é uma classe com um ícone padrão que pode conter atributos e
relacionamentos. Permite relacionamento de generalização, que são usados para descrever
características comuns entre vários atores.
A figura mostra exemplos de atores de vários sistemas:

• o cliente, o gerente e o vendedor de um loja;

• o usuário de uma agenda eletrônica;

....
• o correntista e o sistema contábil de um banco;

• uma balança eletrônica de um sistema de controle de cargas;

• o sensor de temperatura de uma usina atômica;

• o robô de uma linha de montagem de carros;

• qualquer web service de uma operação entre empresas (B2B).

-
E

-
~

-
jiiiii

INSTITUTO INFNET· 120

-
E
:51

=­ o<
:51
.....
..J
o
o«
c..>
Como Identificar os Atores
-c
o
:::l

~ ,
C
U
l-
U
Z
• Para facilitar a identificação dos atores faça
\
L
ó?i
:: as seguintes perguntas:
:iI D
e,
~
- Quem irá usar as funcionalidades básicas do I
C
CC

.. sistema?

:>
:m:
~ ~

=­
~

..""..

O
o«

O
:ui
- Quem irá administrar e manter o sistema?

- Quais os dispositivos de hardware necessários

\ I
:
....
:t:
3: para o sistema? I
r

=­
O
O
O - O sistema irá interagir com outros sistemas?
~

31

ia

=­
:11

:­
=­
11

INSTITUTO INFNET - 121

li
 lIML-I550

<i
Cl
~
o
.«
C>
Caso de Uso
«
U
::> /
o
W
f­
W

• E uma seqüência de ações que um sistema

u,
:!E
a:
oa.
desempenha para produzir um resultado
UJ
o
c
observável por um ator específico.

-
«
>
• O nome do Caso de Uso deve ser uma frase ~
a:

UJ

W'
a:

.«
UJ
indicando a ação que realiza.
(f)
o
!::
W • Um caso de uso é um conjunto de passos e
'.t:
c::
Õ
(f)
o
UJ
o tratamento das suas exceções.
o
Cl
o
f­

I----------------~----------- ­
124

o Caso de USO em si é uma sequência de ações que um sistema desempenha para produzir
um resultado observável por um ator específico. Em outras palavras, um caso de uso define uma
funcionalidade do sistema com um conjunto de ações tomadas pelo ator e a previsão da reação por
parte do sistema.
O Caso de Uso é uma classe, não uma instância. A sua especificação descreve a
funcionalidade como um todo, incluindo erros, possíveis alternativas e exceções que podem
ocorrer durante sua execução. O nome do Caso de Uso deve ser uma frase indicando a ação que
realiza.
Cuidado para não identificar um caso de uso no lugar de um passo! Um caso de uso tem um
conjunto de passos e trata as exceções desses passos. Na descrição do caso de uso é que teremos
que pensar quais as ações que o caso de uso desempenhará.

-
E

-
INSTITUTO INFNET • 124
E
:9
UML -1550

::!

<i.
Cl

:=i I­
..J
o
o«
o­
Exemplos de Casos de USO

«
o
::J

::i
Cl
W
I­
W
Z
u,
as
tI:

::I oo..
rn
o
Cl
«
>
tI:

~
W
rn
w
tI:
o
o«
rn
rn
::I oI­
Ui
tI:
Õ
rn

::s O
rn
O
Cl
O
I­

::t
125

::I

A figura acima mostra exemplos de casos de uso de vários sistemas:

::I

• Supermercado: Fechar caixa

::I
• Universidade: Fazer Inscrição
• Financeira: Aprovar Crédito
::I
• Banco: Incluir Movimento, Depositar
• Qualquer sistema: gerar estatísticas.
:3

Repare que todos os casos de uso citados são operações complexas que englobam diversas
=t
atividades, tanto por parte do sistema, quanto dos atores envolvidos. Pode-se dizer que um caso de
uso é uma conversa completa entre o ator e o sistema.

=t

:=I

:=:t

:I

:t

INSTITUTO INFNET - 125

~
 UML-1550

<i
o
!::;
o
.«
o­
Características e Regras
«
o
:o
o
w • É sempre inicializado por um ator e devolve uma resposta.
li;
Z
u,
~
• São conectados aos atores com associações de

a:
oO-

CIl

o
o
«
comunicação. A associação é bidirecional.

• Um caso de uso tem início, meio e fim. -

~

-
>
a:
w ~
ffl
a:
o
.«
CIl

CIl

o
l­
m
a:
E Consultar C1ientes

-
CIl
o
CIl
o
gerente
E
o
oI­

126

-
~

Um caso de uso, como dito anteriormente, representa uma funcionalidade do sistema: tem
início, uma entrada, uma solicitação, tem meio, um processamento, uma gravação e tem um fim,
uma confirmação, uma impressão, o resultado de uma consulta na tela.
A figura mostra dois atores interagindo com o sistema. A operação "Consultar Clientes"
pode ser executada tanto por funcionário quanto por gerente. A operação "Cadastrar Cliente" pode
ser efetuada apenas pelo ator funcionário, enquanto "Consultar Crédito" só pode ser iniciada pelo
gerente.
Repare que não há indicação de ordem no diagrama, apenas as funcionalidades principais do
ponto de vista dos atores.

-
INSTITUTO INFNET - 126
E
:11
UML-1550

::11I

:11I -
c.:> Estímulos
c

:11I Oi:
;;:
...
z
• Um ator se comunica com o sistema enviando e recebendo
mensagens para um Caso de Uso.
~
'.:
• Mensagens = Estímulos.
:11 i:
,!

< • Existem dois tipos de atores:

>
...
li:

:11I '"
.li.
li:
- Ativos, iniciam algum Caso de Uso.
<: - Passivos, recebem mensagens de um Caso de Uso.
'"
:11. !
:ir
l§
Ator Passivo

=-
~

~ ------<~uar vV·_-+
=­ caixa Sistema Financeiro

=­
127

=­ Um ator se comunica com o sistema enviando e recebendo mensagens - estímulos - para

um caso de uso, que é ativado. Além do ator que o inicializou, o caso de uso pode mandar

=­
mensagens para outros atores.
Os atores são chamados de ativos quando iniciam algum caso de uso e passivos quando
somente participam dele, sem iniciá-lo. Atores passivos recebem mensagens, portanto em um

=­:li diagrama são identificados por setas que chegam até eles.
Atores passivos são, de maneira geral, dispositivos de hardware ou outros softwares com o
qual o sistema se conecta. Por exemplo, em uma operação de venda, deve ser gerado um
movimento financeiro:

=­:11
,.
3

:11

:11

INSTITUTO INFNET - 127

:!I
 UML -155{;1

ci
"~
o
'<1:
o­
Relacionamentos
<I:
tJ
::>
"w
f­
w
• Os relacionamentos indicam a existência de

Z
U-
i!:
te
comunicação entre atores e casos de uso.

o
"­
'"
o • Um caso de uso pode estar associado a mais

"<I:
1é
w
'"
w
te
'o
'<1:
'"
'"
o
!:::
w
de um ator.

• A comunicação será representada como

ligação sem direção,(êíilgeral.
-,
--
iiii

E
te
iS • Quando a iniciativa parte o caso de uso a

o'"
'"
o comunicação deve ser direcionada por uma

"o
f-
seta.

128

-E
Relacionamentos
Diagramas de casos de uso podem especificar os relacionamentos entre casos de
-
~

uso e atores. Os relacionamentos indicam a existência de comunicação entre

atores e casos de uso. Um caso de uso pode estar associado a mais de um ator,
quando a sua execução requer a participação de diferentes atores.

-
~

-
r

INSTITUTO INFNET -128

::!
UML-1550

::i

oi.
Q

:=i ~

o
.....
-:(
Generalização
'O­
<t
U
:::>

::I Q
!.U
.....
W
Z
• Os diagramas de casos de uso podem ser
u,
z
o: simplificados por meio da herança entre
::I oe,
'"
o atores.
Q
<t
>
o:
:::I w
'"
I;!J
o:
o gerente
<
'"
:!i '"
e
ii
o:
E
'"
o
::I '"
o
Q
o
l­
gerente financeiro

:::I
129

~
Os diagramas de casos de uso podem ser simplificados por meio da herança entre atores.
~ Neste caso, mostra-se um caso de uso comum aos atores específicos, que se comunicam apenas
com o ator genérico.
~ A figura mostra as especializações de "Gerente" em "Gerente de Compras" e "Gerente

=­
Financeiro". Trata-se de uma relação de herança entre os atores, ou seja, todas as características e
funções de "Gerente" serão herdadas pelos atores que estão abaixo dele.
Na figura abaixo é mostrado outro exemplo, usado principalmente em sistemas que possuem
diferentes níveis de permissão de uso:
=ti
::li
~
Secretária
::11

fJ
=­
:;li
~
Supervisor
<l ~
Diretor
A secretária pode usar algumas runcionanuaoes ao sistema, o supervisor pode usar as

:11
mesmas da secretária além de outras específicas e o diretor pode usar funcionalidades dos dois e
suas específicas.

::li
INSTITUTO INFNET - 129
~
 L1ML -155:D
I
I
<i.
c
~
o
'00:
Generalização I
o­
00:
o
:::>
c
w ;1
lü
z
lL
~
a::
oc..
CIl
oc
00:
>
a::
w
CIl
.l:!
I

o
'00: !J"!rente de cOJlI:Iras gerent.e gerent.e ~inanceiro
CIl

s~
Ui
a::
15
CIl
o
CIl
oc Sí.JTwlar lil. uxo de
i
~ Caixa

130

Na figura acima, os dois gerentes podem consultar a avaliação de desempenho de seus I

subordinados além de suas tarefas específicas. Portanto, para simplificar o diagrama é criado um
ator genérico e feita a herança (generalização). Assim, as tarefas comuns são ligadas ao ator
genérico e as outras para os seus respectivos atores. I

Outro exemplo, um sistema de controle acadêmico de urna escola. A única operação que
urna secretária pode fazer é "Matricular Aluno". O supervisor também matricula alunos, mas
também contrata professores e agenda cursos. O diretor pode fazer tudo isso e também consulta
inadimplências.

I•
<J--­ <Jr---­
Secret.ária Supervisor Diretor
i
li!

Cont.ratar Pro~essor

I
Matricular JIl. uno ·

INSTITUTO INFNET - 130

•
4
:=li UML-1550

::11
~
:3 ~
::I
-e
o­
Casos de USO Secundários
<
:::
::li .. ir
.ll
Z
• Casos de uso secundários são utilizados
para facilitar a descrição de funcionalidade
=-
.;<!;

~
:t
::I
:::l
mais complexa.
<
>

:ti fi
'"
• Simplificam o comportamento dos casos de
~
::I
o<
:t
uso primários através dos mecanismos de
~ ã
~
Extensão e Inclusão.
:;­
'o"
~ 'o"
:::l
o
....

~
131

=­
:3
Notações especiais são utilizadas para facilitar a descrição de funcionalidade mais
complexa. Entre estas notações, destacam-se os casos de usos secundários, que simplificam o
comportamento dos casos de uso primários através dos mecanismos de extensão e inclusão.
Casos de uso primários são aqueles invocados por iniciativa direta de um ator; casos de uso
secundários são invocados em um passo de outro caso de uso. Os termos "primário" e
~ "secundário", quando referentes a casos de uso, não fazem parte da especificação da UML.

:=11
:li
:iI
:iI
~

::11

:11

=­
INSTITUTO INFNET -131
 UML-I550
I:
C
<i.
c
!:i
o Extensão C
'<t
o­
...:
o
:J
C
W
~
W
Z
• Essa notação pode ser usada para c:

representar fluxos complexos opcionais.

LI.
~
a:
oc,
f
Ul
oc
<t
• O caso de uso "estendido" é referenciado
>
a:
w
'ffia:
nas precondições do caso de uso "extensor". C
o
'<t
Ul

Ul

o
!:::
w
a:
t
Õ
Ul
o
Ul
o
~~---------Gir ~ t:
~<extend»
c Nota
o~
Caixa

C
132

r:

o caso de uso B estende o caso de uso A quando B representa uma situação opcional ou de
exceção, que normalmente não ocorre durante a execução de A. Essa notação pode ser usada para
representar fluxos complexos opcionais ou anormais.
A operação "Emitir Nota Fiscal" é uma funcionalidade que pode ser invocada ou não,
durante a operação "Efetuar Venda". Isso é verdade quando um produto é vendido com uma nota­
fiscal manual, no caso de compra de um eletrodoméstico. Nesse caso, o sistema não deverá emitir
a nota-fiscal a fim de evitar duplicidade de informações.
Observe também que o caso de uso que estende tem uma relação de dependência com o caso
de uso estendido (seta tracejada), ou seja, a 'Emitir Nota Fiscal' só pode ser executada se a
operação 'Efetuar Venda' for executada.
Na figura abaixo é mostrado o diagrama de um blog no qual o visitante acessa determinado
blog e pode ou não escrever comentários.

C::=.c_n~
>
,,

Visitante

INSTITUTO INFNET - 132

:2 UML-1550

:li
~
:11 -
.:<o­ Inclusão

~
::11I iL
i
• Essa notação pode ser usada para representar subfluxos
...:i!:
z complexos e comuns a vários casos de uso.
:2 ~
i:
i
• O caso de uso "incluído" é referenciado no fluxo do caso
<:
de uso "que inclui".

:ti ..
>
E

~ ~"'~""V.
.u.
.u.
E

..!
.:<
. «Include»
• - ~-_

=ti :ir
Super~sor
• - - --.Jo.

3 GxarEsto~
:a 5
""o
5
---Guarv~'
«include»
_,S?'

::11
caixa

133
::11

:2
o caso de uso A inclui o caso de uso B quando B representa urna atividade complexa,
comum a vários casos de uso. Essa notação pode ser usada para representar subfluxos complexos e

=­ comuns a vários casos de uso. O caso de uso "incluído" é referenciado no fluxo do caso de uso
"que inclui".
"Baixar Estoque" representa um comportamento comum a "Fazer Inventário" e "Efetuar
:li Venda",
Observe também que o caso de uso que inclui tem urna relação de dependência com o caso
:ti de uso incluído (seta tracejada). Ou seja, "Fazer Inventário" e "Efetuar Venda" só podem ser
executadas se "Baixar Estoque" também puder.

::li No exemplo abaixo, urna empresa que passou por dificuldades financeiras baixou urna
norma que obriga a todo funcionário solicitar a aprovação de despesas antes de efetuar urna
compra.
::11
::11I
::11
::11
:11
INSTITUTO INFNET - 133
~

 UML-1550

<i.
c
-

!:i
o
.« Desenho do Diagrama
~
g
c
W

I­

• 10 Identificar os Casos de Uso

Z

u,
- A identificação consiste em definir uma lista com os

~
o:
possíveis casos de uso. -=­
ol1. ~
(J)
oc - Uma vez identificado os atores, as seguintes perguntas
«
6:w
(J)
W
0:'
o
.«
(J)
auxiliarão na identificação dos Casos de Uso:
• O que (quais funções) o ator necessita do sistema?
• O ator necessita criar, modificar, excluir, ler ou armazenar
-

r
(J)
ol- informações no sistema?
m
o: • O ator precisa ser notificado sobre eventos do sistema ou
Õ
(J) informar o sistema sobre algo?
o
(J)
oc • O trabalho do ator poderia ser simplificado ou mais eficiente
o
I­
através de novas funções do sistema? Quais?
• Quais entradas e saídas, juntamente com a origem e destino
que o sistema requer?

138

o primeiro passo para se chegar ao desenho do diagrama de caso de uso é a identificação

dos casos de uso. Já visto que um caso de uso é uma funcionalidade no sistema, (tem início, meio e
fim) o que temos que fazer é tentar identificar quais serão os casos de uso a serem descritos para o
sistema a ser desenvolvido.
A identificação dos casos de uso (use cases) não é trivial mas se toma mais fácil com a
prática.

-
~

INSTITUTO INFNET -138

EiUs
::J
UML-1550

::I

<i
::::
:I o
<:
Exemplo: Sistema de Help Desk
c­
<t
~

::I ::;
oU

:uz At~C'
~ Eventos Casos de Uso ~ ""'­
~

::I ~
'"
Vendedor fecha contrato Fechar Contrato IVendedor \ "I
..
o
::::
Vendedor cadastra cliente Cadastrar Cliente \ Vendedo~,/
:2 .'"""
>
E
Cliente solicita serviço Solicitar Serviço (élie~
o

~/
o«
:c Supervisor aloca técnico Alocar Técnico
::I '"
o
....
i:i
Técnico finaliza serviço Finalizar Serviço
-
(f'ecn~Q
.
'"
Q
<,

'"
o Supervisor consulta
:11 '"
o
::::
o
....
pendências
Consultar Pendências Supervisor

Cliente paga conta Pagar Conta Cliente

:11

139

:11

A tabela acima mostra os eventos, casos de uso e atores de um sistema de controle de help
::I desk. Os casos de uso sempre tem um ator que os inicia.
Note que cada caso de uso tem varias ações a serem executadas, é composto de começo
2 meio e fim. Por exemplo, para cadastrar o cliente deve ser verificado se o CPF (ou matrícula) do
cliente já está cadastrado, a busca do endereço através do CEP, e existe a digitação dos dados
propriamente dita.
:11I

:11I

=­
=­
=­
=­:I

:I

INSTITUTO INFNET· 139

~

PWI.A .4" 4J $--44=

 UML-1550
=
==
itilli

<i
a
~
O
-o:
o­
Desenho do Diagrama
<l:
O
:::>
a
w
];j
zu,
• 2° Descrever os Casos de USO
~
c:
O
- Consiste em descrever a interação entre o caso
""cn de uso e o ator, o passo a passo que espera ser
O
a
<l:
>
c:
w
executado se der tudo certo (curso ou fluxo
cn
w
c:
O
principal) e suas possíveis exceções caso ocorra
~
cn
O
algum problema (~~$iygsJ.
l::
w
c:
C
- A descrição servirá para validar a existência do
cn
O
cn
O
caso de uso e também seu possível
a
~ desmembramento.

140

É através da descrição do caso de uso que descobrimos se o caso de uso está complexo ou se
ele na verdade é um passo de outro caso de uso. Por exemplo 'Imprimir boleto' é um caso de uso?
Se a conotação for o ordenamento dos dados para uma impressora então possivelmente este é um
passo de outro caso de uso, como por exemplo 'Visualizar boleto' que tem uma ação de impressão
que pode ser executada ou não.
A atividade 'Imprimir boleto' pode ser um caso de uso que busque dados da compra (valor a
ser pago, data de pagamento) a partir do identificador do cliente e gere o código de barras a partir
destas informações para visualização em tela e impressão.

~
-

INSTITUTO INFNET • 140

;
=

:I

UML-1550

<é
Cl

::i I­
-'
o
<
c>
Desenho do Diagrama
«

=
o
::>
Cl
W
I­
W
Z
• 2° Descrever os Casos de USO
u..
~
o:: - A descrição dos casos de uso pode incluir:
:::I o
O­

'"
o • as suas precondições, ou seja, as condições que
Cl
«
>
o:: supõem estejam satisfeitas, ao iniciar a execução de
::I w
'"
w
o::
um caso de uso;
o
< • o fluxo principal, que representa a execução mais
'"
:i '"
o
I­
iii
o::
normal da função;
2i
'"o • os subfluxos e fluxos alternativos, que representam
::I '"
o
Cl
o
I­
variantes que são executadas sob certas condições.

~
141

:I
::J Os fluxos dos casos de uso são detalhados por meio de descrições textuais. A UML não
impõe formatos obrigatórios para as descrições dos fluxos. A forma de descrição textual aqui
apresentada é semelhante às formas usadas pela maioria dos autores que utilizam os casos de uso.
::I
O detalhamento dos fluxos dos casos inclui no mínimo:
Pré-condições, ou seja, as condições que devem ser satisfeitas, ao iniciar a execução de um
:I
caso de uso;
Fluxo principal, que representa a execução mais normal da função;
=t Fluxos alternativos e subfluxos, que representam variantes que são executadas sob certas
condições.
::i A UML permite que diversas notações sejam utilizadas para descrever os detalhes dos casos
de uso. Uma rápida busca pela Internet revela inúmeros templates de documentação para casos de
:r­ uso.

::I

='

::i
::i
INSTITUTO INFNET - 141
::i
 UML-1550

..:
c
~
o
.«
o­
Desenho do Diagrama
--

«
tJ
::l
C
--=­
w
....
w
Z
• 2° Descrever os Casos deUso "---­

u,
~
a:
oQ.
- Os fluxos são comumente descritos em
rn
o
c
linguagem natural, na forma de uma seqüência
«
>
a:
w
de passos.
rn
w
a:
O·
.«
- Os atores devem aparecer explicitamente como
rn
rn
o sujeitos de cada passo.
1::
w
a:
E
rn
o
rn
o
c
o
....

142
E

Os fluxos são comumente descritos em linguagem natural, na forma de uma seqüência de

passos. Cada passo corresponde a uma ação de um ator ou do sistema; estes devem aparecer
explicitamente como sujeitos da frase. Outros atores podem aparecer como objetos verbais de uma
ação.
Condições e iterações podem aparecer, mas os detalhes destas devem ser descritos em
-

subfluxos, de preferência. Isso ajuda a manter a legibilidade do fluxo; que é essencial para garantir
o bom entendimento de todas as partes.

INSTITUTO INFNET -142

-
-,
UML-1550

- i

oi

~
C
l­
...J
o
-o:
o­
et
Exemplo: Efetuar Venda
(J
---q ::::l

liiiiiiiiiiÕÕ
C
w
l-
1. o Caixa faz a abertura da venda.
W
Z
lL
~
2. O Sistema gera o código da operação de venda.
a:
! oe, 3. Para cada item de venda, o Sistema aciona o subfluxo
o'" Registro.

=
c
et
>
a:
W
4. O Caixa registra a forma de pagamento.
'"a:w S. O Caixa encerra a venda.
o
-o:
'"'"o 6. Para cada item de venda, o Sistema aciona o subfluxo
:i t:::
UJ
a:
Impressão de Linha do Ticket.
Õ
In
o
7. O Sistema notifica o Sistema Financeiro informando:
::I In
oC Data, Número da Operação de Venda, "Receita", Valor
o
l­ Total", Nome do Cliente (caso tenha sido emitida a nota
fiscal).
::I
143

:t Lembre-se que na UML não existe padrão para a descrição do caso de uso, temos sempre
que saber qual o objetivo da utilização do produto que vamos fazer, para que se quer a descrição
dos casos de uso? Se for para servir de base para o programador efetuar seu trabalho poderemos
=t colocar informações mais técnicas, se servir para validar o escopo do projeto com o usuário,
deveremos capturar todas as regras do negócio em uma linguagem mais natural, a ser entendida
:I por pessoas não técnicas.
A descrição acima representa o fluxo típico do caso de uso "Efetuar Venda" de um
:I supermercado. Ela é feita como uma lista numerada para facilitar futuras referências e alterações.
Repare que os detalhes não são omitidos: no passo 7 são informados todos os dados necessários
para o sistema financeiro.
:­
:I
:­
:­
-
11

INSTITUTO INFNET -143

11

..

 UML-1550
-

-
~

-
~

-
oi
c
E
~
o
'..:
Exemplo: Excluir Mercadoria
~
(.J
::l
C
w 1. o Gestor de Compras seleciona a mercadoria.
tu

--

z
u, 2. O Sistema verifica se existe algum pedido pendente que
a:
cc
o contenha esta mercadoria. ~
n.
CIl
o
c
3. Se não houver pedido pendente contendo a mercadoria a
..:
>
cc
w
CIl
W
cc
...:
'0
CIl

CIl

ser excluída:
1. O Sistema desvincula a mercadoria dos fornecedores
(os fornecedores não mais fornecerão a mercadoria que
-
~

o
t:
esta sendo excluída).
w
cc
Õ 2. O Sistema faz a remoção da mercadoria.
CIl
o
CIl
o
4. Se houver pedido pendente contendo a mercadoria a ser
c
o
I­
excluída
1. O Sistema emite uma mensagem de erro.

144

o exemplo acima trata a ocorrência de uma exceção, que deverá ser a reação do sistema se
houver pedido pendente. O tratamento das exceções deverá constar na descrição do caso de uso.
Em casos simples as exceções podem ser colocadas dentro do fluxo típico. Em situações
maiores e mais complexas é mais legível descrevê-las em uma seção separada do documento.

INSTITUTO INFNET - 144

.ú
I
==
UML -1550

::I

<i
c
,,...
::J
...J

~
o
«
Elementos da Descrição
;,: • Sugestão para a descrição de caso de uso:

i'i
::I
JJ
~

JJ
...;!!;
Z
- Nome do Caso de Uso;

- Identificador (opcional) ;

~ ..s
e,

E
Descrição;

- Atores (opcional);

<
> - Pré-condições (opcional);

:::

:I
1.:
::
:.;;.
:::
Pós-condições (opcional);

...
:I - Caso de Uso que foi estendido (opcional);

'"
:: - Casos de Uso incluídos (opcional);

:I
:I
LI
%
3
Fluxos principal e alternativos.
,=
::I
. 'O
o
c
- Histórico de Alterações (opcional);
- Estado Atual (opcional) - "em desenvolvimento", "em revisão",
o
,... "revisto e aprovado", "revisto e rejeitado".
- Freqüência de Uso (opcional);
~ - Questões a respeito do Desenvolvimento (opcional);
145

::I

Os itens acima podem ser colocados em um documento de descrição de casos de uso.

::I
Algumas ferramentas case permitem que o documento de descrição seja associado ao caso de uso.
Existem muitos templates disponíveis para uso em livros e na internet. Na parte de referências da
::I
apostila existem links para os templates.

:I
;j

=­
~

=­
:11

:iI
:11
INSTITUTO INFNET -145

:!li

tiL 2%.
 UML-1550
-
~

<i
a
-
~

~
o
.«
C>
Exemplo de Descrição
«
o
=>
a
w
>­
w
z
• Nome: Matricular em Seminário
u,
~
• Descrição: Matricula um aluno existente
-
o::
o
o. ~
rn
o
a
«
em um curso.
>
o::
w
rn
w
o::
o
• Pré-condições: O aluno está registrado na =:
.«
rn universidade.
rn
o
>­
m
o::
C
• Pós-condições: O aluno será matriculado
e
rn
em um curso se ele atender aos pré­
=
o
rn
o
a
o
>­ requisitos e se existir sala disponível.
c
146

c
C
t::
e
'&:
e
!:
t:
~

I:
INSTITUTO INFNET -146
~

j .
=­ UML-1550

:w

=­ ~
-
~
'"
~
Exemplo de Descrição
:s
::;
'"
~
::
• Fluxo:
1. o aluno entra com o seu nome e número de inscrição, na tela
~
"UI23 Tela de Login".
:I
3
::.
~
2. O sistema verifica se o aluno pode se matricular em seminários, de
< acordo com a regra de negócio "BR129 Verificar a Possibilidade
>
para Matrícula em Seminários".
:I
...
li:
"­
"­
li: 3.0 sistema exibe a tela "UI32 Seleção de Seminário", indicando os
..

<' seminários disponíveis.

=­ 2
ir
~
4.0 aluno seleciona o seminário em que deseja se matricular.
5.0 sistema valida o aluno de acordo com a regra de negócio "BR13ü

=­ ! Verificar Pré-requisitos do Seminário".

~
6.0 sistema valida o seminário em relação ao horário do aluno, de
acordo com a regra de negócio "BR143 Validar Disponibilidade
para Agendamento".
~
147

=­
=­
:li
:11

=­
~

:11

:li

--
--
iI
INSTITUTO INFNET -147

_MA0M4 _ .f!!frio,_
 UML-I550 -
E

<i.
o
!:i
o
'<1;
o­
Exemplo Formatado
<I;
o
:::>
o
w
ti;
Z
LL
~
a:
on.
tn
o
o
-E
~
a:
w
fila:
'0
'<1;
tn
tn _~e~i~~~T; ~;~~i:Ii~:da6 ~_~~~O_~_;t~~c~;_;~t~~~~1~~r;s~minários, de acordo com aregra de n_~~~~~~~_ ~9 I
-
E

O
!:: O sistema exibe a tela "U132 Seleção de Semlnárlo", indicando os seminários disponíveis. -~l
w
a:
Õ O aluno seleciona o seminário em que deseja se matricular.

s o sistema valida a aluna de acordo com a regra de negócio "BR130 Verificar Pré-requisitos do Seminário",
(Jl
O ________ ~!i
O ; O sistema valida o seminário em relação ao horária da aluno, de acordo com a regra de negócio "BR143
O
l­ I Validar Di~??"~i.~i1idade para !:,~:_~~~.~ento". . . ,. .-1
"---------'" .
(Continua)

148

Fluxo (OU curso) típico, normal, ou principal é o que acontece se tudo der certo, nada falhar
e nenhuma condição de erro for executada.

-
~

INSTITUTO INFNET - 148

:S UML-1550

::J
<i
o

::J ::i
o
...:
o­
..:
Exemplo Formatado
u
::l
c
::I ui

kiz
(continuação)
-

~ Fluxos Alternativos
lI: (Passo 2) Caso matrícula não permitida

~
oa,
'"
oa
..: o sistema exibemensagem ~Você nãopodese matricular em seminários. Procure a secretaria docurso"
>
lI:

~
l!J Retornar ao passo 1 da Curso Normal
..,'"
lI:
O
>«
'"
'"
:=iI O
!­
!2:i
lI:
Õ
'"
O

~ '"
O
c
O
!­
Retornar ao passo 4 do Curso Normal

:li

=­:iI
149

Fluxo (OU curso) alternativo ou secundário é o espaço para prever todos os possíveis erros. A
descrição mostra como o sistema deverá reagir se determinada condição for falsa, pois este é o tipo
de informação que deverá constar e estar mapeada nos fluxos alternativos.
:iI
:31

=­:11

=­:s

:iI

:I

INSTITUTO INFNET -149

I: 4.4
 UML-1550

oi.
o
!:i
o
.« Desenho do Diagrama
~
o
::::l
o SystE"m

~ ~
UJ
f­
UJ Efet-.ar
Z
u, Venda
i: Cai~iro Sistema.
EC l'inancei.r1[J
O
e,

'"O
O
«
~
-
>
~
EC

UJ
Estoquista

'"
UJ
EC

C:<1rc~~
O
.« Bmi.tir Pedido

'"O'"
-
d.e.~ra.

~
~
f­
m
EC
Õ
~harC~~
'"
O
Gestor de
C~ras

'"O
O

O
f­
Vsuoirios

150
­
2

-
~

o diagrama de contexto da figura mostra as fronteiras do sistema de supermercado. Do lado

de fora estão os atores que interagem com o sistema. Do lado de dentro estão os casos de uso que
fazem parte do escopo definido para o sistema.
~
-

-
~

INSTITUTO INFNET - 150

E
::I
UML-1550

::s

,~

:s -
.;;:
J
Exemplo: Banco Money
~

:2 ii
Ü • Identificação de Atores e Casos de Uso:
z....

=-
~
:!õ
i:
- Atores:
~
• Pessoa
<:
:>

:2 li:
.Il
.Ir
.Il
:l:
• Cliente

- Casos de Uso:

..
.;;:

:=I :!!
:ii:
• Consultar Saldo
~ • Efetuar Depósito
:!!

~ :!! • Efetuar Saque

• Acessar Conta (Secundário)
~

=­
151

Descrição do Banco Money:

::JI O Banco Money deseja que seus correntistas possam operar as suas contas com caixas
eletrônicos.
:2 Os caixas eletrônicos permitem que o cliente acesse a sua conta-corrente, conta-poupança
ou conta especial e execute consulta de saldos, depósitos e saques.
:3 Para que o cliente possa fazer as transações de consultar saldo e sacar é necessário que já
esteja cadastrado e seja portador de uma senha de acesso.
:2 Qualquer pessoa pode fazer depósitos em cheque ou em dinheiro, basta informar o
número da conta.

:3 A partir desta descrição é possível identificar dois atores: Cliente e Pessoa. Não são o
mesmo ator pois executam tarefas de maneira diferente.
Também é possível identificar quais são as atividades que os atores irão executar no
:11I sistema: consultar saldo, saque, depósito e acesso a conta (senha de acesso).

:11I
:ti
::11I

:11

INSTITUTO INFNET -151

=ti
 UML-1550

<i.
<:>
~
~
Exemplo: Banco Money
0­
co:
U
:::l
<:>
...ww o NOME: Acessar Conta
Z
u,
o ATOR: Cliente
~
a: o DESCRIÇÃO: Validação do acesso da pessoa às informações e ações da

o conta.

c..
CIJ
o
<:>
o Fluxo Normal
co:
>
a:
1. Cliente ~assa cartão do banco na leitora. )
w
CIJ 2. Sistema identifica número da conta. /'
w
a: 3. Cliente informa senha. /.
o
.co:
CIJ
4. Sistema valida senha. _/
CIJ

~
5. Sistema lista operações (consulta saldo e efetuar saque) ../
W o Fluxos Alternativos

a:
Õ
CIJ - Passo 1: Caso cartão inválido ou bloqueado

o
CIJ 1. Sistema exibe mensagem,
o
<:> 2. Retomar ao passo 1 /

...
o
- Passo 4: Caso senha inválida

152
1. Sistema exibe mensagem
2. Retomar ao passo 3
-
~

Descrição completa do caso de uso:

NOME: Acessar Conta

ATOR: Cliente
DESCRIÇÃO: Validação do acesso da pessoa às informações e ações da conta.
Fluxo Normal
Cliente passa cartão do banco na leitora.

Sistema identifica número da conta.

Cliente informa senha.

Sistema valida senha.

Sistema lista operações (consulta saldo e efetuar saque)

Fluxos Alternativos
Passo 1: Caso cartão inválido ou bloqueado

Sistema exibe mensagem

Retornar ao passo 1

Passo 4: Caso senha inválida

Se a senha for inválida pela terceira vez Sistema bloqueia conta

Senão Sistema exibe mensagem

Retornar ao passo 3
I f;

INSTITUTO INFNET - 152

#!idJt!!2L $ a
~
~
UML-1550

::;

<i
c
::5 I­
...J
o
>«
Exemplo: Banco Money
Q.
«
o
:::>

:=:i o
w
I-
w
• NOME: Efetuar Depósito
Z
LI..
• ATOR: Pessoa
~
a: • DESCRIÇÃO: Depósito de cheque ou dinheiro em contas do banco.
~ oa­
o:>
• Fluxo Normal
oo 1. Pessoa solicita depósito.
«
>
a: 2. Pessoa informa agência e conta.
:i w
o:>
w
a:
O,
3.
4.
Sistema verifica conta.
Pessoa informa total e tipo (cheque/dinheiro)
>«
o:> 5. Sistema exibe nome do favorecido e valor de depósito.
::J o:>
o
t::
w
a:
6.
7.
Pessoa confirma depósito.
Sistema abre gaveta.
Õ
o:> 8. Pessoa insere envelope com depósito.
o
:=I o:>
oo
o
I­
9. Sistema emite comprovante
Fluxos Alternativos

- Passo 3: Caso agência ou conta inválidos

:=I • Sistema exibe mensagem

• Retomar ao passo 2
153

~
Descrição completa do caso de uso:
:I
NOME: Efetuar Depósito
~ ATOR: Pessoa
DESCRIÇÃO: Depósito de cheque ou dinheiro em contas do banco.
:I Fluxo Normal
Pessoa solicita depósito.

:iI Pessoa informa agência e conta.

Sistema verifica conta.

=­:I" Pessoa informa total e tipo (cheque/dinheiro)

Sistema exibe nome do favorecido e valor de depósito.
Pessoa confirma depósito.
Sistema abre gaveta.
Pessoa insere envelope com depósito.

=-­ Sistema emite comprovante

Fluxos Alternativos
Passo 3: Caso agência ou conta inválidos
:I Sistema exibe mensagem
Retomar ao passo 2
:f
:I

INSTITUTO INFNET· 153

SI

 UML-1550

~
~
.o,( Exemplo: Banco Money
o­
..:
(J
::l
C
w
tu
z

----I~arDep~
LL
~
a:
oQ.
cn Pessoa
oc
..:
>
a:
W
cn
w
a:
..o.:
cn
CfJ
o
C
w
a:
Õ
cn
o Cliente
cn
oc
o
....

154

No diagrama acima o cliente é uma especialização de pessoa pois além de efetuar depósito
ele também pode efetuar saque e consultar saldo.
O caso de uso "Acessar Conta" é incluído pelos casos de uso "Efetuar Saque" e "Consultar
Saldo" pois é necessário que o cliente tenha um cartão e senha para poder executar estas
operações.

INSTITUTO INFNET - 154

$!2 a x
 I

<i
o
'::i
o
'<t
C-"
<t
Conclusão da UA -3
o
=>
o
• Casos de Uso servem para capturar os requisitos
w
li;
Z
do sistema e para validar com o cliente o escopo
u,
~
Ir
do projeto.
o
n.
til
o
• Não desenhe associação entre atores.
o
<t
>
Ir
w
• Caso de uso não é uma atividade simples, é um
til
W·
Ir conjunto de passos.
o
'<t
til

til

o
• Evite falsos requisitos:
!:::
w
Ir
- Requisito falso tecnológico: deve-se abstrair todos os
Õ
til
o
problemas de tecnologia.
til
o
o - Requisito falso arbitrário: função que o sistema não
~ precisa ter para atender ao seu propósito.

156

•
li

INSTITUTO INFNET - 156