Diagrama de classes UML - Pizza Express

Olá, tudo bem?

Estou tendo algumas dificuldades para elaboração de um projeto. Preciso fazer um diagrama de classes em UML de uma franquia de pizzarias.Se consiste basicamente no funcionamento de uma franquia onde o cliente entra em contato tanto pelo telefone quanto pelo site para realizar o pedido. Assim, o fluxo é demonstrado no diagrama de forma a seguir uma politica de realização de pedido fluída. Com isso, após passar diversas vezes por revisões de meu professor, não consigo encontrar outra forma de melhorar este diagrama.
Poderiam por gentileza apontar possíveis erros, e até conceder dicas para melhorar o meu projeto?

Obrigado desde já!

Sem os requisitos não tem como validar nada.

Amigo, poderia esclarecer? Quais requisitos estão faltando?
Obrigado desde já!

Poste o diagrama aqui no fórum como uma imagem. Adianto que na composição o todo não é o cliente e nem o item, mas sim o pedido…

Amigo, postei a imagem no hyperlink da palavra “meu projeto”.
Deixei como foco mesmo a classe pedido, consequentemente com mais atributos. Poderia julgar se a minha maneira foi a mais correta?

Certo, só links externos tem alguns inconvenientes:
1 - É externo ao fórum então pode ser que fique offline depois de um tempo e pessoas que tiverem o mesmo problema que você não poderão usar esse post adequadamente;
2 - Ao abrir em um link externo, ficar trocando de página para te responder é chato.

Mas como eu disse a modelagem da composição está incorreta. Quando tu postar a imagem no fórum eu digo o porquê.

diagrama%20de%20classes%20pizza%20express%20(1)

Desculpe amigo, tinha em mente que apenas conseguiria mostrar a imagem por meio de um Hyperlink, como acontece no github. Desconhecia este recurso de postar a iimagem aqui neste fórum.

Desde já agradeço a atenção!

Se atente para a seguinte questão: Quem compõem quem. O Cliente compõe um Pedido ou um Pedido é composto por Cliente? A relação entre o cliente e o pedido é mesmo uma composição? Da mesma forma, e quanto ao Item. É claro que tanto Cliente como Item são partes de um todo que é o Pedido. De fato, você percebeu isso e, tanto é que indicou que a classe Cliente e uma lista de Item faz parte do Pedido. Mas é essa participação é necessária (composição) ou casual (agregação) em relação às partes para com o todo?. De qualquer forma, há alguns erros de notação (forma de escrever a simbologia, o diagrama). O primeiro deles, independentemente se o relacionamento está correto ou não, é que o losango preenchido (indicando composição) fica sempre do lado do todo. Logo era esperado algo como:

image

O que está errado (invertido) no relacionamento Cliente-Pedido.
O segundo deles é que, quando se denota que uma associação entre duas classes (associação simples, associação de agregação ou associação de composição), não se indica a classe parte na classe todo, já que o relacionamento já cumpre esse papel. Logo, é redundante indicar a classe Cliente e a classe Item na classe Pedido, já que o relacionamento de composição já indica que essas classes compõem a classe Pedido.
Outro erro é aparentemente, a relação entre Pedido e Cliente não é de composição, mas sim de agregação:

image

Tanto a agregação quanto a composição são formas de associação, cada uma especializando mais a associação. Uma associação é um relacionamento entre duas classes e tem por objetivo definir as responsabilidades de cada classe e a navegabilidade (Fonte: UFCG - Diagrama de Classes). Descreve basicamente uma relação física entre as classes. Uma agregação é um tipo de associação, portanto uma especialização da associação em que há uma ligação semântica. Isso significa que a associação não descreve somente uma ligação física, mas também uma ligação de significante. Em outras palavras, na agregação, descreve-se que existe uma classe que não está totalmente definida em si mesma, precisando de agregados para finalizar a sua definição, ou seja, existe uma relação do todo com as suas partes e vice-versa. No entanto, essa ligação não muito forte, pois as partes em si estão totalmente definidas, estão completas em relação ao sistema. Assim, se o todo deixa de existir ou é excluído, as partes que o compunham não precisam ser excluídas, porque tem existência própria no sistema.
A composição por sua vez é um tipo de agregação mais forte. Isso significa que as partes só fazem sentido no sistema se estiverem no todo. Da mesma forma, o todo não tem como existir sem as partes que o compõem. A grosso modo é como se na agregação, só o todo é dependente, uma mão única de dependência, enquanto que na composição, existe uma dependência mútua entre o todo e as partes que o compõe, uma via de mão dupla. Com base nisso, façamos uma suposição: Suponhamos que o pedido p10 tem vinculado a ele o cliente c1 e os itens i1, i5 e i7. Se você excluir o pedido p10, você precisa excluir o cliente c1, ou ele pode continuar existindo no seu sistema? E os itens? Se você excluir o pedido p10, você tem que excluir os itens i1, i5 e i7? Se a resposta for não, então não há uma relação de composição. De fato, na composição, as partes não podem existir fora do todo, porque a única justificativa para estarem no sistema é a de formar o todo. É como uma casa, onde a única justificativa de se ter paredes é ‘montar’ a casa. Se a casa é demolida, a primeira coisa que vem a baixo são suas paredes. Na composição, o todo tem como função criar as suas partes, ou seja, instanciar as classes que de seus objetos faz uso, por que as classes parte em si não usada em outras partes do sistema senão compondo o todo. Nesse caso, se houver uma relação de composição entre o Pedido e Cliente, caberá a classe Pedido ‘criar’ objetos da classe Cliente. Da mesma forma em relação à classe Item. Se assim for:

image

Na composição, um determinado objeto do todo só pode ser composto por determinados objetos das partes, por isso, deve caber ao todo criar as suas partes.
Depois de exposto tudo isso, vem a ressalva: nem todos os estudiosos do assunto aceitam essa distinção entre agregação e composição, ou que a agregação é um tipo de associação especializada. Já outros criam inúmeras outras formas de agregação além da composição, dando-lhe nesse caso outros nomes (Fonte: UFCG: Diagrama de Classes - Relacionamentos).

Sugiro cogitar a possibilidade de modelar o sistema inicialmente em um Caso de Uso, como fez o @Pedrofl2001 que tem um problema igual (Delivery de Pizzas): Diagrama de Caso de Uso - Delivery. Com base nele, creio eu que fique mais fácil identificar a regra de negócio e as classes envolvidas.

Algumas outras observações:

1 - Se Cliente tem Endereco e Pedido registra Cliente, porque o pedido tem que registrar o Endereco se ele pode recuperar isso pelo Cliente?

2 - Nomes de classe, por convenção deve-se grafar no singular. Logo, era esperado Item e não Itens.

3 - Há classes anêmicas na sua modelagem, isto é que entregam pouca informação ao sistema, como, por exemplo Categoria, Pizzaiolo, etc. Veja se realmente elas são necessárias.

4 - Nome de atributos, classes, etc., devem seguir preferencialmente o padrão de nomenclatura CamelCase ou underscored. Assim, por exemplo, o atributo “forma de pagamento”, pode ser grafado como formaDePagamento, formaPagamento, forma_de_pagamento ou forma_pagamanto. Não se deve usar pontuação e muito menos acentuação, muito embora, o Java use o Unicode e não o ASCII como charset.
Nome de atributos (UML) e características (POO) são grafadas com a primeira letra em minúscula, podendo usar qualquer uma das notações indicadas acima.
Não se deve misturar os dois tipos de notação em uma mesma modelagem