Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » [uml2ecore] UML2EcoreConvertor::ProcessInvariantConstraint
[uml2ecore] UML2EcoreConvertor::ProcessInvariantConstraint [message #1018306] Wed, 13 March 2013 15:37 Go to next message
Klaas Gadeyne is currently offline Klaas Gadeyne
Messages: 86
Registered: July 2009
Member
Hi,

When looking at the source code of the UML2EcoreConvertor::ProcessInvariantConstraint() method, it seems to me that the convertor always creates callable invariants (ie. creating an EOperation rather than EAnnotation).

As stated here (http://www.eclipse.org/forums/index.php/t/351402/), this implies that the constraints cannot be validated.

Is the option to choose for the EAnnotation representation in the target model a missing feature/option of the transformation, or is this intentionally?

Thx,

Klaas
Re: [uml2ecore] UML2EcoreConvertor::ProcessInvariantConstraint [message #1018449 is a reply to message #1018306] Wed, 13 March 2013 21:08 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. Damus
Messages: 789
Registered: July 2009
Senior Member
Hi, Klass,

I think the imminent M6 milestone of the Kepler relase may have what
you're looking for:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=322715

HTH,

Christian


On 2013-03-13 15:37:23 +0000, Klaas Gadeyne said:

> Hi,
>
> When looking at the source code of the
> UML2EcoreConvertor::ProcessInvariantConstraint() method, it seems to me
> that the convertor always creates callable invariants (ie. creating an
> EOperation rather than EAnnotation).
>
> As stated here (http://www.eclipse.org/forums/index.php/t/351402/),
> this implies that the constraints cannot be validated.
>
> Is the option to choose for the EAnnotation representation in the
> target model a missing feature/option of the transformation, or is this
> intentionally?
>
> Thx,
>
> Klaas
Re: [uml2ecore] UML2EcoreConvertor::ProcessInvariantConstraint [message #1018692 is a reply to message #1018449] Thu, 14 March 2013 10:16 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas Gadeyne
Messages: 86
Registered: July 2009
Member
Hi Christian,
Christian W. Damus wrote on Wed, 13 March 2013 17:08
Hi, Klass,

I think the imminent M6 milestone of the Kepler relase may have what
you're looking for:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=322715


I'm not really sure, since I'm not familiar with the EMF delegation mechanism, but from
what I can see in the git-source code and the stuff I read in http://wiki.eclipse.org/MDT/OCLinEcore, the problem is not really in the delegates. I think the problem is rather in _how_ the invariant ends up in the ecore model.
From what I understand from http://wiki.eclipse.org/MDT/OCLinEcore#EClassifier_invariants, there are 2 ways of generating the invariants, and as far as I can see, UML2ecore only supports the "API variant" (where the constraint is represented as an eOperation), whereas I'm apparently looking to have the "non-API" invariant.

This also seems to be confirmed with what I encounter when trying the last UML2 interim build. Unless I'm missing something ofcourse!

regards,

Klaas
Quote:

On 2013-03-13 15:37:23 +0000, Klaas Gadeyne said:
> Hi,
>
> When looking at the source code of the
> UML2EcoreConvertor::ProcessInvariantConstraint() method, it seems to me
> that the convertor always creates callable invariants (ie. creating an
> EOperation rather than EAnnotation).
>
> As stated here (http://www.eclipse.org/forums/index.php/t/351402/),
> this implies that the constraints cannot be validated.
>
> Is the option to choose for the EAnnotation representation in the
> target model a missing feature/option of the transformation, or is this
> intentionally?
>
> Thx,
>
> Klaas
Re: [uml2ecore] UML2EcoreConvertor::ProcessInvariantConstraint [message #1018794 is a reply to message #1018692] Thu, 14 March 2013 13:32 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. Damus
Messages: 789
Registered: July 2009
Senior Member
Hi, Klaas,

No, you're probably not missing anything. Perhaps the enhancement I
referenced uses operation delegates to implement the operation-style
invariants instead of the annotation-style invariants.

If you don't see any options to generate the annotation style, then
that should probably be raised as an enhancement request in bugzilla.

Cheers,

Christian


On 2013-03-14 10:16:30 +0000, Klaas Gadeyne said:

> Hi Christian,
> Christian W. Damus wrote on Wed, 13 March 2013 17:08
>> Hi, Klass,
>>
>> I think the imminent M6 milestone of the Kepler relase may have what
>> you're looking for:
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=322715
>
>
> I'm not really sure, since I'm not familiar with the EMF delegation
> mechanism, but from what I can see in the git-source code and the stuff
> I read in http://wiki.eclipse.org/MDT/OCLinEcore, the problem is not
> really in the delegates. I think the problem is rather in _how_ the
> invariant ends up in the ecore model.
> From what I understand from
> http://wiki.eclipse.org/MDT/OCLinEcore#EClassifier_invariants, there
> are 2 ways of generating the invariants, and as far as I can see,
> UML2ecore only supports the "API variant" (where the constraint is
> represented as an eOperation), whereas I'm apparently looking to have
> the "non-API" invariant.
>
> This also seems to be confirmed with what I encounter when trying the
> last UML2 interim build. Unless I'm missing something ofcourse!
>
> regards,
>
> Klaas
> Quote:
>> On 2013-03-13 15:37:23 +0000, Klaas Gadeyne said:
>>> Hi,
>>>
>>> When looking at the source code of the
>>> UML2EcoreConvertor::ProcessInvariantConstraint() method, it seems to me
>>> that the convertor always creates callable invariants (ie. creating an
>>> EOperation rather than EAnnotation).
>>>
>>> As stated here (http://www.eclipse.org/forums/index.php/t/351402/),
>>> this implies that the constraints cannot be validated.
>>>
>>> Is the option to choose for the EAnnotation representation in the
>>> target model a missing feature/option of the transformation, or is this
>>> intentionally?
>>>
>>> Thx,
>>>
>>> Klaas
Re: [uml2ecore] UML2EcoreConvertor::ProcessInvariantConstraint [message #1018908 is a reply to message #1018794] Thu, 14 March 2013 17:09 Go to previous message
Klaas Gadeyne is currently offline Klaas Gadeyne
Messages: 86
Registered: July 2009
Member
Christian W. Damus wrote on Thu, 14 March 2013 09:32
Hi, Klaas,

No, you're probably not missing anything. Perhaps the enhancement I
referenced uses operation delegates to implement the operation-style
invariants instead of the annotation-style invariants.

If you don't see any options to generate the annotation style, then
that should probably be raised as an enhancement request in bugzilla.


Thx! https://bugs.eclipse.org/bugs/show_bug.cgi?id=403374 raised.
Previous Topic:Obtaining a value of a property defined in a profile
Next Topic:digram class problem
Goto Forum:
  


Current Time: Tue Sep 23 08:26:39 GMT 2014

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

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