Modelagem de

Sistemas

Aula 2

Marcelo Vasques de
Oliveira
 Aula 2 – Casos de Uso

• Conceito e classificação dos requisitos

• Objetivo do diagrama de casos de uso

• Elementos dos diagramas de casos de uso

• Aplicação do diagrama de casos de uso

2
 Requisitos
• Necessidades dos usuários que o sistema
precisa atender
• Levantar requisitos : O QUE o sistema deve
fazer.
• A qualidade da identificação dos requisitos
reflete em todo processo de
desenvolvimento.
– Requisitos errados  sistema que não
atende a necessidade
• Requisitos Funcionais
• Requisitos Não Funcionais
3
 Requisitos Funcionais
• Apresentam as funcionalidades necessárias
para atender as necessidades dos usuários
• Sistema Financeiro
– Cadastrar Contas a pagar
– Cadastrar Contas a receber
– Cadastrar Saldos Bancários
– Gerar Fluxo de Caixa

4
 Requisitos Não Funcionais
• Atributos e propriedades do sistema
– Como um todo (sistema)
– De funcionalidades específicas
• Sistema como um todo
– O sistema deve operar com tela touch screen
– Impressão de boleto de venda não deve
demorar mais que 5 min (performance)
– A entrada de funcionários deve ser controlada
por leitor digital (interface).
– A entrada de funcionários não deve

5
 Diagramas de Casos de Uso
• Um dos mais informais e simples diagramas
• Finalidades:
– Mostrar funcionalidades do sistema
– Validar funcionalidades juntos aos usuários
– Ter a certeza de que todos os requisitos
foram considerados
– Instrumento de comunicação entre a equipe
de desenvolvimento.
• A visão de casos de uso é do ponto de vista
externo, do usuário
• Não mostra detalhes de COMO o sistema
realizará essas funcionalidades
6
 Diagrama de Casos de Uso
• 3 Elementos
– Ator
– Casos de Uso
– Relacionamento
• Atores – caso
• Entre atores
• Entre casos

7
 Atores
• O ator é algo com comportamento, que
interage diretamente com o sistema.
• Um ator participa (realiza) de um ou mais
casos de uso do sistema
• Um ator é o papel que o agente
desempenha em relação ao sistema.
–

8
Atores com papeis interno e externo

9
 Atores
• Um ator pode representar setores e
departamentos da empresa (contabilidade
e contas a pagar), bem como funções
desempenhadas na empresa
(almoxarifado)

10
Ator como setor e função
desempenhada

11
 Atores
• Um ator pode ser dispositivos
eletrônicos, como por exemplo
hardware, servidores ou dispositivos
lógicos, como por exemplo sistemas, de
acordo com a imagem abaixo

12
Ator como setor e função
desempenhada

13
 Identificando Atores
• O primeiro passo para a construção do
modelo de casos de uso é a identificação de
atores. Perguntas úteis :
– Quais órgãos, empresas ou pessoas farão
uso deste sistema de informação?
– Que sistemas ou equipamentos irão se
comunicar com o sistema que será
desenvolvido?
– Quem deve ser informado de alguma
ocorrência no sistema?
– A quem pode interessar os requisitos
funcionais do sistema?
14
 Casos de Uso
• Representam, as funcionalidades do sistema
(ELIPSES)
• o nome do caso de uso deve ser composto
de um Verbo no Infinitivo + Complemento
verbal
• Um caso de uso é um conjunto de cenários.
– descreve uma sequência de ações do ator e
do sistema.
– Sequência de ações = CENÁRIO.

15
 Identificação dos casos de uso
• Podemos pensar nos casos de uso que
representam os objetivos dos atores.
• Estes casos de uso representam os
processos da empresa. Perguntas úteis:
• Quais as necessidades e objetivos de cada
ator em relação ao sistema?
• Que informações serão produzidas pelo
sistema?
• O sistema realizará alguma ação que ocorre
de forma regular no tempo?
• Existe um caso de uso para atender cada
requisito funcional?
16
 Identificação de Casos de Uso
• Em seguida podemos pensar nos casos de
uso que não representam um benefício
direto para os atores mas são necessários
para o funcionamento do sistema. Tais casos
de uso englobam manutenção de cadastros,
e manutenção de informações provenientes
de outros sistemas.

