Skip to content

Model-Driven Engineering Terminology

Consistent use of terminology is important - particularly so in scientific manuscripts (e.g. publications, reports, dissertations). Having reviewed a fair number of manuscripts that use loose/inconsistent terminology, I thought it'd be useful to summarise my current understanding of core concepts and terms such as models, metamodels, graphical/textual/programming/modelling languages etc., mainly for the benefit of my students.

Models and Metamodels

  • A model is a description of a system of interest. With regard to the purpose for which models are constructed, they can be classified into:
    • Descriptive: describe systems that exist (the floor-plan of an existing building).
    • Prescriptive: describe systems that do not exist yet (e.g. the blueprint of a building yet to be built). Prescriptive models can be further placed in the following continuum:
      • Models as Sketches: Capture sufficient information to facilitate informal discussion (e.g. free-form whiteboard drawings).
      • Models as Blueprints: Capture sufficient information for engineers to develop a system based on them (e.g. UML class/sequence diagrams missing the behaviour of operations).
      • Models as Programs: Precise and complete enough to drive automated system implementation/property verification with limited further human input (e.g. Simulink/Stateflow diagrams).
  • A metamodel is an object-oriented specification of the abstract syntax of a language.
    • Metamodels are specified using metamodelling languages such as Ecore and MOF.
    • The terms metamodel and abstract syntax can be used interchangeably.
  • Models conform to metamodels or are instances of metamodels.
    • They do not implement metamodels, depend on metamodels, use metamodels etc.
  • Models consist of model elements.
  • Model elements are instances of types defined in metamodels.
    • A model can conform to multiple metamodels by containing instances of types defined in said metamodels.

Textual and Graphical Languages

  • From a technical viewpoint, there is no such thing as a textual or a graphical language. Syntax-wise a language consists of:
    • an abstract syntax (metamodel)
    • zero or more concrete syntaxes (which can be textual, diagrammatic, tabular, tree-based, hybrid etc.)
  • Still, terms like graphical language and textual language are used in practice as a shorthand for a language with a default/dominant graphical/textual concrete syntax. I will use such shorthands below for convenience.

Modelling and Programming Languages

  • From a technical perspective, there is no clear distinguishing line between modelling languages and programming languages.
    • Most of the languages we would intuitively recognise as programming languages (e.g. Java, C++) have a dominant textual syntax and are Turing-complete. On the flip side, most of the languages we would recognise as modelling languages (e.g. UML, SysML, Archimate) are Turing-incomplete and have a dominant graphical syntax. However, there are also graphical Turing-complete languages (e.g. BPEL) as well as Turing-incomplete textual languages (e.g. SQL 92).
    • If we were to extend (what we would intuitively recognise as) a modelling language for designing state machines with support for specifying transition guards and entry/exit state actions would it become a programming language? If so, exactly at what point? If the tipping point is when it becomes Turing-complete, then we have just invented another synonym (i.e. Turing-complete ≡ programming and Turing-incomplete ≡ modelling). I don't think it is particularly useful to invent synonyms.
  • In my view, the main difference between the modelling and programming activities is related to the intention of the engineer in terms of whether or not they aim/expect to produce an executable artefact as a direct result of their effort.
    • With this in mind, a modelling language could be defined as a language that is predominantly used without the intention of producing an executable artefact (e.g. for understanding, exploration, communication purposes), while a programming language as a language that is most commonly used with the intention of (also) producing an executable artefact.
    • Under this definition, UML is intuitively a modelling language because arguably, most engineers use it without the expectation of producing an executable artefact out of their UML diagrams, while Java is a programming language because most engineers use it with the expectation of producing an executable artefact from their Java (text) files. Still, I sometimes use Java to define a set of classes, their properties and relations, just so that I can get a better understanding of a domain (without expecting to ever execute this Java code) and other times, I end up generating executable code from what we would intuitively recognise as a model (e.g. a UML class diagram).