[qvtd-dev] M2 refactoring

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

M2 includes a major refactoring.

QVTcoreBase has been removed. QVTcore just absorbs necessary functionality.

QVTimperative is very substantially revised. The original 
re-use-the-QVTc-tooling declarative approach that predated Xtext and 
discovery of what was really needed is now replaced by a much simpler 
more assembler like model. A Mapping contains diverse Parameters and a 
sequence of diverse Statements. Domains and their Usage analysis has gone.

The revised model is easier to generate and easier to consume, but 
relies on sensible generation which QVTs2QVTi does. Human generation is 
only for test purposes.

The old analysis (at run-time for interpreted execution) of property 
access and assignments s now replaced by a notify prefix in a 
SetStatement and an ObervableStatement wrapper around an OCL evaluating 
statement. Missing notify/observe give scheduling failures. See a 
serialized.qvti or one of the test cases for examples of the new syntax.

Mappings communicate via buffers (ConnectionVariables). These are now 
explicit as distinct 'append' input parameters with distinct 'appendsTo' 
MappingCall bindings. An 'output' parameter with disciplined (unique) 
append semantics is now supported. Previously this required unpleasant 
contortions to create a new output that combines in and new and also 
passes new to further mappings.

Coming very soon a MappingCall may install rather than call a Mapping. 
An installed Mapping is installed with parameters bound either to 
constant values or connection buffers. The latter case causes the 
Mapping to be invoked automatically for each value added to the 
connection buffer. Thus for the 'allInstances' scenario, an 
'allInstances' connection is declared with an optional constant 
expression to initialize and zero or more Mappings called/installed to 
populate it,. One or more Mappings are installed to consume the connection.

All of this refactoring is motivated by support for incremental 
execution, where a change to an 'allInstances'  must invoke/revoke 
appropriate Mapping instances. This is comparatively easy once the 
connections are smart. Rather difficult when the connection support is 
obfuscated within Mappings.

---

Code using the qvtimperative packages will need significant refactoring, 
which I think I have done. Code only using the QVTc variants should see 
no change, or perhaps a bit of a performance improvement. There is some 
autogenerated QVTi AS documentation in the QVTd help. I tried to do some 
Sirius diagrams but really didn't like it.  Maybe I need to persist, or 
maybe I'll migrate the models to UML so that I can use Papyrus that 
seemed much more satisfactory when I did the QVT specification.

Since the QVTi AS model is so different I have changed the nsURI from 
2015 to 2016 so that use of incompatible tooling will be more obviously 
fatal. You will need to install OCL and QVTd M2 to develop post-M2. The 
QVTd syntax anticipates what I need for installed Mappings so the 
tooling might survive for M3, but ...

    Regards

        Ed Willink


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus