Models & Meta Models


Assuming that models are meant to depict sets of actual instances (descriptive models) or to specify how to create new ones (prescriptive models), one would expect meta-models to do the same for sets of modeling artifacts seen as some kind of “meta” instances.


Meta-models as depictions of models (László Moholy-Nagy)

Based on that understanding, it would be possible to define meta-models with regard to models semantics and abstraction scales.

Models & Semantics

With regard to systems engineering, models’ semantics are unambiguously determined by their target: business environments or systems artifacts:

  • Models of business environments describe the relevant features of selected objects and behaviors, including supporting systems. Such models are said extensional as they target subsets in actual contexts.
  • Models of systems artifacts specify the hardware and software components of supporting systems. Such models are said intensional as they prescribe how new artifacts are to be built.
Business analyst figure maps from territories, software architects create territories from maps

Bottom-up for descriptive models, top-down for prescriptive ones

Assuming that meta-models describe subsets of symbolic artifacts, they can be characterized by the semantics of their target. Depending on frameworks and methodologies, some approaches will use a single (aka “unified”) language to cover all aspects, whereas others will deal separately with the different aspects. Taking the Model Driven Architecture (MDA)  for example, that would include platform specific (PSM), platform independent (PIM), and computation specific (CIM) models, respectively for technical, functional, and business aspects.

Modeling Languages covering technical, functional, and business concerns.

Two alternative options for the modeling of automation systems: unified language, or a meta language covering technical (e.g PSMs), functional (e.g PIMs), and business (e.g CIMs) aspects.

With model based engineering frameworks like MDA, meta-models are mostly used to support downstream models transformation  focused on designs and code; extending their use to upstream models is more challenging as they would have to straddle the divide between business and system realms. For that purpose meta-models would have to support knowledge-based transitions  between targeted businesses and their symbolic footprint in associated supporting systems.

The Semantic Matter of Meta

As mentioned elsewhere, meta-models should not be seen as models set at higher levels on linear abstraction scales, but as a qualitatively different kind of models representing cross concerns set on distinctive abstraction ladders. Whatever their semantics, such ladders can be neatly characterized by the semantic homogeneity of targeted instances:


Meta-models can target homogeneous or heterogeneous artifacts

  • Extensional meta-models (M2ext) will categorize descriptive artifacts (locations, events, actors, documents, etc.) according to considerations other than domain-specific ones, e.g regulatory or organizational contexts and interactions with systems.
  • Intensional meta-models (M2int) will categorize prescriptive artifacts (class, file, etc.) independently of implementation-specific considerations, e.g particular programming languages or operating systems.
  • Mixed meta-models (M2ext-int) will group descriptive and prescriptive artifacts under some common roof, e.g to for design patterns associating extensional categories with their symbolic surrogates.

As should be expected, the semantic nature of meta-models is to determine their use.

Purpose: What’s Meta For ?

From an enterprise architecture perspective, meta-models can serve two kinds of purposes.

Governance driven meta-models focus on management, and are consequently meant to provide user-oriented documentation:

  • Descriptive (extensional) ones are derived from CIMs, e.g to support regulatory or portfolio management.
  • Prescriptive (intensional) ones are derived from PSMs, e.g to support maintenance.
  • Mixed ones combine descriptive and prescriptive elements, e.g to define patterns or to support traceability and risk management. That can be achieved directly, e.g with requirements management tools, or through intermediate models, e.g PIMs.
Meta-models and their use

Meta-models and their use

Engineering driven meta-models are meant to support models transformation, and consequently to feed automated processes:

  • Descriptive (extensional) ones are derived from CIMs and used to support transformations into other descriptive models, e.g analytical or canonical ones.
  • Prescriptive (intensional) ones target platform specific models (PSM), their purpose is to define patterns for crossed transformation or code generation targeting different platforms.
  • Like their governance equivalent, mixed engineering meta-models are meant to provide a conceptual bridge between descriptive and prescriptive artifacts, with the difference that they have to support automated processing.

Combined with MBSE, meta-models provide a conceptual roof to be shared between models semantic (descriptive, prescriptive, or mixed) and enterprise architecture purposes (governance or engineering).

Further Reading

External Links

%d bloggers like this: