After the first post in this series, I discuss today another modeling concept that it’s often misunderstood by new modelers: n-ary associations, and especially, how to interpret the semantics of their cardinalities.

A n-ary association is an association that involves more than two participants. More formally: The degree of a relationship type is the number of participants in that type. Most relationship types have degree 2, and are called binary. Relationship types with a degree greater than 2 are called n-ary. The most common of the n-ary relationship types are those that have degree 3, which are referred
to as ternary (definition taken from the best conceptual modeling book by Antoni Olivé). N-ary relationships are present in UML but also in most other modeling languages, like ER.

An example of a ternary relationship is the one illustrating this post, The association models the fact that players play in teams for a given season. So, a playing record involves a player, a team, and a year. Without one of the three, the information is incomplete.

But let’s see another example with different cardinalities. How should these cardinalities be interpreted? According to the UML specification, “a lower multiplicity for an end of an nary Association of 1 (or more) implies that one link (or more) must exist for every possible combination of values for the other ends”. Not very clear IMHO. So again, I prefer to use the way Antoni describes it in his book: the multiplicity in one end describes how many objects of that type can be linked to a given combination of objects of all the other types.

So, for this Course-Semester-Student example, this would mean that the cardinalities state:

• Every semester, a course has between 20 and 80 students enrolled
• In a given semester, a student can take between 0 and 6 courses
• A student can repeat a course as many times as needed, i.e. a combination of a <course, student> can be linked with an unlimited number of semester objects

Note that these are the only three cardinalities that are graphically stated in the diagram. Aspects like:

• How many courses a student can take during his whole degree?
• In a semester, how many students can be enrolled across all different courses
• How many courses can we have opened in a semester?
• etc

are not covered by the association.

Note that many UML tools do not even support the modeling of n-ary relationships and would suggest reifying the association, i.e. transforming the association into a class. This would reshape the previous example into the following one:

Do you see what we are missing in this new version? All the specific cardinalities constraining the links have now disappeared. So the three multiplicites we were able to depict graphically before will need now to be reexpressed in OCL if we want this reified diagram is semantically equivalent to its corresponding non-reified version.

Jordi Cabot

FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg.  More about me.