Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Can we implement an operation in pure OCL
Can we implement an operation in pure OCL [message #33262] Mon, 16 July 2007 15:42 Go to next message
Eclipse UserFriend
Originally posted by: firstname.name.gmail.com

Hello,

I read the article "implementing model integrity" to get a flavour of what can
we do..

I would like to create an operation in a Stereotype (despite I know that
defining an operation may sound like a side effect of inheritance of a Class)
and define its body with OCL.

Lets say that I want to create a stereotype =MyStereotype= and define a
operation called =reverse= to reverse a given string.

I will create at first the Stereotype =MyStereotype=, next create an operation
called =reverse=, create an input parameter and a return parameter. So at this
point I think that it is enough to create an operation context.

next i am lost, and I even do not know if I can do something.

Obviously I guess that it is not enough and I have to programmaticly do like in
the article "implementing model integraty":
1. helper.setOperationContext(myprofilepackage, reverse),
2. retrieve the body (I do not know what model element is the best adapted),
3. create the query and so on..

at the end, would it be sufficient to provide the helper with an operation
called reverse in the context of this stereotype, something like at M1
self.reverse('toto')!=self.base_Class.name

between how/where are defined all the "meta-operation" such as
self.hasValue():Boolean


thanks a lot.
--
F. Lagarde
Re: Can we implement an operation in pure OCL [message #33331 is a reply to message #33262] Mon, 16 July 2007 16:15 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, François,

The UML2 2.1 release has added support for generating operation bodies from
OCL specified in your UML model (in much the same way as my article). This
applies to operations defined on Stereotypes, as well, if you take
advantage of another new feature in the 2.1 release: static profile
definition. You can generate the Java code implementing your Profile
(converting it to an EPackage), and that generated code is enhanced with
OCL-specified constraints and operations.

I think that James is currently working on documentation of both of these
features. In any case, the UML2 newsgroup (which I have included in this
reply) can help you to get started. Also, if you search that newsgroup, I
think you will find some previous postings on this subject that would help.

HTH,

Christian


François Lagarde wrote:

> Hello,
>
> I read the article "implementing model integrity" to get a flavour of what
> can we do..
>
> I would like to create an operation in a Stereotype (despite I know that
> defining an operation may sound like a side effect of inheritance of a
> Class) and define its body with OCL.
>
> Lets say that I want to create a stereotype =MyStereotype= and define a
> operation called =reverse= to reverse a given string.
>
> I will create at first the Stereotype =MyStereotype=, next create an
> operation called =reverse=, create an input parameter and a return
> parameter. So at this point I think that it is enough to create an
> operation context.
>
> next i am lost, and I even do not know if I can do something.
>
> Obviously I guess that it is not enough and I have to programmaticly do
> like in the article "implementing model integraty":
> 1. helper.setOperationContext(myprofilepackage, reverse),
> 2. retrieve the body (I do not know what model element is the best
> adapted), 3. create the query and so on..
>
> at the end, would it be sufficient to provide the helper with an operation
> called reverse in the context of this stereotype, something like at M1
> self.reverse('toto')!=self.base_Class.name
>
> between how/where are defined all the "meta-operation" such as
> self.hasValue():Boolean
>
>
> thanks a lot.
Re: Can we implement an operation in pure OCL [message #37710 is a reply to message #33331] Mon, 24 September 2007 05:54 Go to previous messageGo to next message
Philipp W. Kutter is currently offline Philipp W. KutterFriend
Messages: 301
Registered: July 2009
Senior Member
Hi, Christian.
Sorry for coming back to the OCL group with this.

I would be interested to generate operation bodies from OCL in my EMF
models, not my UML models. Is there similar support/documentation
planned for this?

Would I have to ask in the EMF newsgroup, rather than here?

Best, Philipp Kutter

Christian W. Damus wrote:

> Hi, François,
>
> The UML2 2.1 release has added support for generating operation bodies from
> OCL specified in your UML model (in much the same way as my article). This
> applies to operations defined on Stereotypes, as well, if you take
> advantage of another new feature in the 2.1 release: static profile
> definition. You can generate the Java code implementing your Profile
> (converting it to an EPackage), and that generated code is enhanced with
> OCL-specified constraints and operations.
>
> I think that James is currently working on documentation of both of these
> features. In any case, the UML2 newsgroup (which I have included in this
> reply) can help you to get started. Also, if you search that newsgroup, I
> think you will find some previous postings on this subject that would help.
>
> HTH,
>
> Christian
>
>
> François Lagarde wrote:
>
>> Hello,
>>
>> I read the article "implementing model integrity" to get a flavour of what
>> can we do..
>>
>> I would like to create an operation in a Stereotype (despite I know that
>> defining an operation may sound like a side effect of inheritance of a
>> Class) and define its body with OCL.
>>
>> Lets say that I want to create a stereotype =MyStereotype= and define a
>> operation called =reverse= to reverse a given string.
>>
>> I will create at first the Stereotype =MyStereotype=, next create an
>> operation called =reverse=, create an input parameter and a return
>> parameter. So at this point I think that it is enough to create an
>> operation context.
>>
>> next i am lost, and I even do not know if I can do something.
>>
>> Obviously I guess that it is not enough and I have to programmaticly do
>> like in the article "implementing model integraty":
>> 1. helper.setOperationContext(myprofilepackage, reverse),
>> 2. retrieve the body (I do not know what model element is the best
>> adapted), 3. create the query and so on..
>>
>> at the end, would it be sufficient to provide the helper with an operation
>> called reverse in the context of this stereotype, something like at M1
>> self.reverse('toto')!=self.base_Class.name
>>
>> between how/where are defined all the "meta-operation" such as
>> self.hasValue():Boolean
>>
>>
>> thanks a lot.
>
Re: Can we implement an operation in pure OCL [message #37745 is a reply to message #37710] Mon, 24 September 2007 09:04 Go to previous messageGo to next message
Miguel Garcia is currently offline Miguel GarciaFriend
Messages: 77
Registered: July 2009
Member
Philipp,

If you want an automatic translation of sthg like:

context LoyaltyAccount
inv invariant_points :
self . points > 0
implies self . transactions -> exists ( t | t. points > 0 )

into:

public boolean invariant_points () {
Boolean implies1 = ( this . getPoints () > 0);
if (!( implies1 )) {
implies1 = Boolean . TRUE ;
} else {
Boolean exists2 = false ;
for ( RandL . Transaction t :
org . eclipse . ocl . util . CollectionUtil . asSet (
this . getTransactions ())) {
if (! exists2 ) {
exists2 = (t. getPoints () > 0);
}
}
implies1 = exists2 ;
}
return implies1 ;
}

Then you may find useful the OCL -> Java Compiler that is about to be part
of the new OCL Tools component in the MDT project.

That compiler has been described in
http://www.sts.tu-harburg.de/~mi.garcia/pubs/2007/ese/oclcom piler.pdf

Regards,

Miguel


--
Miguel Garcia miguel.garcia@tuhh.de
Institute for Software Systems (STS), AB 4-02
Technische Universitaet Hamburg-Harburg
Harburger Schlossstr. 20, 21073 Hamburg Fax: (+49)40-42878-2515
http://www.sts.tu-harburg.de/~mi.garcia


"Philipp W. Kutter" <kutter@montages.com> wrote in message
news:46F75126.9050705@montages.com...
> Hi, Christian.
> Sorry for coming back to the OCL group with this.
>
> I would be interested to generate operation bodies from OCL in my EMF
> models, not my UML models. Is there similar support/documentation planned
> for this?
>
> Would I have to ask in the EMF newsgroup, rather than here?
>
> Best, Philipp Kutter
>
> Christian W. Damus wrote:
>
>> Hi, Fran
Re: Can we implement an operation in pure OCL [message #37841 is a reply to message #37710] Mon, 24 September 2007 13:45 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Philipp,

The article referred to earlier in this thread actually focuses on
generating code with OCL for Ecore models, not UML:

http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html

Also, as Miguel indicated, OCL Tools will soon offer an OCL-to-Java compiler
that does use run-time interpretation as the templates in my article do.
It's very cool, and it actually works! (I've tried it) You may find that
better for your situation, especially once you've finished testing your OCL
in interpreted mode.

HTH,

Christian


Philipp W. Kutter wrote:

> Hi, Christian.
> Sorry for coming back to the OCL group with this.
>
> I would be interested to generate operation bodies from OCL in my EMF
> models, not my UML models. Is there similar support/documentation
> planned for this?
>
> Would I have to ask in the EMF newsgroup, rather than here?
>
> Best, Philipp Kutter
>
> Christian W. Damus wrote:
>
>> Hi, François,
>>
>> The UML2 2.1 release has added support for generating operation bodies
>> from
>> OCL specified in your UML model (in much the same way as my article).
>> This applies to operations defined on Stereotypes, as well, if you take
>> advantage of another new feature in the 2.1 release: static profile
>> definition. You can generate the Java code implementing your Profile
>> (converting it to an EPackage), and that generated code is enhanced with
>> OCL-specified constraints and operations.
>>
>> I think that James is currently working on documentation of both of these
>> features. In any case, the UML2 newsgroup (which I have included in this
>> reply) can help you to get started. Also, if you search that newsgroup,
>> I think you will find some previous postings on this subject that would
>> help.
>>
>> HTH,
>>
>> Christian
>>
>>
>> François Lagarde wrote:
>>
>>> Hello,
>>>
>>> I read the article "implementing model integrity" to get a flavour of
>>> what can we do..
>>>
>>> I would like to create an operation in a Stereotype (despite I know that
>>> defining an operation may sound like a side effect of inheritance of a
>>> Class) and define its body with OCL.
>>>
>>> Lets say that I want to create a stereotype =MyStereotype= and define a
>>> operation called =reverse= to reverse a given string.
>>>
>>> I will create at first the Stereotype =MyStereotype=, next create an
>>> operation called =reverse=, create an input parameter and a return
>>> parameter. So at this point I think that it is enough to create an
>>> operation context.
>>>
>>> next i am lost, and I even do not know if I can do something.
>>>
>>> Obviously I guess that it is not enough and I have to programmaticly do
>>> like in the article "implementing model integraty":
>>> 1. helper.setOperationContext(myprofilepackage, reverse),
>>> 2. retrieve the body (I do not know what model element is the best
>>> adapted), 3. create the query and so on..
>>>
>>> at the end, would it be sufficient to provide the helper with an
>>> operation called reverse in the context of this stereotype, something
>>> like at M1 self.reverse('toto')!=self.base_Class.name
>>>
>>> between how/where are defined all the "meta-operation" such as
>>> self.hasValue():Boolean
>>>
>>>
>>> thanks a lot.
>>
Re: Can we implement an operation in pure OCL [message #38910 is a reply to message #37841] Wed, 26 September 2007 19:13 Go to previous messageGo to next message
Philipp W. Kutter is currently offline Philipp W. KutterFriend
Messages: 301
Registered: July 2009
Senior Member
Hi, Christian.
I tried it out, and it works perfectly!

It would be great, if this is added as a standard option to EMF. Why not
having oclConstraint, oclDerive, and oclBody as standard features of
EClass, EReference, and EOperation?

I mean EMF is the best MOF implementation out there, and OCL is part of MOF.

Are there feature requests like for adding the overwrites that would be
needed for the Validator template? Or is there another plan to make this
easier for more business oriented users of EMF?

Best, and thanks a lot for the great tutorial!

Best, Philipp

Christian W. Damus wrote:
> Hi, Philipp,
>
> The article referred to earlier in this thread actually focuses on
> generating code with OCL for Ecore models, not UML:
>
> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>
> Also, as Miguel indicated, OCL Tools will soon offer an OCL-to-Java compiler
> that does use run-time interpretation as the templates in my article do.
> It's very cool, and it actually works! (I've tried it) You may find that
> better for your situation, especially once you've finished testing your OCL
> in interpreted mode.
>
> HTH,
>
> Christian
>
>
> Philipp W. Kutter wrote:
>
>> Hi, Christian.
>> Sorry for coming back to the OCL group with this.
>>
>> I would be interested to generate operation bodies from OCL in my EMF
>> models, not my UML models. Is there similar support/documentation
>> planned for this?
>>
>> Would I have to ask in the EMF newsgroup, rather than here?
>>
>> Best, Philipp Kutter
>>
>> Christian W. Damus wrote:
>>
>>> Hi, François,
>>>
>>> The UML2 2.1 release has added support for generating operation bodies
>>> from
>>> OCL specified in your UML model (in much the same way as my article).
>>> This applies to operations defined on Stereotypes, as well, if you take
>>> advantage of another new feature in the 2.1 release: static profile
>>> definition. You can generate the Java code implementing your Profile
>>> (converting it to an EPackage), and that generated code is enhanced with
>>> OCL-specified constraints and operations.
>>>
>>> I think that James is currently working on documentation of both of these
>>> features. In any case, the UML2 newsgroup (which I have included in this
>>> reply) can help you to get started. Also, if you search that newsgroup,
>>> I think you will find some previous postings on this subject that would
>>> help.
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>>
>>> François Lagarde wrote:
>>>
>>>> Hello,
>>>>
>>>> I read the article "implementing model integrity" to get a flavour of
>>>> what can we do..
>>>>
>>>> I would like to create an operation in a Stereotype (despite I know that
>>>> defining an operation may sound like a side effect of inheritance of a
>>>> Class) and define its body with OCL.
>>>>
>>>> Lets say that I want to create a stereotype =MyStereotype= and define a
>>>> operation called =reverse= to reverse a given string.
>>>>
>>>> I will create at first the Stereotype =MyStereotype=, next create an
>>>> operation called =reverse=, create an input parameter and a return
>>>> parameter. So at this point I think that it is enough to create an
>>>> operation context.
>>>>
>>>> next i am lost, and I even do not know if I can do something.
>>>>
>>>> Obviously I guess that it is not enough and I have to programmaticly do
>>>> like in the article "implementing model integraty":
>>>> 1. helper.setOperationContext(myprofilepackage, reverse),
>>>> 2. retrieve the body (I do not know what model element is the best
>>>> adapted), 3. create the query and so on..
>>>>
>>>> at the end, would it be sufficient to provide the helper with an
>>>> operation called reverse in the context of this stereotype, something
>>>> like at M1 self.reverse('toto')!=self.base_Class.name
>>>>
>>>> between how/where are defined all the "meta-operation" such as
>>>> self.hasValue():Boolean
>>>>
>>>>
>>>> thanks a lot.
>
Re: Can we implement an operation in pure OCL [message #38935 is a reply to message #38910] Wed, 26 September 2007 19:23 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Philipp,

I'd like to provide enough flexibility to allow things like OCL to be
more easily plugged as an extension without committing to OCL as having
a special status. One might generally want to be able to express even
side-effects so perhaps QVT might be even more powerful in that regard...


Philipp W. Kutter wrote:
> Hi, Christian.
> I tried it out, and it works perfectly!
>
> It would be great, if this is added as a standard option to EMF. Why
> not having oclConstraint, oclDerive, and oclBody as standard features
> of EClass, EReference, and EOperation?
>
> I mean EMF is the best MOF implementation out there, and OCL is part
> of MOF.
>
> Are there feature requests like for adding the overwrites that would
> be needed for the Validator template? Or is there another plan to make
> this
> easier for more business oriented users of EMF?
>
> Best, and thanks a lot for the great tutorial!
>
> Best, Philipp
>
> Christian W. Damus wrote:
>> Hi, Philipp,
>>
>> The article referred to earlier in this thread actually focuses on
>> generating code with OCL for Ecore models, not UML:
>>
>> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>>
>>
>> Also, as Miguel indicated, OCL Tools will soon offer an OCL-to-Java
>> compiler
>> that does use run-time interpretation as the templates in my article
>> do. It's very cool, and it actually works! (I've tried it) You may
>> find that
>> better for your situation, especially once you've finished testing
>> your OCL
>> in interpreted mode.
>>
>> HTH,
>>
>> Christian
>>
>>
>> Philipp W. Kutter wrote:
>>
>>> Hi, Christian.
>>> Sorry for coming back to the OCL group with this.
>>>
>>> I would be interested to generate operation bodies from OCL in my EMF
>>> models, not my UML models. Is there similar support/documentation
>>> planned for this?
>>>
>>> Would I have to ask in the EMF newsgroup, rather than here?
>>>
>>> Best, Philipp Kutter
>>>
>>> Christian W. Damus wrote:
>>>
>>>> Hi, François,
>>>>
>>>> The UML2 2.1 release has added support for generating operation bodies
>>>> from
>>>> OCL specified in your UML model (in much the same way as my
>>>> article). This applies to operations defined on Stereotypes, as
>>>> well, if you take
>>>> advantage of another new feature in the 2.1 release: static profile
>>>> definition. You can generate the Java code implementing your Profile
>>>> (converting it to an EPackage), and that generated code is enhanced
>>>> with
>>>> OCL-specified constraints and operations.
>>>>
>>>> I think that James is currently working on documentation of both of
>>>> these
>>>> features. In any case, the UML2 newsgroup (which I have included
>>>> in this
>>>> reply) can help you to get started. Also, if you search that
>>>> newsgroup,
>>>> I think you will find some previous postings on this subject that
>>>> would
>>>> help.
>>>>
>>>> HTH,
>>>>
>>>> Christian
>>>>
>>>>
>>>> François Lagarde wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I read the article "implementing model integrity" to get a flavour of
>>>>> what can we do..
>>>>>
>>>>> I would like to create an operation in a Stereotype (despite I
>>>>> know that
>>>>> defining an operation may sound like a side effect of inheritance
>>>>> of a
>>>>> Class) and define its body with OCL.
>>>>>
>>>>> Lets say that I want to create a stereotype =MyStereotype= and
>>>>> define a
>>>>> operation called =reverse= to reverse a given string.
>>>>>
>>>>> I will create at first the Stereotype =MyStereotype=, next create an
>>>>> operation called =reverse=, create an input parameter and a return
>>>>> parameter. So at this point I think that it is enough to create an
>>>>> operation context.
>>>>>
>>>>> next i am lost, and I even do not know if I can do something.
>>>>>
>>>>> Obviously I guess that it is not enough and I have to
>>>>> programmaticly do
>>>>> like in the article "implementing model integraty":
>>>>> 1. helper.setOperationContext(myprofilepackage, reverse),
>>>>> 2. retrieve the body (I do not know what model element is the best
>>>>> adapted), 3. create the query and so on..
>>>>>
>>>>> at the end, would it be sufficient to provide the helper with an
>>>>> operation called reverse in the context of this stereotype, something
>>>>> like at M1 self.reverse('toto')!=self.base_Class.name
>>>>>
>>>>> between how/where are defined all the "meta-operation" such as
>>>>> self.hasValue():Boolean
>>>>>
>>>>>
>>>>> thanks a lot.
>>
Re: Can we implement an operation in pure OCL [message #38958 is a reply to message #38935] Wed, 26 September 2007 19:36 Go to previous messageGo to next message
Philipp W. Kutter is currently offline Philipp W. KutterFriend
Messages: 301
Registered: July 2009
Senior Member
I agree.

First step would be to add the overwrite points Christian was missing. I
asked him whether he already made a request for that.

A second step would be to allow an easy way to make this possible as
well for reflective EMF.

By the way, what you propose could be done by the following options:

ECLass:
constraintDef
constraintLanguage

EReference:
deriveDef
deriveLanguage

EOperation:
bodyDef
bodyLanguage

And then an extension point for languages, where people can define the
code needed to bridge from their language to EMF. Christian would then
have his small JetTemplates as part of the extension OCL to your
Ecore-Language extension-point, rather then dynamic templates.

What do you think about this solution?

Best, Philipp



Ed Merks wrote:
> Philipp,
>
> I'd like to provide enough flexibility to allow things like OCL to be
> more easily plugged as an extension without committing to OCL as having
> a special status. One might generally want to be able to express even
> side-effects so perhaps QVT might be even more powerful in that regard...
>
>
> Philipp W. Kutter wrote:
>> Hi, Christian.
>> I tried it out, and it works perfectly!
>>
>> It would be great, if this is added as a standard option to EMF. Why
>> not having oclConstraint, oclDerive, and oclBody as standard features
>> of EClass, EReference, and EOperation?
>>
>> I mean EMF is the best MOF implementation out there, and OCL is part
>> of MOF.
>>
>> Are there feature requests like for adding the overwrites that would
>> be needed for the Validator template? Or is there another plan to make
>> this
>> easier for more business oriented users of EMF?
>>
>> Best, and thanks a lot for the great tutorial!
>>
>> Best, Philipp
>>
>> Christian W. Damus wrote:
>>> Hi, Philipp,
>>>
>>> The article referred to earlier in this thread actually focuses on
>>> generating code with OCL for Ecore models, not UML:
>>>
>>> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>>>
>>>
>>> Also, as Miguel indicated, OCL Tools will soon offer an OCL-to-Java
>>> compiler
>>> that does use run-time interpretation as the templates in my article
>>> do. It's very cool, and it actually works! (I've tried it) You may
>>> find that
>>> better for your situation, especially once you've finished testing
>>> your OCL
>>> in interpreted mode.
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>>
>>> Philipp W. Kutter wrote:
>>>
>>>> Hi, Christian.
>>>> Sorry for coming back to the OCL group with this.
>>>>
>>>> I would be interested to generate operation bodies from OCL in my EMF
>>>> models, not my UML models. Is there similar support/documentation
>>>> planned for this?
>>>>
>>>> Would I have to ask in the EMF newsgroup, rather than here?
>>>>
>>>> Best, Philipp Kutter
>>>>
>>>> Christian W. Damus wrote:
>>>>
>>>>> Hi, François,
>>>>>
>>>>> The UML2 2.1 release has added support for generating operation bodies
>>>>> from
>>>>> OCL specified in your UML model (in much the same way as my
>>>>> article). This applies to operations defined on Stereotypes, as
>>>>> well, if you take
>>>>> advantage of another new feature in the 2.1 release: static profile
>>>>> definition. You can generate the Java code implementing your Profile
>>>>> (converting it to an EPackage), and that generated code is enhanced
>>>>> with
>>>>> OCL-specified constraints and operations.
>>>>>
>>>>> I think that James is currently working on documentation of both of
>>>>> these
>>>>> features. In any case, the UML2 newsgroup (which I have included
>>>>> in this
>>>>> reply) can help you to get started. Also, if you search that
>>>>> newsgroup,
>>>>> I think you will find some previous postings on this subject that
>>>>> would
>>>>> help.
>>>>>
>>>>> HTH,
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> François Lagarde wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I read the article "implementing model integrity" to get a flavour of
>>>>>> what can we do..
>>>>>>
>>>>>> I would like to create an operation in a Stereotype (despite I
>>>>>> know that
>>>>>> defining an operation may sound like a side effect of inheritance
>>>>>> of a
>>>>>> Class) and define its body with OCL.
>>>>>>
>>>>>> Lets say that I want to create a stereotype =MyStereotype= and
>>>>>> define a
>>>>>> operation called =reverse= to reverse a given string.
>>>>>>
>>>>>> I will create at first the Stereotype =MyStereotype=, next create an
>>>>>> operation called =reverse=, create an input parameter and a return
>>>>>> parameter. So at this point I think that it is enough to create an
>>>>>> operation context.
>>>>>>
>>>>>> next i am lost, and I even do not know if I can do something.
>>>>>>
>>>>>> Obviously I guess that it is not enough and I have to
>>>>>> programmaticly do
>>>>>> like in the article "implementing model integraty":
>>>>>> 1. helper.setOperationContext(myprofilepackage, reverse),
>>>>>> 2. retrieve the body (I do not know what model element is the best
>>>>>> adapted), 3. create the query and so on..
>>>>>>
>>>>>> at the end, would it be sufficient to provide the helper with an
>>>>>> operation called reverse in the context of this stereotype, something
>>>>>> like at M1 self.reverse('toto')!=self.base_Class.name
>>>>>>
>>>>>> between how/where are defined all the "meta-operation" such as
>>>>>> self.hasValue():Boolean
>>>>>>
>>>>>>
>>>>>> thanks a lot.
>>>
Re: Can we implement an operation in pure OCL [message #38993 is a reply to message #38910] Wed, 26 September 2007 19:39 Go to previous messageGo to next message
Philipp W. Kutter is currently offline Philipp W. KutterFriend
Messages: 301
Registered: July 2009
Senior Member
Hi, Christian.
Although I find your tutorial near perfect, I have one proposal for
improvement:

In order to be similar to the way how Ecore annotations are done, I
would set as "source" of your OCL annotation the URI
http://www.eclipse.org/ocl/1.1.0/OCL

Rather than the URI http://www.eclipse.org/ocl/examples/OCL which
you have chosen. After a simple query replace, the example worked again.

Best, Philipp

Philipp W. Kutter wrote:
> Hi, Christian.
> I tried it out, and it works perfectly!
>
> It would be great, if this is added as a standard option to EMF. Why not
> having oclConstraint, oclDerive, and oclBody as standard features of
> EClass, EReference, and EOperation?
>
> I mean EMF is the best MOF implementation out there, and OCL is part of
> MOF.
>
> Are there feature requests like for adding the overwrites that would be
> needed for the Validator template? Or is there another plan to make this
> easier for more business oriented users of EMF?
>
> Best, and thanks a lot for the great tutorial!
>
> Best, Philipp
>
> Christian W. Damus wrote:
>> Hi, Philipp,
>>
>> The article referred to earlier in this thread actually focuses on
>> generating code with OCL for Ecore models, not UML:
>>
>> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>>
>>
>> Also, as Miguel indicated, OCL Tools will soon offer an OCL-to-Java
>> compiler
>> that does use run-time interpretation as the templates in my article
>> do. It's very cool, and it actually works! (I've tried it) You may
>> find that
>> better for your situation, especially once you've finished testing
>> your OCL
>> in interpreted mode.
>>
>> HTH,
>>
>> Christian
>>
>>
>> Philipp W. Kutter wrote:
>>
>>> Hi, Christian.
>>> Sorry for coming back to the OCL group with this.
>>>
>>> I would be interested to generate operation bodies from OCL in my EMF
>>> models, not my UML models. Is there similar support/documentation
>>> planned for this?
>>>
>>> Would I have to ask in the EMF newsgroup, rather than here?
>>>
>>> Best, Philipp Kutter
>>>
>>> Christian W. Damus wrote:
>>>
>>>> Hi, François,
>>>>
>>>> The UML2 2.1 release has added support for generating operation bodies
>>>> from
>>>> OCL specified in your UML model (in much the same way as my
>>>> article). This applies to operations defined on Stereotypes, as
>>>> well, if you take
>>>> advantage of another new feature in the 2.1 release: static profile
>>>> definition. You can generate the Java code implementing your Profile
>>>> (converting it to an EPackage), and that generated code is enhanced
>>>> with
>>>> OCL-specified constraints and operations.
>>>>
>>>> I think that James is currently working on documentation of both of
>>>> these
>>>> features. In any case, the UML2 newsgroup (which I have included in
>>>> this
>>>> reply) can help you to get started. Also, if you search that
>>>> newsgroup,
>>>> I think you will find some previous postings on this subject that would
>>>> help.
>>>>
>>>> HTH,
>>>>
>>>> Christian
>>>>
>>>>
>>>> François Lagarde wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I read the article "implementing model integrity" to get a flavour of
>>>>> what can we do..
>>>>>
>>>>> I would like to create an operation in a Stereotype (despite I know
>>>>> that
>>>>> defining an operation may sound like a side effect of inheritance of a
>>>>> Class) and define its body with OCL.
>>>>>
>>>>> Lets say that I want to create a stereotype =MyStereotype= and
>>>>> define a
>>>>> operation called =reverse= to reverse a given string.
>>>>>
>>>>> I will create at first the Stereotype =MyStereotype=, next create an
>>>>> operation called =reverse=, create an input parameter and a return
>>>>> parameter. So at this point I think that it is enough to create an
>>>>> operation context.
>>>>>
>>>>> next i am lost, and I even do not know if I can do something.
>>>>>
>>>>> Obviously I guess that it is not enough and I have to
>>>>> programmaticly do
>>>>> like in the article "implementing model integraty":
>>>>> 1. helper.setOperationContext(myprofilepackage, reverse),
>>>>> 2. retrieve the body (I do not know what model element is the best
>>>>> adapted), 3. create the query and so on..
>>>>>
>>>>> at the end, would it be sufficient to provide the helper with an
>>>>> operation called reverse in the context of this stereotype, something
>>>>> like at M1 self.reverse('toto')!=self.base_Class.name
>>>>>
>>>>> between how/where are defined all the "meta-operation" such as
>>>>> self.hasValue():Boolean
>>>>>
>>>>>
>>>>> thanks a lot.
>>
Re: Can we implement an operation in pure OCL [message #39016 is a reply to message #38910] Wed, 26 September 2007 20:32 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Philipp,

Super! I'm glad that it works for you. You seem to be enjoying it ;-)

Have a look at https://bugs.eclipse.org/bugs/show_bug.cgi?id=191689 re:
out-of-the-box OCL support in EMF.

cW

Philipp W. Kutter wrote:

> Hi, Christian.
> I tried it out, and it works perfectly!
>
> It would be great, if this is added as a standard option to EMF. Why not
> having oclConstraint, oclDerive, and oclBody as standard features of
> EClass, EReference, and EOperation?
>
> I mean EMF is the best MOF implementation out there, and OCL is part of
> MOF.
>
> Are there feature requests like for adding the overwrites that would be
> needed for the Validator template? Or is there another plan to make this
> easier for more business oriented users of EMF?
>
> Best, and thanks a lot for the great tutorial!
>
> Best, Philipp

------8<------
Re: Can we implement an operation in pure OCL [message #39047 is a reply to message #38993] Wed, 26 September 2007 20:35 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Philipp,

I actually chose an "examples" namespace deliberately. This ensures that it
doesn't look like an official implementation, and cannot clash with an
official implementation that may eventually appear. The article is, after
all, just an example.

Cheers,

Christian


Philipp W. Kutter wrote:

> Hi, Christian.
> Although I find your tutorial near perfect, I have one proposal for
> improvement:
>
> In order to be similar to the way how Ecore annotations are done, I
> would set as "source" of your OCL annotation the URI
> http://www.eclipse.org/ocl/1.1.0/OCL
>
> Rather than the URI http://www.eclipse.org/ocl/examples/OCL which
> you have chosen. After a simple query replace, the example worked again.
>
> Best, Philipp
>

-----8<-----
Re: Can we implement an operation in pure OCL [message #39081 is a reply to message #38958] Wed, 26 September 2007 20:38 Go to previous message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Philipp,

Comments below.


Philipp W. Kutter wrote:
> I agree.
>
> First step would be to add the overwrite points Christian was missing.
> I asked him whether he already made a request for that.
I don't think there is such a request.
>
> A second step would be to allow an easy way to make this possible as
> well for reflective EMF.
Yes, it would be really cool to have dynamic models with behavior.
>
> By the way, what you propose could be done by the following options:
>
> ECLass:
> constraintDef
> constraintLanguage
>
> EReference:
> deriveDef
> deriveLanguage
>
> EOperation:
> bodyDef
> bodyLanguage
I'm not a big fan of extending Ecore itself since this will tend to grow
and grow. I think all these things could be accomplished with
annotations without complicating and comprimising the simplicity of Ecore.
>
> And then an extension point for languages, where people can define the
> code needed to bridge from their language to EMF. Christian would then
> have his small JetTemplates as part of the extension OCL to your
> Ecore-Language extension-point, rather then dynamic templates.
Something similar but using annotations would be cool.
>
> What do you think about this solution?
And extension mechanism without at least two extenders will likely end
up overlooking some key aspects. I like the idea overall, but
realistically there seems to be so little time to do cool things. We're
relying heavily on the community to contribute, but that works most
smoothly when they add new layers with minimal needs to modify the
base. Changes to the base still require a great deal of the very spare
amount of development resource we have...
>
> Best, Philipp
>
>
>
> Ed Merks wrote:
>> Philipp,
>>
>> I'd like to provide enough flexibility to allow things like OCL to be
>> more easily plugged as an extension without committing to OCL as
>> having a special status. One might generally want to be able to
>> express even side-effects so perhaps QVT might be even more powerful
>> in that regard...
>>
>>
>> Philipp W. Kutter wrote:
>>> Hi, Christian.
>>> I tried it out, and it works perfectly!
>>>
>>> It would be great, if this is added as a standard option to EMF. Why
>>> not having oclConstraint, oclDerive, and oclBody as standard
>>> features of EClass, EReference, and EOperation?
>>>
>>> I mean EMF is the best MOF implementation out there, and OCL is part
>>> of MOF.
>>>
>>> Are there feature requests like for adding the overwrites that would
>>> be needed for the Validator template? Or is there another plan to
>>> make this
>>> easier for more business oriented users of EMF?
>>>
>>> Best, and thanks a lot for the great tutorial!
>>>
>>> Best, Philipp
>>>
>>> Christian W. Damus wrote:
>>>> Hi, Philipp,
>>>>
>>>> The article referred to earlier in this thread actually focuses on
>>>> generating code with OCL for Ecore models, not UML:
>>>>
>>>> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>>>>
>>>>
>>>> Also, as Miguel indicated, OCL Tools will soon offer an OCL-to-Java
>>>> compiler
>>>> that does use run-time interpretation as the templates in my
>>>> article do. It's very cool, and it actually works! (I've tried
>>>> it) You may find that
>>>> better for your situation, especially once you've finished testing
>>>> your OCL
>>>> in interpreted mode.
>>>>
>>>> HTH,
>>>>
>>>> Christian
>>>>
>>>>
>>>> Philipp W. Kutter wrote:
>>>>
>>>>> Hi, Christian.
>>>>> Sorry for coming back to the OCL group with this.
>>>>>
>>>>> I would be interested to generate operation bodies from OCL in my EMF
>>>>> models, not my UML models. Is there similar support/documentation
>>>>> planned for this?
>>>>>
>>>>> Would I have to ask in the EMF newsgroup, rather than here?
>>>>>
>>>>> Best, Philipp Kutter
>>>>>
>>>>> Christian W. Damus wrote:
>>>>>
>>>>>> Hi, François,
>>>>>>
>>>>>> The UML2 2.1 release has added support for generating operation
>>>>>> bodies
>>>>>> from
>>>>>> OCL specified in your UML model (in much the same way as my
>>>>>> article). This applies to operations defined on Stereotypes, as
>>>>>> well, if you take
>>>>>> advantage of another new feature in the 2.1 release: static profile
>>>>>> definition. You can generate the Java code implementing your
>>>>>> Profile
>>>>>> (converting it to an EPackage), and that generated code is
>>>>>> enhanced with
>>>>>> OCL-specified constraints and operations.
>>>>>>
>>>>>> I think that James is currently working on documentation of both
>>>>>> of these
>>>>>> features. In any case, the UML2 newsgroup (which I have included
>>>>>> in this
>>>>>> reply) can help you to get started. Also, if you search that
>>>>>> newsgroup,
>>>>>> I think you will find some previous postings on this subject that
>>>>>> would
>>>>>> help.
>>>>>>
>>>>>> HTH,
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> François Lagarde wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I read the article "implementing model integrity" to get a
>>>>>>> flavour of
>>>>>>> what can we do..
>>>>>>>
>>>>>>> I would like to create an operation in a Stereotype (despite I
>>>>>>> know that
>>>>>>> defining an operation may sound like a side effect of
>>>>>>> inheritance of a
>>>>>>> Class) and define its body with OCL.
>>>>>>>
>>>>>>> Lets say that I want to create a stereotype =MyStereotype= and
>>>>>>> define a
>>>>>>> operation called =reverse= to reverse a given string.
>>>>>>>
>>>>>>> I will create at first the Stereotype =MyStereotype=, next
>>>>>>> create an
>>>>>>> operation called =reverse=, create an input parameter and a return
>>>>>>> parameter. So at this point I think that it is enough to create an
>>>>>>> operation context.
>>>>>>>
>>>>>>> next i am lost, and I even do not know if I can do something.
>>>>>>>
>>>>>>> Obviously I guess that it is not enough and I have to
>>>>>>> programmaticly do
>>>>>>> like in the article "implementing model integraty":
>>>>>>> 1. helper.setOperationContext(myprofilepackage, reverse),
>>>>>>> 2. retrieve the body (I do not know what model element is the best
>>>>>>> adapted), 3. create the query and so on..
>>>>>>>
>>>>>>> at the end, would it be sufficient to provide the helper with an
>>>>>>> operation called reverse in the context of this stereotype,
>>>>>>> something
>>>>>>> like at M1 self.reverse('toto')!=self.base_Class.name
>>>>>>>
>>>>>>> between how/where are defined all the "meta-operation" such as
>>>>>>> self.hasValue():Boolean
>>>>>>>
>>>>>>>
>>>>>>> thanks a lot.
>>>>
Previous Topic:[Announce] MDT OCL 1.1.1 is available
Next Topic:[Announce] MDT OCL 1.2.0 I200709261645 is available
Goto Forum:
  


Current Time: Fri Dec 19 12:27:29 GMT 2014

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

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