The problem
-----------
In the reflexion package of MOF2, the proposal for links assumes that
AssociationEnds are ordered.
There is an implicit mapping between firstObject and secondObject roles and
AssociationEnds is based on this assumption:
FirstObject maps to the first associationEnd
SecondObject maps to the second associationEnd
This leads to the following Operation to create links in the Factory Class:
createLink(association: Association, firstObject : Object, secondObject :
Object): Link
At first glance, this solution provides an easy way to identify the link
members in parameters of link operations. However, the AssociationEnd is
difficult to read. It is closer to relational concepts than to
object/association principles.
One will always have to guess which is the first or second object.
The modeler who has created the association might remember the order. But
the user using the association will probably be lost.
Example:
Country:Class - resident:AssociationEnd (First) - Citizenship:Association
- country:AssociationEnd (Second) - Country:Class
createLink("Citizenhip": Association, "Thomas": Object : "France" :
Object)
Proposal
--------
The idea is to benefit from the semantic carried by AssociationEnds
themselves:
A link defines members. Each member references a participant object
according to a role defined by the AssociationEnd.
Thanks to opposite association of AssociationEnds (aka Property), it is
possible to identify one end from another. This means that if we create
links from an AssociationEnd viewpoint, there is no need to order
AssociationEnd.
The proposal is to order the creation parameters as follow: sourceObject,
oppositeRole, oppositeObject.
Of course, this approach only works for binary associations. But the focus
of AssociationEnd is the first step to take into account nary associations.
This also highlight that what matters most in Association semantic is the
role name of AssociationEnds.
It is usually much more difficult to have a meaningful name for association.
This is why we can often see names such as "has for ..." which do not carry
much information about the association.
All operations on links are redefined as follow:
createLink (sourceObject : Object, oppositeRole : Property, oppositeObject :
Object)
Example:
createLink("Thomas:Object","country:Role","France:Object")
equivalent to:
createLink("France:Object","resident:Role","Thomas:Object")
linkedObjects (sourceObject : Object, oppositeRole : Property) :
Object[0..*]
LinkExists (sourceObject : Object, oppositeRole : Property, oppositeObject :
Object) : Boolean
Proposal Comments
-----------------
A better proposal would not use the opposite role but the role attached to
the object participation to the association.
createLink("resident:Property","Thomas:Object","France:Object")
But experience shows that this is two much unsual for modelers. This would
however be the right path for the introduction of nary associations.