Casos de uso

Objetivo:

● Auxiliar a comunicação entre os analistas e o

cliente.
● Descreve um cenário que mostra as
funcionalidades do sistema do ponto de vista do
usuário.
● O cliente deve ver no diagrama de Casos de

Uso as principais funcionalidades de seu

sistema.
● Notação (representação):
– Atores

Um ator é representado por

um boneco e um rótulo com
o nome do ator. Um ator é
um usuário do sistema, que
pode ser um usuário
humano ou um outro
sistema computacional.
– Caso de uso

Um caso de uso é representado

por uma elipse e um rótulo com
o nome do caso de uso. Um
caso de uso define uma grande
função do sistema. A implicação
é que uma função pode ser
estruturada em outras funções
e, portanto, um caso de uso
pode ser estruturado.
● Relacionamento (ajudam a descrever casos
de uso).
– Entre um ator e um caso de uso.
● Associação
Navegabilidade para
Uma direção

Navegabilidade para
ator Caso de uso Ambos os lados

Define uma funcionalidade do sistema do ponto de vista do

usuário
– Entre atores.
● Generalização

Ator B - Os casos de uso de B são também

casos de uso de A
- A tem seus próprios casos de uso

Ator A
– Entre casos de uso.
● Inclusão <<include>> - instância outros casos de uso
para suas condições
● Extensão <<extend>> - acrescenta outros casos de uso
para suas condições
Incluir produto
No pedido
Fornecer dados
Do cliente Definir formas
De pagamentos
<<include>>

<<include>> <<include>>

1 * Colocar Pedido
Vendedor
Consultar
<<extend>> catálogos
O vendedor pede o catálogo
– Sistema.
● Limites do sistema: representado por um retângulo
envolvendo os casos de uso que compõem o sistema.
● Nome do sistema: Localizado dentro do retângulo.

– Multiplicidade.
● Indica quantos objetos estão relacionados ao link.
– Ex. 1...*, 1...1, *...*, etc

– Ator.
● Primário e secundário
Exemplo
 Cenários

Deve-se especificar o comportamento de um

caso de uso descrevendo textualmente um ou
mais fluxos de ações, de modo que um usuário
não técnico o possa entender sem dificuldade. Tal
especificação deve incluir:
● Como e quando o caso de uso começa e termina;
● Quando é que o caso de uso interage com os atores;

● Que objetos são trocados;

● Cenário principal, e

●
Cenários alternativos (e.g., situações de exceção).
 Exemplo
A operação de um caixa eletrônico tem início a partir de uma sessão
em que o cliente seleciona a opção de realizar saque. O cliente então
escolhe uma quantia a ser retirada, a partir de um conjunto de opções
de quantia disponíveis. O sistema verifica se o caixa eletrônico tem
saldo e notas adequadas para compor o valor solicitado (Ex. R$ 50,00
não podem ser fornecidos se só houver três notas de R$ 20,00). Caso
tenha notas adequadas, os números da conta e da agência do cliente
são enviados ao banco para determinar se existe saldo suficiente na
conta do Cliente. Se não houver saldo, uma mensagem adequada é
reportada. Havendo saldo, o sistema inicia uma transação com o ator
banco e solicita a retirada da quantia desejada e o banco aprova ou
desaprova a transação. Se a transação é aprovada, a máquina libera
a quantia correspondente e emite um recibo. Se a transação é
desaprovada, uma mensagem adequada é reportada. O banco é
notificado, independentemente de uma transação aprovada ter sido
completada ou não pela máquina. Se a transação é completada, o
banco realiza o débito na conta do cliente .
●
Caso de Uso - Realizar Saque
●
Objetivo: Este caso de uso possibilita a um cliente realize um saque de um caixa eletrônico
●
Atores: Cliente, Banco
●
Pré-Condições: Cliente autenticado
●
Condição de Entrada: o ator Cliente seleciona a opção realizar saque
●
Fluxo Principal
1. O sistema pergunta ao Cliente a quantia a ser retirada.
2. O Cliente digita a quantia desejada.[A1]
3. O sistema verifica se a importância requisitada é maior do que a quantia disponível.
4. O saldo é suficiente no caixa [A2]
5. O sistema verifica se a importância desejada pode ser fornecida com as notas existentes no caixa
eletrônico.(R$ 50,00 não podem ser fornecidos se só houver três notas de R$ 20,00).
6. Valores disponíveis [A3]
7. O sistema contata o ator banco para determinar se existe saldo suficiente na conta do Cliente.
8. O banco informa que cliente tem saldo[A4]
9. O sistema inicia uma transação com o ator banco e solicita a retirada da quantia desejada.
10. O banco envia aprovação da transação.[A5]
11. O sistema libera a quantia desejada
12. O sistema emite um recibo para o Cliente
13. O sistema fecha a transação com o ator banco.
14. O sistema envia ao banco um log da transação.
15. O caso de uso se encerra.
● Fluxos Alternativos
A1 O cliente não digita a quantia desejada
– Após 20 seg encerra o caso de uso
A2 O caixa automático não tem disponibilidade de dinheiro para atender a
solicitação do ator cliente
1. O sistema reporta uma mensagem de “falta de recursos no caixa”
2. O caso de uso se encerra.
A3 O caixa automático não tem disponibilidade notas para compor o valor
solicitado pelo ator cliente
1. O sistema reporta uma mensagem de “não temos notas de R$X,00 disponíveis
para compor esse valor, tente outro valor”
2. O caso de uso retorna para o passo 1 do fluxo principal
A4. O Cliente não tem saldo suficiente
1. O sistema reporta uma mensagem seu saldo não é suficiente para esse saque
2. O caso de uso se encerra.
A5 O banco não aprova a transação devido à violação de alguma regra de
negócio (por exemplo: limite diário excedido)
1. O sistema reporta uma mensagem adequada
2. O caso de uso se encerra.
 Diagrama de Classe

Objetivo:

Descrever os vários tipos de objetos no sistema e

o relacionamento entre eles.
● Perspectivas
– Um diagrama de classes pode oferecer três
perspectivas, cada uma para um tipo de usuário
diferente. São elas:
● (1) Conceitos ou Entidades
– Representa os conceitos do domínio em estudo.
– Perspectiva destinada ao cliente.
● (2) Classes
– Tem foco nas principais interfaces da arquitetura, nos
principais métodos, e não como eles irão ser
implementados.
– Perspectiva destinada as pessoas que não precisam saber
detalhes de desenvolvimento, tais como gerentes de
projeto.
● (3) Classes de Software
– Aborda vários detalhes de implementação, tais
como navegabilidade, tipo dos atributos, etc.
– Perspectiva destinada ao time de desenvolvimento.
● Um diagrama de classes contém:
– Entidades
– Relacionamentos
# Entidades
– Classe: é representada na forma de um retângulo,
contendo duas linhas que separam 3 partes. A primeira
contém no nome da classe, a segunda os atributos da
classe e a última os métodos da mesma.

– Interface: Representação Gráfica

● Perspectivas:
– Conceitual
● Apenas classes são utilizadas. Neste tipo de perspectiva, uma
classe é interpretada como um conceito. Apenas atributos são
utilizados.
– Especificação
● Tanto classes como interfaces são utilizados neste tipo de
perspectiva. O foco consiste em mostrar as principais
interfaces e classes juntamente com seus métodos.
● Não é necessário mostrar todos os métodos, pois o objetivo
deste diagrama nesta perspectiva é prover uma maior
entendimento da arquitetura do software a nível de interfaces.
– Implementação
● Nesta perspectiva, vários detalhes de implementação podem
ser abordados, tais como:
– visibilidade de atributos e métodos;
– parâmetros de cada método, inclusive o tipo de cada um;
– tipos dos atributos e dos valores de retorno de cada método.
● # Relacionamentos
– Papel: Descreve o relacionamento.

– Multiplicidade (utilizado em todas as perspectivas

de forma uniforme)
● Notações possíveis Exemplo:
● Associação (utilizado em todas as perspectivas)
– Representação Gráfica
Associação

● Perspectiva:
– Conceitual
● Define um relacionamento entre duas entidades conceituais do

sistema.
– Especificação
● Define responsabilidades entre duas classes. Implica que
existem métodos que tratam desta responsabilidade.
– Implementação
● Permite saber quem está apontando para quem, através da

representação gráfica da navegabilidade. Além disto, é

possível compreender melhor de que lado está a
responsabilidade.
● Herança ou Generalização (utilizado em todas as
perspectivas)
– Representação Gráfica

Perspectiva:
– Seja B uma generalização (extensão) de A.
● Conceitual
● Considera que B é um subtipo ou um tipo especial de A. O que é válido para A,
também é válido para B.
● Especificação
● Ocorre uma herança de interface.
● Implementação
● Ocorre uma herança de implementação.

Exemplo de uma herança de implementação:

● Navegabilidade (utilizado apenas na perspectiva de
implementação)
Um relacionamento sem navegabilidade implica que ele pode ser lido de
duas formas, isto é, em suas duas direções. Ex.:

Uma empresa possui um trabalhador, como também um trabalhador

trabalha em uma empresa.
Utilizando a propriedade de navegabilidade, podemos restringir a forma
de ler um relacionamento. Isto é, em vez de termos duas direções,
teremos apenas uma direção (de acordo com a direção da navegação).
Ex.:

Uma empresa possui um trabalhador.

● Agregação (utilizado apenas na perspectiva de
implementação)
Definição
Agregação é uma associação em que um objeto é parte de outro, de
tal forma que a parte pode existir sem o todo.
Em mais baixo nível, uma agregação consiste de um objeto contendo
referências para outros objetos, de tal forma que o primeiro seja o
todo, e que os objetos referenciados sejam as partes do todo.
A diferença entre os relacionamentos de associação e agregação
ainda é algo de bastante discussão entre os gurus. De forma geral,
utiliza-se agregação para enfatizar detalhes de uma futura
implementação (perspectiva de implementação).

Representação gráfica
– Agregação com navegabilidade
● Composição (utilizado apenas na perspectiva de
implementação)
Definição
Em mais baixo nível, em termos de passagem por parâmetro,
seria uma passagem por valor. Enquanto que agregação seria
uma passagem por referência.
O todo contém as partes (e não referências para as partes).
Quando o todo desaparece, todas as partes também
desaparecem.

Representação Gráfica
● Implementação (utilizado apenas na perspectiva
de implementação)
Definição
Utilizado para indicar que uma classe implementa uma
interface

Representação Gráfica

Exemplo
Exemplos
 Diagrama de interação:
sequência
● Diagramas de Interação são modelos que
descrevem como grupo de objetos colaboram
em um determinado comportamento.
● Um diagrama de interação captura o
comportamento entre objetos dentro um único
caso de uso.
● Consiste em um diagrama que tem o objetivo de mostrar como as
mensagens entre os objetos são trocadas no decorrer do tempo para a
realização de uma operação.
● Em um diagrama de sequência, os seguintes elementos podem ser
encontrados:
● Linhas verticais representando o tempo de vida de um objeto (lifeline);
● Estas linhas verticais são preenchidas por barras verticais que indicam
exatamente quando um objeto passou a existir. Quando um objeto
desaparece, existe um "X" na parte inferior da barra;
● Linhas horizontais ou diagonais representando mensagens trocadas entre
objetos. Estas linhas são acompanhadas de um rótulo que contém o nome
da mensagem e, opcionalmente, os parâmetros da mesma. Observe que
também podem existir mensagens enviadas para o mesmo objeto,
representando uma iteração;
● Uma condição é representada por uma mensagem cujo rótulo é envolvido
por colchetes;
● Mensagens de retorno são representadas por linhas horizontais tracejadas.
Este tipo de mensagem não é frequentemente representada nos diagramas,
muitas vezes porque sua utilização leva a um grande número de setas no
diagrama, atrapalhando o entendimento do mesmo. Este tipo de mensagem
só deve ser mostrada quando for fundamental para a clareza do diagrama.
 Exemplo: Partindo do
diagrama de Casos de Uso
 Exemplo: Partindo do
diagrama de Casos de Uso
 Exercício

Elabore o Diagrama de Casos de Uso para uma

biblioteca escolar.
 Exercício

Elabore o Diagrama de Casos de Uso para um

sistema de reserva de salas.
 Exercício

Elabore o Diagrama de Casos de Uso para um

sistema de entrega de pizzas.
 Exercício

Faça o diagrama de casos de uso para um

sistema de Inscrição de um congresso, por
exemplo o SICOMP (Simpósio Interinstitucional
de Computação).
 Exercício

Construa um modelo de casos de uso para a

seguinte situação fictícia: "Estamos criando um
serviço de entregas. Nossos clientes podem nos
requisitar a entrega de volumes. Alguns volumes
são considerados de maior valor por nossos
clientes, e, portanto, eles querem ter tais volumes
segurados durante o transporte. Contratamos
uma companhia de seguro para segurar volumes
de valor"