Home » Modeling » OCL » Ease of Use of OCL in EMF
| Ease of Use of OCL in EMF [message #39754] |
Tue, 02 October 2007 05:23  |
 Philipp Kutter
Messages: 306
Registered: July 2009 |
Senior Member |
|
|
Hi, Everybody.
I read Ed and Christian's comments on my questions about implementing an
operation in OCL carefully.
The article of Christian Damus:
http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
shows how to do it in a way that is easy to do, but sometime hard to
maintain.
Ed Merks explained why adding features in EMF would not be an option.
Thus I'd like to start the discussion which things would have to be done
to get one step further.
1. Request override points in the file ValidatorClass.javajet, which
allow to restrict the changes Christian does in the article to fewer
places. It seems Ed would not be in principle against this.
2. Write an article which show how to use the Validation framework, to
add constraints to Ecore iself, guaranteeing that the OCL annotations
in the article are correct. For instance, a constraint that checks that
if a OCL "derive" is here, the corresponding ERererence is derived=true,
volatile=true, transient=true. Or a constraint that checks that an OCL
constraints is then as well mentioned in the corresponding ECORE
annotation "constraints"
3. Write an article which shows how to write small actions, that create
the different type of OCL annotations for constraints, derived features,
and operations.
With this in place, everybody could further extend the ideas how to use
OCL to tailor the EMF generated code as done in Christian's paper for
constraints, derived features, e.t.c.
I volunteer to actively test and comment any kind of contribution in
this direction. Unfortunately, I am not yet in the position to do it on
my own.
Best, Philipp
|
|
|
| Re: Ease of Use of OCL in EMF [message #39785 is a reply to message #39754] |
Tue, 02 October 2007 12:29  |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Philipp,
Comments below.
Philipp W. Kutter wrote:
> Hi, Everybody.
> I read Ed and Christian's comments on my questions about implementing
> an operation in OCL carefully.
>
> The article of Christian Damus:
> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>
> shows how to do it in a way that is easy to do, but sometime hard to
> maintain.
>
> Ed Merks explained why adding features in EMF would not be an option.
I only explained that providing hard code support specifically only for
OCL doesn't seem like a good approach.
>
> Thus I'd like to start the discussion which things would have to be
> done to get one step further.
>
> 1. Request override points in the file ValidatorClass.javajet, which
> allow to restrict the changes Christian does in the article to fewer
> places. It seems Ed would not be in principle against this.
I'm definitely in favor of making our templates more flexible. It's
very little work to add such things and they are obviously useful. This
is what I think https://bugs.eclipse.org/bugs/show_bug.cgi?id=191689 is
asking for.
>
> 2. Write an article which show how to use the Validation framework, to
> add constraints to Ecore iself, guaranteeing that the OCL annotations
> in the article are correct. For instance, a constraint that checks
> that if a OCL "derive" is here, the corresponding ERererence is
> derived=true,
> volatile=true, transient=true. Or a constraint that checks that an OCL
> constraints is then as well mentioned in the corresponding ECORE
> annotation "constraints"
I think this is related to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=143478. I could imagine
some type of mechanism whereby based on the source URI of an
EAnnotation, a validator could be registered to validate EAnnotations
with that source URI.
>
> 3. Write an article which shows how to write small actions, that
> create the different type of OCL annotations for constraints, derived
> features, and operations.
>
It would be awesomely cool to be able to have these mechanisms work for
dynamic models too. OCLs non-side-effect nature seems to be a bit of a
limitation. I wonder if QVT would be more powerful in that regard...
>
> With this in place, everybody could further extend the ideas how to
> use OCL to tailor the EMF generated code as done in Christian's paper
> for constraints, derived features, e.t.c.
>
>
> I volunteer to actively test and comment any kind of contribution in
> this direction. Unfortunately, I am not yet in the position to do it
> on my own.
And unfortunately our time is very limited as well. :-( We really
need the community of interested parties to help drive much of this
since I can at best devote some of my non-copious spare time toward such
efforts.
>
> Best, Philipp
|
|
|
| Re: Ease of Use of OCL in EMF [message #39816 is a reply to message #39754] |
Tue, 02 October 2007 13:24 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Philipp,
Of course, I'll be more than happy to review and test any such articles as
you describe that the community may contribute. It would be great to make
OCL a first-class citizen of EMF-land! :-)
I'm not sure that I understand Ed's concern about OCL not side-effect-free.
For the constraints that it is intended for (even initial values, which
imply assignment) it does a good job. For implementing complex behaviours,
I don't imagine one would really consider OCL anyway.
I wonder whether this discussion shouldn't be continued under the aegis of
the OCL Tools component. There is already talk in OCL Tools of
contributions of OCL-rewriting technologies for efficient evaluation, and
the initial contribution to that component is an OCL-to-Java compiler.
This would be a natural starting point for extension of EMF's code
generation.
Cheers,
Christian
Philipp W. Kutter wrote:
> Hi, Everybody.
> I read Ed and Christian's comments on my questions about implementing an
> operation in OCL carefully.
>
> The article of Christian Damus:
>
http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
> shows how to do it in a way that is easy to do, but sometime hard to
> maintain.
>
> Ed Merks explained why adding features in EMF would not be an option.
>
> Thus I'd like to start the discussion which things would have to be done
> to get one step further.
>
> 1. Request override points in the file ValidatorClass.javajet, which
> allow to restrict the changes Christian does in the article to fewer
> places. It seems Ed would not be in principle against this.
>
> 2. Write an article which show how to use the Validation framework, to
> add constraints to Ecore iself, guaranteeing that the OCL annotations
> in the article are correct. For instance, a constraint that checks that
> if a OCL "derive" is here, the corresponding ERererence is derived=true,
> volatile=true, transient=true. Or a constraint that checks that an OCL
> constraints is then as well mentioned in the corresponding ECORE
> annotation "constraints"
>
> 3. Write an article which shows how to write small actions, that create
> the different type of OCL annotations for constraints, derived features,
> and operations.
>
>
> With this in place, everybody could further extend the ideas how to use
> OCL to tailor the EMF generated code as done in Christian's paper for
> constraints, derived features, e.t.c.
>
>
> I volunteer to actively test and comment any kind of contribution in
> this direction. Unfortunately, I am not yet in the position to do it on
> my own.
>
> Best, Philipp
|
|
|
| Re: Ease of Use of OCL in EMF [message #39847 is a reply to message #39816] |
Tue, 02 October 2007 13:39 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------070208050709090108070407
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Christian,
If one wanted to use OCL to implement an operation that was intended to
have a side effect by changing the state I'm not sure that could be done
with OCL. So it's exactly the issue of implementing complex behaviors
where it would be nice to have a more general solution and why I would
like to ensure that whatever hooks we put in place will provide first
class support for OCL as well as any other language you might want to
plug in.
Given that the OCL tools component would be able to compile an OCL
expression down to Java, that would certainly provide some cool
capability on top of the interpreted OCL support you've already prototyped!
Christian W. Damus wrote:
> Hi, Philipp,
>
> Of course, I'll be more than happy to review and test any such articles as
> you describe that the community may contribute. It would be great to make
> OCL a first-class citizen of EMF-land! :-)
>
> I'm not sure that I understand Ed's concern about OCL not side-effect-free.
> For the constraints that it is intended for (even initial values, which
> imply assignment) it does a good job. For implementing complex behaviours,
> I don't imagine one would really consider OCL anyway.
>
> I wonder whether this discussion shouldn't be continued under the aegis of
> the OCL Tools component. There is already talk in OCL Tools of
> contributions of OCL-rewriting technologies for efficient evaluation, and
> the initial contribution to that component is an OCL-to-Java compiler.
> This would be a natural starting point for extension of EMF's code
> generation.
>
> Cheers,
>
> Christian
>
>
> Philipp W. Kutter wrote:
>
>
>> Hi, Everybody.
>> I read Ed and Christian's comments on my questions about implementing an
>> operation in OCL carefully.
>>
>> The article of Christian Damus:
>>
>>
> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>
>> shows how to do it in a way that is easy to do, but sometime hard to
>> maintain.
>>
>> Ed Merks explained why adding features in EMF would not be an option.
>>
>> Thus I'd like to start the discussion which things would have to be done
>> to get one step further.
>>
>> 1. Request override points in the file ValidatorClass.javajet, which
>> allow to restrict the changes Christian does in the article to fewer
>> places. It seems Ed would not be in principle against this.
>>
>> 2. Write an article which show how to use the Validation framework, to
>> add constraints to Ecore iself, guaranteeing that the OCL annotations
>> in the article are correct. For instance, a constraint that checks that
>> if a OCL "derive" is here, the corresponding ERererence is derived=true,
>> volatile=true, transient=true. Or a constraint that checks that an OCL
>> constraints is then as well mentioned in the corresponding ECORE
>> annotation "constraints"
>>
>> 3. Write an article which shows how to write small actions, that create
>> the different type of OCL annotations for constraints, derived features,
>> and operations.
>>
>>
>> With this in place, everybody could further extend the ideas how to use
>> OCL to tailor the EMF generated code as done in Christian's paper for
>> constraints, derived features, e.t.c.
>>
>>
>> I volunteer to actively test and comment any kind of contribution in
>> this direction. Unfortunately, I am not yet in the position to do it on
>> my own.
>>
>> Best, Philipp
>>
>
>
--------------070208050709090108070407
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Christian,<br>
<br>
If one wanted to use OCL to implement an operation that was intended to
have a side effect by changing the state I'm not sure that could be
done with OCL. So it's exactly the issue of implementing complex
behaviors where it would be nice to have a more general solution and
why I would like to ensure that whatever hooks we put in place will
provide first class support for OCL as well as any other language you
might want to plug in. <br>
<br>
Given that the OCL tools component would be able to compile an OCL
expression down to Java, that would certainly provide some cool
capability on top of the interpreted OCL support you've already
prototyped!<br>
<br>
<br>
Christian W. Damus wrote:
<blockquote cite="mid:fdtgq4$u1u$1@build.eclipse.org" type="cite">
<pre wrap="">Hi, Philipp,
Of course, I'll be more than happy to review and test any such articles as
you describe that the community may contribute. It would be great to make
OCL a first-class citizen of EMF-land! :-)
I'm not sure that I understand Ed's concern about OCL not side-effect-free.
For the constraints that it is intended for (even initial values, which
imply assignment) it does a good job. For implementing complex behaviours,
I don't imagine one would really consider OCL anyway.
I wonder whether this discussion shouldn't be continued under the aegis of
the OCL Tools component. There is already talk in OCL Tools of
contributions of OCL-rewriting technologies for efficient evaluation, and
the initial contribution to that component is an OCL-to-Java compiler.
This would be a natural starting point for extension of EMF's code
generation.
Cheers,
Christian
Philipp W. Kutter wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi, Everybody.
I read Ed and Christian's comments on my questions about implementing an
operation in OCL carefully.
The article of Christian Damus:
</pre>
</blockquote>
<pre wrap=""><!----><a class="moz-txt-link-freetext" href=" http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html"> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html</a>
</pre>
<blockquote type="cite">
<pre wrap="">shows how to do it in a way that is easy to do, but sometime hard to
maintain.
Ed Merks explained why adding features in EMF would not be an option.
Thus I'd like to start the discussion which things would have to be done
to get one step further.
1. Request override points in the file ValidatorClass.javajet, which
allow to restrict the changes Christian does in the article to fewer
places. It seems Ed would not be in principle against this.
2. Write an article which show how to use the Validation framework, to
add constraints to Ecore iself, guaranteeing that the OCL annotations
in the article are correct. For instance, a constraint that checks that
if a OCL "derive" is here, the corresponding ERererence is derived=true,
volatile=true, transient=true. Or a constraint that checks that an OCL
constraints is then as well mentioned in the corresponding ECORE
annotation "constraints"
3. Write an article which shows how to write small actions, that create
the different type of OCL annotations for constraints, derived features,
and operations.
With this in place, everybody could further extend the ideas how to use
OCL to tailor the EMF generated code as done in Christian's paper for
constraints, derived features, e.t.c.
I volunteer to actively test and comment any kind of contribution in
this direction. Unfortunately, I am not yet in the position to do it on
my own.
Best, Philipp
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------070208050709090108070407--
|
|
|
| Re: Ease of Use of OCL in EMF [message #39874 is a reply to message #39847] |
Tue, 02 October 2007 13:54 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Ed,
I guess what I was trying to say was just that, from an OCLer's perspective,
the question of how to specify behaviour with OCL isn't interesting. One
wouldn't think to try. :-)
I didn't mean to question the value of having pluggable support for
languages. The EMF Validation framework takes a similar approach. Did you
know that in the early days of EMF Validation Framework, I actually had a
working implementation of a "constraint language" extension that used a
Prolog-like rules engine for Java? Complete with a library of EMF-specific
primitives for definition of rules. I had a lot of fun with that.
Cheers,
Christian
Ed Merks wrote:
> Christian,
>
> If one wanted to use OCL to implement an operation that was intended to
> have a side effect by changing the state I'm not sure that could be done
> with OCL. So it's exactly the issue of implementing complex behaviors
> where it would be nice to have a more general solution and why I would
> like to ensure that whatever hooks we put in place will provide first
> class support for OCL as well as any other language you might want to
> plug in.
>
> Given that the OCL tools component would be able to compile an OCL
> expression down to Java, that would certainly provide some cool
> capability on top of the interpreted OCL support you've already
> prototyped!
>
-----8<-----
|
|
| |
| Re: Ease of Use of OCL in EMF [message #40283 is a reply to message #39847] |
Wed, 10 October 2007 07:56 |
Philipp Kutter
Messages: 306
Registered: July 2009 |
Senior Member |
|
|
Hi, Ed.
Part of QVT is an imperative extension to QVT, where you can define
sideeffects and loops.
I agree with Christian that some things, you would not want to do with
OCL only. A combination with State Machines would be more appropriate.
Which brings me to the question: Where has the EMF version of state
machines disappeared? I remember Omondo had this. Any chance of porting
this, at least as an Ecore Example to EMF 2.4?
Best, Philipp
Ed Merks wrote:
> Christian,
>
> If one wanted to use OCL to implement an operation that was intended to
> have a side effect by changing the state I'm not sure that could be done
> with OCL. So it's exactly the issue of implementing complex behaviors
> where it would be nice to have a more general solution and why I would
> like to ensure that whatever hooks we put in place will provide first
> class support for OCL as well as any other language you might want to
> plug in.
>
> Given that the OCL tools component would be able to compile an OCL
> expression down to Java, that would certainly provide some cool
> capability on top of the interpreted OCL support you've already prototyped!
>
>
> Christian W. Damus wrote:
>> Hi, Philipp,
>>
>> Of course, I'll be more than happy to review and test any such articles as
>> you describe that the community may contribute. It would be great to make
>> OCL a first-class citizen of EMF-land! :-)
>>
>> I'm not sure that I understand Ed's concern about OCL not side-effect-free.
>> For the constraints that it is intended for (even initial values, which
>> imply assignment) it does a good job. For implementing complex behaviours,
>> I don't imagine one would really consider OCL anyway.
>>
>> I wonder whether this discussion shouldn't be continued under the aegis of
>> the OCL Tools component. There is already talk in OCL Tools of
>> contributions of OCL-rewriting technologies for efficient evaluation, and
>> the initial contribution to that component is an OCL-to-Java compiler.
>> This would be a natural starting point for extension of EMF's code
>> generation.
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Philipp W. Kutter wrote:
>>
>>
>>> Hi, Everybody.
>>> I read Ed and Christian's comments on my questions about implementing an
>>> operation in OCL carefully.
>>>
>>> The article of Christian Damus:
>>>
>>>
>> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>>
>>> shows how to do it in a way that is easy to do, but sometime hard to
>>> maintain.
>>>
>>> Ed Merks explained why adding features in EMF would not be an option.
>>>
>>> Thus I'd like to start the discussion which things would have to be done
>>> to get one step further.
>>>
>>> 1. Request override points in the file ValidatorClass.javajet, which
>>> allow to restrict the changes Christian does in the article to fewer
>>> places. It seems Ed would not be in principle against this.
>>>
>>> 2. Write an article which show how to use the Validation framework, to
>>> add constraints to Ecore iself, guaranteeing that the OCL annotations
>>> in the article are correct. For instance, a constraint that checks that
>>> if a OCL "derive" is here, the corresponding ERererence is derived=true,
>>> volatile=true, transient=true. Or a constraint that checks that an OCL
>>> constraints is then as well mentioned in the corresponding ECORE
>>> annotation "constraints"
>>>
>>> 3. Write an article which shows how to write small actions, that create
>>> the different type of OCL annotations for constraints, derived features,
>>> and operations.
>>>
>>>
>>> With this in place, everybody could further extend the ideas how to use
>>> OCL to tailor the EMF generated code as done in Christian's paper for
>>> constraints, derived features, e.t.c.
>>>
>>>
>>> I volunteer to actively test and comment any kind of contribution in
>>> this direction. Unfortunately, I am not yet in the position to do it on
>>> my own.
>>>
>>> Best, Philipp
>>>
>>
>>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 18 20:19:14 GMT 2024
Powered by FUDForum. Page generated in 0.02149 seconds |
] 
Search
Help
Register
Login
Home
