Models, Meta Models and Meta-Meta Models, oh My!

A Basic Metamodel
Lets say I want to represent a user called Steve Kelly. The model in this case is Steve. But I need some structure for storing the information about users (whether that be a database schema, an XSD describing an XML schema, a grammar description in Extended-BNF or some other format). That would be my meta model.

In a database schema, it could be described with:

An XSD might be:

This would then allow me to create and validate XML documents containing users with a FirstName and LastName property - both of type: String.

You could also come up with some kind of abstract notation. Perhaps:

But over time you're going to want to create many of these meta-models. You'll have one for users, another for products, another for views and another for controller actions. What we need is a meta-meta model for describing what a valid meta-model is.

A Basic Meta-Metamodel
Well for our use case to date, all we need is that a Class has 0.* Attributes - each of which have exactly one DataType (1.1). Using the same abstract notation, we could maybe write this as:

Cool - so now we have a general way of talking about the structure of our metamodels. As you start to work with code generation this becomes really important as it allows you to work with arbitrary model structures in a consistent way.

Extending the Meta-Model
Well, that's fine, but what happens if I want to add addresses to my user? Now I need the concept of Relationships along with containment (is the related item composed within the parent or just associated to it - generally if you delete an item, any composed items will be deleted although associated ones won't be) and some constraints in terms of lower and upper bounds (0.1, 0.*, 1.1, 1.*, 2.5, etc.). So I might now describe something like:

and my meta-metamodel now has:

I've actually chosen to follow the ecore (EMF metamodel) from the Java/Eclipse world as if I *do* end up using third party tooling it'll probably be on a Java/Eclipse stack. Microsoft also has a meta-metamodel for their DSL tools. It also has the concepts of Classes, Relationships and Types, although they are described slightly differently, and its meta-metamodel also includes concrete syntactic information relating to the visual modeling tool - stuff like shapes and connectors. In fact, all modeling tools have some kind of meta-metamodel. Most of them are recognizably similar to the ecore (because there are only so many ways to really describe the structure of a meta-model), although MetaEdit+ has a superior but unusual meta-metamodel that allows relationships to be associated to multiple classes - not just two. It's a more powerful model, but it's possible to model most use cases without the extra sophistication of the MetaEdit+ approach.

So, we've looked at the structure of the meta-metamodel with some very basic constraints (lower and upper bounds for references). Next we might want to add support for inheritance.

Adding Inheritance

There are a number of ways we *could* add inheritance. In EMF ecore models, you simply add the concept of an eSuperType, where an eClass can have 0.* eSuperTypes (yep - multiple inheritance). So perhaps we could extend our concept of a class to reflect this:

And now we have a fairly usable meta-metamodel. We're probably going to need to have a richer set of constraints than just basic data types and upper and lower bounds for relationships (is FirstName required? What are the maximum and minimum number of characters a FirstName can contain, etc), but lets treat that as a refinement. Firstly it's time to start to create some actual metamodels and then we can always extend the meta-metamodel as and when required.

So, our candidate metamodel (basically a subset of ecore):