17
Relacionamento entre Ator e Casos de
Uso
• Indicado por uma linha sólida,
• O Ator interage com o Caso de uso.
• A comunicação é bidirecional ou seja o ator
informa dados ao caso de uso e recebe
informações por ele processadas

18
 Relacionamento entre Atores
• Generalização/especialização,
• Linha sólida com uma seta na extremidade
que aponta pata o ator geral,

O ator geral é o Funcionário O

ator especialista, o Gerente.

19
 Relacionamento entre Atores
• O ator geral é Usuário. Os atores
especializados são Aluno e atendente.
• Aluno e Atendente se relacionam com todos
os casos de uso associados ao ator Usuário.

Apenas o ator Atendente

se relaciona com
Cancelar Matrícula em

20
 Relacionamento entre Atores
• Esta é uma associação útil para definir
sobreposição de papéis entre atores, onde:
– O ator especializado interage com o caso de
ao qual está associado diretamente e com
todos os casos de uso com o qual o ator
generalizado se associa.
– Já o inverso não ocorre, o ator generalizado
não interage com os casos de uso
associados ao ator generalizado.

21
 Relacionamento entre Casos de Uso
• INCLUSÃO (include ou uses): um caso de
uso (principal) incorpora o comportamento
de outro caso de uso (incluído).
• O caso de Uso incluído é parte integrante do
caso de uso principal e
• A fatoração acontece pois outros casos de
uso também poderão incorporar o Caso de
Uso incluído e assim evitar repetições de
fluxos.

22
Relacionamento <Include> entre casos
• O caso de uso Validar Disciplina agrega o que
é comum aos casos de uso Incluir Disciplina e
Eliminar Disciplina.

23
 Relacionamento entre Casos de Uso
• EXTENSÃO (extends): para descrever
cenários opcionais em caso de uso,
• Uma variação do comportamento normal.
• Através de uma condição, o caso estendido á
acionado, executado e retorna ao principal
• O caso de uso estendido pode não ser
executado.

24
Relacionamento <extends> entre casos

25
Relacionamento <extends> entre casos

26
 Relacionamento entre Casos de Uso
• GENERALIZAÇÂO: quando um caso de uso é
semelhante a outro, mas executa algumas
funções a mais.
• É pouco usado, pois seu uso confunde-se
com o extends - também pode resolver essa
questão da variação de comportamento
• Nesse caso um comportamento com
adição de funcionalidade..

27
 Generalização entre casos de uso
• Especialização do caso de uso Solicitar
Produtos (internet ou telefone)
• Existem partes comuns, que estão
especificadas em Solicitar Produtos (caso
mais geral).

28
Modelagem de
Sistemas

Atividade 2

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. 30
 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.

31
 1. Identificando Atores
• Identificar no texto, os substantivos que indiquem
interação com o sistema, seja recebendo dados ou
informações
– Hóspede – não interage diretamente, mas informa dados e
recebe informações de sua hospedagem
– Gerente – retira e recoloca quarto de uso; recebe mapa de
ocupação; inclui novos quartos; recebe informação das
reservas do período
– Caixa – recebe informação do total recebido R$ por dia
– Recepcionistas – procedimentos de reserva (inclusão e
cancelamento), checkin e checkout (incluindo pagamento);

32
 1. Identificando Casos de Uso
• Para cada ator, identificar funcionalidade associadas
• Ator: Gerente
– Incluir quarto
– Bloquear quarto por inatividade
– Desbloquear quarto da inatividade
– Consultar Mapa de Ocupação
– Consultar Reservas no Periodo
• Ator Caixa
– Consultar recebimentos em espécie

33
 1. Identificando Casos de Uso
• Recepcionista
– Reservar Quarto
– Cancelar Reserva
– Registrar Entrada do Hospede
– Registrar Saída do Hóspede (pagamento e Bloqueio de
quarto para limpeza)
– Liberar Quarto da Limpeza

• Cancelamento automático da reserva – qual ator ?

– Cancelar Reservar Automaticamente
• Evento temporal – Sistema ou Computador, já que será o
relógio deste que vai disparar o evento.

34
1. Identificando Casos de Uso

35
 Estudo de Caso
Alteração de Requisito
- O hospede deve ser cadastrado, quando fizer primeira
reserva ou primeira hospedagem.

Solução
- Criar um caso de uso Cadastrar Cliente, que deve
estender os casos de uso Registrar Reserva e Registrar
Entrada do Hóspede

36
1. Identificando Casos de Uso

37