Sunday, December 19, 2010

Grammar and Template's Role in Modeling

Grammar and Template are two essential components for model-driven reflection and generation.

Note that this article relates to high-level, abstract view of Model Driven Engineering. And it's going to be boring and theoretical, but I have to write it down so I won't forget. ;-)

With a Grammar, you can 'read' or understand or introspect or reflect or parse or deconstruct or reverse-engineer or (in a way) deserialize... from a concrete artifact, and generating a model as an output.

With a Template, you can 'write' or generate or create or build or construct or (in a way) serialize... an artifact as an output, from a model.

The third element which is required by both processes, is the metamodel. It's actually a prerequirement.

These three are the core ingredients for model driven engineering.

Now to actually bake these ingredients, you need equipment, the tools. Fortunately these are all provided by Eclipse Modeling Framework projects.

The first ingredient you need to create is the metamodel, which usually means an Ecore model. In later phases, the metamodel is not always the first artifact, it can be a generated artifact.

To read an artifact, you need a tool, the parser, that can read your metamodel. And create a grammar in a language that the tool understands. An example is Xtext with its Xtext grammar language. And Xtext, of course, understands Ecore models as the metamodel.

Given: metamodel + grammar --> Xtext, you will get a Parser.

A parser is an artifact reader that is customized to your grammar and metamodel. Given concrete artifact(s) as input, it generates a model as output.

To write to an artifact, you need a tool, that is a generator, that can read your metamodel. Then you create a template in a language that the generator understands.

Such a generator is Eclipse M2T Xpand, and its Xpand language.

Given metamodel + model + template --> Xpand, you get: (textual) artifact!

Actually, the concrete examples above assume one thing: the other metamodel (the "artifact") is a filesystem with text files.

In an abstract way, all transformations are model-to-model (M2M) transformations, hence conceptually requiring two metamodels, not just one. M2T (generation) and T2M (parsing) are conceptually M2M where one side is textual files, or "textual metamodel".

No comments:

Post a Comment

 
Copyright 2009 Spring vs Java EE Web Dev. Powered by Blogger Blogger Templates create by Deluxe Templates. WP by Masterplan