Home » Modeling » OCL » [OCL Tools] article draft
| [OCL Tools] article draft [message #38881] |
Wed, 26 September 2007 16:12  |
 Miguel Garcia
Messages: 77
Registered: July 2009 |
Member |
|
|
While it's true that the OCL Tools component in MDT has not yet been
provisioned, I guess we may anyway keep discussing future steps for that
component. In line with that, I've posted the draft of a Technical Article,
"OCL Tools: Status and Perspectives"
https://bugs.eclipse.org/bugs/show_bug.cgi?id=204701
Its summary follows:
----------
With the availability of infrastructural support for OCL (Object Constraint
Language) provided by MDT OCL, the next step consists in simplifying the
authoring of OCL specifications with feature-rich tools, as part of the more
general task of model authoring. The capabilities of the OCL Tools project
are
described (currently they comprise an OCL -> Java compiler and a text editor
for OCL). A discussion of areas for improvement and related work follows
(refactoring of OCL expressions, detecting code smells, analyzing and
optimizing OCL expressions). These ideas for future work fall under the
umbrella of model compilers, essential elements of Model-Driven Software
Engineering.
By Miguel Garcia, Technische Universitaet Hamburg-Harburg (Germany)
and A. Jibran Shidqie, Technische Universitaet Hamburg-Harburg (Germany)
----------
Actually most of the off-list emails I've received about OCL Tools focus on
merging efforts for the OCL Text Editor. The article describes the status of
a prototype my team has developed, thus offering a base for comparison. It's
not yet an initial contribution, only the OCL -> Java compiler component is.
It's a brave new world all this model-driven tooling stuff. And I'm talking
just about the OCL-related tools. I hope we can manage as a community :)
For those OCLers attending the Eclipse Summit Europe in two weeks, perhaps
we could gather in a BOF. What do you think?
Miguel
--
Miguel Garcia miguel.garcia@tuhh.de
Institute for Software Systems (STS), AB 4-02
Technische Universitaet Hamburg-Harburg Tel: (+49)40-42878-2929
Harburger Schlossstr. 20, 21073 Hamburg Fax: (+49)40-42878-2515
http://www.sts.tu-harburg.de/~mi.garcia
|
|
|
| Re: [OCL Tools] article draft [message #39382 is a reply to message #38881] |
Fri, 28 September 2007 10:43  |
Eclipse User |
|
|
|
Originally posted by: jcabot.uoc.edu
Hi all,
I have developed (together with Ernest Teniente) a set of techniques for the
efficient (i.e. incremental) evaluation of OCL constraints. Roughly, my
techniques:
1 - inform about which constraints must be verified after executing a given
operation (depending on the kinds of modifications applied during the
operation execution). Constraints not affected by the operation can be
discarded during the verification process needed after the operation
finishes, avoiding a lot of irrelevant verifications.
2 - compute an OCL expression "exp" that can be used instead of the original
constraint in order to check that the system state is still consistent after
the operation execution,
where evaluating "exp" is much more efficient than evaluating the whole
constraint (understanding more efficient as accessing less objects during
the evaluation at run-time). Again, "exp" is a specialized version of the
original constraint that takes into account the modifications applied and
the objects affected by them in order to minimize the amount of data to
check.
These kinds of efficiency issues are not addressed in current
code-generation tools (see
http://www.lsi.upc.edu/~jcabot/research/OCLSurvey/index.html)
As part of these techniques, I also developed some transformation techniques
for OCL expressions that are able to simplify a given expression (by means
of applying a set of equivalence rules). With my transformation techniques
is also possible to change an OCL constraint from a context type A to a
context type B. The constraint body is automatically redefined in terms of
the new B context type.
For more information on both topics you can check
http://www.lsi.upc.edu/~jcabot/research.html or contact me directly.
I think that all these techniques may be of interest for this OCL Tools
component. All techniques have a preliminary prototype implementation but it
is based on MDR (for parsing the XMI file) and Dresden OCL (for parsing the
OCL expressions). I guess that there is no easy way to port this existing
source code from MDR to eclipse-based technologies.
Jordi Cabot
Open University of Catalonia
www.lsi.upc.edu/~jcabot
jcabot@uoc.edu
"Miguel Garcia" <miguel.garcia@tuhh.de> escribi
|
|
|
| Re: [OCL Tools] article draft [message #39413 is a reply to message #39382] |
Fri, 28 September 2007 11:50 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi Jordi,
This sounds very interesting! If this will ever make it to EMF based
models I suggest to make the detection of affected objects pluggable.
While many users focus mostly on the command framework I often like to
be able to work on direct model level where there are no commands.
Cheers
/Eike
Jordi Cabot schrieb:
> Hi all,
>
> I have developed (together with Ernest Teniente) a set of techniques for the
> efficient (i.e. incremental) evaluation of OCL constraints. Roughly, my
> techniques:
> 1 - inform about which constraints must be verified after executing a given
> operation (depending on the kinds of modifications applied during the
> operation execution). Constraints not affected by the operation can be
> discarded during the verification process needed after the operation
> finishes, avoiding a lot of irrelevant verifications.
> 2 - compute an OCL expression "exp" that can be used instead of the original
> constraint in order to check that the system state is still consistent after
> the operation execution,
> where evaluating "exp" is much more efficient than evaluating the whole
> constraint (understanding more efficient as accessing less objects during
> the evaluation at run-time). Again, "exp" is a specialized version of the
> original constraint that takes into account the modifications applied and
> the objects affected by them in order to minimize the amount of data to
> check.
>
> These kinds of efficiency issues are not addressed in current
> code-generation tools (see
> http://www.lsi.upc.edu/~jcabot/research/OCLSurvey/index.html)
>
> As part of these techniques, I also developed some transformation techniques
> for OCL expressions that are able to simplify a given expression (by means
> of applying a set of equivalence rules). With my transformation techniques
> is also possible to change an OCL constraint from a context type A to a
> context type B. The constraint body is automatically redefined in terms of
> the new B context type.
>
> For more information on both topics you can check
> http://www.lsi.upc.edu/~jcabot/research.html or contact me directly.
>
> I think that all these techniques may be of interest for this OCL Tools
> component. All techniques have a preliminary prototype implementation but it
> is based on MDR (for parsing the XMI file) and Dresden OCL (for parsing the
> OCL expressions). I guess that there is no easy way to port this existing
> source code from MDR to eclipse-based technologies.
>
> Jordi Cabot
> Open University of Catalonia
> www.lsi.upc.edu/~jcabot
> jcabot@uoc.edu
>
>
>
>
>
>
> "Miguel Garcia" <miguel.garcia@tuhh.de> escribió en el mensaje
> news:fde0dl$5a7$1@build.eclipse.org...
>
>> While it's true that the OCL Tools component in MDT has not yet been
>> provisioned, I guess we may anyway keep discussing future steps for that
>> component. In line with that, I've posted the draft of a Technical
>> Article, "OCL Tools: Status and Perspectives"
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=204701
>>
>> Its summary follows:
>>
>> ----------
>>
>> With the availability of infrastructural support for OCL (Object
>> Constraint
>> Language) provided by MDT OCL, the next step consists in simplifying the
>> authoring of OCL specifications with feature-rich tools, as part of the
>> more
>> general task of model authoring. The capabilities of the OCL Tools project
>> are
>> described (currently they comprise an OCL -> Java compiler and a text
>> editor
>> for OCL). A discussion of areas for improvement and related work follows
>> (refactoring of OCL expressions, detecting code smells, analyzing and
>> optimizing OCL expressions). These ideas for future work fall under the
>> umbrella of model compilers, essential elements of Model-Driven Software
>> Engineering.
>>
>> By Miguel Garcia, Technische Universitaet Hamburg-Harburg (Germany)
>> and A. Jibran Shidqie, Technische Universitaet Hamburg-Harburg (Germany)
>>
>> ----------
>>
>> Actually most of the off-list emails I've received about OCL Tools focus
>> on merging efforts for the OCL Text Editor. The article describes the
>> status of a prototype my team has developed, thus offering a base for
>> comparison. It's not yet an initial contribution, only the OCL -> Java
>> compiler component is.
>>
>> It's a brave new world all this model-driven tooling stuff. And I'm
>> talking just about the OCL-related tools. I hope we can manage as a
>> community :)
>>
>> For those OCLers attending the Eclipse Summit Europe in two weeks, perhaps
>> we could gather in a BOF. What do you think?
>>
>>
>> Miguel
>>
>>
>> --
>> Miguel Garcia miguel.garcia@tuhh.de
>> Institute for Software Systems (STS), AB 4-02
>> Technische Universitaet Hamburg-Harburg Tel: (+49)40-42878-2929
>> Harburger Schlossstr. 20, 21073 Hamburg Fax: (+49)40-42878-2515
>> http://www.sts.tu-harburg.de/~mi.garcia
>>
>>
>>
>
>
>
|
|
|
| Re: [OCL Tools] article draft [message #39445 is a reply to message #39382] |
Fri, 28 September 2007 15:10 |
Miguel Garcia
Messages: 77
Registered: July 2009 |
Member |
|
|
Jordi,
The techniques in question are definitely of interest for the OCL Tools
community: both "backstage processing" as well as "user knobs" are required
to offer useful, advanced, OCL tools.
Right away I want to mention that porting from other OCL libraries to MDT
OCL may in fact be *not* that difficult, in that the existing OCL Tools
infrastructure takes care of providing OCL ASTs ready for manipulation. I
want to believe that your work (incrementalization, context change) and
other processing tasks that manipulate OCL ASTs can be encapsulated in their
own components, taking OCL ASTs as input and producing OCL ASTs as output.
OK, I also see that your algorithms, besides a compile-time activity, also
have a run-time aspect, and that Java code to achieve such behavior needs to
be generated (i.e., either EMF CodeGen has to be extended or the code
generated by the OCL -> Java compiler has to be extended).
There is as of now no infrastructure in the OCL compiler for such
"customizable codegen" (beyond writing custom JET templates for pre-defined
hookpoints in yet other JET templates). I'm not fully familiar with the area
of "weaving compilers" but perhaps some OCLer can jump in with pointers on
this topic.
In any case, if there are time constraints from your side you might consider
offering this topic for a grad student to carry out, perhaps we can provide
those students looking for interesting topics with more than a problem
statement (in your case, you've already described your techniques in
publications, thus making viable for someone else to take on the porting
task).
A project worth pushing forward.
Regards,
Miguel
--
Miguel Garcia miguel.garcia@tuhh.de
Institute for Software Systems (STS), AB 4-02
Technische Universitaet Hamburg-Harburg Tel: (+49)40-42878-2929
Harburger Schlossstr. 20, 21073 Hamburg Fax: (+49)40-42878-2515
http://www.sts.tu-harburg.de/~mi.garcia
"Jordi Cabot" <jcabot@uoc.edu> wrote in message
news:fdils3$nqs$1@build.eclipse.org...
> Hi all,
>
> I have developed (together with Ernest Teniente) a set of techniques for
> the efficient (i.e. incremental) evaluation of OCL constraints. Roughly,
> my techniques:
> 1 - inform about which constraints must be verified after executing a
> given operation (depending on the kinds of modifications applied during
> the operation execution). Constraints not affected by the operation can be
> discarded during the verification process needed after the operation
> finishes, avoiding a lot of irrelevant verifications.
> 2 - compute an OCL expression "exp" that can be used instead of the
> original constraint in order to check that the system state is still
> consistent after the operation execution,
> where evaluating "exp" is much more efficient than evaluating the whole
> constraint (understanding more efficient as accessing less objects during
> the evaluation at run-time). Again, "exp" is a specialized version of the
> original constraint that takes into account the modifications applied and
> the objects affected by them in order to minimize the amount of data to
> check.
>
> These kinds of efficiency issues are not addressed in current
> code-generation tools (see
> http://www.lsi.upc.edu/~jcabot/research/OCLSurvey/index.html)
>
> As part of these techniques, I also developed some transformation
> techniques for OCL expressions that are able to simplify a given
> expression (by means of applying a set of equivalence rules). With my
> transformation techniques is also possible to change an OCL constraint
> from a context type A to a context type B. The constraint body is
> automatically redefined in terms of the new B context type.
>
> For more information on both topics you can check
> http://www.lsi.upc.edu/~jcabot/research.html or contact me directly.
>
> I think that all these techniques may be of interest for this OCL Tools
> component. All techniques have a preliminary prototype implementation but
> it is based on MDR (for parsing the XMI file) and Dresden OCL (for parsing
> the OCL expressions). I guess that there is no easy way to port this
> existing source code from MDR to eclipse-based technologies.
>
> Jordi Cabot
> Open University of Catalonia
> www.lsi.upc.edu/~jcabot
> jcabot@uoc.edu
>
>
>
>
>
>
> "Miguel Garcia" <miguel.garcia@tuhh.de> escribi
|
|
|
Goto Forum:
Current Time: Sun Nov 10 01:30:03 GMT 2024
Powered by FUDForum. Page generated in 0.03057 seconds |
] 
Search
Help
Register
Login
Home
