Modelagem de Sistemas

Aula 3

Marcelo Vasques de
Oliveira
 Aula 3 – Especificações de Casos de Uso

• Importância da especificação de casos de Uso

• Formas de especificação de casos de uso

• Técnicas de Especificação de casos de uso

2
 Especificações de casos de uso
• Fundamental para complementar o diagrama
de casos de uso
• A UML nada define sobre o texto narrativo.
• Descreve o passo a passo do
comportamento do caso de uso
• Interação entre ator e sistema
• Ações do sistema
• Vários cenários (principal e alternativos)
• 3 formatos possíveis:
• Resumido
• Informal
• Completo

3
 Especificação – os 3 formatos
• Resumido
• Resumo de 1 parágrafo contendo o cenário
principal (sucesso)
• Uso: Análise Inicial de Requisitos
• Informal
– Múltiplos parágrafos cobrindo vários cenários
de uso.
– Uso: Análise Inicial de Requisitos
• Completo
– Todos os cenários (principal e alternativos)
são descritos em detalhes,
– Uso: Análise de requisitos e de sistemas
– Adequado aos casos de uso relevantes

4
 Especificação – os 3 formatos
• A especificação de um caso de uso, deve
mostrar a interação entre o ator e o sistema
(caso de uso em questão), ou seja a
“conversa” entre ator e sistema na
realização (acontecimento) do caso de uso.
• Para mostrar a diferença entre os 3 tipos de
especificação, vamos usar como exemplo o
caso de uso: Registrar venda

5
 Formato Resumido
Caso de Uso: Registrar Venda
O cliente chega em um ponto de pagamento
da loja com os itens que deseja adquirir. O
caixa registra cada item desejado. Ao final, o
sistema apresenta o total a pagar e a relação
de itens comprados. O cliente informa e o
caixa registra os dados do pagamento, que
são validados e registrados pelo sistema. O
sistema atualiza o estoque. O cliente recebe o
recibo das compras e sai com os itens
adquiridos

6
 Formato Informal
Caso de Uso: Registrar Venda
Cenário Principal (de sucesso)
• cliente chega ao ponto de pagamento da loja
com os itens a serem adquiridos. O caixa usa
o sistema PDV para registrar todos os itens
comprados. Ao final, o sistema apresenta o
total a pagar e a relação de itens comprados.
O cliente informa e o caixa registrar os dados
do pagamento, que são validados e
registrados pelo sistema. O sistema atualiza
o estoque. O cliente recebe o recibo das
compras e sai com os itens adquiridos.

7
 Formato Informal
Cenários Alternativos
Se o identificador do item adquirido não for
encontrado no sistema, esse notifica o caixa e
sugere que esse entre manualmente com a
identificação do item (que talvez esteja
corrompido).
Se o cliente informou pagamento em cartão e a
operadora não aprova a transação, informe o
cliente e solicite nova forma de pagamento;
Se o sistema não consegue atualiza o estoque,
sugere que o caixa registre no formulário de
problemas do dia, para balanço ao final do dia.

8
 Formato Completo
Nome do caso de Uso: Registrar Venda
Escopo: Sistema de Vendas – PDV
Nível: Usuário
Atores: Caixa
Interessados e Interesses:Caixa: deseja que
o sistema seja eficiente, sem erros e de fácil
utilização
Cliente: deseja adquirir os produtos desejados
de forma rápida, sem muitom esforço e
encontrar o que precisa e ao final um
comprovante do que comprou

9
 Formato Completo
Interessados e interesses
Orgãos fiscais: Deseja cobrar os impostos de
cada venda realizada
Operadoras de cartão: Deseja receber
solicitações de autorização de crédito no
formato e protocolo corretos.
Pré condição: todos os produtos registrados
no sistema e com respectivos preços; caixa
autenticado e PDF registrado
Pós condições: Venda salva, impostos
calculados, estoques atualizados, autorizações
de pagamento registradas, Recibo gerado.

10
 Formato Completo
Cenário Principal (ou fluxo básico)
1.Cliente chega ao PDV com os itens que
deseja adquirir
2.Caixa inicia uma nova venda
3.Para cada item de venda do cliente, FACA
a) Caixa insere o identificador do item
b) Sistema Localiza o Item
c) Sistema registra apresenta a linha do
item de venda, com o identificador, nome e
valor unitário do produto
d) Sistema calcula os impostos do item

11
 Formato Completo
4. Sistema apresenta o valor total da venda
com impostos calculados
5. Caixa informa total ao cliente e solicita
pagamento
6. Caixa informa o pagamento do cliente
7. Sistema registra e trata o pagamento do
cliente
8. Sistema Finaliza venda e apresenta o
recibo da mesma
9. Sistema contabiliza a baixa no estoque de
cada item vendido.

12
 Formato Completo
Cenários Alternativos (extensões).
2.a. Sistema não inicializa
1. Caixa inicia a venda em planilha manual
(contingência) , registrando cada item e o
pagamento e encerra o caso
3.a........
Requisitos Especiais:
1. Interface de Usuário com tela sensivel a toque em
um monitor de tela plana com pelo menos 23 “
2. Resposta de autorização de crédito, dentro de 30
segundos, em 90% dos casos.
3. A recuperação de falhas de servidores devem ser
consistente e robusta.

13
 Seção da Significado
Especificação
Nome Verbo no infinitivo + Complemento Verbal

Escopo O Nome do Sistema / Projeto

Nível Objetivo do usuário ou sub-função (include, extends e
especialização)
Atores (*) Atores envolvidos : principal e secundários
Interessados e Quem se importa com esse caso de uso e o que eles
Interesses desejam?
Pré condição (*) O que precisa ser verdade para esse caso de uso acontecer

Pós condição ou O que precisa ser verdade quando da finalização bem

Garantia de sucesso (*) sucedida desse caso de uso
Cenário Principal (*) O cenário de sucesso, um caminho típico , incondicional
Cenários Cenários alternativos, quando o cenário principal tem uma
Alternativos ou variação do fluxo bem sucedido.
extensões (*)
RequisitosEspeciais Requisitos não funcionais relacionados

14
Especificação com Include

15
 Especificação com caso de Include
Especificação do Caso Incluir Dependente
Cenário Principal
1. Atendente informa identificação do cliente
2. Sistema localiza dados do cliente informado
3. Atendente informa dados do dependente
4. Sistema localiza dados do dependente informado
– <<Include Pesquisar Dependente >>
5. Sistema registra dados do dependente do cliente
informado

16
 Especificação com caso de Include
Especificação do Caso Incluir Dependente
Cenários Alternativos
2.a. Cliente NÃO localizado
• Sistema informa “Cliente não registrado no sistema” e
retorna ao passo 1 do cenário principal
4.a. Dependente JÁ registrado
• sistema informa “Dependente já registrado no sistema
”e retorna ao passo 3 do cenário principal

17
Especificação com caso de Extends

18
 Especificação com Extends
Cenário Principal
1. Atendente informa identificação da mídia
2. Sistema Localiza Locação com a Mídia informada
3. Sistema apresenta Registro da locação com Valor
Pagar
4. Atendente informa forma de pagamento
5. Caso forma de pagamento seja
DINH: <extends PAGAR EM DINHEIRO>
CARTÃO: <extends PAGAR no CARTÃO>
Fim-Caso
6. Sistema Registra devolução
7. Sistema emite Recibo de Quitação do Pagamento

19
 Especificação com Extends
