Diagrama de Caso de Uso na Fase de Concepção

Prévia do material em texto

5- DIAGRAMA DE CASO DE USO 
(Utilização da UML no ciclo de vida Iterativo e 
Incremental - Fase de Concepção)
Professor: Lázaro P. de Oliveira
Curso: Sistemas de Informação
REQUISITOS FUNCIONAIS
 Necessidades dos usuários que o sistema precisa 
atender.
 A qualidade da identificação dos requisitos reflete em 
todo processo de desenvolvimento.
 Requisitos errados 
 sistema que não 
atende a 
necessidade.
DIAGRAMA DE CASOS DE USO
REQUISITOS FUNCIONAIS - Exemplos
 Cadastrar Contas a pagar
 Cadastrar Contas a receber
 Consultar Saldos Bancários
 Gerar Fluxo de Caixa
 Cadastrar Clientes
 Cadastrar Fornecedors
 Registrar Vendas
 Emitir Notas Fiscais
DIAGRAMA DE CASOS DE USO
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 segundos 
(performance)
 A entrada de funcionários deve ser controlada por leitor digital (interface).
 O sistema deverá permitir sua operação via ambiente mobile.
 O sistema funcionará no sistema operacional Windows.
 O sistema utilizará o ambiente Web
DIAGRAMA DE CASOS DE USO
O QUE É
 Representação gráfica do relacionamento entre Atores e Casos de Uso.
 Como o próprio nome faz-se lembrar, os casos de uso são descrições 
de utilização do sistema. Em outras palavras, os modelos de casos de 
uso visam descrever como o sistema é operado por agentes externos. 
 De acordo com Sommerville (2007), a técnica é baseada em cenários e 
são de fundamental importância para a modelagem de requisitos de 
sistemas orientados a objetos, utilizando a UML. 
 A representação de um caso de uso em um modelo de sistema é feita 
por uma elipse e, internamente, o nome do caso de uso.
DIAGRAMA DE CASOS DE USO
Exemplo de um Caso 
de Uso. Representa o 
Requisito do Sistema
DIAGRAMA DE CASOS DE USO
 Objetivo:
 Auxiliar a comunicação entre os analistas e os clientes.
 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.
DIAGRAMAS DE CASOS DE USO
• 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
3 ELEMENTOS 
DO DIAGRAMA DE CASOS DE USO
Caso de Uso
ATOR...
( O que é e quem ele representa )
É um agente externo que interage 
diretamente com o caso de uso. 
O ator é quem realiza o caso de 
uso. Pode ser representado por 
Pessoas, Setores, Departamentos, 
Funções desempenhadas, Outros 
sistemas, Dispositivos eletrônicos, 
Organizações, etc.
Gerente
Recursos Humanos Servidor 
de e-mail
Leitor Digital
Sistema Financeiro
ATORES COM PAPEIS INTERNO E EXTERNO
Ator Interno
Ator Externo
ATOR COMO SETOR E FUNÇÃO DESEMPENHADA
12
ATOR COMO SETOR E FUNÇÃO DESEMPENHADA
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?
Caso de Uso...
(O que é e como deve ser nomeado)
 Representam os requisitos, as 
funcionalidades do sistema.
 Devem estar alinhados aos processos da 
empresa. 
 É representado por uma elipse com o 
nome do caso de uso.
 Nome: Verbo no Infinitivo + 
