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 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 
    • an actual support for ExpressionLabel's lacks the automatic updates, which had 
      been many times requested already (e.g. [3]).
  • VisualEffect's 
    • 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 offer help 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. 
[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
Version: 2012.0.1901 / Virus Database: 2109/4697 - Release Date: 12/22/11


Back to the top