[news.eclipse.modeling.mdt.uml2] Re: uml2.ecore mistake

[Ed Merks <Ed.Merks@xxxxxxxxx>]

Cyril,

Comments below.

Cyril Faucher wrote:
> Ed,
>
> I think there is a redundancy, I mean:
>
> The context:
> EClass Element
> Element.owner as type Element (derived)
> Element.ownedElement as type Element (derived)
> Element.owner and Element.ownedElement are opposite
>
> If I want to get the value of Element.owner then I am using the 
> implementation of the dedicated getter. 
It looks to be derived from EObject.eContainer.
> The same thing for Element.ownedElement.
This looks to be a derived union, so I imagine it's effectively like 
containment reference.
> Now, if I have a setter on Element.owner, I am using the 
> implementation of the dedicated setter.
But there doesn't appear to be one. 
> This setter could not impact the value of Element.owner then 
> Element.ownedElement (opposite) will be not updated.
I guess it wouldn't be clear setting the owner which specific 
containment reference the child should go into.   However, if the child 
is added to some specific containment reference and hence effectively 
into the owned elements derived union, then that does impact the owner 
in the usual bidirectional way.  So while it doesn't seem necessary to 
make these things opposites, and hence redundant, it doesn't seem wrong 
or inconsistent.  In fact it seems useful in a perhaps fairly useless way...
> Finally, in my opinion and in this specific case, the opposite is 
> there just there for a semantic sugar, but ignored in the rest.
I guess so.  If you looked at the class diagram representation, it's 
represented as an association with two ends though right?
> Cyril.
>
> Ed Merks a écrit :
> > Cyril,
> >
> > It sounds okay to me, especially if they are derived from references 
> > that are similarly paired as opposites.  Why do you think it doesn't 
> > make sense?
> >
> >
> > Cyril Faucher wrote:
> > > Hi,
> > >
> > > I have a question about the metamodel of uml2: uml2.ecore.
> > > The EClass "Element" has 2 EReferences "owner" and "ownedElement".
> > > These 2 EReferences are derived.
> > > My problem is: why they are opposite, I guess that comes from the 
> > > translation of an UML Association in Ecore.
> > >
> > > For me, I think that does not make sense in Ecore to have 2 derived 
> > > EReferences and opposite.
> > >
> > > Best regards,
> > > Cyril.