Complemento verbal.
Nome do 
Caso de UsoExemplo de 
Caso de Uso
IDENTIFICAÇÃO DOS CASOS DE USO
• Podemos pensar nos casos de uso que representam as necessidades 
dos atores. 
• Estes casos de uso representam os requisitos do sistema. Perguntas 
úteis para se identificar os casos de uso:
• 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?
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.
RELACIONAMENTO
O Relacionamento pode ser:
Entre Ator e Caso de Uso.
Entre Atores.
Entre Casos de Uso.
RELACIONAMENTO
ENTRE ATOR E CASO DE USO 
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
RELACIONAMENTO 
ENTRE ATORES
• Generalização/especialização,
• Linha sólida com uma seta na extremidade que aponta para o ator geral,
O ator geral é o Funcionário. O ator especialista é 
o Gerente. O gerente pode realizar todos os casos 
de uso do ator funcionário e dele mesmo. Já o ator 
funcionário só pode executar os casos de uso que 
a ele está relacionado diretamente.
RELACIONAMENTO 
ENTRE ATORES
Generalização
Especialização
No exemplo, o ator aluno pode 
realizar os casos de uso “matricular 
em curso” e “incluir disciplina”. Já o 
ator Atendente pode realizar os dois 
casos de uso do ator aluno e, ainda, 
realizar o caso de uso “cancelar 
matrícula em curso”
• O ator geral é o “Usuário”. Os atores 
especializados são “Aluno” e 
“atendente”.
• Os atores “Aluno” e “Atendente” 
realizam todos os casos de uso 
associados ao ator “Usuário”.
Apenas o ator Atendente 
realiza o caso de uso 
“Cancelar Matrícula em 
Curso”
RELACIONAMENTO 
ENTRE ATORES
• Esta é uma associação útil para definir sobreposição de papéis entre 
atores, onde: 
 O ator especializado interage com os casos de uso que a ele estão 
associados diretamente e, além disso, também interage com todos 
os casos de uso relacionados ao ator generalizado. 
 Já o inverso não ocorre, o ator generalizado não interage com os 
casos de uso associados ao ator especializado.
RELACIONAMENTO 
ENTRE ATORES
RELACIONAMENTO 
ENTRE CASOS DE USO
No exemplo da Figura acima, um vendedor realiza a venda de um produto. Porém, 
quando o caso de uso “vender produto” é efetuado, outros casos de uso podem ser 
realizados automaticamente. 
Neste caso, pode-se fazer uma analogia em que o ator dos casos de uso “emitir nota 
fiscal” e “cadastrar cliente” é o caso de uso “vender produto”. 
No caso de “emitir nota fiscal”, por se tratar de uma relação de <<include>>, este caso de 
uso será obrigatoriamente realizado. Em outras palavras, ao vender um produto, a nota 
fiscal é emitida obrigatoriamente no sistema. Já no caso de uso “cadastrar cliente”, por 
ser uma relação do tipo <<extend>>, não é obrigatório que o cliente seja cadastrado a 
cada venda de produto efetuada. 
RELACIONAMENTO 
ENTRE CASOS DE USO
Pode-se dizer, analisando o exemplo da Figura acima, que este sistema trabalha da 
seguinte forma: 
 O vendedor é o responsável por efetuar a venda de produtos; 
 Ao se realizar uma venda, a nota fiscal é obrigatoriamente emitida; 
 Caso o cliente ainda não seja cadastrado, ao efetuar uma venda, pode-se cadastrar 
