Definição

UML 2.0
Comunicação entre clientes, usuários

e desenvolvedores
Diagrama de casos de uso
Prof. Cesar Augusto Tacla
Funcionalidades oferecidas pelo
sistema

Exemplo Elementos do diagrama

Atores

Casos de uso

Relações

Ator Como encontrar atores?

São externos ao sistema

Representam
papéis desempenhados por usuários
entidades externas ao sistema
(ex. hardware, outros sistemas) A
A chave
chave está
está em
em determinar
determinar onde
onde oo sistema
sistema termina
termina

Iniciam casos de uso

Fornecem e/ou recebem
informações dos casos de uso

1
Como encontrar atores? Como encontrar atores?

Iniciar pelos atores primários
Não esquecer dos atores auxiliares

A quem o sistema oferece algo de valor?  para tomar decisões
Sem eles, o sistema não seria necessário!  realizar serviços específicos do sistema
Definir os papéis destes usuários

Atores nem sempre são pessoas
Papéis = atores  equipamentos, sensores e outros sistemas

Como encontrar atores? Atores ou não?

Identifique as fontes de informação
Banco de dados?

Não
Sistema tem as informações para tratar um
Sistema operacional?
evento gerado por um ator? Não

Impressora?
Não! Então quem a fornece? Outro ator? Não

Sensor de calor num sistema de
monitoramento de incêndio?
Sim

Caso de uso Como identificar casos de uso?

Quais são as tarefas de cada ator?

Um caso de uso é um conjunto de ações
Que informações o ator obtém do

realizadas pelo sistema que produz um resultado sistema?
significativo (com valor) para um ator Quem as fornece?
Quem as captura?

Nas fases iniciais (inception), pois na fase de elaboração são

refinados para incluir casos auxiliares ao funcionamento do sistema

2
 Como identificar casos de uso? Descrição de um caso de uso
Nome

Algum ator precisa ser informado sobre
eventos produzidos pelo sistema? Autor
Sim => casos de uso de registro e notificação Descrição
Pré-condições

Há eventos externos que devem ser
Pós-condições
notificados ao sistema?
Sim => devem haver casos para que os atores Fluxo básico de Ator x sistema
possam notificar o sistema eventos
Fluxo alternativo
de eventos

Fluxo de eventos Fluxo de eventos

um caminho entre muitos

como sistema e atores colaboram
para produzir algo de valor aos atores
Tipos
Fluxo básico

o que pode impedir sua obtenção Fluxo alternativo
Subfluxo

Exemplo Fluxo básico

Para ir ao churrasco, pegue a BR116 na direção São Paulo. Logo após o clube Santa
O que ocorre normalmente
Mônica, tem um retorno por baixo da pista. Faça o retorno e continue reto (não
retorne à BR). Continue nesta estradinha asfaltada por 1 km, no entroncamento
pegue a estrada de terra à direita, ande cerca de 500m, você verá um grande
eucalipto e uma araucária. A entrada da chácara é entre os dois. Não se esqueça de
trazer o pinhão. // primário

Início do caso
Se estiver chovendo muito, os 500m na terra podem ser bem difíceis porque o barro
é mole. Neste caso, siga reto no entroncamento (ao invés de virar à direita) e na
próxima a direita pegue a rua de paralelepípedos. Ande cerca de 1 km e depois vire
interação normal
na segunda a direita que vai desembocar na frente da chácara. // alternativo 1
Se você for comprar o pinhão no caminho, logo depois de fazer o retorno da BR tem
sem tratamento de exceções
uma venda. Se estiver fechada, um pouco mais a frente, tem um senhor da chácara
Pinhais que também vende. Se não encontrar pinhão, não tem problema.
// alternativo 2
descrição de como o caso termina.

3
 Fluxo básico: exemplo Caso de uso: cabeçalho
Nome: Buscar produtos e fazer pedido
Um cliente realiza compras on-line num site
Descrição: Este caso descreve como um cliente usa o sistema
utilizando um carrinho de compras virtual.
para visualizar e comprar produtos disponíveis.
O projetista do sistema previu um caso Para encontrar um produto, o cliente pode pesquisar o catálogo
por tipo de produto,
chamado buscar produtos e fazer pedido
fabricante ou por palavras-chaves.
especificado pelo fluxo básico seguinte –
Pré-condições: o cliente está logado no sistema.
extraído de (Bittner e Spencer, 2003) Pós-condições: o cliente realiza uma compra ou não.
Fluxos básico
Subfluxos
Fluxos alternativos

