Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » constraint on EReference
constraint on EReference [message #882130] Tue, 05 June 2012 22:47 Go to next message
Roger Druback is currently offline Roger DrubackFriend
Messages: 6
Registered: March 2012
Junior Member
Hello,

I have three ECore classes A ,B and C.

Now I introduce two EReferences from A to B and from A to C. as follows:

A "ref1"--> 0..1 B
"ref2"--> 0..1 C


My Questions is now how can I express that if "ref1" is set (1 B) "ref2" should be unset (0 C) and vice versa? I.e. only one EReference at a time?

Do I need OCL or is there some standard way to do this in EMF/Ecore?


Thanks for all help
greetings
Re: constraint on EReference [message #882239 is a reply to message #882130] Wed, 06 June 2012 05:26 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4188
Registered: July 2009
Senior Member
Hi

You may be able to to express this structurally by introducing a BorC
interface which B and C both implement.

Then you can have a required ref to a BorC and derived optional refs to
B and to C.

Regards

Ed Willink


On 05/06/2012 23:47, Roger Druback wrote:
> Hello,
>
> I have three ECore classes A ,B and C.
>
> Now I introduce two EReferences from A to B and from A to C. as follows:
>
> A "ref1"--> 0..1 B
> "ref2"--> 0..1 C
>
>
> My Questions is now how can I express that if "ref1" is set (1 B)
> "ref2" should be unset (0 C) and vice versa? I.e. only one EReference
> at a time?
>
> Do I need OCL or is there some standard way to do this in EMF/Ecore?
>
>
> Thanks for all help
> greetings
>
Re: constraint on EReference [message #882337 is a reply to message #882239] Wed, 06 June 2012 09:17 Go to previous messageGo to next message
Roger Druback is currently offline Roger DrubackFriend
Messages: 6
Registered: March 2012
Junior Member
Hello,

thank you for your answer.

I have attaced a graph of my problem and of what I understood was your possible solution.

My problem is that the EClass A is in another metamodel than B and C and at runtime their will be instances of both B and C. So I guess both B and C need to implement the interface?

A should make the decision which instance to reference but only one at a time.

I am not so familiar with OCL but isn't there something like:

"IF ref1 set to B THAN ref2 = null ..."

But sure a good model without OCL would be better.


Regards
Re: constraint on EReference [message #882344 is a reply to message #882337] Wed, 06 June 2012 09:26 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4188
Registered: July 2009
Senior Member
Hi

OCL is the power solution; you asked for a simple solution.

Using the OCLinEcore editor you can open your *.ecore file and do
something like

class A
{
property ref1 : B[?];
property ref2 : C[?];
invariant ExactlyOneBorC: ref1->size() + ref2->size() = 1;
}

[There are many algorithms for implementing XOR; the above avoids 'if'
cases.]

If you're really clever/insane you do it all with EAnnotations in the
Ecore Diagram Properties View.

Regards

Ed Willink

On 06/06/2012 10:17, Roger Druback wrote:
> Hello,
>
> thank you for your answer.
>
> I have attaced a graph of my problem and of what I understood was your possible solution.
>
> My problem is that the EClass A is in another metamodel than B and C and at runtime their will be instances of both B and C. So I guess both B and C need to implement the interface?
>
> A should make the decision which instance to reference but only one at a time.
>
> I am not so familiar with OCL but isn't there something like:
>
> "IF ref1 set to B THAN ref2 = null ..."
>
> But sure a good model without OCL would be better.
>
>
> Regards
Re: constraint on EReference [message #882449 is a reply to message #882130] Wed, 06 June 2012 13:33 Go to previous message
Roger Druback is currently offline Roger DrubackFriend
Messages: 6
Registered: March 2012
Junior Member
Thank you very much for explaining both options. Smile

I think I'll go with No.2 as I do not want to introduce new model elements.


Regards
Previous Topic:Association Class in Ecore
Next Topic:[Announce] Eclipse OCL 4.0.0 (Juno) RC3 is now available
Goto Forum:
  


Current Time: Sun Dec 21 13:02:23 GMT 2014

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

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