Excelente pergunta! Não sou muito fã de adotar esta prática, pois isso acaba poluindo nossos diagramas. Talvez eu seja um pouco purista, mas entendo que as classes usadas devem ser aquelas que de fato interagem para a realização das ações em um caso de uso. Por exemplo: se estou modelando um sistema para uma oficina mecânica, terei a classe veículo, cliente, funcionário, peça, dentre outras... Percebe como uma classe relatório destoaria de todas essas outras? Pessoalmente, eu criaria essas funcionalidades, ou dentro de um package ou por meio de um diagrama de componentes. Uma outra abordagem seria adicionar a cada uma das classes um método como geraRelatorio(). Mas se vc desejar centralizar tudo em um aglomerado só, eu recomendaria a primeira abordagem! Espero ter ajudado! Um abraço!
Opa! Escrever um caso de uso é como contar uma história. Duas pessoas podem contar a mesma história de formas diferentes, que ainda assim será a mesma história. Todavia, existem coisas invariáveis, como fluxos de exceção. Eles precisam estar lá e independente de quem esteja contando a história, não podem ser omitidos. Comece por um livro de UML por exemplos que isso facilitará sua iniciação! Um abraço!
Complementando minha resposta, recomendo o livro Aprenda UML por meio de estudos de caso, de Wilson Moras Goes. Também tem o UML - Uma abordagem prática, do Gilleanes T A Guedes. São as bibliografias que uso.
A categoria é opcional dentro do contexto que estiver sendo trabalhado. A consequência da retirada dela é que os itens de itemCardapio ficariam "soltos".
Se eu tiver como classe: produto, compra, e venda, e quiser registrar a quantidade vendida de um produto em uma venda, é necessário criar uma nova classe? Senão, em qual classe faz mais sentido eu registrar?
Existem várias formas de modelar. Vou te sugerir uma aqui: a classe produto pode ter um parâmetro chamado estoque (int). A classe compra e venda referenciarão esta classe e terão o parâmetro qtde (int). A regra de negócio deverá calcular a quantidade do produto por meio de estoque + compra->qtde e subtraindo venda->qtde daquele total. Outro meio seria, por meio da regra de negócio, adicionar ou subtrair do parâmetro estoque, mas em sua implementação mais simples, isso faria perder o histórico de compras e vendas. Espero ter ajudado! Um abraço!
@@thyne_ A classe cliente se relaciona com a tabela venda, que o referenciará, para indicar quem está comprando, endereço de entrega, etc... É interessante falar que a modelagem das classes não necessariamente será idêntica à modelagem relacional do banco de dados. Assim, na modelagem relacional, eu criaria uma entidade fraca chamada venda_produto, onde eu vou criar uma tabela relacionando a entidade da venda com os produtos adquiridos. A lógica que te passei ainda se aplica, mas é necessário compreender qual seria a aplicação. Se for pra um sistema interno de uma loja, por exemplo, podemos ser mais pragmáticos. Já se for para um e-commerce de um grande varejista, deixamos o pragmatismo de lado e partimos para soluções bem mais complexas. Por fim, para tentar te ajudar o máximo dentro do que este campo de texto permite, pressupondo que trata-se de uma solução mais simples, pense nas entidades Cliente, Produto, Movimentação (que pode ser entrada ou saída). Na tabela produto, não teremos mais o campo estoque. Os quantitativos serão controlados por meio do campo movimentação. Criamos uma relação entre a entidade Movimentação e Cliente, para indicar por meio de quem o produto entrou ou saiu. É a implementação mais direta e simples que consigo conceber neste momento, em minutos e com os recursos que possuo. Espero ter ajudado!
@@Maxuuth eu colocaria, visto que o CPF não pode ser considerado um identificador unívoco. Pode demorar, mas um mesmo CPF pode pertencer a duas pessoas.
Nossa, UAU! Que aula maravilhosa!
Mto bom a aula , parabéns 👊👍
precisava de ajuda com um exercicio, como posso entrar em contato com o senhor?
Bom dia. Estou um pouco enrolado por causa dos fechamentos de notas de fim de ano. Vc consegue mandar sua dúvida por aqui?
qual seu nome so pra colocar no projeto
Opa! Marcelo Campos Brito
se tiver por exemplo, geração de relatório, como faz? cria uma classe relatórios?
Excelente pergunta! Não sou muito fã de adotar esta prática, pois isso acaba poluindo nossos diagramas. Talvez eu seja um pouco purista, mas entendo que as classes usadas devem ser aquelas que de fato interagem para a realização das ações em um caso de uso. Por exemplo: se estou modelando um sistema para uma oficina mecânica, terei a classe veículo, cliente, funcionário, peça, dentre outras... Percebe como uma classe relatório destoaria de todas essas outras? Pessoalmente, eu criaria essas funcionalidades, ou dentro de um package ou por meio de um diagrama de componentes. Uma outra abordagem seria adicionar a cada uma das classes um método como geraRelatorio(). Mas se vc desejar centralizar tudo em um aglomerado só, eu recomendaria a primeira abordagem! Espero ter ajudado! Um abraço!
@@mcbrito1 muito obrigado 🙏
Oi, tudo bem?
Há algum livro introdutório que eu consiga entender as diferentes abordagem que é possível na criação de modelagem?
Opa! Escrever um caso de uso é como contar uma história. Duas pessoas podem contar a mesma história de formas diferentes, que ainda assim será a mesma história. Todavia, existem coisas invariáveis, como fluxos de exceção. Eles precisam estar lá e independente de quem esteja contando a história, não podem ser omitidos. Comece por um livro de UML por exemplos que isso facilitará sua iniciação! Um abraço!
Complementando minha resposta, recomendo o livro Aprenda UML por meio de estudos de caso, de Wilson Moras Goes. Também tem o UML - Uma abordagem prática, do Gilleanes T A Guedes. São as bibliografias que uso.
professor como faço para ampliar o icone dos relacionamentos
Opa! Tudo bem? Ali do lado direito, tem um painel onde é possível selecionar a espessura da linha e alterar o ícone das pontas.
Única coisa que não entendi. O que seria a parte de Categoria? Se retirasse a Categoria e deixasse ItemCardapio em diante, em que isso impactaria?
A categoria é opcional dentro do contexto que estiver sendo trabalhado. A consequência da retirada dela é que os itens de itemCardapio ficariam "soltos".
Se eu tiver como classe: produto, compra, e venda, e quiser registrar a quantidade vendida de um produto em uma venda, é necessário criar uma nova classe? Senão, em qual classe faz mais sentido eu registrar?
Existem várias formas de modelar. Vou te sugerir uma aqui: a classe produto pode ter um parâmetro chamado estoque (int). A classe compra e venda referenciarão esta classe e terão o parâmetro qtde (int). A regra de negócio deverá calcular a quantidade do produto por meio de estoque + compra->qtde e subtraindo venda->qtde daquele total. Outro meio seria, por meio da regra de negócio, adicionar ou subtrair do parâmetro estoque, mas em sua implementação mais simples, isso faria perder o histórico de compras e vendas. Espero ter ajudado! Um abraço!
@@mcbrito1 Opa, eu errei ao dizer venda, na verdade tenho aqui Clientes,Venda e Produto.
Ainda se aplica essa lógica que vc me passou?
@@thyne_ A classe cliente se relaciona com a tabela venda, que o referenciará, para indicar quem está comprando, endereço de entrega, etc... É interessante falar que a modelagem das classes não necessariamente será idêntica à modelagem relacional do banco de dados. Assim, na modelagem relacional, eu criaria uma entidade fraca chamada venda_produto, onde eu vou criar uma tabela relacionando a entidade da venda com os produtos adquiridos. A lógica que te passei ainda se aplica, mas é necessário compreender qual seria a aplicação. Se for pra um sistema interno de uma loja, por exemplo, podemos ser mais pragmáticos. Já se for para um e-commerce de um grande varejista, deixamos o pragmatismo de lado e partimos para soluções bem mais complexas. Por fim, para tentar te ajudar o máximo dentro do que este campo de texto permite, pressupondo que trata-se de uma solução mais simples, pense nas entidades Cliente, Produto, Movimentação (que pode ser entrada ou saída). Na tabela produto, não teremos mais o campo estoque. Os quantitativos serão controlados por meio do campo movimentação. Criamos uma relação entre a entidade Movimentação e Cliente, para indicar por meio de quem o produto entrou ou saiu. É a implementação mais direta e simples que consigo conceber neste momento, em minutos e com os recursos que possuo. Espero ter ajudado!
@@mcbrito1 Cara é necessário colocar o ID no funcionário sendo que ele já possui o CPF para identificação? (Só dúvida mesmo)
@@Maxuuth eu colocaria, visto que o CPF não pode ser considerado um identificador unívoco. Pode demorar, mas um mesmo CPF pode pertencer a duas pessoas.
Qual é o nome que vc está usando p criar um diagrama?
Vc diz o aplicativo? É o diagrama.net. Ele está disponível online.