o cliente.
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. 
RELACIONAMENTO <INCLUDE> 
ENTRE CASOS DE USO 
• O caso de uso Validar Disciplina agrega o que é comum aos casos de
uso Incluir Disciplina e Eliminar Disciplina.RELACIONAMENTO <EXTEND> 
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.
RELACIONAMENTOS 
ENTRE CASOS DE USO 
RELACIONAMENTOS 
ENTRE CASOS DE USO
RELACIONAMENTO 
ENTRE CASOS DE USO
GENERALIZAÇÂO DE CASOS DE USO: 
• Além da generalização de atores, pode-se adotar também a generalização de casos de 
uso, seguindo o mesmo conceito e aplicações. 
A figura acima representa uma generalização de casos de uso onde, a ação de 
cadastrar um aluno generaliza as outras duas ações de forma que, em casos 
específicos, pode-se realizar um dos casos de uso especiais (“cadastrar aluno de 
graduação” e “cadastrar aluno de pós-graduação”) e em casos gerais pode-se 
realizar o caso de uso “cadastrar aluno”.
RELACIONAMENTO 
ENTRE CASOS DE USO
GENERALIZAÇÂO DE CASOS DE USO: 
Observando o exemplo apresentado na figura 
ao lado, têm-se três atores e três casos de 
uso. 
O ator “secretária-chefe” realiza o caso de 
uso “cadastrar aluno”, isto significa que este 
ator pode cadastrar qualquer tipo de aluno, 
seja ele de graduação ou de pós-graduação, 
pois este caso de uso está generalizando os 
casos “cadastrar aluno de pós-graduação” e 
“cadastrar aluno de graduação”. 
Nota-se que o ator “secretária de graduação”, 
diferentemente do ator “secretária-chefe”,
não realiza o caso de uso generalizado, e sim o especializado, chamado “cadastrar aluno de 
graduação”. Sendo assim, este ator é impossibilitado de realizar o caso de uso “cadastrar 
aluno de pós-graduação”. O mesmo acontece com o ator “secretária de pós-graduação”, que 
é impossibilitado de realizar o caso de uso “cadastrar aluno de graduação”. 
De forma resumida, quando se utiliza generalização em casos de uso, pode-se deixar os 
modelos mais concisos e enxutos, além de possibilitar descrição mais abrangente e 
detalhada do requisito. 
EXEMPLO DE CASO DE USO
 O cenário apresentado na figura acima demonstra que, no sistema em questão, no 
momento em que um cliente registra uma solicitação de serviço, o sistema 
automaticamente valida o cliente (verifica se o mesmo é cadastrado) e notifica os 
responsáveis. 
 Por se tratar de um <<include>>, a notificação dos responsáveis e a validação do cliente 
são ações obrigatórias na realização do caso de uso “solicitar serviço”.
PERGUNTA: Se o requisito descrito pela figura fosse tal que o cliente 
pudesse optar por enviar ou não uma notificação aos responsáveis, 
quais seriam as alterações necessárias no diagrama para que 
representasse esta mudança no requisito?
EXEMPLO DE CASO DE USO
Neste outro cenário, a figura demonstra 
um diagrama de casos de uso onde o 
funcionário técnico da empresa atua na 
solicitação feita anteriormente.
O ator “técnico” pode realizar dois 
casos de uso: 
 Registrar atuação; 
 Finalizar solicitação.
registrando um trabalho efetuado para a resolução da solicitação do cliente. 
Ao realizar este caso de uso, não é obrigatório que se realize também “notificar solicitante” 
e “notificar superior”, pois estes relacionamentos são do tipo <<extend>>. 
Na realização do caso de uso “finalizar solicitação”, é necessário (obrigatório) que se 
notifique o solicitante. Portanto, o relacionamento entre “finalizar solicitação” e “notificar 
solicitante” deve ser do tipo <<include>>. 
Já o relacionamento entre “finalizar solicitação” e “notificar superior” é do tipo 
<<extend>>, o que significa que não é obrigatória a notificação do superior quando um 
técnico finaliza a solicitação.
O caso de uso “registrar atuação” significa que o técnico estaria
Loja de Materiais 
para Construção
ESTUDO DE CASO: LOJA DE MATERIAL PARA 
CONSTRUÇÃO
 Em entrevista com o proprietário, os alunos da Estácio identificaram as
seguintes atividades realizadas na loja e que, portanto, devem ser
contempladas no sistema:
 O gerente só compra produtos de fornecedores qualificados.
 Os fornecedores são todos cadastrados pelo próprio gerente.
 Os atendentes realizam as vendas dos produtos no balcão e emitem as
notas fiscais.
 O gerente também pode vir a atender no balcão, vendendo produtos.
 Quando os clientes assim desejam, os produtos vendidos são entregues