Cenários Alternativos
1.a. MÍDIA NÃO localizada
– Sistema informa “Mídia não registrado no sistema
ou NÃO alugada” e retorna ao passo 1 do cenário
Principal
2.a. Locação NÃO localizada (inconsistência de
dado
– Sistema informa “Locação NÃO registrada para a
mídia no sistema” e encerra caso de uso.
3.b. SE Data Corrente > Data Prevista de Devolução
ENTÃO Calcular Multa <<Extends CALCULAR
MULTA POR ATRASO>>

20
 Considerações Finais
• Não use detalhes de implementação
– A tecnologia ficará obsoleta e o caso
precisará ser revisto
– “Usuário insere o seu cartão” – não
– “Usuário informa dados: agencia, conta e
senha” - OK
• Procure não associar Casos de Uso a telas
de sistemas
– é cedo para pensarmos em interface, que
será objeto da fase de projeto do sistema,
embora usuários adorem telas

21
 Considerações Finais
• Os casos de uso incluídos (chamados por
<include>) ou estendidos (chamados por
<extends>) também devem ter descrição
textual, podendo ser no formato resumido ou
informal.
• Perguntas que podem ajudar no
detalhamento dos cenarios principal e
alternativos.
– Quando tudo ocorre na normalidade (com
sucesso), qual o comportamento do sistema ? –
esse será o passo a passo do cenário principal.

22
 Considerações Finais
– Algo pode acontecer de forma diferenciada,
nesse passo ? – indicará um cenário alternativo
(relacionado a esse passo).
– O que pode dar errado nesse passo ? – da
mesma forma que a pergunta acima, essa
conduz a identificação de um cenário
alternativo.
• Quando um passo for muito complicado, ele pode
vir a ser um novo caso de uso, que se relacionará
com o caso original pelo esteriótipo <include>.
• Façam casos de uso enxutos, pois casos longas
podem não ser lidos em sua totalidade.

23
 Ações do ATOR
Formato em 2 colunas
Ações do SISTEMA
Cenário Principal
1. Atendente informa
dados da reserva
2. Sistema verifica se cliente Cadastrado - <Include Pesquisa Cliente>

3. Sistema verifica disponibilidade de quarto

4. Atendente confirma a
reserva
5. Sistema confirma a reserva
Cenários Alternativos
2.a. Cliente não é cadastrado
2.a.1. Sistema Informa cliente não cadastrado
2.a.2 Executa caso de extensão: <Extends> Cadastrar Cliente
2.a.3. Retornar ao passo 3 do Caso de uso

3a. Não há disponibilidade

3.a.1. Sistema informa “Não há disponibilidade no período desejado”.
3.a.2. Encerar caso de uso

24
 As descrições podem ser feitas de forma abreviada ou na detalhada,
de acordo com o estágio que se encontre ciclo de desenvolvimento,
do projeto, e dos riscos associados à execução do sistema.
Elas especificam o nome, o propósito, a lista de atores, as pré e pós
condições, além dos fluxos típico (apenas um para um caso de uso),
alternativos e de exceção (usualmente vários) da interação entre os
usuários e o sistema, dentre outras informações.
Descrições não especificam como vai se fazer, e sim, o que vai se
fazer...

25
1. Por que mencionamos que o caso de uso que chama outro é
aquele de onde parte o relacionamento de inclusão ou o aonde
chega o relacionamento de extensão?

2. Por que estabelecemos a regra básica de que inclusões são

especificadas nas descrições do curso típico e extensões em um
dos cursos alternativos?

26
Modelagem de
Sistemas

Atividade 3

Marcelo Vasques de
Oliveira
 Estudo de Caso
Em um hotel da cidade, um hóspede pode obter um quarto
de 2 formas: através de uma reserva prévia ou obtendo um
quarto se houver disponibilidade no ato. Ao reservar são
registrados Nome, CPF, Período da estada, quantidade de
quartos e de hospedes. Na chegada do hóspede (com ou
sem reserva) são registrados, além dos dados acima, os
dados (Nome e data de nascimento) dos demais hóspedes.
Na saída do hóspede, registra-se a data de saída, bem
como apresenta o valor a pagar ao hospede, que informa
forma de pagamento (dinheiro, cartão ou cheque). Se
pagamento em cheque (banco, agencia, conta e cheque)
registra-se os dados do cheque. Se pagamento em cartão,
registra-se dados do cartão (administradora, numero cartão
e validade). Após saída do hóspede, o recepcionista deve
liberar o quarto para limpeza , que ao ser encerrada deve
liberar o quarto para uso novamente.

28
 Estudo de Caso
O gerente pode retirar um quarto de uso, seja para obra ou
qualquer outra ação, podendo retornar o quarto para
hospedagem, sempre que desejar. O gerente poderá incluir
novos quartos, quando forem construídos.
Sempre que solicitado o gerente deve receber um mapa de
ocupação dos quartos (reservas e ocupados) em um período
(por ele informado).
Ao final do dia o caixa precisa saber o total recebido em
dinheiro e o gerente as reservas canceladas.
Uma reserva pode ser cancelada pelo recepcionista
(obedecendo pedido do hóspede) ou automaticamente, se o
hóspede não chegar ate as 17h.
Todo atendimento (reservas, checkin e checkout) é feito
pelos recepcionistas.

29
1. Identificando Casos de Uso

30
 Caso de Uso: Reservar Quarto
Cenário Principal
1. Recepcionista informa qtde de quartos, num pessoas por
quarto
2. Recepcionista informa período da reserva
3. Sistema verifica disponibilidade de quartos no período
4. Recepcionista informa CPF do hóspede
5. Sistema localiza hóspede
6. Sistema mostra dados da reserva e do hóspede
7. Recepcionista confirma dados da reserva
8. Sistema registra Reserva com status de Reservada
Cenários Alternativos
3.a. Não há disponibilidade de quartos
1. Sistema informa que não há disponibilidade de quartos
2. Sistema retorna ao passo 1 do cenário principal.
5.a. Hóspede não registrado
1. <<Extends Cadastrar Hóspede>>

31
 Caso: Cancelar Reservas do Dia
Cenário Principal
1. Para cada reserva a iniciar no dia com status de
“reservada” FACA
a) Sistema cancela a reserva, atualizando o status da reserva
para Cancelada.
Cenários Alternativos
1. a) Não existem reservas a serem canceladas
- Sistema encerra caso de uso

32
 Caso : Registrar Entrada do hóspede
Cenário Principal
1. Recepcionista informa CPF do hóspede
2. Sistema localiza Hóspede
3. Recepcionista informa período da reserva
4. Sistema localiza Reserva
5. Sistema mostra dados da reserva registrada
6. Recepcionista confirma dados da reserva
7. Sistema atualiza status da reserva para “Hospedado”
8. Sistema registra Entrada do hóspede com data corrente
Cenários Alternativos
2.a. Hóspede não cadastrado
1. <<Extends Cadastrar Hóspede>>
4.a. Reserva não localizada
1. <<Extends Reservar Quarto>>
2. Sistema retorna ao passo 5 do cenário principal
6.a. Recepcionista altera os dados da reserva
1. Recepcionista altera algum dado da reserva: Periodo da reserva,
qtde quartos e pessoas por quarto
2. Sistema registra alteração de dados da reserva

33
1. Identificando Casos de Uso

34
 Caso : Registrar Entrada do hóspede
Cenário Principal
1. Recepcionista informa CPF do hóspede e período da reserva
2. Sistema localiza Reserva
3. Sistema mostra dados da reserva registrada
4. Recepcionista confirma dados da reserva
5. Sistema atualiza status da reserva para “Hospedado”
6. Sistema registra Entrada do hóspede com data corrente
Cenários Alternativos
2.a. Reserva não localizada
1. <<Extends Reservar Quarto>>
4.a. Recepcionista altera os dados da reserva
1. Recepcionista altera algum dado da reserva: Periodo da reserva,
qtde quartos e pessoas por quarto
2. Sistema registra alteração de dados da reserva

- VERSAO MELHORODA – OTIMIZANDO PASSOS

35
1. Identificando Casos de Uso

36
 Extends : Cadastrar Hospede
Cenário Principal
1. Sistema mostra CPF do Hóspede
2. Recepcionista informa dados (nome, endereço completo e
telefone) do hóspede
3. Sistema Registra dados do hóspede

37