|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  regarding the OCL ImpactAnalyzer which is actually available as an example  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. ). * 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.  http://www.eclipse.org/forums/index.php/mv/msg/207755/770147/#msg_770147 <http://www.eclipse.org/forums/index.php/t/207755/>  http://git.eclipse.org/c/mdt/org.eclipse.ocl.git/tree/examples/org.eclipse.ocl.examples.impactanalyzer  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