2

In the UML, a Property is an association end and can be owned either by the association or by a participating Classifier, which is typically a class. When a Property is owned by a class, it's called an attribute. For example, an attribute Book::author could get one of the following notations (where a dot should be drawn at the author association end of the right-hand side diagram):

enter image description here

The attribute could be used in constraint expressions like: self.author or mybook.author->count()

This is straightforward for binary associations. But I have doubts how this works with ternary (or more generally N-ary) associations, for example:

enter image description here

Is it correct to state that Project would have an attribute participant and an attribute role since these are the opposite member ends of the association?

And considering that participant and role are not independent, how to make use of their correlation in constraints, for example to refer to the contributors having a given role, or to the set of (participant,role)-tuples to constrain its ->count() to less than 10?

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
Christophe
  • 68,716
  • 7
  • 72
  • 138
  • Wasn't it Axel who commented in a recent thread that one should avoid ternary assocs? Seems here's one more reason. I'd guess that each class has all the roles on the other ends. Now, what about the dot-notation? – qwerty_so Feb 27 '22 at 07:57
  • @qwerty_so In [this answer](https://stackoverflow.com/a/71275308/3723423) I suggested to better refactor ternaries into a set of binary associations. But in [his comment](https://stackoverflow.com/questions/71273913/historical-association-pattern/71275308#comment125988966_71275308), Axel made an interesting point about cases where ternary could have an advantage. So I overcame my difficulty to interpret the mutliple multiplicities and digged further and stumbled into this very practical question. More probably because of my disconfort with ternaries and my ignorance. – Christophe Feb 27 '22 at 10:40
  • 1
    I'll try to investigate as soon as the pipes in my ears get a bit more silent... – qwerty_so Feb 27 '22 at 19:25

2 Answers2

1

Of course, in your example, attributes like Project::participant or Project::role do not make any sense for representing ternary links.

The UML spec (in 11.4.3.1 Classes) states that

Attributes of a Class are Properties that are owned by the Class. Some of these attributes may represent the ends of binary Associations.

They don't mention the possibility of attributes as ends of non-binary Associations.

In 11.5.4 (page 202), as pointed out by @Christophe, they say

Ownership of Association ends by an associated Classifier may be indicated graphically by a small filled circle, which (...) we will term a dot.(...) The dot shows that the model includes a Property of the type (...). This Property is owned by the Classifier at the other end.

The important concept here is "the other end", which is also called "the opposite end" in other statements of the spec. It implies that there must be a unique other end of the association.

Consequently, since Attributes are association ends (= Properties) owned by the Classifier at the opposite end, they can only be the ends of a binary association.

This implies that for n-ary associations, the participating classes cannot own any end and can therefore not have (reference) attributes like Project::participant.

Also, using common sense: what would be the possible meaning of an attribute like Project::participant (or better: Project::participants)? It could be intended to represent the collection of all Contributor objects that participate in an instance/link of the ternary association Project-Contributor-Role. This could be defined as a derived attribute using an OCL expression. But it does not allow to represent/implement/reconstruct the ternary association.

In OOP, you could have a property like Project::contributorByRole the values of which would be ordered pairs from the Cartesian Product of Contributor and Role. Such a property represents/implements the ternary association. But, afaik, UML does not define Cartesian Product types and does, therefore, not support such tuple-valued properties.

Gerd Wagner
  • 5,481
  • 1
  • 22
  • 41
  • Interesting point. If indeed the member-end properties of a class would require a binary association, the problem would be solved. However, the usual meaning of MAY in standards (cf. [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) but also similar ISO guidelines), implies that "some may be binary" without excluding ternary. If your interpretation would be correct, the wording of the UML specs would require improvements. – Christophe Feb 28 '22 at 18:42
  • Unfortunately, several other places contradict such a restriction, in particular 9.5.3: "When a Property is an Association’s memberEnd, the value or values are related to the instance or instances at the other end**(s)** of the association". The explicit plural suggest that there might be more than one "other end" and allow for n-ary where n>2. The same section explains that the UML property `ownedAttribute` indicates whether or not the member end is a property and nothing seems to prevent this property to be set in ternary associations. – Christophe Feb 28 '22 at 18:46
  • A similar remark can be found later in 9.5.3: "In either case, when instantiated a Property represents a value or collection of values associated **with an instance of one (or in the case of a ternary or higher-order association, more than one)** Classifier." Wouldn't this wording explicitly aknowledge the existence of class propreties that are member ends of a ternary association? – Christophe Feb 28 '22 at 18:49
  • @Christophe No, they are not attributes (of the class "at the opposite end", which does not exist in the non-binary case), but "member end" properties of the association. – Gerd Wagner Feb 28 '22 at 19:06
  • Btw, in your last paragraph, do would you mean a combined property like [here](https://stackoverflow.com/questions/53269167/uml-ternary-association-implement-java-code#comment93561402_53269167)? Would there be any UML notation that could represent this for example with a qualifier? – Christophe Feb 28 '22 at 19:12
  • @Christophe "the wording of the UML specs" is not always logically precise, as you probably know yourself. On p. 202 they say "Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were assumed to be owned by the Association whereas navigable ends were assumed to be owned by the Classifier at the opposite end." The important concept here is "the opposite end". Since attributes are ends owned by the Classifier at the opposite end, they can only be the ends of a binary association. – Gerd Wagner Feb 28 '22 at 19:39
  • Thanks for this additional information. I see the reasoning about the opposite end. As the second quote refers to an obsolete semantic, I checked the definition of the dot notation. In 11.5.4 page 202: "***Ownership of Association ends** by an associated Classifier may be indicated graphically by a small filled circle, which (...) we will term a dot.(...) The dot shows that the model includes a Property of the type (...). This Property is owned by **the** Classifier at **the other end***". By applying your reasoning, and considering the explicit double singular form, we can infer that .../... – Christophe Feb 28 '22 at 22:29
  • .../... `ownedAttribute` can be set in the case of a member end, only in the case of a binary association, exactly as you suggest. Would you mind replacing your second quote about navigability with the quote about dot notation for association-end ownership? I'd then accept the answer – Christophe Feb 28 '22 at 22:33
  • 1
    Done. I've also improved the wording of your question. – Gerd Wagner Mar 01 '22 at 10:10
  • Excellent ! Many thanks ! All this is now very clear :-) – Christophe Mar 01 '22 at 12:07
1

For n-ary associations all ends must be owned by the association and thus, they are not attributes.

There is a constraint in section 11.8.1.8, so, it is as clear as it gets:

association_ends

Ends of Associations with more than two ends must be owned by the Association itself.

inv: memberEnd->size() > 2 implies ownedEnd->includesAll(memberEnd)

Axel Scheithauer
  • 2,758
  • 5
  • 13
  • Excellent. It definitively confirms the deduction that Gerd’s made from other clauses with an authoritative quote. I can accept only one answer, but I can give you my deep gratitude :-) – Christophe Mar 03 '22 at 12:57