[m2t-dev] Backend model as an EMF model

[Cédric Brun <cedric.brun@xxxxxxx>]

Hi,

One of the discussion we had at EclipseCon, was about having or not an ecore 
based representation of the backend model. 

To start this discussion on the mailling list I'll briefly evoke why I think 
this can be interesting, on the other side Sven seemed concerned with the 
computing cost and the "overhead" work of using an Ecore model for such en 
evolving code base.

Please feel free to answer and comment, this mail is just a start for the 
discussion ;)

*Testing*
One of the thing we want to emphasize with the MTL component is code quality 
and test coverage. That mean every step of the generation, from the parsing 
to the evaluation and generation should be covered by unit and non-regression 
tests. Our experience showed that using models, even for intermediate data 
like the backend model, makes it possible to serialize the expected result of 
the MTL2Backend transformation and then compare it with the actual result 
using EMF compare. 

*Serialization*
Let's consider the backend model as a "compiled" MTL model. Then we'll quickly 
want to get something similar to the Java .class file. A serialized backend 
model would be this file, and then the EMF URIConverters could also be 
leverage to manage inter-model references.

Another assets for this kind of solution is the fact that a serialized backend 
transformation split in many file will only load what is needed to generate 
and not the whole model thanks to EMF's lazy loading.

*References*
At some point we will also need some kind of links between the MTL model and 
the backend one, one obvious use case is the debugger. We'll want to display 
the MTL expressions and functions while evaluating those of the backend 
model. Using EMF it will be easy to create this kind of weaving models 
referencing the elements from one to another.

In the same kind of requirements, we'll want to trace the backend2text 
transformation to keep traçeability information, then, again, using an EMF 
model makes easy to reference elements from the backend model.	

*M2M transformations*
In the first versions the MTL2Backend transformation will, quite obviously, be 
a Java implementation, but some M2M projects provides nice perspectives in 
this domain providing features you don't have in Java, for instance 
QVT-Relational can be leveraged to provide incremental transformation and 
then avoid the coast of a huge "one process doing all the stuffs" 
transformation.

*Documentation*
Well, it may seem obvious, but having an Ecore model describing all the 
elements a backend model may contain is usefull for people like us ;)

These are just a few examples but the Eclipse modeling world is so full of 
great components that a number of other interesting, or just "fun" use cases 
mixing different tools may arise.

In a nutshell, my concern is that at some point, I have the feeling we'll want 
most of the features of EMF for this model even if it may have a computing 
cost. It seems to me that this overhead will be easier to anhihilate 
providing "higher level" optimizations.

Any comment ? Arno, did you had other specific reasons for that choice (even 
If I understand that at some point it can be easier to maintain Java 
interfaces than a Ecore model ;)


Cédric