DiagramaCasosUso

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.