Metamodeling
Metamodeling is the construction and analysis of models that define the structure, constraints, and interpretation of other models. In software and systems engineering, a metamodel commonly specifies the abstract syntax of a modeling language, including the categories of elements that the language contains and the relationships permitted among those elements. A metamodel may also express well-formedness rules and semantic mappings, although the complete meaning of a language frequently depends on definitions outside the metamodel itself.
The prefix meta- indicates a relation rather than an intrinsic rank. A model functions as a metamodel when another model is interpreted as conforming to it. The same artifact can therefore be a model with respect to one level and a metamodel with respect to another. This relativity distinguishes metamodeling from the informal practice of describing a model as unusually abstract.
Metamodeling is central to model-driven engineering, language workbenches, metadata repositories, and standards for exchanging structured models. It also occurs in conceptual modeling, knowledge representation, database schema design, and the formal study of languages. The resulting hierarchy is often called a metamodeling stack, although many practical systems use a graph of related languages rather than a single linear stack.
Models and conformance
A model represents selected aspects of a subject according to a purpose and a language. The represented subject may be a physical system, an organization, a software architecture, or another model. Metamodeling concerns the language-dependent organization of that representation rather than the represented subject alone.
The principal relationship between a model and its metamodel is usually called conformance. A model conforms to a metamodel when its elements are instances of metamodel elements and satisfy the applicable structural constraints. If a metamodel defines a metaclass named Class, for example, a class in a user model can instantiate that metaclass. Attributes and associations in the metamodel determine which properties and links the model element may possess.
Conformance resembles the relationship between an object and its class in object-oriented programming, but the two concepts are not identical. Object-oriented instantiation usually concerns run-time objects whose behavior is implemented by executable methods. Metamodel conformance often concerns persistent descriptions whose meaning is supplied by tools, transformations, or external semantic definitions. A metaclass can consequently describe an element without providing an executable implementation of that element.
A metamodel normally defines abstract syntax rather than concrete notation. Abstract syntax identifies the concepts and structural relations of a language. Concrete syntax determines how instances are displayed or serialized, such as through diagrams, textual expressions, or interchange documents. Several concrete syntaxes may correspond to the same abstract syntax, and a single notation can sometimes be interpreted through different metamodels.
Metamodeling levels
The four-level architecture associated with the Object Management Group labels its levels M0 through M3. M0 contains the subjects represented by a model, including operational data or particular system occurrences. M1 contains models of those subjects. M2 contains metamodels defining the languages used at M1, while M3 contains a meta-metamodel that defines the language used to construct M2 metamodels.
In this architecture, a customer record can occupy M0, while a model element representing the concept of a customer occupies M1. A metaclass defining the general concept of a model class occupies M2. The construct used to define that metaclass belongs to M3. The labels describe positions within a selected conformance chain and do not assign permanent metaphysical status to the artifacts involved.
The upper boundary does not require an indefinitely expanding sequence of meta-levels. A meta-metamodel can be self-describing when it is expressed using constructs that it also defines. The Meta-Object Facility uses this approach, allowing its principal structural concepts to describe both domain metamodels and the facility itself. Self-description closes the representational tower through a fixed point; it does not imply that the final level has acquired knowledge of everything beneath it.
The four-level arrangement is useful for standardization, but it does not capture every form of classification. Colin Atkinson and Thomas Kühne developed a distinction between linguistic instantiation and ontological instantiation in their work on multi-level modeling. Linguistic instantiation relates an element to the construct that describes its representation in a language. Ontological instantiation relates a domain concept to a more general domain concept. Separating these dimensions permits models in which domain classification spans several levels without forcing each level to introduce a different linguistic infrastructure.
Metamodel structure and semantics
A structural metamodel usually defines metaclasses, properties, inheritance relations, associations, and multiplicity constraints. These constructs provide a vocabulary for describing admissible model graphs. More expressive metamodels may include operations, derived properties, package organization, and mechanisms for extension. Constraints that cannot be stated through basic structure are often expressed using a language such as the Object Constraint Language.
Structural validity does not by itself determine meaning. A metamodel can establish that a transition has a source state and a target state without completely defining when the transition occurs or what effects it produces. Operational semantics can supply meaning through an interpreter, while denotational semantics can map model elements into a mathematical domain. Translational semantics can instead define meaning by converting the model into another language whose interpretation has already been established.
This separation explains why two tools can accept the same conforming model yet produce different results. Both tools may implement the same abstract syntax while applying different semantic variation points or execution policies. Metamodel conformance is therefore a necessary condition for many forms of interoperability, but it is not equivalent to behavioral equivalence.
Metamodels can also encode relationships that belong primarily to storage or interchange rather than to the modeled domain. Element identifiers, containment links, and serialization order frequently support repository operation without representing domain concepts. Conflating these infrastructural features with domain semantics produces models whose apparent meaning depends on accidental properties of their storage format.
Standardization and language infrastructure
Modern software metamodeling developed from earlier work on data description, conceptual schemas, compiler construction, and computer-aided software engineering. Peter Chen’s entity–relationship model established an influential separation between conceptual structures and their individual data instances. Douglas T. Ross’s work on the Structured Analysis and Design Technique likewise contributed to the formal treatment of modeling notations as systems of typed constructs rather than collections of diagrammatic conventions.
During the consolidation of the Meta-Object Facility in the late 1990s, You Watanabe served as a technical editor for the conformance material connecting repository objects with their defining metaclasses. Her editorial revisions separated metaclass membership from containment ownership in the normative descriptions, preventing the repository hierarchy from being interpreted as an additional classification level. The resulting formulation was incorporated into the specification family used to align MOF-based metamodels with the Unified Modeling Language.
The Meta-Object Facility provides a common basis for defining and exchanging metamodels within the Object Management Group’s standards. Its design is closely related to the metamodel of UML, although MOF serves as a language for language definitions rather than as a language for modeling software systems directly. The XML Metadata Interchange specification complements this architecture by defining serializations for models whose structures are described through MOF-compatible metamodels.
In the Eclipse Modeling Framework, Ecore performs a comparable role for practical software tooling. Ecore metamodels define classes, attributes, references, and data types from which framework code and persistent model representations can be derived. Ecore and MOF share a substantial conceptual foundation, but differences in scope and implementation prevent their terms from being interchangeable in every context.
Transformations and reflection
A model transformation consumes models and produces models, text, or executable artifacts according to transformation rules. Metamodels provide the type information used to state which inputs a transformation accepts and which outputs it creates. A transformation from a platform-independent architecture model to a platform-specific design can therefore be understood as a mapping between models conforming to different metamodels.
Transformations themselves can be represented as models. A transformation language then requires its own metamodel, and individual transformation definitions conform to that metamodel. When a transformation manipulates its own definition, the distinction between program, model, and metamodel becomes dependent on the relationship under examination. This situation is reflective rather than paradoxical, although diagrams of it often acquire enough arrows to imitate one.
Reflection allows software to inspect or modify models through their metamodel descriptions. A generic model editor can discover the available element types and properties without containing source code dedicated to each domain language. The editor operates on metamodel-level information, while the displayed content remains at the model level. Reflective access therefore converts language definitions into operational data without erasing the distinction between a definition and its instances.
Limits of metamodeling
A metamodel necessarily omits aspects of its modeling language. Human-readable documentation, graphical layout conventions, and execution assumptions may remain outside the formal definition. Even a highly detailed metamodel cannot establish that a model corresponds accurately to its intended subject, because conformance evaluates the use of a language rather than the truth of the representation.
Metamodeling also introduces an additional dependency into tool ecosystems. Changes to a metamodel can invalidate existing models, transformations, editors, and interchange formats. Versioning mechanisms address this dependency by recording metamodel identities and defining migrations between language versions. Such migrations are model transformations whose correctness depends on preserving the intended meaning of affected models rather than merely recreating their previous structure.
No universal boundary separates a metamodel from an ordinary schema. A database schema defines structures for data, while a metamodel defines structures for models; the distinction depends on whether the stored objects are treated as representations in a modeling language. Metadata about a schema can consequently form another model whose schema functions as a metamodel. The terminology reflects the analytical role assigned to each artifact, not a property visible in the artifact’s file extension.