Home » Modeling » GMF (Graphical Modeling Framework) » ocl link constraint
| | | |
| Re: ocl link constraint [message #203737 is a reply to message #203720] |
Thu, 28 August 2008 17: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 17:57 |
 Richard Gronback
Messages: 605
Registered: July 2009 |
Senior Member |
|
|
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 20: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 21:19 |
Richard Gronback
Messages: 605
Registered: July 2009 |
Senior Member |
|
|
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 22: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<-----
>
|
|
| |
Goto Forum:
Current Time: Fri Apr 26 13:37:33 GMT 2024
Powered by FUDForum. Page generated in 0.03710 seconds |
] 
Search
Help
Register
Login
Home
