Home » Modeling » GMF (Graphical Modeling Framework) » ocl link constraint
ocl link constraint [message #203695] |
Thu, 28 August 2008 11:10  |
Eclipse User |
|
|
|
Hi, I am trying to use ocl as a link constraint
I have 3 types of nodes (a,b,c) and I want to alow all nodes to connect to
each other but I want to stop node c from connecting to its self!
I am currently using...
Target End: oppositeEnd.oclIsKindOf(a) or oppositeEnd.oclIsKindOf(b)
This is making it so node c cannot connect to anything, and I only want to
stop it connecting to its self!
Does anyone have any ideas how I could do this?
Thank you in advance,
Gary
|
|
| | | |
Re: ocl link constraint [message #203737 is a reply to message #203720] |
Thu, 28 August 2008 13:51   |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Rich, Gary,
Try this:
oppositeEnd.oclIsKindOf(C) implies oppositeEnd <> self
HTH,
Christian
Richard Gronback wrote:
> Try something like:
>
> ((self.oclIsTypeOf(A) and (oppositeEnd.oclIsTypeOf(B) or
> oppositeEnd.oclIsTypeOf(C)) or (self.oclIsTypeOf(B) and
> (oppositeEnd.oclIsTypeOf(A) or oppositeEnd.oclIsTypeOf(C)) or
> (self.oclIsTypeOf(C) and (oppositeEnd.oclIsTypeOf(A) or
> oppositeEnd.oclIsTypeOf(B)))
>
> Ugly, but I don't know of an easier way using OCL given the way it works
> with types; that is, assuming I understand your problem. It sounds similar
> to a problem I had in the past where this was the only solution I found.
>
> - Rich
>
>
> On 8/28/08 11:23 AM, in article
> 4bb2290aed32488d0a242444361a251e$1@www.eclipse.org, "Gary"
> <gazdrumtastic@hotmail.com> wrote:
>
>> Yes, the trouble is my link is used for all 3 connections!
>> so i need to have some way of checking that the source node = C and the
>> target node = C then use the constraint self <> oppositeEnd
>>
>> Because if you just use 'self <> oppositeEnd' you cannot connect A or B to
>> its self as well as C
>>
>> Thank you,
>> Gary
>>
>
|
|
|
Re: ocl link constraint [message #203745 is a reply to message #203737] |
Thu, 28 August 2008 13:57   |
Eclipse User |
|
|
|
Hmmm...
Gary, you'll need to clarify one point for me... Is it just C you want to
prevent from connecting to itself, or any of the types from connecting to
themselves? I (mistakenly?) understood the problem to be that you want to
make connections between one type and any of the other two types, but never
to itself. Maybe I made it too hard?
Thanks,
Rich
On 8/28/08 1:51 PM, in article g96ojo$p9$1@build.eclipse.org, "Christian W.
Damus" <cdamus@zeligsoft.com> wrote:
> Hi, Rich, Gary,
>
> Try this:
>
> oppositeEnd.oclIsKindOf(C) implies oppositeEnd <> self
>
> HTH,
>
> Christian
>
>
> Richard Gronback wrote:
>> Try something like:
>>
>> ((self.oclIsTypeOf(A) and (oppositeEnd.oclIsTypeOf(B) or
>> oppositeEnd.oclIsTypeOf(C)) or (self.oclIsTypeOf(B) and
>> (oppositeEnd.oclIsTypeOf(A) or oppositeEnd.oclIsTypeOf(C)) or
>> (self.oclIsTypeOf(C) and (oppositeEnd.oclIsTypeOf(A) or
>> oppositeEnd.oclIsTypeOf(B)))
>>
>> Ugly, but I don't know of an easier way using OCL given the way it works
>> with types; that is, assuming I understand your problem. It sounds similar
>> to a problem I had in the past where this was the only solution I found.
>>
>> - Rich
>>
>>
>> On 8/28/08 11:23 AM, in article
>> 4bb2290aed32488d0a242444361a251e$1@www.eclipse.org, "Gary"
>> <gazdrumtastic@hotmail.com> wrote:
>>
>>> Yes, the trouble is my link is used for all 3 connections!
>>> so i need to have some way of checking that the source node = C and the
>>> target node = C then use the constraint self <> oppositeEnd
>>>
>>> Because if you just use 'self <> oppositeEnd' you cannot connect A or B to
>>> its self as well as C
>>>
>>> Thank you,
>>> Gary
>>>
>>
|
|
|
Re: ocl link constraint [message #203758 is a reply to message #203745] |
Thu, 28 August 2008 16:57   |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Rich,
Yeah, the way I read it was that only Cs are not allowed to connect to
themselves, though they may connect to other Cs.
I will be submitting some proposals for issue resolution, soon, to the
OCL 2.1 RTF. One of these includes resurrection of a means to access
the class of an element: oclType(). This would greatly simplify your
constraint, as well as making it more generic:
not (self.oclIsKindOf(otherEnd.oclType())
or otherEnd.oclIsKindOf(self.oclType()))
Cheers,
Christian
Richard Gronback wrote:
> Hmmm...
>
> Gary, you'll need to clarify one point for me... Is it just C you want to
> prevent from connecting to itself, or any of the types from connecting to
> themselves? I (mistakenly?) understood the problem to be that you want to
> make connections between one type and any of the other two types, but never
> to itself. Maybe I made it too hard?
>
> Thanks,
> Rich
>
-----8<-----
|
|
|
Re: ocl link constraint [message #203764 is a reply to message #203758] |
Thu, 28 August 2008 17:19   |
Eclipse User |
|
|
|
Hi Christian,
That would be an excellent addition, thanks! Any chance you'll implement it
in MDT OCL as a preview of coming spec attractions? ;) And will closure()
ever become "official"?
I wonder if we'll ever hear back from Gary?
Best,
Rich
On 8/28/08 4:57 PM, in article g973gi$vre$1@build.eclipse.org, "Christian W.
Damus" <cdamus@zeligsoft.com> wrote:
> Hi, Rich,
>
> Yeah, the way I read it was that only Cs are not allowed to connect to
> themselves, though they may connect to other Cs.
>
> I will be submitting some proposals for issue resolution, soon, to the
> OCL 2.1 RTF. One of these includes resurrection of a means to access
> the class of an element: oclType(). This would greatly simplify your
> constraint, as well as making it more generic:
>
> not (self.oclIsKindOf(otherEnd.oclType())
> or otherEnd.oclIsKindOf(self.oclType()))
>
> Cheers,
>
> Christian
>
>
> Richard Gronback wrote:
>> Hmmm...
>>
>> Gary, you'll need to clarify one point for me... Is it just C you want to
>> prevent from connecting to itself, or any of the types from connecting to
>> themselves? I (mistakenly?) understood the problem to be that you want to
>> make connections between one type and any of the other two types, but never
>> to itself. Maybe I made it too hard?
>>
>> Thanks,
>> Rich
>>
>
> -----8<-----
|
|
|
Re: ocl link constraint [message #203771 is a reply to message #203764] |
Thu, 28 August 2008 18:02   |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Rich,
See some replies in-line, below.
cW
Richard Gronback wrote:
> Hi Christian,
>
> That would be an excellent addition, thanks! Any chance you'll implement it
Well, I'm hoping that I can effect the changes that I want in time for
the December meeting, when the 2.1 review is planned. Then, MDT OCL
would bump to version 2.0, because the changes I'm aiming for are
incompatible.
Of course, it's always feasible to add a non-spec feature with one of my
silly Options ... haven't had any request, yet.
> in MDT OCL as a preview of coming spec attractions? ;) And will closure()
> ever become "official"?
I've already taken on a pretty big task, trying to get the spec into
sufficient shape to be able to implement it. :-( One of the problems
with closure() is that I don't know (yet) how to define it in terms of
the other iterators, which is sort-of required by OCL in the definition
of additional iterators. This is precisely why it is so useful.
> I wonder if we'll ever hear back from Gary?
Only Gary can tell us that. :-D I think he has enough ammo to beat his
problem, anyway.
> Best,
> Rich
>
>
> On 8/28/08 4:57 PM, in article g973gi$vre$1@build.eclipse.org, "Christian W.
> Damus" <cdamus@zeligsoft.com> wrote:
>
>> Hi, Rich,
>>
>> Yeah, the way I read it was that only Cs are not allowed to connect to
>> themselves, though they may connect to other Cs.
>>
>> I will be submitting some proposals for issue resolution, soon, to the
>> OCL 2.1 RTF. One of these includes resurrection of a means to access
>> the class of an element: oclType(). This would greatly simplify your
>> constraint, as well as making it more generic:
>>
>> not (self.oclIsKindOf(otherEnd.oclType())
>> or otherEnd.oclIsKindOf(self.oclType()))
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Richard Gronback wrote:
>>> Hmmm...
>>>
>>> Gary, you'll need to clarify one point for me... Is it just C you want to
>>> prevent from connecting to itself, or any of the types from connecting to
>>> themselves? I (mistakenly?) understood the problem to be that you want to
>>> make connections between one type and any of the other two types, but never
>>> to itself. Maybe I made it too hard?
>>>
>>> Thanks,
>>> Rich
>>>
>> -----8<-----
>
|
|
|
Re: ocl link constraint [message #203797 is a reply to message #203764] |
Fri, 29 August 2008 03:39  |
Eclipse User |
|
|
|
Hi, Rich and Christian
I just wana thank you guys for your help!
I have used the following:
oppositeEnd.oclIsKindOf(C) implies oppositeEnd <> self
This does the job perfectly ;)
Thanks alot,
Gary
|
|
|
Goto Forum:
Current Time: Thu Jul 03 12:40:14 EDT 2025
Powered by FUDForum. Page generated in 0.04343 seconds
|