Home » Modeling » EMF » symmetric references
| |
| Re: symmetric references [message #417130 is a reply to message #417118] |
Wed, 27 February 2008 13:46   |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Ed,
I don't know of any restriction in UML/CMOF that constrains a reflexive
association of multiplicity [1] on both ends to not be bidirectional. The
classic example is the circular linked list, in which an Entry has a
next<--->previous association and when there is only one element in the
list, the sole entry is its own next and previous.
Cheers,
Christian
Ed Merks wrote:
> Jim,
>
> If I recall correctly, things like inverseAdd become problematic for the
> case x1 is connectedTo x1. I think such a thing also doesn't correspond
> to an association in UML/CMOF. Special case support would be needed to
> produce correct behavior.
>
>
> Jim Steel wrote:
>>
>> Hi,
>>
>> I have an class X that has a reference "connectedTo", of type X. The
>> reference is symmetric, i.e. x1.connectedTo == x2 implies that
>> x2.connectedTo == x1. Intuitively, connectedTo is its own eOpposite.
>>
>> I found a thread from a couple of years back that this was not
>> supported, but without any particularly good reason why not.
>>
>> Any update on that?
>>
>> Jim.
|
|
|
| Re: symmetric references [message #417136 is a reply to message #417130] |
Wed, 27 February 2008 14:03 |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------090004040803090806020306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Christian,
I just asked Kenn and he says this isn't allowed in UML2. I.e., he says
the member ends of an association must be unique and there must be at
least two. Your example of next/previous is using two different
references representing the ends of the association is fine and of
course there is only one type involved in this case. But Jim's example
is not fine.
Christian W. Damus wrote:
> Hi, Ed,
>
> I don't know of any restriction in UML/CMOF that constrains a reflexive
> association of multiplicity [1] on both ends to not be bidirectional. The
> classic example is the circular linked list, in which an Entry has a
> next<--->previous association and when there is only one element in the
> list, the sole entry is its own next and previous.
>
> Cheers,
>
> Christian
>
>
> Ed Merks wrote:
>
>
>> Jim,
>>
>> If I recall correctly, things like inverseAdd become problematic for the
>> case x1 is connectedTo x1. I think such a thing also doesn't correspond
>> to an association in UML/CMOF. Special case support would be needed to
>> produce correct behavior.
>>
>>
>> Jim Steel wrote:
>>
>>> Hi,
>>>
>>> I have an class X that has a reference "connectedTo", of type X. The
>>> reference is symmetric, i.e. x1.connectedTo == x2 implies that
>>> x2.connectedTo == x1. Intuitively, connectedTo is its own eOpposite.
>>>
>>> I found a thread from a couple of years back that this was not
>>> supported, but without any particularly good reason why not.
>>>
>>> Any update on that?
>>>
>>> Jim.
>>>
>
>
--------------090004040803090806020306
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Christian,<br>
<br>
I just asked Kenn and he says this isn't allowed in UML2. I.e., he
says the member ends of an association must be unique and there must be
at least two. Your example of next/previous is using two different
references representing the ends of the association is fine and of
course there is only one type involved in this case. But Jim's example
is not fine.<br>
<br>
<br>
Christian W. Damus wrote:
<blockquote cite="mid:fq3pis$k9h$1@build.eclipse.org" type="cite">
<pre wrap="">Hi, Ed,
I don't know of any restriction in UML/CMOF that constrains a reflexive
association of multiplicity [1] on both ends to not be bidirectional. The
classic example is the circular linked list, in which an Entry has a
next<--->previous association and when there is only one element in the
list, the sole entry is its own next and previous.
Cheers,
Christian
Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Jim,
If I recall correctly, things like inverseAdd become problematic for the
case x1 is connectedTo x1. I think such a thing also doesn't correspond
to an association in UML/CMOF. Special case support would be needed to
produce correct behavior.
Jim Steel wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
I have an class X that has a reference "connectedTo", of type X. The
reference is symmetric, i.e. x1.connectedTo == x2 implies that
x2.connectedTo == x1. Intuitively, connectedTo is its own eOpposite.
I found a thread from a couple of years back that this was not
supported, but without any particularly good reason why not.
Any update on that?
Jim.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------090004040803090806020306--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: symmetric references [message #417138 is a reply to message #417136] |
Wed, 27 February 2008 14:56 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Ock!
I had misunderstood Jim's original definition. Of course, an association is
ill-formed if it has fewer than two ends. Care to hear my ideas for
support of higher-order associations in EMF? ;-)
So, this case is just like the EReference::eOpposite that came up for
discussion, recently.
Sorry to have injected confusion.
cW
Ed Merks wrote:
> Christian,
>
> I just asked Kenn and he says this isn't allowed in UML2. I.e., he says
> the member ends of an association must be unique and there must be at
> least two. Your example of next/previous is using two different
> references representing the ends of the association is fine and of
> course there is only one type involved in this case. But Jim's example
> is not fine.
>
>
> Christian W. Damus wrote:
>> Hi, Ed,
>>
>> I don't know of any restriction in UML/CMOF that constrains a reflexive
>> association of multiplicity [1] on both ends to not be bidirectional.
>> The classic example is the circular linked list, in which an Entry has a
>> next<--->previous association and when there is only one element in the
>> list, the sole entry is its own next and previous.
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Ed Merks wrote:
>>
>>
>>> Jim,
>>>
>>> If I recall correctly, things like inverseAdd become problematic for the
>>> case x1 is connectedTo x1. I think such a thing also doesn't correspond
>>> to an association in UML/CMOF. Special case support would be needed to
>>> produce correct behavior.
>>>
>>>
>>> Jim Steel wrote:
>>>
>>>> Hi,
>>>>
>>>> I have an class X that has a reference "connectedTo", of type X. The
>>>> reference is symmetric, i.e. x1.connectedTo == x2 implies that
>>>> x2.connectedTo == x1. Intuitively, connectedTo is its own eOpposite.
>>>>
>>>> I found a thread from a couple of years back that this was not
>>>> supported, but without any particularly good reason why not.
>>>>
>>>> Any update on that?
>>>>
>>>> Jim.
>>>>
>>
>>
|
|
|
| Re: symmetric references [message #417139 is a reply to message #417138] |
Wed, 27 February 2008 15:01 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070605010200090704070903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Christian,
Kenn and I did look at ternary associations as part of
http://ed-merks.blogspot.com/2008/01/modeling-associations-w ith-ecore.html
I don't think CMOF supports them though, so that was enough excuse for
me to wash my hands of them. :-P
Christian W. Damus wrote:
> Ock!
>
> I had misunderstood Jim's original definition. Of course, an association is
> ill-formed if it has fewer than two ends. Care to hear my ideas for
> support of higher-order associations in EMF? ;-)
>
> So, this case is just like the EReference::eOpposite that came up for
> discussion, recently.
>
> Sorry to have injected confusion.
>
> cW
>
> Ed Merks wrote:
>
>
>> Christian,
>>
>> I just asked Kenn and he says this isn't allowed in UML2. I.e., he says
>> the member ends of an association must be unique and there must be at
>> least two. Your example of next/previous is using two different
>> references representing the ends of the association is fine and of
>> course there is only one type involved in this case. But Jim's example
>> is not fine.
>>
>>
>> Christian W. Damus wrote:
>>
>>> Hi, Ed,
>>>
>>> I don't know of any restriction in UML/CMOF that constrains a reflexive
>>> association of multiplicity [1] on both ends to not be bidirectional.
>>> The classic example is the circular linked list, in which an Entry has a
>>> next<--->previous association and when there is only one element in the
>>> list, the sole entry is its own next and previous.
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>> Ed Merks wrote:
>>>
>>>
>>>
>>>> Jim,
>>>>
>>>> If I recall correctly, things like inverseAdd become problematic for the
>>>> case x1 is connectedTo x1. I think such a thing also doesn't correspond
>>>> to an association in UML/CMOF. Special case support would be needed to
>>>> produce correct behavior.
>>>>
>>>>
>>>> Jim Steel wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> I have an class X that has a reference "connectedTo", of type X. The
>>>>> reference is symmetric, i.e. x1.connectedTo == x2 implies that
>>>>> x2.connectedTo == x1. Intuitively, connectedTo is its own eOpposite.
>>>>>
>>>>> I found a thread from a couple of years back that this was not
>>>>> supported, but without any particularly good reason why not.
>>>>>
>>>>> Any update on that?
>>>>>
>>>>> Jim.
>>>>>
>>>>>
>>>
>
>
--------------070605010200090704070903
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Christian,<br>
<br>
Kenn and I did look at ternary associations as part of <br>
<blockquote><a
href=" http://ed-merks.blogspot.com/2008/01/modeling-associations-w ith-ecore.html"> http://ed-merks.blogspot.com/2008/01/modeling-associations-w ith-ecore.html</a><br>
</blockquote>
I don't think CMOF supports them though, so that was enough excuse for
me to wash my hands of them. :-P<br>
<br>
<br>
Christian W. Damus wrote:
<blockquote cite="mid:fq3tmp$efb$2@build.eclipse.org" type="cite">
<pre wrap="">Ock!
I had misunderstood Jim's original definition. Of course, an association is
ill-formed if it has fewer than two ends. Care to hear my ideas for
support of higher-order associations in EMF? ;-)
So, this case is just like the EReference::eOpposite that came up for
discussion, recently.
Sorry to have injected confusion.
cW
Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Christian,
I just asked Kenn and he says this isn't allowed in UML2. I.e., he says
the member ends of an association must be unique and there must be at
least two. Your example of next/previous is using two different
references representing the ends of the association is fine and of
course there is only one type involved in this case. But Jim's example
is not fine.
Christian W. Damus wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi, Ed,
I don't know of any restriction in UML/CMOF that constrains a reflexive
association of multiplicity [1] on both ends to not be bidirectional.
The classic example is the circular linked list, in which an Entry has a
next<--->previous association and when there is only one element in the
list, the sole entry is its own next and previous.
Cheers,
Christian
Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Jim,
If I recall correctly, things like inverseAdd become problematic for the
case x1 is connectedTo x1. I think such a thing also doesn't correspond
to an association in UML/CMOF. Special case support would be needed to
produce correct behavior.
Jim Steel wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
I have an class X that has a reference "connectedTo", of type X. The
reference is symmetric, i.e. x1.connectedTo == x2 implies that
x2.connectedTo == x1. Intuitively, connectedTo is its own eOpposite.
I found a thread from a couple of years back that this was not
supported, but without any particularly good reason why not.
Any update on that?
Jim.
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------070605010200090704070903--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: symmetric references [message #417146 is a reply to message #417138] |
Thu, 28 February 2008 00:36 |
Jim Steel
Messages: 54
Registered: July 2009 |
Member |
|
|
Hi Christian, Ed,
Thanks for your quick responses.
I'm a little confused. Aren't we using EMOF? Its been a while since I
read the spec (forgive me), but I was pretty certain that EMOF had no
associations.
Cheers,
Jim.
Aside the first: Being an old MOF 1.x user, I was initially against not
having associations in EMOF/ECore, but having used it, I don't really
miss them.
Aside the second: Yes, this is exactly the case that would have come up
with EReference::eOpposite, although that is slightly different because
if I remember correctly (and I'm happy to be corrected), EMOF itself is
defined (in the spec) as a CMOF metamodel, whereas my metamodel is
defined only in EMOF.
Christian W. Damus wrote:
> Ock!
>
> I had misunderstood Jim's original definition. Of course, an association is
> ill-formed if it has fewer than two ends. Care to hear my ideas for
> support of higher-order associations in EMF? ;-)
>
> So, this case is just like the EReference::eOpposite that came up for
> discussion, recently.
>
> Sorry to have injected confusion.
>
> cW
>
> Ed Merks wrote:
>
>> Christian,
>>
>> I just asked Kenn and he says this isn't allowed in UML2. I.e., he says
>> the member ends of an association must be unique and there must be at
>> least two. Your example of next/previous is using two different
>> references representing the ends of the association is fine and of
>> course there is only one type involved in this case. But Jim's example
>> is not fine.
>>
>>
>> Christian W. Damus wrote:
>>> Hi, Ed,
>>>
>>> I don't know of any restriction in UML/CMOF that constrains a reflexive
>>> association of multiplicity [1] on both ends to not be bidirectional.
>>> The classic example is the circular linked list, in which an Entry has a
>>> next<--->previous association and when there is only one element in the
>>> list, the sole entry is its own next and previous.
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>> Ed Merks wrote:
>>>
>>>
>>>> Jim,
>>>>
>>>> If I recall correctly, things like inverseAdd become problematic for the
>>>> case x1 is connectedTo x1. I think such a thing also doesn't correspond
>>>> to an association in UML/CMOF. Special case support would be needed to
>>>> produce correct behavior.
>>>>
>>>>
>>>> Jim Steel wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have an class X that has a reference "connectedTo", of type X. The
>>>>> reference is symmetric, i.e. x1.connectedTo == x2 implies that
>>>>> x2.connectedTo == x1. Intuitively, connectedTo is its own eOpposite.
>>>>>
>>>>> I found a thread from a couple of years back that this was not
>>>>> supported, but without any particularly good reason why not.
>>>>>
>>>>> Any update on that?
>>>>>
>>>>> Jim.
>>>>>
>>>
>
|
|
|
| Re: symmetric references [message #417149 is a reply to message #417146] |
Thu, 28 February 2008 01:53 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Jim,
That's true, but things like CMOF and UML are built in layers on top of
the core. So if these higher level and more expressive and powerful
abstractions don't support such a concept, in addition to the
implementation difficulties, it fuels the reasons for why they aren't
supported in Ecore.
Jim Steel wrote:
>
> Hi Christian, Ed,
>
> Thanks for your quick responses.
>
> I'm a little confused. Aren't we using EMOF? Its been a while since I
> read the spec (forgive me), but I was pretty certain that EMOF had no
> associations.
>
> Cheers,
>
> Jim.
>
>
> Aside the first: Being an old MOF 1.x user, I was initially against
> not having associations in EMOF/ECore, but having used it, I don't
> really miss them.
>
> Aside the second: Yes, this is exactly the case that would have come
> up with EReference::eOpposite, although that is slightly different
> because if I remember correctly (and I'm happy to be corrected), EMOF
> itself is defined (in the spec) as a CMOF metamodel, whereas my
> metamodel is defined only in EMOF.
>
>
>
> Christian W. Damus wrote:
>> Ock!
>>
>> I had misunderstood Jim's original definition. Of course, an
>> association is
>> ill-formed if it has fewer than two ends. Care to hear my ideas for
>> support of higher-order associations in EMF? ;-)
>>
>> So, this case is just like the EReference::eOpposite that came up for
>> discussion, recently.
>>
>> Sorry to have injected confusion.
>>
>> cW
>>
>> Ed Merks wrote:
>>
>>> Christian,
>>>
>>> I just asked Kenn and he says this isn't allowed in UML2. I.e., he
>>> says
>>> the member ends of an association must be unique and there must be at
>>> least two. Your example of next/previous is using two different
>>> references representing the ends of the association is fine and of
>>> course there is only one type involved in this case. But Jim's example
>>> is not fine.
>>>
>>>
>>> Christian W. Damus wrote:
>>>> Hi, Ed,
>>>>
>>>> I don't know of any restriction in UML/CMOF that constrains a
>>>> reflexive
>>>> association of multiplicity [1] on both ends to not be
>>>> bidirectional. The classic example is the circular linked list, in
>>>> which an Entry has a
>>>> next<--->previous association and when there is only one element in
>>>> the
>>>> list, the sole entry is its own next and previous.
>>>>
>>>> Cheers,
>>>>
>>>> Christian
>>>>
>>>>
>>>> Ed Merks wrote:
>>>>
>>>>
>>>>> Jim,
>>>>>
>>>>> If I recall correctly, things like inverseAdd become problematic
>>>>> for the
>>>>> case x1 is connectedTo x1. I think such a thing also doesn't
>>>>> correspond
>>>>> to an association in UML/CMOF. Special case support would be
>>>>> needed to
>>>>> produce correct behavior.
>>>>>
>>>>>
>>>>> Jim Steel wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have an class X that has a reference "connectedTo", of type X. The
>>>>>> reference is symmetric, i.e. x1.connectedTo == x2 implies that
>>>>>> x2.connectedTo == x1. Intuitively, connectedTo is its own eOpposite.
>>>>>>
>>>>>> I found a thread from a couple of years back that this was not
>>>>>> supported, but without any particularly good reason why not.
>>>>>>
>>>>>> Any update on that?
>>>>>>
>>>>>> Jim.
>>>>>>
>>>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: symmetric references [message #417351 is a reply to message #417149] |
Wed, 05 March 2008 23:23 |
Jim Steel
Messages: 54
Registered: July 2009 |
Member |
|
|
Hi Ed,
OK, so accepting that a reference being its own eOpposite is a bad idea,
what is the recommended way of modelling a symmetric relationship? My
reference is [0..*], so I can't just override set to do an assert on the
reverse direction. Putting a membership check and a symmetric add in the
didAdd() method of the EList?
Cheers,
Jim.
Ed Merks wrote:
> Jim,
>
> That's true, but things like CMOF and UML are built in layers on top of
> the core. So if these higher level and more expressive and powerful
> abstractions don't support such a concept, in addition to the
> implementation difficulties, it fuels the reasons for why they aren't
> supported in Ecore.
>
>
> Jim Steel wrote:
>>
>> Hi Christian, Ed,
>>
>> Thanks for your quick responses.
>>
>> I'm a little confused. Aren't we using EMOF? Its been a while since I
>> read the spec (forgive me), but I was pretty certain that EMOF had no
>> associations.
>>
>> Cheers,
>>
>> Jim.
>>
>>
>> Aside the first: Being an old MOF 1.x user, I was initially against
>> not having associations in EMOF/ECore, but having used it, I don't
>> really miss them.
>>
>> Aside the second: Yes, this is exactly the case that would have come
>> up with EReference::eOpposite, although that is slightly different
>> because if I remember correctly (and I'm happy to be corrected), EMOF
>> itself is defined (in the spec) as a CMOF metamodel, whereas my
>> metamodel is defined only in EMOF.
>>
>>
>>
>> Christian W. Damus wrote:
>>> Ock!
>>>
>>> I had misunderstood Jim's original definition. Of course, an
>>> association is
>>> ill-formed if it has fewer than two ends. Care to hear my ideas for
>>> support of higher-order associations in EMF? ;-)
>>>
>>> So, this case is just like the EReference::eOpposite that came up for
>>> discussion, recently.
>>>
>>> Sorry to have injected confusion.
>>>
>>> cW
>>>
>>> Ed Merks wrote:
>>>
>>>> Christian,
>>>>
>>>> I just asked Kenn and he says this isn't allowed in UML2. I.e., he
>>>> says
>>>> the member ends of an association must be unique and there must be at
>>>> least two. Your example of next/previous is using two different
>>>> references representing the ends of the association is fine and of
>>>> course there is only one type involved in this case. But Jim's example
>>>> is not fine.
>>>>
>>>>
>>>> Christian W. Damus wrote:
>>>>> Hi, Ed,
>>>>>
>>>>> I don't know of any restriction in UML/CMOF that constrains a
>>>>> reflexive
>>>>> association of multiplicity [1] on both ends to not be
>>>>> bidirectional. The classic example is the circular linked list, in
>>>>> which an Entry has a
>>>>> next<--->previous association and when there is only one element in
>>>>> the
>>>>> list, the sole entry is its own next and previous.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> Ed Merks wrote:
>>>>>
>>>>>
>>>>>> Jim,
>>>>>>
>>>>>> If I recall correctly, things like inverseAdd become problematic
>>>>>> for the
>>>>>> case x1 is connectedTo x1. I think such a thing also doesn't
>>>>>> correspond
>>>>>> to an association in UML/CMOF. Special case support would be
>>>>>> needed to
>>>>>> produce correct behavior.
>>>>>>
>>>>>>
>>>>>> Jim Steel wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have an class X that has a reference "connectedTo", of type X. The
>>>>>>> reference is symmetric, i.e. x1.connectedTo == x2 implies that
>>>>>>> x2.connectedTo == x1. Intuitively, connectedTo is its own eOpposite.
>>>>>>>
>>>>>>> I found a thread from a couple of years back that this was not
>>>>>>> supported, but without any particularly good reason why not.
>>>>>>>
>>>>>>> Any update on that?
>>>>>>>
>>>>>>> Jim.
>>>>>>>
>>>>>
>>>
|
|
|
| Re: symmetric references [message #417360 is a reply to message #417351] |
Thu, 06 March 2008 13:14 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Jim,
All I can think is to have two different features that are opposites and
to have a third derived feature that's a union of the two.
Jim Steel wrote:
>
> Hi Ed,
>
> OK, so accepting that a reference being its own eOpposite is a bad
> idea, what is the recommended way of modelling a symmetric
> relationship? My reference is [0..*], so I can't just override set to
> do an assert on the reverse direction. Putting a membership check and
> a symmetric add in the didAdd() method of the EList?
>
> Cheers,
>
> Jim.
>
>
>
> Ed Merks wrote:
>> Jim,
>>
>> That's true, but things like CMOF and UML are built in layers on top
>> of the core. So if these higher level and more expressive and
>> powerful abstractions don't support such a concept, in addition to
>> the implementation difficulties, it fuels the reasons for why they
>> aren't supported in Ecore.
>>
>>
>> Jim Steel wrote:
>>>
>>> Hi Christian, Ed,
>>>
>>> Thanks for your quick responses.
>>>
>>> I'm a little confused. Aren't we using EMOF? Its been a while since
>>> I read the spec (forgive me), but I was pretty certain that EMOF had
>>> no associations.
>>>
>>> Cheers,
>>>
>>> Jim.
>>>
>>>
>>> Aside the first: Being an old MOF 1.x user, I was initially against
>>> not having associations in EMOF/ECore, but having used it, I don't
>>> really miss them.
>>>
>>> Aside the second: Yes, this is exactly the case that would have come
>>> up with EReference::eOpposite, although that is slightly different
>>> because if I remember correctly (and I'm happy to be corrected),
>>> EMOF itself is defined (in the spec) as a CMOF metamodel, whereas my
>>> metamodel is defined only in EMOF.
>>>
>>>
>>>
>>> Christian W. Damus wrote:
>>>> Ock!
>>>>
>>>> I had misunderstood Jim's original definition. Of course, an
>>>> association is
>>>> ill-formed if it has fewer than two ends. Care to hear my ideas for
>>>> support of higher-order associations in EMF? ;-)
>>>>
>>>> So, this case is just like the EReference::eOpposite that came up for
>>>> discussion, recently.
>>>>
>>>> Sorry to have injected confusion.
>>>>
>>>> cW
>>>>
>>>> Ed Merks wrote:
>>>>
>>>>> Christian,
>>>>>
>>>>> I just asked Kenn and he says this isn't allowed in UML2. I.e.,
>>>>> he says
>>>>> the member ends of an association must be unique and there must be at
>>>>> least two. Your example of next/previous is using two different
>>>>> references representing the ends of the association is fine and of
>>>>> course there is only one type involved in this case. But Jim's
>>>>> example
>>>>> is not fine.
>>>>>
>>>>>
>>>>> Christian W. Damus wrote:
>>>>>> Hi, Ed,
>>>>>>
>>>>>> I don't know of any restriction in UML/CMOF that constrains a
>>>>>> reflexive
>>>>>> association of multiplicity [1] on both ends to not be
>>>>>> bidirectional. The classic example is the circular linked list,
>>>>>> in which an Entry has a
>>>>>> next<--->previous association and when there is only one element
>>>>>> in the
>>>>>> list, the sole entry is its own next and previous.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> Ed Merks wrote:
>>>>>>
>>>>>>
>>>>>>> Jim,
>>>>>>>
>>>>>>> If I recall correctly, things like inverseAdd become problematic
>>>>>>> for the
>>>>>>> case x1 is connectedTo x1. I think such a thing also doesn't
>>>>>>> correspond
>>>>>>> to an association in UML/CMOF. Special case support would be
>>>>>>> needed to
>>>>>>> produce correct behavior.
>>>>>>>
>>>>>>>
>>>>>>> Jim Steel wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have an class X that has a reference "connectedTo", of type
>>>>>>>> X. The
>>>>>>>> reference is symmetric, i.e. x1.connectedTo == x2 implies that
>>>>>>>> x2.connectedTo == x1. Intuitively, connectedTo is its own
>>>>>>>> eOpposite.
>>>>>>>>
>>>>>>>> I found a thread from a couple of years back that this was not
>>>>>>>> supported, but without any particularly good reason why not.
>>>>>>>>
>>>>>>>> Any update on that?
>>>>>>>>
>>>>>>>> Jim.
>>>>>>>>
>>>>>>
>>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: symmetric references [message #417375 is a reply to message #417360] |
Thu, 06 March 2008 23:12 |
Jim Steel
Messages: 54
Registered: July 2009 |
Member |
|
|
Would it not be better to just have a single unidirectional reference
'x', then ensure in the impl code that whenever 'b' is inserted into
'a.x', then a check is made to ensure that 'a' is present in 'b.x'? I'd
like to avoid cluttering up my metamodel.
Ed Merks wrote:
> Jim,
>
> All I can think is to have two different features that are opposites and
> to have a third derived feature that's a union of the two.
>
>
> Jim Steel wrote:
>>
>> Hi Ed,
>>
>> OK, so accepting that a reference being its own eOpposite is a bad
>> idea, what is the recommended way of modelling a symmetric
>> relationship? My reference is [0..*], so I can't just override set to
>> do an assert on the reverse direction. Putting a membership check and
>> a symmetric add in the didAdd() method of the EList?
>>
>> Cheers,
>>
>> Jim.
>>
>>
>>
>> Ed Merks wrote:
>>> Jim,
>>>
>>> That's true, but things like CMOF and UML are built in layers on top
>>> of the core. So if these higher level and more expressive and
>>> powerful abstractions don't support such a concept, in addition to
>>> the implementation difficulties, it fuels the reasons for why they
>>> aren't supported in Ecore.
>>>
>>>
>>> Jim Steel wrote:
>>>>
>>>> Hi Christian, Ed,
>>>>
>>>> Thanks for your quick responses.
>>>>
>>>> I'm a little confused. Aren't we using EMOF? Its been a while since
>>>> I read the spec (forgive me), but I was pretty certain that EMOF had
>>>> no associations.
>>>>
>>>> Cheers,
>>>>
>>>> Jim.
>>>>
>>>>
>>>> Aside the first: Being an old MOF 1.x user, I was initially against
>>>> not having associations in EMOF/ECore, but having used it, I don't
>>>> really miss them.
>>>>
>>>> Aside the second: Yes, this is exactly the case that would have come
>>>> up with EReference::eOpposite, although that is slightly different
>>>> because if I remember correctly (and I'm happy to be corrected),
>>>> EMOF itself is defined (in the spec) as a CMOF metamodel, whereas my
>>>> metamodel is defined only in EMOF.
>>>>
>>>>
>>>>
>>>> Christian W. Damus wrote:
>>>>> Ock!
>>>>>
>>>>> I had misunderstood Jim's original definition. Of course, an
>>>>> association is
>>>>> ill-formed if it has fewer than two ends. Care to hear my ideas for
>>>>> support of higher-order associations in EMF? ;-)
>>>>>
>>>>> So, this case is just like the EReference::eOpposite that came up for
>>>>> discussion, recently.
>>>>>
>>>>> Sorry to have injected confusion.
>>>>>
>>>>> cW
>>>>>
>>>>> Ed Merks wrote:
>>>>>
>>>>>> Christian,
>>>>>>
>>>>>> I just asked Kenn and he says this isn't allowed in UML2. I.e.,
>>>>>> he says
>>>>>> the member ends of an association must be unique and there must be at
>>>>>> least two. Your example of next/previous is using two different
>>>>>> references representing the ends of the association is fine and of
>>>>>> course there is only one type involved in this case. But Jim's
>>>>>> example
>>>>>> is not fine.
>>>>>>
>>>>>>
>>>>>> Christian W. Damus wrote:
>>>>>>> Hi, Ed,
>>>>>>>
>>>>>>> I don't know of any restriction in UML/CMOF that constrains a
>>>>>>> reflexive
>>>>>>> association of multiplicity [1] on both ends to not be
>>>>>>> bidirectional. The classic example is the circular linked list,
>>>>>>> in which an Entry has a
>>>>>>> next<--->previous association and when there is only one element
>>>>>>> in the
>>>>>>> list, the sole entry is its own next and previous.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>>
>>>>>>> Ed Merks wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Jim,
>>>>>>>>
>>>>>>>> If I recall correctly, things like inverseAdd become problematic
>>>>>>>> for the
>>>>>>>> case x1 is connectedTo x1. I think such a thing also doesn't
>>>>>>>> correspond
>>>>>>>> to an association in UML/CMOF. Special case support would be
>>>>>>>> needed to
>>>>>>>> produce correct behavior.
>>>>>>>>
>>>>>>>>
>>>>>>>> Jim Steel wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I have an class X that has a reference "connectedTo", of type
>>>>>>>>> X. The
>>>>>>>>> reference is symmetric, i.e. x1.connectedTo == x2 implies that
>>>>>>>>> x2.connectedTo == x1. Intuitively, connectedTo is its own
>>>>>>>>> eOpposite.
>>>>>>>>>
>>>>>>>>> I found a thread from a couple of years back that this was not
>>>>>>>>> supported, but without any particularly good reason why not.
>>>>>>>>>
>>>>>>>>> Any update on that?
>>>>>>>>>
>>>>>>>>> Jim.
>>>>>>>>>
>>>>>>>
>>>>>
|
|
|
| Re: symmetric references [message #417376 is a reply to message #417375] |
Thu, 06 March 2008 23:36 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Jim,
Perhaps. Things like proxies and their resolution are tricky to
handle. And of course you have to consider when set replaces an object
and when remove removes one too. Making bidirectional references work
properly is surprising complex....
Jim Steel wrote:
>
> Would it not be better to just have a single unidirectional reference
> 'x', then ensure in the impl code that whenever 'b' is inserted into
> 'a.x', then a check is made to ensure that 'a' is present in 'b.x'?
> I'd like to avoid cluttering up my metamodel.
>
>
>
> Ed Merks wrote:
>> Jim,
>>
>> All I can think is to have two different features that are opposites
>> and to have a third derived feature that's a union of the two.
>>
>>
>> Jim Steel wrote:
>>>
>>> Hi Ed,
>>>
>>> OK, so accepting that a reference being its own eOpposite is a bad
>>> idea, what is the recommended way of modelling a symmetric
>>> relationship? My reference is [0..*], so I can't just override set
>>> to do an assert on the reverse direction. Putting a membership check
>>> and a symmetric add in the didAdd() method of the EList?
>>>
>>> Cheers,
>>>
>>> Jim.
>>>
>>>
>>>
>>> Ed Merks wrote:
>>>> Jim,
>>>>
>>>> That's true, but things like CMOF and UML are built in layers on
>>>> top of the core. So if these higher level and more expressive and
>>>> powerful abstractions don't support such a concept, in addition to
>>>> the implementation difficulties, it fuels the reasons for why they
>>>> aren't supported in Ecore.
>>>>
>>>>
>>>> Jim Steel wrote:
>>>>>
>>>>> Hi Christian, Ed,
>>>>>
>>>>> Thanks for your quick responses.
>>>>>
>>>>> I'm a little confused. Aren't we using EMOF? Its been a while
>>>>> since I read the spec (forgive me), but I was pretty certain that
>>>>> EMOF had no associations.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Jim.
>>>>>
>>>>>
>>>>> Aside the first: Being an old MOF 1.x user, I was initially
>>>>> against not having associations in EMOF/ECore, but having used it,
>>>>> I don't really miss them.
>>>>>
>>>>> Aside the second: Yes, this is exactly the case that would have
>>>>> come up with EReference::eOpposite, although that is slightly
>>>>> different because if I remember correctly (and I'm happy to be
>>>>> corrected), EMOF itself is defined (in the spec) as a CMOF
>>>>> metamodel, whereas my metamodel is defined only in EMOF.
>>>>>
>>>>>
>>>>>
>>>>> Christian W. Damus wrote:
>>>>>> Ock!
>>>>>>
>>>>>> I had misunderstood Jim's original definition. Of course, an
>>>>>> association is
>>>>>> ill-formed if it has fewer than two ends. Care to hear my ideas for
>>>>>> support of higher-order associations in EMF? ;-)
>>>>>>
>>>>>> So, this case is just like the EReference::eOpposite that came up
>>>>>> for
>>>>>> discussion, recently.
>>>>>>
>>>>>> Sorry to have injected confusion.
>>>>>>
>>>>>> cW
>>>>>>
>>>>>> Ed Merks wrote:
>>>>>>
>>>>>>> Christian,
>>>>>>>
>>>>>>> I just asked Kenn and he says this isn't allowed in UML2. I.e.,
>>>>>>> he says
>>>>>>> the member ends of an association must be unique and there must
>>>>>>> be at
>>>>>>> least two. Your example of next/previous is using two different
>>>>>>> references representing the ends of the association is fine and of
>>>>>>> course there is only one type involved in this case. But Jim's
>>>>>>> example
>>>>>>> is not fine.
>>>>>>>
>>>>>>>
>>>>>>> Christian W. Damus wrote:
>>>>>>>> Hi, Ed,
>>>>>>>>
>>>>>>>> I don't know of any restriction in UML/CMOF that constrains a
>>>>>>>> reflexive
>>>>>>>> association of multiplicity [1] on both ends to not be
>>>>>>>> bidirectional. The classic example is the circular linked list,
>>>>>>>> in which an Entry has a
>>>>>>>> next<--->previous association and when there is only one
>>>>>>>> element in the
>>>>>>>> list, the sole entry is its own next and previous.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Christian
>>>>>>>>
>>>>>>>>
>>>>>>>> Ed Merks wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Jim,
>>>>>>>>>
>>>>>>>>> If I recall correctly, things like inverseAdd become
>>>>>>>>> problematic for the
>>>>>>>>> case x1 is connectedTo x1. I think such a thing also doesn't
>>>>>>>>> correspond
>>>>>>>>> to an association in UML/CMOF. Special case support would be
>>>>>>>>> needed to
>>>>>>>>> produce correct behavior.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Jim Steel wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I have an class X that has a reference "connectedTo", of type
>>>>>>>>>> X. The
>>>>>>>>>> reference is symmetric, i.e. x1.connectedTo == x2 implies that
>>>>>>>>>> x2.connectedTo == x1. Intuitively, connectedTo is its own
>>>>>>>>>> eOpposite.
>>>>>>>>>>
>>>>>>>>>> I found a thread from a couple of years back that this was not
>>>>>>>>>> supported, but without any particularly good reason why not.
>>>>>>>>>>
>>>>>>>>>> Any update on that?
>>>>>>>>>>
>>>>>>>>>> Jim.
>>>>>>>>>>
>>>>>>>>
>>>>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Apr 20 03:49:37 GMT 2024
Powered by FUDForum. Page generated in 0.04051 seconds |
] 
Search
Help
Register
Login
Home
