Home » Modeling » UML2 » [uml2ecore] UML2EcoreConvertor::ProcessInvariantConstraint
|
Re: [uml2ecore] UML2EcoreConvertor::ProcessInvariantConstraint [message #1018449 is a reply to message #1018306] |
Wed, 13 March 2013 21: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
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 |
Klaas Gadeyne Messages: 165 Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Christian W. Damus wrote on Wed, 13 March 2013 17:08Hi, 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 |
|
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
|
|
| |
Goto Forum:
Current Time: Mon Sep 23 03:30:46 GMT 2024
Powered by FUDForum. Page generated in 0.04712 seconds
|