Bom gente, esses diagramas de casos de uso devem ser bem simples mesmo? sem importar com banco de dados… uma visão geral do sistema para que se saiba as tarefas e o papel que cada ator vai desempenhar certo?
Gostaria de saber se posso representar banco de dados da forma que representei na imagem abaixo.
ou se a representação desses diagramas é algo mais generalizado, sem se importar com o processo interno do sistema como na imagem abaixo.
Obrigado.
Sim, um diagrama de casos de uso deve ser simples, descrevendo apenas a interação entre usuário e sistema em uma visão conceitual.
Não pode, por dois motivos:
- Um ator é quem realiza uma ação no sistema. Um exemplo de ator que não seria um humano pode ser uma tarefa agendada do sistema operacional que dispara alguma funcionalidade do sistema. Já o banco de dados em questão não realiza essa ação, ele é passivo
- Um caso de uso não deve conter detalhes tecnológicos e de implementação, o banco de dados é um detalhe tecnológico e não deveria estar aí.
[quote]ou se a representação desses diagramas é algo mais generalizado, sem se importar com o processo interno do sistema como na imagem abaixo.
Obrigado.[/quote]
Essa imagem também não representa o que um caso de uso deve ter. Impressora não é um ator, ela faz parte do processo de “Imprimir”. O sistema de vendas tampouco é um ator.
Certo, então se retirar esses “atores” a estrutura do diagrama vai estar correta?
Aproveitando a oportunidade, alguem recomenda um bom livro sobre UML?
[quote=MasterK]Certo, então se retirar esses “atores” a estrutura do diagrama vai estar correta?
http://i.imgur.com/fPKixIo.jpg[/quote]
Já está mais adequado, porém como geralmente também se apresenta o diagrama de casos de uso para pessoas que não são da área técnica, o termo “CRUD” pode não trazer muito valor, pode sim até ser discutido entre a equipe técnica, mas eu particularmente não deixaria explícito no título.
Assumindo que seu caso de uso “Cadastrar Cliente” realmente faça as 4 operações inclusive a READ do CRUD, ter um caso de uso “Cadastrar Cliente” + “Consultar Cliente” é um pouco redundante, eu tiraria o “Consultar Cliente” daí se ele não tiver regras mutio específicas.
Recomendo a terceira edição do livro de UML do Martin Fowler, o qual é inclusive bibliografia de Análise de Requisitos da minha pós:
Português: http://www.saraiva.com.br/uml-essencial-3-ed-2004-160586.html?pac_id=25371&utm_source=buscape&utm_medium=comparador&utm_campaign=cpc_Livros-160586_25371&
Inglês: http://www.amazon.com/UML-Distilled-Standard-Modeling-Language/dp/0321193687/ref=sr_1_1?ie=UTF8&qid=1432826740&sr=8-1&keywords=uml+distilled
Realmente é verdade,notei que tanto o consultar cliente como o consultar peça não são necessários né? Então o CRUD não precisa estar explicito? outra dúvida que me surgiu. Quando não se utiliza todas as operações do CRUD? devo representar separadamente em casos de uso?
Qual é o correto?
- http://i.imgur.com/1cmQzfD.jpg
- http://i.imgur.com/OebPXLx.jpg
- Substituir CRUD pelas suas operações…
Cara, que forum bacana já faz um tempão que estou a procura de alguem que possa me ajudar nestes temas, difcil encontrar um local que te dê um feedback legal sobre eng. de soft e seus afins.
vou ver se estudo por este livro, parece ser mto bom pela descrição, gostei bem de UML, só que alguns tipos de dúvidas só são sanadas por um profissional da area, obrigado mesmo por me ajudar.
[quote=MasterK]Realmente é verdade,notei que tanto o consultar cliente como o consultar peça não são necessários né? Então o CRUD não precisa estar explicito? outra dúvida que me surgiu. Quando não se utiliza todas as operações do CRUD? devo representar separadamente em casos de uso?
- http://i.imgur.com/1cmQzfD.jpg
- http://i.imgur.com/OebPXLx.jpg
- Substituir CRUD pelas suas operações…
Qual é o correto?
[/quote]
O acrônimo CRUD não deve estar explícito, pois como mencionado anteriormente, ele não traz tanto valor para o pessoal que não é da área técnica.
Acredito que quando se modela um caso de uso, não se deve ter uma linha de raciocínio “cartesiana”, cenário comum para nós desenvolvedores, ou seja, esqueça o CRUD e pense no seu negócio, em qual valor o seu caso de uso deve trazer ao usuário, o CRUD será apenas o caminho para gerar esse valor.
Quanto a separar ou não as operações em diferentes casos de uso, isso vai depender se cada operação possui muitas particularidades, por exemplo: para remover um cliente é preciso de um processo diferenciado, como o parecer de um gerente? A remoção possuirá algum ator que não esteja presente nas outras operações do cadastro de cliente? Caso sim, você deve separar em casos de uso diferentes, mas se for um cadastro simples eu não vejo a necessidade de separar.
Em resumo, acredito que não exista receita de bolo pra isso, depende da análise de cada negócio.
[quote]
Cara, que forum bacana já faz um tempão que estou a procura de alguem que possa me ajudar nestes temas, difcil encontrar um local que te dê um feedback legal sobre eng. de soft e seus afins.
vou ver se estudo por este livro, parece ser mto bom pela descrição, gostei bem de UML, só que alguns tipos de dúvidas só são sanadas por um profissional da area, obrigado mesmo por me ajudar.[/quote]
Seja bem vindo ao forum! Eu particularmente nem de longe sou um expert, mas tem uma galera muito top por aqui =]
Pra quem acompanhou o tópico vou passar o resultado final do diagrama que utilizei.
Obrigado pela ajuda!
[quote=MasterK]Pra quem acompanhou o tópico vou passar o resultado final do diagrama que utilizei.
Obrigado pela ajuda! [/quote]
Só lembrando que desenho sozinho não representa nada. As descrições dos casos de uso que podem levar a algum desenho, a fim de representar graficamente o que foi levantado, quando for necessário melhor entendimento.