em suas residências. Para tanto, o atendente precisa gerar uma nota de
entrega e cadastrar o cliente (caso este seja um cliente novo ou ainda
não tenha sido cadastrado).
IDENTIFIQUEM OS ATORES E OS 
CASOS DE USO
1. IDENTIFICANDO ATORES E CASOS DE USO
 Em entrevista com o proprietário, os alunos da Estácio identificaram as
seguintes atividades realizadas na loja e que, portanto, devem ser
contempladas no sistema:
 O gerente só compra produtos de fornecedores qualificados.
 Os fornecedores são todos cadastrados pelo próprio gerente.
 Os atendentes realizam as vendas dos produtos no balcão e
emitem as notas fiscais.
 O gerente também pode vir a atender no balcão, vendendo
produtos.
 Quando os clientes assim desejam, os produtos vendidos são
entregues em suas residências. Para tanto, o atendente precisa
gerar uma nota de entrega e cadastrar o cliente (caso este seja um
cliente novo ou ainda não tenha sido cadastrado).
REQUISITOS FUNCIONAIS
Caso de 
Uso
Caso de Uso
2- DIAGRAMA DE CASO DE USO ( SIMPLIFICADO )
3- DIAGRAMA DE CASO DE USO 
(COM INCLUDE E EXTEND)
3- DIAGRAMA DE CASO DE USO 
(COM INCLUDE E EXTEND)
3- DIAGRAMA DE CASO DE USO 
(COM INCLUDE E EXTEND)
Cadastro de Material 
Didático
Crie um diagrama de casos de uso que represente a funcionalidade de cadastro de 
um material didático por um professor em um sistema de gestão de materiais de 
disciplinas. 
Os requisitos do sistema são: 
 O professor cadastra material didático; 
 O sistema checa se o professor é vinculado à disciplina em questão; 
 O sistema checa se a extensão do arquivo do material é condizente e 
segura; 
 O professor pode escolher proteger o material cadastrado com uma senha.
EXERCÍCIO 
Atores
ALUNOS FAZEM
RESOLUÇÃO DO EXERCÍCIO
Identificando Atores
ASSINALE ABAIXO AS ALTERNATIVAS CUJOS ATORES TÊM RELAÇÃO DIRETA 
COM O SISTEMA.
1) Lavadeira em um sistema de lavanderia.
2) Arrumadeira em um sistema de hotel.
3) Secretária em um sistema de diagnóstico médico.
4) Sistema da Operadora de Cartão em um Sistema de Vendas de 
Supermercado.
5) Cliente em um Sistema de Vendas de Supermercado.
6) Supervisor de Venda em uma funcionalidade de estornar item de 
venda.
EXERCÍCIO 
Atores
Assinale abaixo as alternativas cujos atores têm relação direta com o 
sistema.
1) Lavadeira em um sistema de lavanderia.
2) Arrumadeira em um sistema de hotel.
3) Secretária em um sistema de diagnóstico médico.
4) Sistema da Operadora de Cartão em um Sistema de Vendas de 
Supermercado.
5) Cliente em um Sistema de Vendas de Supermercado.
6) Supervisor de Venda em uma funcionalidade de estornar item de 
venda.
SOLUÇÃO
As respostas podem ser 
diferentes a depender das 
regras de negócios 
aplicadas em cada 
situação isolada
Relacionamento 
(Atores e Casos de 
Uso – UC)
Identifique o tipo de relacionamento que deve/pode ser
estabelecido entre as afirmações abaixo:
1) Depto financeiro e UC: Registrar Encomenda.
2) UC: Registrar encomenda e UC: Calcular Preço de Venda da 
Encomenda.
EXERCÍCIO 
Relacionamento (Atores e Casos de Uso – UC)
3) Aluno matriculado na Instituição e Aluno ouvinte (sem matrícula, mas com vínculo na
Instituição)
4) Depto Administrativo e UC: Manter Cliente.
5) UC: Registrar Devolução de Livro e UC: Calcular Multa.
6) UC: Imprimir Mapa de Notas de um aluno e UC: Validar Aluno.
7) Funcionário da empresa e Caixa da Empresa.
8) UC: Registrar entrada do Veículo e UC: Emitir Ticket de Estacionamento
Identifique o tipo de relacionamento que deve/pode ser estabelecido entre as 
afirmações abaixo:
1) Depto financeiro e UC: Registrar Encomenda:
• R: ASSOCIAÇÃO
2) UC:Registrar encomenda e UC: Calcular Preço de Venda da Encomenda:
 R: INCLUSÃO (include)
