First is there a store, which can be a grocery store. Any store has two type of objects: items and purchases. Without items and/or purchases will the store stop to exist. Items will exist without the store (they must be delivered to the store for instance), but the purchases belong to the store itself. That is why there is an aggregational relationship between store and item, yet a compositional relationship between store and purchase.
Items have some features, like name, edible, taxable, weight and unit. I did not implement all characteristics of an item, but the idea is there. There are a lot of ways to sell those items. There might be more strategies used at the same time. For that situation is the decorator pattern designed. It can add several strategies dynamically at runtime. It is decorating the item - interface, because it is associated with the item, because change in the way to sell finds its cause in the Item. It has an association with the class purchase, but it is not part of the purchase. Every item that will be sold belongs to a specific purchase. It can also have the state not being sold yet. That is why the multiplicity of the purchase is 0-1. All in all boils it down to this: