MDE – Model Driven Engineering – reference guide

While I’m getting a lot of questions about MDE, MDA, MDD, DSL, metamodels, etc. I thought it would be a good time to give a short overview of Model-Driven Engineering and its related concepts. I’ve managed to do it in about 350 words. However, if you have no experience with model driven software development it can be a bit dense. That’s why I have added a glossary below, explaining every used term in more detail (that took another 2000 words… 😉 ).

When trying to explain so many concepts you definitely are going to make errors. So, please report them in the comments. I’m of course also happy to receive questions!

MDE explained

Model Driven Engineering, MDE for short, aims to raise the level of abstraction in program specification and increase automation in program development. The idea promoted by MDE is to use models at different levels of abstraction for developing systems, thereby raising the level of abstraction in program specification. An increase of automation in program development is reached by using executable model transformations. Higher-level models are transformed into lower level models until the model can be made executable using either code generation or model interpretation.

A model is specified in some model notation or model language. Since model languages are mostly tailored to a certain domain, such a language is often called a Domain-Specific Language (DSL). A DSL can be visual or textual. A sound language description contains an abstract syntax, one or more concrete syntax descriptions, mappings between abstract and concrete syntax, and a description of the semantics. The abstract syntax of a language is often defined using a metamodel. The semantics can also be defined using a metamodel, but in most cases in practice the semantics aren’t explicitly defined, they have to be derived from the runtime behavior.

A model specified using a DSL is called a Domain-Specific Model (DSM). A complex system is usually described using multiple DSMs specified in different DSLs. These models refer to each other and have to be combined when executing them. Because complex systems ask for a lot of DSMs to model them, it is important to structure the modeling space.

As in each software engineering approach quality is an important aspect of MDE. Quality in MDE can be checked, or ensured, with three different techniques: model validation, model checking, and model-based testing.

MDE is often confused with Model Driven Architecture (MDA). MDA can be seen as OMG’s (Object Management Group) vision on MDE. The MDA focuses on the technical variability in software, i.e. how to specify software in a platform independent way. The OMG holds a trademark on MDA. I’ve explained the basic concepts of MDA in a previous post. Another term in this field trademarked by the OMG is Model Driven Development (MDD).



Model transformation

QVT – Query/View/Transformation

Code generation

Model interpretation

Model language

DSL – Domain-Specific Language

Domain-Specific Visual Language

Abstract syntax

Concrete syntax



MOF – Meta Object Facility

DSM – Domain-Specific Model


Modeling space

Model validation

Model checking

MBT – Model-based Testing


The term "model" is derived from the Latin word modulus, which means measure, rule, pattern, example to be followed. A formal definition of model can be: Any subject using a system A that is neither directly nor indirectly interacting with a system B, to obtain information about the system B, is using A as a model for B.

This definition is fairly generic, we can describe the concept model more precise by presenting three criteria for a model. Stachowiak describes that a model needs to meet three criteria otherwise it is not a model:

  • Mapping: a model is based on an original. The original (system) might be something yet to be build or it may remain completely imaginary.
  • Reduction: not all the properties of the subject are mapped onto the model, but the model is somehow reduced. However, a model must mirror at least some properties of the subject. 
  • Pragmatic: a model needs to be usable in place of an subject with respect to some purpose.

More on different model roles and usage…

Model transformation

Transforming a model into another model means that a source model is transformed into a target model based on some transformation rules. Different methods can be used for defining the transformation rules. In 2007 the OMG released QVT, a model transformation language specification.

We can make a distinction between transformations (or refinements) adding computational information and transformations adding technology (or platform) information. The first case needs human intervention, the latter can be done automatically if we feed the transformation with the information of the platform.

If we, for example, want to transform a business process model into an lower level format, we have to add all kind of information: rules, data, presentation, etc. If we want to transform a data model into Java code (which can be considered as another model) we can define an automatic transformation based on the information of the platform we have (Java).

Although both examples are transformations between abstraction layers, they differ in executability. That’s why we have to distinguish between automatic and manual transformations.

Another transformation type I want to highlight is a change propagating transformation. Change propagating transformations support the non-destructive propagation of changes from the source model to the already existing target model. So, instead of rerunning the full transformation, only the changes are propagated to the target model. Using a change propagating transformation enables the replacement of a component at runtime or with preservation of runtime data. An example of such a transformation is updating the structure of a database (the target model) based on an object model (the source model) without losing data. This, of course, isn’t possible for every change.

More on different model transformation approaches…

QVT – Query/View/Transformation

As model transformation is a critical component in the MDA the OMG has been working on a model transformation standard for a while. In 2007 the final specification of the Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification has been released. This specification, better known as QVT, defines metamodels for defining model transformation languages. The resulting languages can transform source models into target models where the source and target models may conform to an arbitrary MOF metamodel. The transformation language itself is also a model and conforms also to a MOF metamodel.

Code generation

Code generation is the act of generating source code (in a programming language like Java or C#) from a model. This can be done in various way, for example by using templates and rewrite rules or by constructing a metamodel of a programming language and defining formal transformations from the metamodel of the model to the metamodel of the programming language.

Model interpretation

Model interpretation or model execution means that we directly execute a model on an engine (or virtual machine). So, we don’t generate code or define transformations, we just put the model in a runtime environment and it executes as defined by the semantics of the model.

Model language

A model is specified in some modeling notation. Such a modeling notation is mostly referred to as a modeling language, thereby combining MDE with language theory. Since model languages are mostly tailored to a certain domain, such a language is often called a Domain-Specific Language (DSL).

DSL – Domain-Specific Language

A DSL can be defined as a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain.

The domain specificity of a language is a matter of degree. Any language has a certain scope of applicability, but some of them are more focused than others. Languages can be compared using levels based on the number of code statements needed for implementing a function point. This results in a table ranging from low level languages like natural language, machine language and assembly to high level languages which are targeted at a very specific domain (see the SPR programming languages table). Although the difference between a GPL (General Purpose Language) and a DSL is a matter of degree, we mostly consider only the more focused languages as a DSL, such as BNF, HTML or SQL.

More on Domain-Specific Languages…

More on the difference between UML and DSL…

Domain-Specific Visual Language

A DSL with a graphical concrete syntax.

More on the structure of Domain-Specific Languages…

Abstract syntax

The abstract syntax defines the concepts of a language and their relationships.

Concrete syntax

The concrete syntax defines the physical appearance of language. For a textual languages this means that it defines how to form sentences. For a graphical language this means that it defines the graphical appearance of the language concepts and how they may be combined into a model.


The semantics describe the meaning of a sentence or model specified in some language. In the context of MDE this means that the semantics of a model describe what the effect is of executing that model.


A metamodel is often defined as a model of a model. The concept of metamodeling is used as a means of language definition. Atkinson and Kühne call this linguistic metamodeling. But according to Atkinson and Kühne this "traditional" point of view on metamodeling covers only one of the two important dimensions. Besides linguistic instantiation, like student is an instance of entity, an ontological instantiation relation exists defining that student is also an instance of person. In linguistic metamodeling student and person are on the same layer, whereas from an ontological point of view person would be on a meta layer. Atkinson and Kühne call this ontological metamodeling.

So, a linguistic metamodel defines the abstract syntax of a language, while an ontological metamodel defines the semantics of a language. As said before, the semantics are almost never formally defined in current practice. They are implicitly defined by the runtime behavior of the languages.

A metamodel itself also needs to be expressed in some language. A possible language with this purpose is MOF.

More on metamodels, different types of metamodels, and metamodel hierarchies…

MOF – Meta Object Facility

MOF is a standard hosted by the OMG
. MOF can be seen as a DSL for defining metamodels. In other words: a standard for writing metamodels. While MOF itself is also expressed as a model, it is often called a meta-metamodel.

DSM – Domain-Specific Model

I mostly use DSM to refer to a Domain-Specific Model, i.e. a model specified using a DSL. However, the most common use of DSM is to refer to Domain-Specific Modeling. According to the DSM Forum DSM is defined as:

Domain-Specific Modeling raises the level of abstraction beyond programming by specifying the solution directly using domain concepts. The final products are generated from these high-level specifications. This automation is possible because both the language and generators need fit the requirements of only one company and domain. Your expert defines them, your developers use them.


In literature multi-modeling is defined as the act of combining diverse models, which can be done in two ways:

  • Hierarchical multi-modeling: hierarchical compositions of distinct modeling styles are combined to take advantage of the unique capabilities and expressiveness of the distinct modeling styles.
  • Multi-view modeling: distinct and separate models of the same system are constructed to model different aspects of the system.

When I refer to multi-modeling I mean multi-view modeling as defined above. While in multi-modeling a complete system is described using multiple interdependent DSMs, the integration of these DSMs is needed to synthesize the described system.

More on multi-modeling…

Modeling space

A complex system is described with a lot of models, modeling different parts of the system. We call all these models together the modeling space. It is important to structure the modeling space, which can be done by categorizing the model perspectives. We can, for example, categorize the models on

  • the system aspect they describe (e.g., data, presentation, security, business rules, workflows),
  • the subject area they describe (e.g., order entry, customer portal, back-end administration),
  • the abstraction level they are defined in (e.g., CIM, PIM, PSM), 
  • etc.

If we see these categorizations as dimensions of the modeling space, we can combine them, thereby creating a structured way to deal with a lot of models. Example models in such a structured space are: a platform independent data model of a customer portal, a computation independent workflow model of an order entry component, etc. As you can see models are defined on the intersections of the chosen dimensions.

Model validation

Model validation, or consistency checking, is used for evaluating models with respect to the semantic and syntactic quality criteria. Consistency checking evaluates a model against its metamodels. In addition to metamodels constraints can be used (mostly defined in the metamodel) for validating a model.

The most used constraint language is the Object Constraint Language (OCL), a formal language used to describe expressions on UML models. Hence, you can only use them if you use UML as language for defining your models. That might not always be the best choice…

Model checking

Model checking is a formal verification technique based on state exploration. Given a state transition system and a property, model checking algorithms exhaustively explore the state space to determine whether the system satisfies the property.

For example: the autonomous services of a service-oriented solution are communicating using messages. Each message receipt can trigger a state transition (in state full services) and/or results in a new message. If most of the services are implemented using a process definition the whole system can be modeled in a formal way using processes and interactions. A model checker uses this definition as input along with some correctness claims to check the correctness of a system.

MBT – Model-Based Testing

Besides testing, validating and checking models, we also want to test the resulting software artifact. Testing the behavior of the runtime system with use of test cases automatically generated from models is called Model-Based Testing (MBT).

More on model validation, checking, and testing…

13 Comments Added

Join Discussion
  1. Akshaya June 24, 2009 | Reply

    Can you tell me more about Abstract syntax of a model language? How it is represented and written, etc..

  2. Akshaya June 24, 2009 | Reply

    please e-mail me any details..

  3. Johan den Haan June 26, 2009 | Reply

    Hi Akshaya,
    The abstract syntax of a language is often represented with a metamodel. In the context of parser we often talk about AST (Abstract Syntax Tree). See this article for an example.
    A lot can be said about this subject. If you want more detailed information please detail your question.

  4. Azman Taa August 8, 2009 | Reply

    Dear Johan,
    If I model:
    1. requirements using goal analysis approach
    2. process and data model using ontology+UML
    q1:which level of MDE is appropriate for each of the modeling approach as I use above?
    q2:It’s QVT technique can be apply to transform the goal analysis model into ontology model?
    Definitely, ontology model can be transformed into coding … so can we say this going to be Domain Specific Language (DSL)?
    Need your help to explain. Anyway thanks for your articles.

  5. Johan den Haan August 11, 2009 | Reply

    Hi Azman,
    A starting point as answer to your question can be this article on Model-Driven SOA:
    It describes a framework to come from an organization model to a working implementation. Translating it to your situation you will have something like: organization model / requirements -> functional model / process and data model -> construction model / models specified with executable languages (DSLs).
    What you try to do sounds reasonable, however, I have my doubts with using the goal analysis approach as starting point. You should really make sure that you formalize that approach enough to use it as input for an automated transformation. If everybody comes up with a different goal tree for the same real-life situation you can’t use it as starting point for an automated transformation.
    Anyway, it seems your working on something nice! Good luck, I’m happy to answer your questions.

  6. Gisela BONNAUD September 6, 2009 | Reply

    I consider important to inform all readers about a new Postgraduate Diploma concerning MDE.
    The MDE International post-graduate specialization Diploma in Model Driven Engineering (MDE) for Software Management is offered by Ecole des Mines de Nantes.
    Its objective is to train engineers to manage complex projects in various IT fields with the latest cutting-edge modeling technologies.
    If you are interested in having more information, you can email :

  7. sugumaran January 4, 2010 | Reply

    Dear Johan,
    May i know how we can use the MDE in redocumenting the legacy source code? Can you give example of application using MDE concept?

  8. Johan den Haan January 4, 2010 | Reply

    Hi Sugumaran,
    I do not have much experience with reverse engineering legacy systems into models. You can look at this conference/workshop wrap-up for pointers to interesting information:
    For examples of applications build using a model-driven approach see (the case studies at the right).

  9. Micha Riser April 20, 2010 | Reply

    Good Glossary! You might be interested to try out the new model-driven code generator ”actifsource” which follows pritty much the presented definitions.

  10. Christian Merenda May 8, 2010 | Reply

    I like the glossary as well. If you like you can have a look at OOMEGA’s online documentation where some of the terms are explained in more detail, e.g. you can see how to specify a textual concrete syntax for a metamodel. In contrast to the last post… OOMEGA is an open source (!) model-driven engineering platform:

  11. Sumit November 18, 2012 | Reply

    Hello Johan,
    The Blog is simply wonderfull.
    Can you please present me a brief comparison of MDE to other Software Engineering Models-like waterfall, agile etc,

  12. Johan den Haan November 26, 2012 | Reply

    Hi Sumit,
    MDE only says something about the tooling. Waterfall/agile are about the process. In my opinion they can be perfectly combined.
    See for example

  13. Khuna July 25, 2014 | Reply

    Hi Johan,

    I just read your page and it has really clarify some of the misconceptions am having on language engineering. Am working on a language that has a defined abstract syntax as well as a concrete syntax, this two syntax were defined independent of any platform, but using the standard formalism of meta-modeling for the abstract syntax. We know that the two syntax do not have an awareness of each other even if the concrete was designed in mind considering the abstract syntax. I am now at a point where i have to show the mapping between these two syntax and also the mapping should be independent of any tool or platform. Please do you have an idea of how i can go about it, because from the literature review i have done , it has come to my notice that most papers shows the mapping using tools.

    Thank you for your contribution.

Leave a Reply