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).