Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Problem with Emfatic + OCL Annotation
Problem with Emfatic + OCL Annotation [message #550887] Wed, 04 August 2010 14:28 Go to next message
Toñi Reina is currently offline Toñi Reina
Messages: 204
Registered: July 2009
Senior Member
Hi,

I'm trying to write a GMF editor using Eugenia. And I want to add
some OCL constraints to specify the metamodel better.

I have found a example that uses a
@"http://www.eclipse.org/OCL/examples/ocl" annotation. I want to specify
two different things:

1. Derived references
2. Constraint the kinds of values some elements can have.

One example of the first OCL annotation is the one shown below, in this
case I have tested the constraint with the OCL console, so I suppose is
correct.

class EntryPort extends Port{

@"http://www.eclipse.org/OCL/examples/ocl"(
derive="self.tasks->collect(outputSlots)")
derived val Slot[+] slots;

}

One example of the second kind of OCL annotation is the one shown below,
specifying that there can not be two tasks with the same name.

@Ecore(constraints="noDuplicateTask")
@"http://www.eclipse.org/ocl/examples/OCL"(noDuplicateTask="self.tasks->forAll(t1
: Task |
self.tasks->forAll(t2 : Task | t1 <> t2 implies t1.name <>
t2.name))"
)


The problem is that it seems the annotations have no effect. Is
sufficient with writing the annotations or do I need to configure
something else?

How can I check if the code for the derived reference is correctly
generated?

