Order of aggregation with generalization and specialization

Both diagrams are correct, but have a very different meaning:

• The first diagram says that an order is an aggregation of products, and these products can be more specialized (e.g. milk and pizza). This design decouples the order from specific products: You can therefore easily imagine other product specializations such as Cake without changing the meaning of the order (it is said to be "open for extension").
• The second diagram says that an order is an aggregate of pizzas and milk, and that pizza an milk are by the way specializations of products. This is much more restrictive: the order is coupled to specific products, so every time your order should deal with a new kind of products that is neither some kind of milk or some kind of pizza (e.g. Cake), the definition of your order would have to be modified.

Considering the Open-Closed Principle the first diagram is definitely the one to chose. The second one is too cumbersome.

Remark: by the way, while aggregation is still very popular for historical reasons, the UML specifications don't define its semantic. You could therefore remove the white diamonds and express exactly the same meaning.

Both are semantically correct, meaning they can be properly interpreted.

Moreover, if the multiplicities in all aggregations are 1 (on diamond side) and * (on opposite end) and there are is other information regarding those relationships then they even have the same semantical meaning. In such case usually using an aggregation to the generalised class is usually preferred due to simpler diagram, but even in such case there may be reasons to use the second notation.

However the proposed above multiplicities may not be the case and there can be many other reasons to distinguish the aggregations between two different product types. In those cases only the second notation will be suitable (however there are other possibilities as well).

You may also want to indicate things where the aggregation to the generalised class is significant, in which case it is a better way of simple presentation of the requirements.

Just a few examples.

If you want to show you need to have anything in the order, no matter the type, the first notation will serve better.

If you need to order a minimum quantity of pizza, but milk is optional, the second is better.

If you have a limit of how much pizzas and how much milk can you order (each separate), then the second is better.

If your order has a weight limit, regardless of the amounts, then the first one will probably be better (with respective constraint).

You get the picture.

Moreover, sometimes you actually combine both on a single diagram (and the same classes).

Example: Let's say you cannot order more than 10 elements but at the same time you need to order at least one item of each type. You will show both types of aggregation, adding the /subsets constrain to indicate these are actually the same elements involved.

For more detailed answer, you'd have to provide more detailed question ;-)