3) Aluno da Instituição e Aluno Especial da Instituição (sem matrículo, mas 
com vínculo na Instituição):
 R: GENERALIZAÇÃO ENTRE ATORES
4) Depto Administrativo e UC: Manter Cliente:
 R: ASSOCIAÇÃO
SOLUÇÃO
Exercício - (Atores e Casos de Uso – UC)
Identifique o tipo de relacionamento que deve/pode ser estabelecido entre as afirmações
abaixo:
5) UC: Registrar Devolução de Livro e UC: Calcular Multa:
 R: EXTENSÃO (extend)
6) UC: Imprimir Mapa de Notas de um aluno e UC: Validar aluno:
 R: INCLUSÃO (include)
7) Funcionário da empresa e Caixa da Empresa:
 R: GENERALIZAÇÃO ENTRE ATORES
8) UC: Registrar entrada do Veículo e UC: Emitir Ticket de Estacionamento:
 R: INCLUSÃO (include)
SOLUÇÃO
Exercício - (Atores e Casos de Uso – UC)
Identificando Atores, 
Casos de Uso e Tipo 
de Relacionamento
Modele usando a notação de UML e identifique o tipo de relacionamento que 
deve/pode ser estabelecido entre as afirmações abaixo:
1) Depto financeiro e UC: Registrar Encomenda
2) UC: Registrar encomenda e UC: Calcular Preço de Venda da Encomenda
3) Aluno da Instituição e Aluno Especial da Instituição (sem matrícula, mas 
com vínculo na Instituição)
4) Depto Administrativo e UC: Manter Cliente
5) UC: Registrar Devolução de Livro e UC: Calcular Multa
6) UC: Imprimir Mapa de Notas e UC: Validar Aluno
7) Funcionário da empresa e Caixa da Empresa
8) UC: Registrar entrada do Veículo e UC: Emitir Ticket de Estacionamento
EXERCÍCIO
Diagrama de Casos de Uso
SOLUÇÃO
1) Tipo de Relacionamento: Associação
SOLUÇÃO
2) Tipo de Relacionamento: Inclusão
SOLUÇÃO
3) Tipo de Relacionamento: Generalização entre atores
SOLUÇÃO
4) Tipo de Relacionamento: Associação
SOLUÇÃO
5) Tipo de Relacionamento: Extensão
SOLUÇÃO
6) Tipo de Relacionamento: Inclusão
SOLUÇÃO
7) Tipo de Relacionamento: Generalização entre atores
SOLUÇÃO
8) Tipo de Relacionamento: Inclusão
Futebol
EXERCÍCIO
Monte o Diagrama de Casos de Uso a partir do contexto a seguir: 
“FUTEBOL”
Considere o sistema de uma equipe de futebol constituído pelos 
seguintes atores: 
 Jogador; Treinador; Atacante; Goleiro; Volante; Defesa; 
Presidente. 
Desenhe o respectivo diagrama de casos de uso, considerando a 
organização das seguintes atividades a serem realizadas pela equipe: 
 Jogar; Treinar; Defender a trave; Pagar ao jogador; Pagar ao 
treinador; Vender jogador; Contratar jogador; Contratar 
treinador; Demitir treinador.
Fonte: Internet (tradução livre)
RESOLUÇÃO