Xtext Tip: Some reasons to use a separated EMF model

In a previous tip I showed how to migrate from a generated EMF model to a manually maintained one. Turning something automatic to manual sounds completely counter intuitive. We should automate more, not the contrary. However, there are some good reasons to do this. Let’s explore them:

Separation of concerns

I see the grammar is a presentation artifact. It represents the allowed inputs. However, the easiest way to input something is not always the best way to represent it for its intended purpose. The typical example, is the graph and the matrix. A matrix can perfectly represent a weighted graph. For certain computations it might be the optimal solution, but for others, a graphical representation of the graph is much better.

There is a delicate balance between the representation of grammar and metamodel. If the metamodel is too different from the grammar, many customizations must be done at the EMF level to make the grammar generate the right AST. However, if the metamodel matches exactly the grammar (like the Xtext generated metamodels), then the generation or analysis of the metamodel might become too complex or require an extra translation to another metamodel more amenable to analysis/code generation.

Customization of metamodel behavior

EMF offers its users with a lot of customizations. One can for example add custom adapters, derived fields and a lot of other interesting enhancements to EMF metamodels. Sometimes this is needed to simplify the analysis or code generation. However, adding some of these customizations require using a manually maintained metamodel. Just be careful, Xtext has a lot of features that might allow these customizations without needing a manually maintained metamodel.

Reuse an existing metamodel

Sometimes you just need to use an existing metamodel. In these cases, you just cannot use Xtext. However, it is worth noting that a generated metamodel can use a manually maintained one. The opposite, is not true. Your manually maintained metamodel, cannot use a generated metamodel.

Conclusions

Mi personal take on this is the following. Keep using the generated metamodel as long as it stays in line with your conception of the domain. When you encounter one of the aforementionned reasons, then you can use previous tip to migrate.