Thanks in advance,
Toñi
Re: Problem with Emfatic + OCL Annotation [message #550945 is a reply to message #550887] Wed, 04 August 2010 16:22 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4046
Registered: July 2009
Senior Member
Hi Toni

If you really want to do the EAnnotations the hard way you should read
the first part of http://wiki.eclipse.org/MDT/OCLinEcore so that get all
the package constraints that you've omitted.

Alternatively, you might want to look at the second part and use
OCLinEcore rather than Emfatic. OCLinEcore provides first class syntaxes
for invariants and such like and automates the additional control
annotations. OCLinEcore allows the model to be persisted as *.ecore
(currently without comments and whitesapce preservation) or as
*.oclinecore (textual equivalent). OCLinEcore also gives you syntax and
partial semantic validation of your OCL. Full semantic validation in the
next release.

[I considered using the Emfatic syntax for OCLinEcore but rejected it in
favour of something that more closely resembles the style of OMG
specifications. I'm not sure whether Emfatic supports generics.
OCLinEcore successfuly round-trips Ecore.ecore.]

Regards

Ed Willink

On 04/08/2010 15:28, Toñi Reina Quintero wrote:
>
> Hi,
>
> I'm trying to write a GMF editor using Eugenia. And I want to add some
> OCL constraints to specify the metamodel better.
>
> I have found a example that uses a
> @"http://www.eclipse.org/OCL/examples/ocl" annotation. I want to specify
> two different things:
>
> 1. Derived references
> 2. Constraint the kinds of values some elements can have.
>
> One example of the first OCL annotation is the one shown below, in this
> case I have tested the constraint with the OCL console, so I suppose is
> correct.
>
> class EntryPort extends Port{
>
> @"http://www.eclipse.org/OCL/examples/ocl"(
> derive="self.tasks->collect(outputSlots)")
> derived val Slot[+] slots;
>
> }
>
> One example of the second kind of OCL annotation is the one shown below,
> specifying that there can not be two tasks with the same name.
>
> @Ecore(constraints="noDuplicateTask")
> @"http://www.eclipse.org/ocl/examples/OCL"(noDuplicateTask="self.tasks->forAll(t1
> : Task |
> self.tasks->forAll(t2 : Task | t1 <> t2 implies t1.name <> t2.name))"
> )
>
>
> The problem is that it seems the annotations have no effect. Is
> sufficient with writing the annotations or do I need to configure
> something else?
>
> How can I check if the code for the derived reference is correctly
> generated?
>
> Thanks in advance,
> Toñi
>
Re: Problem with Emfatic + OCL Annotation [message #550964 is a reply to message #550945] Wed, 04 August 2010 17:11 Go to previous messageGo to next message
Toñi Reina is currently offline Toñi Reina
Messages: 204
Registered: July 2009
Senior Member
Hi Ed,

thanks for the reference. Regarding to OCLinEcore, as far as I
understood, it needs Eclipse Helios, isn't it?

The reason for using Emfatic is that I'm also using Eugenia to
facilitate the generation of GMF editors. I don't know if these two
tools are well integrated.

El 04/08/2010 18:22, Ed Willink escribió:
> Hi Toni
>
> If you really want to do the EAnnotations the hard way you should read
> the first part of http://wiki.eclipse.org/MDT/OCLinEcore so that get all
> the package constraints that you've omitted.
>
> Alternatively, you might want to look at the second part and use
> OCLinEcore rather than Emfatic. OCLinEcore provides first class syntaxes
> for invariants and such like and automates the additional control
> annotations. OCLinEcore allows the model to be persisted as *.ecore
> (currently without comments and whitesapce preservation) or as
> *.oclinecore (textual equivalent). OCLinEcore also gives you syntax and
> partial semantic validation of your OCL. Full semantic validation in the
> next release.
>
> [I considered using the Emfatic syntax for OCLinEcore but rejected it in
> favour of something that more closely resembles the style of OMG
> specifications. I'm not sure whether Emfatic supports generics.
> OCLinEcore successfuly round-trips Ecore.ecore.]

>
> Regards
>
> Ed Willink
>
> On 04/08/2010 15:28, Toñi Reina Quintero wrote:
>>
>> Hi,
>>
>> I'm trying to write a GMF editor using Eugenia. And I want to add some
>> OCL constraints to specify the metamodel better.
>>
>> I have found a example that uses a
>> @"http://www.eclipse.org/OCL/examples/ocl" annotation. I want to specify
>> two different things:
>>
>> 1. Derived references
>> 2. Constraint the kinds of values some elements can have.
>>
>> One example of the first OCL annotation is the one shown below, in this
>> case I have tested the constraint with the OCL console, so I suppose is
>> correct.
>>
>> class EntryPort extends Port{
>>
>> @"http://www.eclipse.org/OCL/examples/ocl"(
>> derive="self.tasks->collect(outputSlots)")
>> derived val Slot[+] slots;
>>
>> }
>>
>> One example of the second kind of OCL annotation is the one shown below,
>> specifying that there can not be two tasks with the same name.
>>
>> @Ecore(constraints="noDuplicateTask")
>> @"http://www.eclipse.org/ocl/examples/OCL"(noDuplicateTask="self.tasks->forAll(t1
>>
>> : Task |
>> self.tasks->forAll(t2 : Task | t1 <> t2 implies t1.name <> t2.name))"
>> )
>>
>>
>> The problem is that it seems the annotations have no effect. Is
>> sufficient with writing the annotations or do I need to configure
>> something else?
>>
>> How can I check if the code for the derived reference is correctly
>> generated?
>>
>> Thanks in advance,
>> Toñi
>>
>
Re: Problem with Emfatic + OCL Annotation [message #550979 is a reply to message #550964] Wed, 04 August 2010 18:18 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4046
Registered: July 2009
Senior Member
i Toni

Thanks for the Eugenia mention; looks like it does some of the things I
dislike most about GMF not doing. Next time I play with graphics I'll
give it a try.

OCLinEcore certainly needs Helios.

http://download.eclipse.org/modeling/gmt/epsilon/interim/ lists a
27-July build so it's probably Helios.

Regards

Ed Willink

On 04/08/2010 18:11, Toñi Reina Quintero wrote:
>
> Hi Ed,
>
> thanks for the reference. Regarding to OCLinEcore, as far as I
> understood, it needs Eclipse Helios, isn't it?
>
> The reason for using Emfatic is that I'm also using Eugenia to
> facilitate the generation of GMF editors. I don't know if these two
> tools are well integrated.
>
> El 04/08/2010 18:22, Ed Willink escribió:
>> Hi Toni
>>
>> If you really want to do the EAnnotations the hard way you should read
>> the first part of http://wiki.eclipse.org/MDT/OCLinEcore so that get all
>> the package constraints that you've omitted.
>>
>> Alternatively, you might want to look at the second part and use
>> OCLinEcore rather than Emfatic. OCLinEcore provides first class syntaxes
>> for invariants and such like and automates the additional control
>> annotations. OCLinEcore allows the model to be persisted as *.ecore
>> (currently without comments and whitesapce preservation) or as
>> *.oclinecore (textual equivalent). OCLinEcore also gives you syntax and
>> partial semantic validation of your OCL. Full semantic validation in the
>> next release.
>>
>> [I considered using the Emfatic syntax for OCLinEcore but rejected it in
>> favour of something that more closely resembles the style of OMG
>> specifications. I'm not sure whether Emfatic supports generics.
>> OCLinEcore successfuly round-trips Ecore.ecore.]
>
>>
>> Regards
>>
>> Ed Willink
>>
>> On 04/08/2010 15:28, Toñi Reina Quintero wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to write a GMF editor using Eugenia. And I want to add some
>>> OCL constraints to specify the metamodel better.
>>>
>>> I have found a example that uses a
>>> @"http://www.eclipse.org/OCL/examples/ocl" annotation. I want to specify
>>> two different things:
>>>
>>> 1. Derived references
>>> 2. Constraint the kinds of values some elements can have.
>>>
>>> One example of the first OCL annotation is the one shown below, in this
>>> case I have tested the constraint with the OCL console, so I suppose is
>>> correct.
>>>
>>> class EntryPort extends Port{
>>>
>>> @"http://www.eclipse.org/OCL/examples/ocl"(
>>> derive="self.tasks->collect(outputSlots)")
>>> derived val Slot[+] slots;
>>>
>>> }
>>>
>>> One example of the second kind of OCL annotation is the one shown below,
>>> specifying that there can not be two tasks with the same name.
>>>
>>> @Ecore(constraints="noDuplicateTask")
>>> @"http://www.eclipse.org/ocl/examples/OCL"(noDuplicateTask="self.tasks->forAll(t1
>>>
>>>
>>> : Task |
>>> self.tasks->forAll(t2 : Task | t1 <> t2 implies t1.name <> t2.name))"
>>> )
>>>
>>>
>>> The problem is that it seems the annotations have no effect. Is
>>> sufficient with writing the annotations or do I need to configure
>>> something else?
>>>
>>> How can I check if the code for the derived reference is correctly
>>> generated?
>>>
>>> Thanks in advance,
>>> Toñi
>>>
>>
>
Previous Topic:[QVTO/OCL] Usage of non-standard "closure" operator
Next Topic:OCL 3.0 and OCL 2.0
Goto Forum:
  


Current Time: Mon Sep 22 00:21:50 GMT 2014

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

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