Transformation Based MetaModeling (what to do when your DSLs change)
One approach is to make the changes to your metamodel and then use versioning to associate new models to the new version of the DSL and perhaps you manually write scripts to migrate your old models to the new version at some point in the future.
Another approach is to change your metamodel and then run a tree comparator that compares the two metamodels and tries to determine the difference between them, automatically using that information to try to generate migration scripts for your models.
However, it's always seemed to me that an easier approach might just be to change your metamodel by describing the changes and applying those transformations to both the metamodel and the models at the same time. For instance, in the above case, you'd select the attribute and choose a "transform attribute to class" transformation and it'll automatically make the necessary changes to both the metamodel and all models within the metamodel (think migrations where you transform both the schema and the data contained within the tables). Of course, not all transformations can be completely automated, but by describing schema evolution in terms of transformations, creating tooling now becomes the fairly straightforward process of coming up with and then implementing code to apply different transformations rather than the much trickier problem of comparing metamodels (which never works if you apply a "rename" transformation unless you have some kind of element identity independent of the strings used to name your metamodel elements) or the much less attractive proposition of having to manually upgrade your models from one version to another using hand written scripts.
Thoughts?



There are no comments for this entry.
[Add Comment]