Metamodel
A metamodel is the model of a model: it defines which elements, relationships and rules are allowed in a model. Metamodels play the same role for models as a grammar does for languages — they make models formally unambiguous and thus machine-processable, for example for validation and code generation.
What does a metamodel define?
A metamodel answers three questions about a modeling language:
- Concepts: Which kinds of elements exist? (e.g., state, transition, event)
- Relationships: How may elements be connected to each other, with which cardinalities? (e.g., a transition connects exactly one source state to exactly one target state)
- Rules (constraints): Which additional conditions must a valid model satisfy? (e.g., every automaton has exactly one initial state)
Only this formal definition turns a model into more than a drawing: a tool can check whether a model is valid, and a generator can rely on which structures it will find.
A concrete example
A simple metamodel for state machines could look like this:
| Concept | Properties | Relationships |
|---|---|---|
| StateMachine | name | contains 1..* States, 0..* Transitions, 0..* Events |
| State | name, isInitial | — |
| Transition | guard (optional) | exactly 1 source State, exactly 1 target State, 1 triggering Event |
| Event | name | — |
Plus one rule: every StateMachine contains exactly one State with isInitial = true.
A concrete model — say, a traffic light controller with the states Red, Red-Yellow, Green, Yellow and transitions between them — is then an instance of this metamodel. The metamodel itself says nothing about traffic lights; it only says what a well-formed state machine is. Exactly the same relationship holds between a Java program and the Java grammar.
Meta levels: from object to MOF
The Object Management Group (OMG) organizes these relationships in a four-layer architecture:
- M0 — the real runtime objects (the concrete traffic light at the intersection),
- M1 — the model (the state machine of the traffic light controller),
- M2 — the metamodel (the definition of what a state machine is; the UML metamodel also lives on this level),
- M3 — the meta-metamodel: the Meta Object Facility (MOF), the language in which metamodels are described. The MOF describes itself; no further levels are needed.
In tooling practice, Ecore from the Eclipse Modeling Framework (EMF) frequently takes on the role of the M3 level — a pragmatic de facto standard that many modeling tools align with.
Metamodels in practice
Explicit metamodels are the foundation of every serious modeling toolchain. Whoever designs a domain-specific language (DSL) first designs its metamodel — from it, language workbenches such as Xtext or JetBrains MPS derive editors, live validation and the typed model API for generators. Metamodels are also the key when integrating heterogeneous tools: only when both sides formally expose their concepts can models be transformed and reconciled without loss. Practical experience shows: the hard part is rarely the technology, but the clean carving out of the domain concepts — a metamodel is always also a clarification of terminology within the team.