Buscar

06 - Introdução à UML e Casos de Uso - Detalhes

Prévia do material em texto

Curso Superior de Tecnologia em 
Análise e Desenvolvimento de 
Sistemas - ADS
Análise e Projeto de Sistemas
06 – Erros comuns em Diagramas
de Casos de Uso
Prof. Dr. F Gerson Meneses
Conteúdo
 Atentai bem...
 Então...
 Detalhes de implementação e/ou abusar dos 
relacionamentos
 Detalhes de troca fluxos entre casos de uso
 Quando precisar, use o “CRUD”
 Detalhes de interface devem ser evitados...
Atentai bem...
• O diagrama de Casos de Uso talvez seja da UML o mais 
abstrato, flexível e informal.
• O limite da abstração é apresentar as características 
importantes para o desenvolvimento e suprimir as que não 
são importantes para um determinado cenário.
• É provável portanto, que duas pessoas façam abstrações 
diferentes dos mesmo problema, ABSTRAÇÕES SÃO 
ABSTRAÇÕES e como tal podem ter excessos ou faltas, 
dependendo do observador.
Então...
• O limite entre o excesso e a falta em um Diagrama de Casos de 
Uso é muito tênue.
• Agora, independente do excesso ou da falta, tem que se 
observar a sintaxe do modelo e entender os fundamentos dos 
estereótipos (gráficos e textuais) e onde empregar cada um 
(ator, casos de uso e relacionamentos). 
• São erros certos tratar um caso de uso como se fosse um ator e 
vice-versa ou colocar uma relação de include com o rótulo de 
extend, por exemplo.
• Em muitos casos a subjetividade impera e é importante 
entender a relação que há entre o analista (modelador) e os 
demais membros do seu time (programadores, principalmente).
• No entanto, algumas boas práticas devem ser 
observadas, Vejamos...
Detalhes de implementação e/ou 
abusar dos relacionamentos
• Cuidado com casos de uso nomeados como: gravar, imprimir, 
selecionar, exibir...pois são típicos detalhes de implementação.
• Esse “erro” pode trazer outro que seria o excesso de
relacionamentos.
O excedente 
poderá ser 
omitido, se 
necessário, deverá 
ser colocado no 
detalhamento do 
caso de uso
Detalhes de troca fluxos entre casos 
de uso
• Deve-se tomar cuidado e evitar desnecessariamente apresentar 
casos de uso como sendo um fluxo de ações, partes integrantes 
da execução de um processo.
Entre casos de uso, os 
relacionamentos 
indicados são inclusão, 
extensão e herança. 
Nesse caso temos um 
relacionamento de 
comunicação.
Para se representar 
fluxos, pode se usar o 
diagrama de atividades!
Quando precisar, use o “CRUD”
• Uma abreviação de (Create, Read, Update e Delete), portanto 
quando precisar usar o Criar, Ler, Atualizar ou Deletar, sendo 
todos relacionados a um só ação, uma solução para evitar o 
excesso de casos de uso é fazer um só abstraindo as ações 
citadas. Dessa forma:
Nesses casos pode-
se inserir o termo 
<<CRUD>> como 
um estereótipo do 
caso de uso.
Detalhes de interface devem ser evitados
• Evitar expressar detalhes relacionados à interface do sistema 
com os usuários, tais práticas, costumam “poluir” o diagrama.
• Detalhes como: botões, navegação entre telas, detalhes de 
campos de formulário devem ser evitados.
Para se representar 
detalhes de interface 
pode-se usar o diagrama 
de sequencia!
Referências:
 Disponíveis na ementa da disciplina.

Continue navegando