UML ternary association

Heeiman picture Heeiman · Oct 24, 2017 · Viewed 7.3k times · Source

I'm currently having some trouble understanding ternary associations in UML. I get the binary ones, but I am unsure how multiplicity works on ternary. I'm doing exercises that I got from my university, the current one goes like this:

One department may sell many products, but only to one market. On a market one product may only be sold by one department.

enter image description here

I've read on different sources about how I'm supposed to think about a pair of the two classes I'm not trying to figure out the multiplicity for, but my brain just isn't getting it. Help me Overflow Kenobi, you're my only hope.

Answer

Geert Bellekens picture Geert Bellekens · Oct 25, 2017

There seems to be some ambiguity in the specification of multiplicities on ternary associations. See also this paper

But I understand it like this:

The multiplicity says something about how many times an instance may be present in this associations for any given tuple of linked instances.

As an example, consider the following (traditional) family enter image description here
I would understand that as

In any given family there must be one father, one mother and zero or more children.

If we apply that to your case then I come to something like this:

enter image description here
I understand that as

For any given Offering there must be exactly one market, one department and one or more products

That seems to satisfy more or less all of your constraints

  • A Product can only be offered to one market by one department
  • A Department can offer multiple products, but one product can only be offered to one market

I don't think it's waterproof though, but as the paper already stated, UML does not have enough tools to make a waterproof design with the multiplicities on the ends alone. So for good measure, your constraints should also be modeled as UML constraints.

Disclaimer: Ternary associations are really nice for academical discussions, but are not really used in the (IT) industry, probably because they are so hard to understand.