Issue 5996: MOF 2 Issue: Reflexion and Links (mu2i-ftf) Source: MEGA International (Mr. Antoine Lonjon, antoine.lonjon@mega.com alonjon@mega.com mblin@mega.com) Nature: Uncategorized Issue Severity: Summary: 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. Resolution: Revised Text: Actions taken: July 11, 2003: received issue Discussion: End of Annotations:===== From: LONJON Antoine To: "'issues@omg.org'" Subject: MOF 2 Issue: Reflexion and Links Date: Fri, 11 Jul 2003 18:04:16 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) 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. MEGA - Reflection and Link.doc