Tag Archives: xtext

The Future of Software Engineering: Model Driven Engineering

In this first article I will cover Model Driven Engineering (MDE , also called Domain Driven Design DDD) and briefly explain the core concepts of MDE. MDE is a relatively new research field in software engineering, the first ideas are from research papers in the end of the 20th century. A lot of research is done in the last decade and it has become more prevalent in the software industry.

First some of the problems that MDE tries to tackle are  discussed. After that the core concepts of MDE are covered. The article will end with some applications of MDE.

What MDE Tries to Solve

As a programmer you may not notice this on a first glance, but there are some basic problems with the current programming approaches. The holy grail of software engineering is to perform software development in a similar way to how they do it in mechinical engineering: create a model of your software, check that model for failures and use that model as a blueprint for actually creating your product. Lets look at the problems we have in achieving that goal.

The gap between Problem Domain and Implementation

Software is written to achieve a certain goal for a certain domain. This domain is called the problem domain. Examples of such domains are banking, healthcare, social network etc etc. The goals are made explicit by a joint effort between the domain experts and software developers in some kind of requirements document. These requirements are mostly specified in human readable text and refer to concepts in the problem domain. It is the task of the development team to implement the software given the requirements.

The problem here is that the solution to the problem (the implementation) is expressed in a (relatively low level) programming language, which only provides algorithmic concepts. The requirements, on the other hand,  are specified ambigously in text using problem domain concepts. This makes it difficult to check if your requirements are met. It would be easier if we could express the solution, or even the requirements themselves, in a model which refers to concepts related to our problem domain. The solution that MDE provides is the ability to create intermediate languages in which one can use problem domain concepts to specify a model. Or as Douglas C. Smith puts it:

“Model-driven engineering technologies offer a promising approach to address the inability of third-generation languages to alleviate the complexity of platforms and express domain concepts effectively.”

Dealing with Software Evolution

Change is a major factor in software systems, requirements change, personnel leave and join, and even the software/deploy platforms change over time. When requirements change the software is out of sync and also needs to be changed. When new programmers join the company they have to understand code written by someone else. A change to a new software platform may require a complete rewrite of the implementation!

Again the solution that MDE proposes is the use of higher level models. These higher level models are closer to the problem domain, smaller then the implementation and with no boilerplate code. The model is platform independend, easier to understand and therefere it copes better with change.

Model Driven Engineering Concepts

While not all problems MDE solves are discussed we move onto the real deal: MDE itself. In this section the MDE approach is discussed briefly to give you a glimpse into the future of software development!

The Unifying Power of Models

The major corner stone of MDE are models. Without going into much detail you can view a model as a representation of system written in a certain modelling language. In MDE any software artifact is viewed as a model. This may be a code, but also requirements are specified as a model. All models conform to a  metamodel. Suppose we have a model written in a modelling language A, then that model will conform to the metamodel of the language A. This is similar to how a C++ program (the model) conforms to the C++ specification (the metamodel). Or how an XML document (model) conforms to an XMLSchema (metamodel). Or how a BNF syntax specification (model) conforms to BNF (metamodel). This is visualised in the diagram below.

The 3 Layers in MDE

The diagram also shows the metametamodel layer, which is out of the scope of this article. But let’s just say that the metametamodel has a nice property: it is defined in itself (for example xmlschema defined in xmlschema).

The concept of model might look a bit vague at this point. It may look like just a cosmetic change: what we call a program is called in model in MDE. This is partially true. A program may be a model, but a model does not have to be a program. For example the data in google maps provides a partial model of the world, this however can not be seen as a program. Also a model does not have to be textual like most programming languages. A model is a logical entity and it can be edited visually or textually depending on the MDE framework you use. For now one can see a model as some kind of annotated graph.

Increasing the Level of Abstraction

Abstraction is an important concept in computer science. Developers and researchers used abstractions to express their programs in terms of their design instead of the underlying computer technology (assembly, c, c++, php, sql, java etc). This shielded them from the complexity of those underlying platforms. Again MDE takes a similar path, it too increases the level of abstraction.

Currently most software projects are written in general purpose programming language (GPLs). As explained in the problem section these language are not close to the problem domain. A solution that to this problem is the use of domain specific languages (DSLs). Current GPLs are language like Java, C++ and PHP while DSLs are languages like SQL, Excel, HTML. The problem with DSL’s is that they are limited and not easy to create.

An ideal DSL is a language that fits your problem domain perfectly. Here is where the main power of MDE comes in: it allows one to a create DSL very easily using your own domain concepts. The DSL can then be use to create models which are closer to your problem domain. These models can then in turn be used to define your final implementation.

Bridging the requirements gap

Code Generation

An attentive reader might think: so where is the actual code/implementation? The most used approach is to write a code generator which generates GPL code from your DSL model. If the model changes new code can be generated. However if the DSL metamodel changed the code generator also has to be changed to generate new code. This is actually how it is often done in most industry applications today. Maintaining your code generator may seem like a disadvantage. However if your DSL is good enough the code generator only has to built once for each target platform. The rate of change of a well designed DSL is also low compared to the rate of change of your DSL, therefore the code generator does not have to change that often.

Code generation is nothing new. For example when you compile your C++ application it basically generates a low level model (opcodes) from your high level model (your program). A database management system translates (generates) your SQL query to relational algebra, optimizes it, and executes code to retrieve the data. XML Data is fed into an XSLT stylesheet to generate a website / digital print etc. MDE basically provides a framework on a higher level.

Another approach is to make your DSL executable. This is a more theoretical approach; one has to define the semantics of your DSL formally. This approach is currently under heavy research. In fact my master thesis was about this approach.

Model Checking, Model Transformations and More

Another important advantages of MDE is that it allows certain rigorous mathematical techniques to be applied on it. For example model checking can be applied on a model of the software. In this sense MDE brings us closer to the holy grail of software engineering: 100% bug free software!

There are other advantages of having models as artifacts: we can transform models to other models using model transformation. Suppose we could generate an initial software model from the requirements model. Using model transformation we could trace how a certain change of a requirement impacts the software model, this is called impact analysis.


MDE can basically be used in any software project. However its main benefit is prevalent in bigger software projects with multiple stakeholders. A short list of concrete applications is given below to give the reader some concrete examples:

  • Usage in data centric applications: The model describes the data, constraints, relationships and workflow. The implementation (a web applicaton) could be generated from this model. Forms, form validation, SQL Code, correct control flow, etc are all generated from your domain model.
  • Usage in function critical applications: A model is needed to perform model checking.
  • Mobile Application Development: writing the same application for multiple platforms proves difficult due to the differences between the platforms. A DSL provides one language for all platforms.

Most applicatons of MDE are domain specific and therefore only used by a certain company or in a certain domain. Therefore it is difficult to give some real world examples.


MDE basically raises the level of abstraction as has happened always in computer science. It is fairly new and of course time has to tell if it succeeds. However its goal is ambitious: it provides a solution to the growing complexity of software systems and takes a big step from moving from programming to mature software engineering.

MDE itself is maturing. MDE is used more and more in practice. Big companies are adopting it (for example ASML, Microsoft, Motorola, SAP, Ordina, Atos Origin and IBM). And also tool support becoming better and better (for example: Eclipse EMF).

Below are some references if you want to continue reading:

And one in Dutch: