Oi pessoal, bem eu tô com uma grande dificuldade em relação ao meu diagrama de classe de um projeto da escola que estou desenvolvendo, é sobre um Fast Food. Eu coloquei uma classe abstrata chamada Pessoa e duas classes concretas dela chamada Cliente e Funcionário, e sobre o resto, estou em dúvida se coloco a classe Pedido como abstrata e mais as classes Comida e Bebida sendo subclasses dela…ou se coloco só uma classe chamada Pedido e um atributo chamado tipo ou categoria pra especificar se é bebida ou comida o tipo do pedido… e esse sistema vai ter que ter um Banco de Ddados e os dados vão ser adicionado por meio de um formulário em html e php!
E no diagrama tenho que colocar: herança, classe abstrata, concreta e interface.
Me ajudem pessoal, o professor disse que esse trabalho é só a última martelada no prego pra fechar nosso caixão kkk sério, o que vocês acham? Tem alguma ideia?
Cliente, Funcionario, Pedido, ItemPedido, Produto e Categoria (do produto). Sem essas complicações de herança.
No caso da classe Pessoa e as classes Cliente e Funcionario, eu não usaria herança e sim delegação, ou melhor, composição:
A menos que o seu professor queira que seja herança (ou não tenha ensinado sobre composição). Caso seja esse o caso:
Comida e Bebida, creio eu não são subclasses de Pedido, mas sim de Produto ou Item (generalização requer um nome genérico). Pedido pressupõe venda, mas parece que está só ‘ajudando’ na definição de Bebida e Comida. Sobre como modelar, depende. Comida e Bebida terão características (atributos) diferentes? Se não, creio que não faça sentido separá-las em duas classes especializadas de uma outra genérica. Mas são só ilações da minha parte, pois depende da sua regra de negócio.
Se tu expor melhor como o negócio funciona, ou seja, a regra de negócio (como as coisas devem funcionar) fica mais fácil modelar. Tu deve escrever no papel como as coisas funcionam para depois traduzir isso para um modelo (minha opinião).
1 curtida
Então, @Iohannes tem que ter herança porquê no diagrama tem que conter classe Abstrata, concreta e interface… Ah e eu esqueci de dizer que esse sistema vai ter que ter um banco de dados e os daods vão ser adicionado por meio de um formulário em html e php!
Screenshot_20191026-145228|281x500
@Iohannes
Na classe Pedido(que vou mudar para Produto, como você sugeriu) os atributos são: nome, preço e descrição, e em Comida e Bebida, os atributos de Bebida seria: marca, quantidadeML e tipo que indica se é refrigerante ou suco, agora em Comida eu não consegui ainda identificar nenhum atributo que possa se encaixar…Tem alguma idéia?
Se houver herança pobre, então não está bem fundamentado (uma das premissa que uso para validar herança).
Algumas indagações:
1 - Qual é a importância do Funcionario para a modelagem do negócio? Você precisa registrar a quantidade de vendas que ele fez ou algo assim? Deve se logar para poder alimentar o sistema. Ou vais implementá-lo só para justificar a ‘herança’ com Pessoa?
2 - O que uma Pessoa tem de características que precisa ser especializado em outros papéis de pessoa, no caso Cliente e Funcionario? Isto é, Cliente e Funcionário, melhoram a definição de Pessoa entregando mais informações sobre a Pessoa?
3 - O que há em Cliente que não há em Funcionario? Ou seja, quais características (atributos) determinam que um Cliente é uma Pessoa diferente de Funcionario?
4 - O que tem em Comida que especializa um Produto ou Item? E em Bebida? O que difere um Produto Comida de um Produto Bebida?
5 - Onde pretende aplicar interface?
Qunato a interface, eu tava pensando em colocar ela para as subclasses da classe abstrata Pessoa, implementando todos os métodos do CRUD existentes nas duas subclasses
Ah, e agora analisei direito a classe Funcionário e realmente estou usando ela só pra de alguma forma inserir o uso de herança que o professor pede. @Iohannes eu tiro ela então?
Se não participa da regra de negócio (não interage com o sistema) sim, deve ser retirada. O seu site terá uma sessão administrativa? Se sim, você pode definir um administrador do sistema que, nesse caso, participaria da regra de negócio alimentando as informações sobre as bebidas e comidas, por exemplo. Desta forma, o sistema teria um sistema de login e você poderia usar o conceito de herança que você havia pensado para a classe Funcionario. Como se vê, tudo depende da sua regra de negócio.
Sim, terá uma seção administrativa, eu tava pensando em fazer o sistema para ser utilizado pelo Funcionário e não pelo Cliente. O Funcionário entraria com o login dele e a partir daí poderia adicionar(um CRUD completo) clientes, bebidas e comidas sabe?
Mas se é uma aplicação web, dessa forma, creio eu, não faria sentido. O sistema deve possibilitar que o cliente se cadastre, faça o pedido e realize sem sair de casa (sem precisar ir até o estabelecimento, ou telefonar…), por que senão qual o sentido de ser uma aplicação da web? O funcionário ou administrador só seria responsável por alimentar a grade de opções (de comidas e bebidas, preços, promoções, etc.). Mas como eu disse, quem define a regra de negócio é você.
Entendi… e é realmente faz sentido!
E parece ser mais fácil, vou tentar implementa-lo assim, valeu pelas dicas aí e tudo, eu tava muito confuso nessa parte e antes de começar eu achava que a fase do Diagrama de Classes seria a mais fácil haha
Obrigado @Iohannes!
Como o título diz que é um sistema de fast food, talvez pareça meio sem sentido não permitir que o usuário tenha acesso ao processo de realizar pedido. Porém, se formos pensar em uma pizzaria, onde ter os dados do cliente cadastrado é fundamental e é o funcionário quem interage com o sistema, então, faz sentido.
Particularmente, eu acho um saco isso de ter obrigatoriedade na inclusão de certas coisas. Se o aluno não identificou a necessidade, não coloca. Apenas justifica, com fundamentação, que aquilo era dispensável.
Porém, é como as coisas funcionam, manda quem pode, obedece quem tem juízo, não é?
Verdade, eu tava querendo fazer assim de inicio, só que como é um sistema web fica sem sentido mesmo.
Então se eu fizer assim, o Cliente vai fazer o pedido online, e aí o pedido fica salvo no Banco de Dados né? Só isso? Não tem essa de pagamento?
Cara, vamos voltar ao foco: o diagrama de classes nem sempre vai interferir ou mesmo alterar a funcionalidade da tua aplicação.
Veja, a ideia do diagrama de classes é ter uma visão macro das principais classes do teu sistema.
Obviamente, estas classes serão as que você vai definir como sendo o modelo da aplicação. Elas irão, sim, refletir no banco de dados. Porém, a maneira como você vai interagir não precisa, necessariamente, ser especificada nesse diagrama.
Exemplo: cadastro de cliente pode ser manipulado pelo cliente e por um funcionário. Pedido, pode ser feito por um cliente ou funcionário. Executar pedido só pode ser feito pelo funcionário. Dar pontuação de atendimento, apenas o cliente. Relatórios, só o gerente. E assim por diante.
Essas especificidades não precisam, necessariamente, constar do diagrama de classes (talvez caibam no diagrama de casos de uso, por exemplo).
Ok, obrigado @darlan_machad!
Outra dúvida, quanto a classe Pedido, o que vc acha de ter outras duas subclasses dela chamada Comida e Bebida? Ou você acha mais fácil deixar só Pedido?
Acho uma péssima ideia.
Para mim, pedido é o mesmo que comanda. Você vai marcar ali o que foi solicitado pelo cliente, independente de bebida, comida ou seja o que for. Como o @javaflex sugeriu: Pedido, item pedido, produto. Aí sim, produto pode ter generalizações, bebida e comida.
Cada pedido tem N produtos e cada produto pode constar em N pedidos, logo, você cria uma classe associativa chamada ItemPedido que nada mais é que uma classe que identifica o produto e sua quantidade, sendo inserido numa coleção da classe Pedido.
Aí você tem composição (Pedido tem um ou vários item pedido), composição (um item pedido tem um produto), generalização (ou herança) (um produto é uma bebida ou uma comida).
Para representar a implementação (uso de interfaces), você vai acabar entrando no quesito funcionalidade (toda interface é um contrato. Contratos definem comportamentos). Assim sendo, seria interessante pensar em como essa interface pode ser útil em mais de um aspecto. Exemplo: definir entrega (para viagem, comer no local, delivery). Cada forma de entregar demanda uma implementação distinta.
Minha nossa, é complicado mesmo essas coisas!
Pelo contrário, era pra ser simples, sem heranças e interfaces. Mas como é um exercício te obrigando a usar herança e interface, faz o que Darlan sugeriu.
