Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community Forums[uml2ecore] UML2EcoreConvertor::ProcessInvariantConstraint
https://www.eclipse.org/forums/index.php/mv/msg/458888/1018306/#msg_1018306
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).
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]]>Klaas Gadeyne2013-03-13T15:37:23-00:00Re: [uml2ecore] UML2EcoreConvertor::ProcessInvariantConstraint
https://www.eclipse.org/forums/index.php/mv/msg/458888/1018449/#msg_1018449
I think the imminent M6 milestone of the Kepler relase may have what
you're looking for:
> 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]]>Christian Damus2013-03-13T21:08:33-00:00Re: [uml2ecore] UML2EcoreConvertor::ProcessInvariantConstraint
https://www.eclipse.org/forums/index.php/mv/msg/458888/1018692/#msg_1018692
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:
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
]]>Klaas Gadeyne2013-03-14T10:16:29-00:00Re: [uml2ecore] UML2EcoreConvertor::ProcessInvariantConstraint
https://www.eclipse.org/forums/index.php/mv/msg/458888/1018794/#msg_1018794
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]]>Christian Damus2013-03-14T13:32:31-00:00Re: [uml2ecore] UML2EcoreConvertor::ProcessInvariantConstraint
https://www.eclipse.org/forums/index.php/mv/msg/458888/1018908/#msg_1018908
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.