What is Model Driven Development?

In short, Model Driven Development is abstracting the terms, concepts, patterns and elements used within a certain domain area into models that describe them.
These models are then in turn used for defining the actual elements of the domain and used for generating the code artifacts needed for the chosen target platforms. In other words, you move away from using general-purpose tools towards using tools tailored specifically to your domain.

Using a model based approach to development has a number of advantages over the more common “algorithmic” approach. Here is a list of the most important in no significant order.

Higher level of abstraction

By making models that is based on your own domain, you raise the level of abstraction from something that is close to the implementation, to terms and elements that reflects the business. By using technology-independent models of your domain, it is easier to focus on the business needs, when you do not have to relate to more technical terms and decision.

Higher abstraction level using UML compared to raw JPA annotated code

(View as PDF)

Low abstraction level using JPA (Java Persistence API) annotated Java code

Low abstraction level using JPA (Java Persistence API) annotated Java code

Tailored to your needs

When you make models of your domain, you both raise the level of abstraction and make it possible to make assumptions and use invariants since the model is closer to the problem domain. This will both restrict the user in what they can do and also make it possible to have the generators automatically generate code based on these general assumptions and invariants.
Domain specific models are smaller in size, than compared to generic models, which makes them easier to write and maintain.

Higher productivity

Higher productivity using a model driven approach is gained by a high degree of automation and use of code generators. A change in the business model will not require time consuming manual code changes or refactoring but just require that you re-generate the code. The same is the case when adding new functionality or elements to the meta-models or if you change the underlying technology. Once the code generators have been changed, you re-generate the code and the new functionality is implemented across the whole system.

Hide technology

By using models of your domain and using these models to generate code from, you can effectively hide the target technologies used for running the generated solution. This makes it possible to change the underlying technologies with none or only minor changes to the models. In order to be able to support a new technical platforms all that needs to be changed are the generators and the generator models.

By hiding the technology, you can also defer technical decisions to a later time. If you e.g. need to support history (e.g. bi-temporal history) on a certain element, you can start by specifying that the element must have history without having de decide how this should be implemented. This can be done at a later stage and even replaced later on, without having to change the model. Only the generators will have to change.


An example of hiding technology and implementation is show below, where we model an advanced business concept called bi-temporal history using a UML stereotype, that we chose ourselves, called History. In the model we show that from a business perspective a Person always has exactly one Name, but during a Persons life his or her Name will typically change several times (e.g. due to being married).
From a business perspective we need to keep track of when a persons name changed. This can be stated using a simple sentence “We would like to keep a historical track of a Persons name throughout his/her lifespan” and can also easily be modeled using e.g. the History stereotype (highlighted using the orange box in the picture below).

Modeling Bi-temporal History between Person and the persons Name in UML

Modeling Bi-temporal History between Person and the persons Name in UML

Implementing bi-temporal history is another story and is where expert developers come in and define how to translate the intention behind the History stereotype to the final solution. Below is shown the proces where the model is transformed through TRIMM and resulting in 3 different technical solutions (depending on what solution you prefer):
TRIMM Model to Solution Transformation

Better quality

Using models and a code generator approach, the quality of the produced code is more consistent and typically of a higher quality than if developed by hand. By generating the code you ensure that everything is done in the same way, that all code conventions are met, and that the right patterns are applied in the right places. Also, you are sure that if you have errors in the generated code, it is the same error you have in all the places where this piece of code is generated and thereby easy correct by modifying the generator.

Documentation is up-to-date

Another positive side effect of models is that the documentation is always up-to-date, since the models are used for code generation, as opposed to traditional development where the models have a tendency to become more and more obsolete and not updated when the code is changed.

Other positive side effects…

Once you start thinking in models and start using a model driven approach to development, it becomes apparent that other elements of traditional software development can be modelled and automated. Examples are generating documentation from the models, generate deploy scripts and also both unit- and technical integration-tests. Since the models contain meta-information about every element, both positive and negative tests can be performed on the attribute level and for complex domain areas, the setup code for a test can be generated based on a simple graph analysis.