I have a hard time understanding the concept of association class as explained in UML 2.5 specification. The thing that confuses me the most is the following sentence taken from page 199:
NOTE. Even when all ends of the AssociationClass have isUnique=true, it is possible to have several instances associating the same set of instances of the end Classes.
As noted here: https://issues.omg.org/issues/UMLR-757 this single sentence seems to undermine the usefulness of the concept. At the same time, it makes pretty much every text explaining the concept written before 2.5 version of the UML spec obsolete – see for example the discussion here: UML association class - clarifying
But how can this actually work conceptually? Assuming all ends of the association class have isUnique=true
, how can one have more than one instance of association class associating the same set of instances of the end classes, when isUnique
property of member ends clearly forbids existence of such links?
I’ve always thought that an association class is just a regular association with extra attributes and/or operations. That interpretation seems to invalid now. So what exactly is association class? How can it have uniqueness independent from that of association member ends? There seem to be some unspoken multiplicity lurking somewhere (uniqueness is irrelevant property without maximum multiplicity higher than 1
), but I can't figure out where.
An association class defines an object-oriented pattern to manage * -- * (many to many) associations when data needs to be stored about each link of that association. An association class is a class and can have the items found in an ordinary class (attributes, state machines, etc.).
In UML diagrams, an association class is a class that is part of an association relationship between two other classes. You can attach an association class to an association relationship to provide additional information about the relationship.
Each end of an association is a role specifying the face that a class plays in the association. Each role must have a name, and the role names opposite a class must be unique. The role name should be a noun indicating the associated object's role in relation to the associating object.
You can create as many associations between classes as you need. There is no limit. You should add association-end names to clarify the purpose of each association, since without them the model will just not make much sense. However, in your example you have one association class and a normal association.
Indeed, this is not super-clear and would deserve a better explanation. To make it short: it’s just a consequence of the lack of integration in the dual semantics defined for the association class.
According to UML 2.5.1 section 11.5.3.1, page 197:
When one or more ends of the Association have isUnique=false, it is possible to have several links associating the same set of instances.
We can deduct using logical contraposition that:
If it is not possible to have several links associating the same set of instances, all ends of the association have isUnique=true.
So we'd expect this to apply to an assocation class as well, since the association class is also an association.
According to UML 2.5.1 section 11.5.3.2:
An AssociationClass is both an Association and a Class, and preserves the static and dynamic semantics of both.
So, an association class is not just "an association with extra attributes". If it were that simple, the association class could perfectly be a generalization of an association: the specialized association would just inherit the extra attributes. But this is explicitly prohibited page 199:
An AssociationClass cannot be a generalization of an Association or a Class.
because any specialization into a class would loose the association semantics, and any specialization into an association would loose the class semantics.
And this duality, is the cause of our issue.
According to UML section 11.5.3.2, page 199 (formatting from me):
An instance of an AssociationClass has the characteristics both of a link representing an instantiation of the AssociationClass as a kind of Association, AND of an object representing an instantiation of the AssociationClass as a kind of Class.
If isUnique=true
for all association ends, the instances of the association are guaranteed to be unique. Remind however that the association is only about tuples made out of the association ends:
An Association declares that there can be links between instances whose types conform to or implement the associated types. A link is a tuple with one value for each memberEnd of the Association, where each value is an instance whose type conforms to or implements the type at the end.
However, nothing in the specs requires that the class instantiation (object) representing the association instantiation needs to be unique.
Imagine for example, that we have an association class between class A
and class B
, and a
and b
are instances of these classes. Imagine that the association ends have isUnique=true
. This means that there can be only one tuple (a,b)
since the association is guaranteed to be unique.
Let P be a property of the association class, and let (a,b,p1)
and (a,b,p2)
be two instances of the class in the association-class. The class knows no association-ends: from the point of view of the class, there is no unicity requirement. And from the point of view of the association, we have only one tuple (a,b)
, so it's ok as well.
The NOTE just explains that this (unfortunate and ambiguous) situation is possible.
Formally, there is no contradiction. This is the result of the way the association class is defined: a class and an association at the same time, without further defining the relationship between the respective instances.
But this creates some issues in regard of the semantics of associations having non-unique ends:
When one or more ends of the Association have
isUnique=false
, it is possible to have several links associating the same set of instances. In such a case, links carry an additional identifier apart from their end values.
More precisely, this makes the the association-class with unique ends useless, since the same result can be achieved with non-unique ends:
IMHO, this is unfortunate:
isUnique=true
should have a unique object instance of the class for a unique combination association ends. This clearly goes against the principle of least astonishment: I started with deny and it took me a while to accept this, since it was so terribly different from the traditional ways to implement association classes.A simple solution to this issue would be to require a unique class instance (object corresponding to the association class) to correspond to a link that uniquely associates association ends. In that way, unique association ends would imply unique association object, without requiring other changes to the UML specs.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With