DSM/SPL: Getting Practical - A Sample Metamodel

So, I've decided to continue (at least for now) with a database for storing my meta models and models using a meta-metamodel based on a subset of ecore from the EMF project. The next step is to come up with some example metamodels to see what we'd need to do to implement them and to create a storage mechanism for both the metamodels and their associated models. So I'm going to start with a set of simplistic languages for generating web applications using a subset of what I currently have in SystemsForge . . .

Our Meta-Metamodel
Just as a reminder, the basic meta-metamodel we're going to start off with is as follows: (I've added the "E" prefix as used in ecore to make it easy to distinguish the meta-metamodel concepts from similar metamodel concepts that may be used in languages for describing things like domain entities/classes. It'll also mean that all of the meta-model tables will be together if I'm looking at the underlying db which will be useful until I rebuild enough tooling on top of this to make direct viewing of the db tables unnecessary.)

Anyone familiar with ecore will know this is only a simplified subset, but I don't want to add additional elements until they're absolutely required. Also for simplicity, I've changed the Eclass.eSuperType to a 0.1 relationship instead of 0.* (i.e. I'm only supporting single inheritance). It'll simplify the initial table structure as I won't need a joining table for joining EClasses to their parents and it's consistent with my current metamodels - none of which use multiple inheritance. When I need to change that design decision it'll be a perfect chance to practice a little schema evolution (or in this case meta-schema evolution).

The Entity Model
When you're building non-trivial web applications, you often want to start with your business object model. Describing users, articles, products, categories, and the like. Let's start off with a VERY simplistic entity model and then work from there.

This is clearly a very simplistic model, but it provides a starting point to start creating functionality around and once we have the core system we should be able to easily extend it by applying transformations to the meta-metamodel to add additional entities, attributes, relationships, etc.

So, we have a sample metamodel described in a manner that's consistent with out meta-metamodel. Now we need to find a way to store this metamodel in the database. To do that, we need to create a set of tables representing our meta-metamodel. From there we can then create a set of tables for storing model statements within this metamodel (e.g. objects like Product or User or Article or Page). Once we've done that manually, we should be in a pretty good place to generalize and to write a simple script to create metamodel tables for storing model statements for any arbitrary metamodel. But I think this posting is long enough, so lets put that into another post . . .