Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] ImpactAnalyzer from MDT OCL examples - possible use in GMF-T 
Hi,
I see one important aspect in the integration of the IA with compiled OCL. Partial evaluation of expressions plays an important role in the IA. As long as the interpreter remains in the code base (which I assume since most of its classes have probably been visible to others and therefore cannot easily be removed), the IA should just continue to work, whether compiled or interpreted is used to evaluate expressions.
It would be very difficult to change the partial evaluation required by the IA to partially evaluate compiled expressions. It would require a capability to inject variable values into the evaluation context, and it depends on a specific exception to be thrown when a VariableExp is evaluated without the respective variable being in the context. This kind of support would probably require some careful and tricky preparation for the compilation.
The good news therefore was in the first paragraph: I don't expect the IA to be affected by whether compiled or interpreted evaluation is used outside of the IA. 

Best,
-- Axel

On 12/23/2011 7:15 PM, Ed Willink wrote:

Hi Michael

This all seems interesting. It will be good to have intra-Eclipse
examples. You seem to be actually doing what I had only vaguely considered:

[When using the IMP editor, outline labels merited a smart refresh.
Unfortunately the Xtext editor does total refresh regardless. Maybe once
we learn how to use OCL equations we can have a new kind of Outline
fragment. Also in the main editor mappings there are opportunities for
incremental update. Maybe OCL equations could even define the primary
equations that the Xtext team very reasonably regard as too complex to
do other than by total refresh.]

I understand that GMF tooling is rejoining the train, so your use of the
Impact Analyzer as examples plugins is presumably a major problem that
would vanish if we promote the IA to non-examples, as originally planned
for Juno.

The current OCL execution practice relies on run-time compilation and
then interpretation which makes me uncomfortable performance-wise. I
think it's worth a try to promote the new OCL run-time (the
examples.domain and examples.library plugins). This can eliminate the
run-time compile costs and improve execution speed by 5 to 50 fold. The
new run-time should resolve the longstanding specification accuracy
issues. There is no way the rest of the pivot support can be ready for
Juno promotion. I think this will lead to a minor limitation in that
there will be no support for oclType() without the examples plugins, but
oclType() doesn't work in the old code anyway.

This will give two modes of operation.

A) ocl.ecore and IA installed at run-time and compile-time
Existing functionality with manual activation; just a package
renaming/tidy up of the existing IA examples plugins.

B) ocl.ecore and IA and examples.domain and examples.library installed
at run-time
plus all OCL Examples and Acceleo installed at compile time
OCL 2 Java generation occurs at genmodel-time and IA is hooked up
automatically

If you're planning a substantial suite of OCL equations, you may find
that Complete OCL is more suitable than OCLinEcore, since it will allow
an aspect-oriented style in which each concern can be in a separate OCL
document complementing the primary model.

So: work to do for M6

1) Review all IA plugins to ensure release quality and carefully review
public APIs.
2) Prepare examples.domain and examples.library plugins for review.
3) Review examples.domain and examples.library plugins to ensure release
quality and carefully review public APIs.
4) Determine how to hook up the IA.
5) Upgrade the OCL 2 Java code generator to provide the hook up the IA
automatically.

If you can do 1) and 4), I'll try to get 2) done.

Regards

Ed Willink

On 23/12/2011 16:33, Michael Golubev wrote:

Hello,

There was a recent discussion at the forum [1] regarding the OCL
ImpactAnalyzer which is actually
available as an example [2] for MDT OCL in Indigo.

I would like to note that GMF Tooling team is actually considering the
use of this
component in the generated diagram editors.
We see the following areas where the usage of the ImpactAnalyzer may
be beneficial:

  * Diagram labels defined by the OCL expressions
      o an actual support for ExpressionLabel's lacks the automatic
        updates, which had
        been many times requested already (e.g. [3]).
  * VisualEffect's
      o the bindings of the graphical properties for the diagram
        element into the
        OCL-defined function of corresponding semantic element (e.g.,
        UML Class name
        rendered in italic font if the Class is abstract)
  * OCL defined audits and metrics

All these scenarios require an external component that manages the
incoming changes
in the semantic model and updates the diagram editor automatically. We
believe that
ImpactAnalyzer may be a very suitable for our needs and would allow us
to make visual
editors configurable with OCL in a scalable way.

Thus the GMF Tooling is very interested in the discussion about the
promotion of the
ImpactAnalyzer into the plugin inside the MDT OCL. In order to support
this discussion,
we would like to offerhelp with our resources to review the code for
the impact analyzer, and comment on:

  * bugs that should be fixed
  * API that should be improved
  * overall integration

We are going to work on that during January in order to be in position
to make a decision before Juno API freeze.

[1]
http://www.eclipse.org/forums/index.php/mv/msg/207755/770147/#msg_770147
<http://www.eclipse.org/forums/index.php/t/207755/>
[2]
http://git.eclipse.org/c/mdt/org.eclipse.ocl.git/tree/examples/org.eclipse.ocl.examples.impactanalyzer

[3] http://www.eclipse.org/forums/index.php/m/652004/

Regards,
--

*Michael "Borlander" Golubev
*Eclipse Committer (GMF, UML2Tools)
at Montages Think Tank, Prague, Czech Republic

Montages AG
Stampfenbachstr. 48, CH-8006 Zürich

tel: +41 44 260 75 57
mob: +420 602 483 463




_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev


No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2012.0.1901 / Virus Database: 2109/4697 - Release Date: 12/22/11





_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev

Back to the top