How to represent merchandise flavours (or product variants)?

Question

I have the following UML diagram:

Where VarietyCategory could take values like size and colour, and Variety for size could be S, M, L, and for colour could be green, red.

Now I can have a stock per combination of varieties, taken from the Cartesian product of all the variety categories a merchandise have (for example, 5 S-green items and 10 M-red items). How can I add this information to the UML diagram?

I guess I'm seeing this as an optional association class from Merchandise to the space defined by the Cartesian product of all the VarietyCategorys with a quantity attribute specifying the stock for that given combination, but I can't see how to express that in UML.

After thinking a bit I've come up with this, but this doesn't seem to fully convey the intention, as I had to put a note to specify a multiplicity depending on another part of the diagram, along with the constraint of selecting a variety from each variety category:

Any better ideas on how to do this?

Answer 1

The problem

This is indeed a popular scenario in some industries such as apparels, where each item in the catalogue is configurable regarding size, color and style.

The stock of a configurable merchandise such as "Shirt" does not make sense except for statistical purpose, but what really matters is the stock of the configured merchandises, e.g. {Item: "Shirt", size: "M", color="white", style:"italian colar"}. Here it's even more complicated, since the configuration elements are dynamic.

Your solution

Your second diagram models this very well by using a combination that you've called Flavor. So for the shirt, each possible combination of the configuration variables (Variety), e.g. the tuple ( "M","white","italian colar) would be a distinct flavor. Your association would class would hold the stock quantity of the Flavor.

The multiplicity on the Variety side would be by deduction 1..*. The constraint then needs to express that for an occurence of Flavor, the size of set of associated Variety occurrences is the same than those indirectly associated with the Merchandise. A full-text expression like you did is just fine. The other alternative would be to express this with a complex OCL predicate, which is very difficult considering some missing role names and the multiple indirections. Btw, most readers wouldn't anyway understand it.

However, I would not keep this solution:

• Its main weakness is that the Flavor seems independent from the Merchandise, whereas in reality it only makes sense for a given Merchandise (your constraint proves it).
• It is not easy to manage more complex stock, for example if you'd have a stock per warehouse.

Better alternatives

If you'd consider Flavor as a flavor of a given Merchandise, you could make this explicit and simplify the design: Flavor would become the configured Merchandise (instead of just a combination of Variety) and could make it a component of the Merchandise composite.

You could then simplify and store the stock quantity at the level of the Flavor . Or you could manage the stock quantity in an association class between the Flavor and a Warehouse (which you could not really do with your current model).

Everywhere you'd use a Merchandise, you'd use a Flavor instead, facilitating for example the ordering or the shiping of configured products, which is much more difficult if you'd keep the flavor independent of the merchandise.

To avoid confusion, it would nevertheless be better to rename Flavor in something more explicit that reminds that it's a product that you manage in your system.

Answer 2

A product variant (like Tesla's Model 3 in Pearl White with Sport Wheels) for a product (like Tesla's Model 3) has all features of the product (like a top speed of 140 mph) and additionally a set of attribute-value slots for all variation attributes of the product (like "Paint" and "Wheel" in the case of Tesla's Model 3). This is described by the following class diagram:

The diagram includes data samples next to classes for illustrating their meaning.

Notice that using composition for associating variation attributes to products and variation attribute values to variation attributes means that these attributes and their values are specific and not shared among products/attributes.

A corresponding relational database schema can be read off from this model:

products( id, vendor_id)
product_variation_attributes( id, product_id, name)
variation_attribute_values( id, product_variation_attribute_id, value)
product_variants( id, product_id, price)
variant_slots( product_variant_id, product_variation_attribute_id, variation_attribute_value_id)

This model/schema is compatible (modulo renaming) with the confirmed answers https://stackoverflow.com/a/19200349/2795909 and https://stackoverflow.com/a/24941744/2795909.