Aula_03 - MODELAGEM DE SISTEMAS

Prévia do material em texto

Modelagem de Sistemas
Marcelo Vasques de Oliveira
Aula 3
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
14
Seção da Especificação
Significado
Nome
Verbo no infinitivo + Complemento Verbal
Escopo
O Nome do Sistema / Projeto
Nível
Objetivo do usuário ousub-função(include,extendse especialização)
Atores (*)
Atores envolvidos : principal e secundários
Interessados e Interesses
Quem se importa com esse caso de uso e o que eles desejam?
Précondição (*)
O que precisa ser verdade para esse caso de uso acontecer
Pós condição ou Garantia de sucesso (*)
O que precisa ser verdade quando da finalização bem sucedida desse caso de uso
Cenário Principal (*)
O cenário de sucesso, um caminho típico , incondicional
Cenários Alternativos ou extensões (*)
Cenários alternativos, quando o cenário principal tem uma variação do fluxo bem sucedido.
RequisitosEspeciais
Requisitos não funcionais relacionados
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
Formato em 2 colunas
24
Ações do ATOR
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
 
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Atividade 3
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.
26
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.
27
1. Identificando Casos de Uso
28
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>>
	
29
Caso: Cancelar Reservas do Dia
Cenário Principal
Para cada reserva a iniciar no dia com status de “reservada” FACA
Sistema cancela a reserva, atualizando o status da reserva para Cancelada.
Cenários Alternativos
a) Não existem reservas a serem canceladas
- Sistema encerra caso de uso
	
30
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
	
31
1. Identificando Casos de Uso
32
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
	
33
1. Identificando Casos de Uso
34
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
	
35