Domain Specific Modeling: Choosing a Meta-metamodel

If you want to develop external Domain Specific Languages, one of the first choices you need to make - and understand - is what meta-metamodel you're going to use and how that's going to grow with your needs. Most people start developing external DSLs by choosing a concrete syntax and/or toolkit (database tables, XML, Xtext, MetaEdit+, Microsoft DSL Tools, etc.) and that isn't always the best approach . . .

(If you're not sure what I'm talking about when I mention meta-metamodels, you might want to look here. )

If you're planning to use a third party toolkit for your DSL development (MetaEdit+, Microsoft DSL Tools, openArchitectureWare, etc), you may not need to worry about meta-metamodels at all. If the toolkit you've chosen meets your needs, you'll just use their built in meta-metamodel and can just get straight down to modeling. However, if you're building your own tools for whatever reason, you're going to want to think carefully about the meta-metamodel you use. For example, in the current version of my software product line, I use an XML concrete syntax and decided to use XSDs (XML Schema Documents) to describe my metamodels, so XSD effectively became my meta-metamodel. That wasn't a problem per se, but it did mean that all of my models are dependent on the way of thinking about the world that XSD's structure implies. For example, there was no explicit support for multiple inheritance (as in ecore), relationships were between two objects - not an arbitrary number (as in MetaEdit+), and I was limited to the type system and constraints supported by XSDs.

It just so happens that has worked out well for me, and given that both ecore and XSD are now part of the Eclipse Modeling Framework, there is support for transformation of meta models between xsds and ecore (although this article gives a good introduction to some of the issues to look out for), but it's important to understand that certain refactorings will be impossible.

For example, if you take advantage of the flexibility of the meta-metamodel in MetaEdit+ and later want to transform your metamodels into something you could use in Microsoft DSL tools, you may not be able to automate that process as Microsoft DSL tools uses a meta-metamodel that is fundamentally less expressive. If you're just using your DSLs on a project for a year or two this may not matter, but if they are part of a Software Product Line initiative you plan to build on top of, you need to think carefully both about what your meta-metamodel allows you to express and how practical it would be to transform your meta-models and models from your current meta-metamodel to a different one should you wish to change your tooling over time.

Building Your Own
You should be particularly careful if you take the perilous path of building your own meta-metamodel. You run the risks of both being unable to express everything you need to within your metamodels and of being unable to transform your metamodels and models to take advantage of another toolkit because you have fundamentally incompatible meta-metamodels.

My Approach
I've chosen to (re)build my own tooling only because none of the other tools I've come across are as good a fit to my needs - specifically most of the DSM tools aren't designed from the ground up with the idea of model reuse as part of a software product line. It's certainly possible to reuse models and metamodels across projects, but the tooling isn't generally optimized to do so (IMO). However, I'm developing on a Java stack and am impressed with tools like XText and the rest of the openArchitectureWare family, so I've decided to develop a meta-metamodel based on ecore. Basically I'm starting with the simplest subset of ecore required to meet my needs (specifically the abstract structure it supports - not the details of the methods and factories it exposes for working programatically with the meta-models in Java). In that way, I only have to support functionality that I need, when I *do* need richer functionality (say a constraint language for my meta-models - which I'm going to need pretty soon), I can just take whatever I need from EMF rather than reinventing a solution to the constraint language problem, and if I ever want to interoperate with EMF, all of my models and meta-models will be transformable.

Conclusions
If you're going to use third party DSL tooling, you don't need to worry about meta-metamodels (which is one of the many reasons to use existing tools). If you are building your own toolkit, think very carefully about both the expressiveness of your meta-metamodel and how easy it will be to transform your metamodels and models to another toolkit if you want to down the line.