Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » uml2.ecore mistake
uml2.ecore mistake [message #423913] Thu, 09 October 2008 16:14 Go to next message
Cyril Faucher is currently offline Cyril FaucherFriend
Messages: 63
Registered: July 2009
Member
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.
Re: uml2.ecore mistake [message #423915 is a reply to message #423913] Thu, 09 October 2008 16:20 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
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.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: uml2.ecore mistake [message #423933 is a reply to message #423915] Fri, 10 October 2008 08:18 Go to previous messageGo to next message
Cyril Faucher is currently offline Cyril FaucherFriend
Messages: 63
Registered: July 2009
Member
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. The same thing for
Element.ownedElement.
Now, if I have a setter on Element.owner, I am using the implementation
of the dedicated setter. This setter could not impact the value of
Element.owner then Element.ownedElement (opposite) will be not updated.

Finally, in my opinion and in this specific case, the opposite is there
just there for a semantic sugar, but ignored in the rest.

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.
Re: uml2.ecore mistake [message #423936 is a reply to message #423933] Fri, 10 October 2008 10:49 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
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.


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:[CDO 1.0] CDOInvalidationNotification
Next Topic:[EMF] PropertyType of an EStructuralFeature
Goto Forum:
  


Current Time: Fri Mar 29 14:49:57 GMT 2024

Powered by FUDForum. Page generated in 0.02408 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top