Caso de uso: fluxo básico

1. O caso de uso inicia quando o ator cliente escolhe a opção de consultar o catálogo de produtos.
Exercícios
2. {Mostrar catálogo de produtos}
3. O sistema mostra os produtos oferecidos, ressaltando os produtos cujas categorias constam no perfil do cliente.
4.
5.
{Escolher produto}
O cliente escolhe um produto a ser comprado e define a quantidade desejada.

Fazer 1, 2 e 3 da apostila página 32
6. Para cada produto selecionado disponível em estoque, o sistema registra o código do produto e a quantidade
solicitada reservando-a no estoque e adiciona-o ao carrinho de compras.
7. {Produto esgotado} Pontos de extensão
8. Os passos 4-7 se repetem até que o cliente decida efetuar a compra dos produtos. Subfluxos
9. {Processar pedido} Req. não funcionais
10. O sistema pergunta ao cliente se deseja fornecer informações sobre o pagamento.
11. O sistema utiliza um protocolo seguro para obter as informações de pagamento do cliente.
12. Executar subfluxo validar informações de pagamento (S1)
13. {Informações de pagamento não válidas}
14. O sistema pergunta ao cliente se deseja fornecer informações sobre o envio das mercadorias.
15. O sistema utiliza um protocolo seguro para obter as informações de envio.
16. Executar subfluxo validar informações de envio.
17. {Informações de envio não válidas}
18. Executar subfluxo efetuar transação financeira.
19. O sistema pergunta ao cliente se deseja comprar mais produtos.
20. Se o cliente desejar comprar mais produtos, retomar o caso no ponto {Mostrar catálogo de produtos}, se não o caso
termina.

Subfluxo Exemplo de subfluxo

Decomposição de um fluxo de eventos
No exemplo da apostila

Objetivo: melhorar a legibilidade

Cuidado!!! excesso de fragmentação
S1 Validar informações de pagamento;

Subfluxo é atômico
S2 Validar informações de envio;

S3 Efetuar transação financeira.

4
Ex. de subfluxo

S1 validar informações de pagamento
1. Sistema verifica o dígito verificador e a data de
expiração do cartão de crédito
2. Sistema solicita confirmação dos dados a
administradora do cartão (nome, país)
3. Sistema sinaliza se informações foram validadas ou
não
FLUXO ALTERNATIVO

Fluxos alternativos sempre são dependentes da
existência de uma condição que ocorre em um
ponto de extensão de outro fluxo de eventos

Representam
comportamento alternativo ou opcional complexos
Exemplos

Tratamento de exceções
Ex. fluxo alternativo específico

A2 - Tratar produto esgotado

Em {Produto esgotado} quando não há a quantidade
requisitada do produto em estoque.

O sistema informa que o pedido não pode ser
completamente satisfeito.

// a descrição deste fluxo continua com oferta de
quantidades e produtos alternativos ao cliente

O fluxo de eventos básico é retomado no ponto onde foi
interrompido.
Pontos de extensão

Identificam locais num fluxo de eventos

{ponto de extensão}

Privados: visível somente no CdU

Públicos: visíveis nos CdUs que estendem
Tipos de fluxos alternativos

Específico: iniciam num ponto de
extensão.

Regional: podem ocorrer entre dois
pontos de extensão.

Geral: podem ocorrer em qualquer ponto
do caso de uso.
Ex. fluxo alternativo regional

A1 Pesquisar por palavras-chaves

Entre
{Mostrar catálogo de produtos} e {Escolher produto}
quando o cliente escolhe realizar uma pesquisa por
palavras-chaves.

O sistema pergunta ao cliente pelos critérios de busca
do produto.

O cliente fornece os critérios de busca de produto.

// a descrição deste fluxo continua

O fluxo de eventos básico é retomado em
{Escolher produto}.
5
Por que utilizar fluxos alternativos? Representação gráfica de fluxos

São comportamentos opcionais

Não são necessariamente essenciais

Podem ser caros
Diagrama de atividades:
Permitem adicionar funcionalidades representação simplificada
incrementalmente da descrição textual

Cenários Realização de casos de uso

Fluxo Modelo de casos de uso

cenário alternativo

Modelo de projeto
Fluxo básico

Relações Associação ator x ator

Associação

Inclusão

Extensão

Generalização/especialização

NÃO representam a ordem de execução dos casos;

devem melhorar a compreensão do que o sistema deve fazer
(e não como projetá-lo). Não é recomendável colocar este tipo de relação no diagrama de casos de uso

6
Associação ator x caso de uso Associação ator x caso de uso

indica quem inicia a comunicação

indica o fluxo de informações
No diagrama superior, pode-se
deduzir que o emissor inicia a
chamada telefônica e, no inferior,
esta informação está explícita

bidirecional
unidirecional

Inclusão: caso x caso Inclusão

Emitir histórico escolar

Não use <<include>>
para decomposição funcional
Um caso de uso é reutilizável,
não sabe que o incluiu!

Se o subfluxo não é compartilhado, não o
represente como um caso de uso,
deixe-o fora

Não use <<include>>

Subfluxos na descrição textual
não implicam <<include>>
para representar opções de menu

Extensão: caso x caso Extensão

Uso
Extensão não requer mudança no

Opções ao comportamento normal estendido
Tratamento de erros e exceções complexos
Extensão conhece o caso base
Customização: diferentes clientes, diferentes  ≠ da inclusão
comportamentos
Extensão nasce como fluxo alternativo
Administração de escopo e de release:
Nem todo fluxo alternativo vira extensão
comportamentos incluídos futuramente

7
Extensão x fluxos alternativos Extensão: Caso x caso

Extensão só conhece o ponto de extensão

Fluxos alternativos são parte do caso

Quando um fluxo alternativo é candidato à

extensão?
Sim, se o sistema puder ser entregue sem o
mesmo.
Pode ser excluído sem prejuízo da funcionalidade principal?

Extensão: ponto de extensão público Generalização: caso x caso

Especialização de comportamentos
genéricos

Os casos específicos são executados

Os genéricos são abstratos

Uso
Família de produtos

Generalização: exemplo Generalização/Especialização x Extensão

Especialização Extensão
O caso de uso O caso de uso base é
especializado é executado
executado
O caso de uso base não O caso de uso base deve
precisa ser completo e ser completo e com
com sentido. Há várias sentido.
lacunas preenchidas
somente nas
especializações.
O comportamento de O comportamento de
uma execução depende uma execução depende
unicamente do caso do caso de uso base e de
específico. todas as extensões que
Ver 4.4 da apostila
são executadas.

8
Generalização de atores Generalização

Conjunto de atores com responsabilidades

ou características comuns

Herdam os casos de uso

dos quais bibliotecário
participa

Administrador Acervista

Generalização: ator x ator Dicas de modelagem

Não utilizar atores para
Não esqueça dos casos de uso auxiliares
Ex. Configurar, registrar usuários
representar permissões de acesso
representar organogramas (hierarquias) de
Não faça decomposição funcional
cargos de uma empresa. SÍNTESE

Não estruture e detalhe em demasia

EVITE excesso de relações
Utilizar atores somente para definir papéis em relação ao sistema

O modelo de casos de uso é mais que o
diagrama de casos de uso
Diagrama é apenas um panorama

Passos de modelagem (1/4) Passos de modelagem (2/4)

Recapitular a visão do sistema (estudo de
Identificar os atores do sistema.

viabilidade) aos envolvidos.
Identificar os casos de uso
descrevê-los e rascunhar o fluxo de eventos.

Elaborar diagrama de contexto (se não se preocupe com fluxos alternativos.
necessário) 10 minutos para descrever cada caso de uso.

Esboçar o diagrama

9
Passos de modelagem (3/4) Passos de modelagem (4/4)

Verificar os casos de uso:
Descrever os casos detalhadamente

Há casos de uso sem conexão com requisitos
funcionais? Caso haja, pode haver casos em excesso
ou requisitos que não foram identificados!
Há requisitos funcionais sem casos? Alguns casos
podem ter sido esquecidos.
Todos os requisitos não-funcionais foram tratados
(associados aos casos de uso quando são
específicos)?
Todos os papéis de usuários foram mapeados para um
ator ao menos?

Representar os subfluxos (<<include>>) e
fluxos alternativos (<<extend>>)
considerados importantes no diagrama

Verificá-los:
É possível eliminar os casos incluídos ou as
extensões e ainda ser capaz de entender o que
o sistema faz para as partes interessadas?

Pacotes de casos de uso Casos de uso agrupados

Sistemas grandes = número elevado de

casos

Agrupá-los por similaridade

Representação: pacotes

10