Descrição formal de Casos de Uso

17.276 visualizações

Publicada em

Como documentar formalmente diagramas de Caso de Uso para geração do documento de especificação de requisitos.

Publicada em: Tecnologia
0 comentários
8 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
17.276
No SlideShare
0
A partir de incorporações
0
Número de incorporações
8
Ações
Compartilhamentos
0
Downloads
402
Comentários
0
Gostaram
8
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Descrição formal de Casos de Uso

  1. 1. #AnaliseDeSistem as Prof. Natanael Simões natanaelsimoes Descrição de Casos de Uso Documentando formalmente os cenários elicitados
  2. 2. Pra que descrever? • Diagramas não falam • Diagramas propiciam interpretações equivocadas • Descrever define melhor o escopo • Descrever define como programar 2
  3. 3. Casos de Uso • Nome Qual o nome do caso de uso? • Objetivo Qual o propósito principal? • Requisitos (Funcionais) Quais os requisitos funcionais relacionados? • Atores Quem são os atores envolvidos? 3
  4. 4. Casos de Uso • Prioridade Qual o prioridade de desenvolvimento? • Pré-condições Qual(is) estado(s) do sistema para entrar no caso de uso? • Frequência de uso Com que frequência esse caso de uso será executado? 4
  5. 5. Casos de Uso • Pós-condições Em qual(is) estado(s) o sistema está após o término desse caso de uso? • Campos Quais dados estarão envolvidos? • Fluxo principal Quais passos serão necessários para que ocorra com sucesso o caso? 5
  6. 6. Casos de Uso • Fluxos alternativos Que outros rumos o ator ou sistema podem tomar dentro do fluxo principal? • Fluxos de exceção O que pode dar errado? • Validações Como o sistema vai verificar o que pode dar errado? 6
  7. 7. Casos de Uso • Protótipo das telas Como serão as telas necessárias para cumprir o caso de uso? 7
  8. 8. UC001 – Nome do caso de uso Objetivo: Requisitos: Atores: Prioridade: Pré-condições: Frequência de uso: Pós-condições: Campos: Fluxo principal: Fluxo alternativo: Fluxo de exceção: Validações: Protótipo das telas: [Qual propósito?] [Quais requisitos funcionais?] [Quais atores?] [Qual prioridade de desenvolvimento?] [Qual estado anterior do sistema?] [Qual frequência do uso?] [Qual estado posterior do sistema?] [Quais campos serão necessários?] a) Ação 1. (A1) b) Ação 2. (A2)(E1) c) Caso de uso é encerrado. A1 – fluxo alternativo qualquer a) Ação 1. b) Ação 2. c) Volta ao passo “b” do fluxo principal. A2 – outro fluxo ... E1 – uma exceção a) Ação 1. b) Volta ao passo “a” do fluxo principal. [Como validar para saber se há exceção?] 8
  9. 9. Exemplo 9
  10. 10. Nome • Código + Número sequenciado = ID UC001 • Nome do caso de uso (mesmo do diagrama) Emprestar exemplar UC001 – Emprestar exemplar 10
  11. 11. Atores • Indicar TODOS os envolvidos no processo • Separar com vírgula Atendente, Usuário 11
  12. 12. Prioridade • Não confundir com frequência de uso • Cria uma ordem para ser programado UC001 – Emprestar exemplar UC002 – Devolver exemplar UC003 – Reservar publicação UC004 – Cancelar reserva P = 3 / Alta P = 2 / Média P = 1 / Baixa P = 1 / Baixa • Se vai usar número ou nomes, você decide! • Mesmas regras valem para FREQUÊNCIA 12
  13. 13. Pré-condições • São requisitos/estados que o sistema deve estar para que o caso aconteça • Se (requisito_estado != esperado) então some daqui. Pré-condição de “UC004 – Cancelar reserva” será a existência de uma reserva realizada em “UC003 – Reservar publicação” 13
  14. 14. Pós-condições • São requisitos/estados que o sistema deve estar após o caso acontecer • Aqui não tem “se”, é OBRIGATÓRIO Pós-condição de “UC004 – Cancelar reserva” será a inexistência da reserva antes realizada em “UC003 – Reservar publicação” 14
  15. 15. Campos • Todas as características de todos os objetos não-atores envolvidos no caso Objetos de “UC001 – Emprestar exemplar” • Atendente (ator) • Usuário (ator) • Livro o o o o o Nome Autor ISBN Quantidade de páginas ... 15
  16. 16. Fluxos • Mecânica para todos os fluxos a) Ator faz alguma coisa b) Sistema responde c) Ator faz outra d) Sistema responde e) O caso de uso é encerrado 16
  17. 17. Fluxo principal • Pode conter fluxos alternativos e de exceção a) Cliente solicita visualizar extrato de pontuação; b) Sistema requer o mês de referência; c) Cliente seleciona um mês de referência e (A1) confirma a operação; d) Sistema exibe o extrato referente ao mês selecionado pelo Cliente; e) Cliente seleciona (A2) retornar ao menu principal; f) O caso de uso é encerrado. A1 – cancelar operação/voltar para página anterior A2 – emitir novo extrato 17
  18. 18. Fluxo alternativo • Pode apontar para outro fluxo alternativo e de exceção • Pode encerrar em si mesmo • Pode voltar para o fluxo principal A1 – cancelar operação/voltar para página anterior a) Cliente cancela operação ou volta para a página anterior; b) Retorna ao passo ‘f’ do fluxo principal. A2 – emitir novo extrato a) Cliente seleciona emitir novo extrato; b) Retorna ao passo ‘b’ do fluxo principal. 18
  19. 19. Fluxo de exceção • Pode apontar para outro fluxo alternativo e de exceção • Pode encerrar em si mesmo • Pode voltar para o fluxo principal E1 – valor inválido a) Sistema reconhece que o valor entrado é inválido e informa ao operador; b) Retorna ao passo ‘e’ do fluxo principal. 19
  20. 20. Validações • Algoritmo que dispara fluxos de exceção Apenas os campos de e-mail e do representante não são requeridos, o restante é obrigatório. O tipo de contrato só poderá ser MENSAL, TRIMESTRAL, SEMESTRAL e ANUAL. O estado da loja no sistema será 0 e 1 para desativado e ativado respectivamente. 20
  21. 21. Protótipo de telas 21

×