Model Driven Engineering

UPDATE: I’ve posted a reference guide for Model-Driven Engineering, explaining MDE in detail along with a glossary for all related concepts.

We’ve seen in MDA, Model Driven Architecture, basic concepts that MDA focuses on architecture, on artefacts and on models. The OMG has included some high level vision in their MDA document (OMG, 2003) addressing the usage of these artefacts en models. Although the MDA acknowledge things like a richer modelling space than just the dichotomy between PIM and PSM and the automation of transformations between models, they stay far from defining a real engineering approach.

As in the MDA the basic principle of Model-Driven Engineering (MDE) is "everything is a model", compared to the basic principle of object orientation "everything is an object" (Bézivin, 2004). MDE, however, is wider in scope than MDA, it combines process and analysis with architecture (Kent, 2002). According to Favre (Favre, 2004) MDA can be seen as a specific incarnation of the MDE approach. MDE is an open and integrative approach that embraces many other Technological Spaces in a uniform way. A technological space is a working context with a set of associated concepts, body of knowledge, tools, required skills, and possibilities (Kurtev, Bézivin, & Aksit, Technological Spaces: an Initial Appraisal, 2002). Examples of technological spaces are Programming languages concrete and abstract syntax, Ontology engineering, XML-based languages, Data Base Management Systems (DBMS) and MDA.

The goal of Model Driven Engineering

The underlying motivation for Model-Driven Engineering is to improve productivity. In the current complex enterprise landscapes, with a growing diversity of systems and platforms, newly build software applications can’t be compatible with all existing and future systems. MDE aims to increase the return a company derives from its software development effort. This benefit is delivered in two basic ways (Atkinson & Kühne, 2002):

  1. By improving the short-term productivity of developers. That is, by increasing the value of primary software artefacts in terms of how much functionality they deliver.
  2. By improving the long-term productivity of developers. That is, by reducing the rate at which primary software artefacts become obsolete.

The primary focus of most tool vendors is to deliver the first benefit. New software artefacts can be generated from (mostly technical) models, thereby supporting developers in their productivity. However, after the initial building process no support is delivered in managing the lifecycle of the software artefact. Changes have to be made in the generated source code or in parts of the model, this will lead to round-trip problems.

In the current fast changing enterprise landscapes the second benefit will become more and more important. The longer a software artefact remains of value, the greater the return derived from the initial effort to create the artefact. According to (Atkinson & Kühne, 2002) a second and strategically even more important aspect of MDE is reducing the sensitivity of primary artefacts to change. They indicate four main fundamental forms of change which are of particular importance:

  1. Personnel; vital development knowledge shouldn’t be only stored in the minds of developers, such information will be lost in the all too frequent event of personnel fluctuations. Therefore this information should be made easy accessible for others than the initial creators of the software artefact. If possible it should take a form which is understandable by all interested stakeholders including customers.

    Technical implication: primary software artefacts can be expressed using a concise and tailorable presentation.

  2. Requirements; changing requirements is a known problem in software engineering. However, nowadays this problem is bigger than ever. In the current fast changing business environment of enterprises new functionality have to be developed faster than ever. In the mean time all these changes must have a low impact on existing systems in terms of maintenance and disrupting online-systems. In the most ideal situation changes have to be made while the systems keep running.

    Technical implication: the need to support the dynamic addition of new types at runtime.

  3. Development platforms; development platforms are also in a state of constant evolution. To decouple the lifetime of a software artefact from the development tool used for its initial creation it is necessary to decouple the artefact or the model representing the artefact from the development tool.

    Technical implication: tools should store artefacts in formats that can be used by other tools, in other words, they should support high-levels of interoperability.

  4. Deployment platforms; the last form of change is the evolution in deployment platforms. New platforms, middleware solutions, application servers, etc. are released faster and faster. To increase the lifetime of software artefacts it is necessary to protect them against changes in the deployment platform. This form of change is the main driver behind the MDA approach presented by the OMG (OMG, 2003).

    Technical implication: it is necessary to automate (to the greatest extent possible) the process of obtaining platform specific software artefacts from platform independent ones through the application of user definable mappings.

In most cases when people are talking about MDA or MDE the only goal associated with these terms is to reduce the software artefacts’ sensitivity for change in deployment platforms by using a PIM and a PSM. The other mentioned goals, however, are of the same importance and a methodology fulfilling all these needs can solve a lot of problems in software development processes and business-IT alignment.

Summarized: the goal of MDE is to increase both the short-term productivity, e.g. the amount of functionality delivered by a software artefact, and the long-term productivity, e.g. reducing the software artefacts’ sensitivity for changes in personnel, requirements, development platforms and deployment platforms.

Modelling dimensions

An approach fulfilling the goal of MDE has to have more than the only modelling dimension presented in the Model Driven Architecture of OMG. They present the platform specific/platform independent dimension which, in principle, is an example of the more general abstract/concrete dimension. In this dimension we can only talk about whether a model is abstract (or platform independent) with respect to some other model. It depends on the viewpoint whether a model is platform independent or platform specific (abstract or concrete), but whenever a model is platform specific it must include all details needed for implementation (OMG, 2003).

Kent (Kent, 2002) defines two additional categories of dimensions needed for MDE. The first category contains various dimensions of concern. The first dimension of concern comes from the distinction of models on the base of the subject area they belong to. Different users of the system may have different viewpoints on the system focusing on a subset of the system features. By example the part of the system dealing with customers, or the part of the system concerned with processing of orders. The second dimension of concern enumerates aspects of a system. Examples of aspects are information /data, presentation, concurrency control, security, distribution and error handling.

The second category of dimensions is less concerned with the technical aspects of a system, but more with organizational issues. The dimensions in this category include authorship, version (as in version and configuration control), location (in case the system development is distributed across sites) and stakeholder (such as business expert or programmer) (Kent, 2002).

In software development projects it is necessary to determine the important dimensions for a particular project. In most projects authorship and versioning will be important, but other dimensions need the identification of points of interest, like which subject areas play a role and which system aspects are of importance. Another important decision is the levels of abstraction to be used in the process and which stakeholders are involved (for which understandable models have to be made). When building models in a software development process, each model can be placed at an intersection of the dimensions. The various dimensions at an intersection play an important role in the choice for a modelling language for that particular model. By example, the modelling language is influenced by the subject area, the stakeholders and the level of abstraction.

Software engineering process

We’ve talked about the artefacts (models) needed in MDE, this only constitutes the part of what is required. There need to be some process, at the very least some guidelines on the order in which models should be produced, how the work should be divided between teams and so on (Kent, 2002). According to Kent macro and micro processes are associated with the engineering of the different models. Macro processes concern the order in which models are produced and how they are coordinated. Micro processes amount to the guidelines for producing a particular model. Within macro processes a distinction can be made between processes describing the building of new software systems and processes guiding the evolution of software systems.

Software development

A software development process is a problem solving activity, which transfers a set of problems into a set of executable solutions (Aksit, 2004). The set of problems is mostly indicated as the set of requirements while the set of executable solutions can be called a software system. Requirements can be categorized into functional and non-functional requirements. Functional requirements describe what the system should do, they describe the services provided for the users and for the other systems. Non-functional requirements can be divided into three main categories: quality requirements (performance, reliability, availability, etc.), platform requirements (computing platform, technology to be used, etc. ) and process requirements (methodology used, cost and delivery date, etc.) (Lethbridge & Laganière, 2005).


Kurtev (Kurtev, Adaptability of Model Transformations, 2005) describes two different scenarios for creating new software systems. The first scenario indicates the presence of alternative solutions for a set of requirements. In terms of a transformation process from a source model to a target model this scenario may arise in two ways as Figure 1 shows.

Alternatives in the transformation pattern

Figure 1 – Alternatives in the transformation pattern: alternatives derived from alternative source models (a) and alternatives derived via alternative transformations (b) (Kurtev, Adaptability of Model Transformations, 2005).

In Figure 1a two alternative source models (S1 and S2) are created for the requirements (R). The distinction between S1 and S2 can be originated from different styles of modelling. The transformation models TM1 and TM2 can be identical or different, depending on the differences in S1 and S2. Figure 1b shows another possibility for generating alternative solutions. A single source model (S) can be transformed into two different target models (T1 and T2) by using different transformation models (TM1 and TM2). T1 and T2 can, by example, differ in functional requirements. The transformation from a PIM to a PSM, as presented in the MDA, can be seen as an example of this possibility. In that case TM1 and TM2 (and eventually other transformation models) transform platform independent model S to different platform specific models (T1, T2, etc.).

The transformation process between a source and a target model can be applied multiple times, so the described scenario can also occur multiple times in a software development process.

Decomposition and composition

The second scenario described by Kurtev (Kurtev, Adaptability of Model Transformations, 2005) illustrates the possibility to decompose requirements and compose the corresponding solutions. Complex software systems are derived from a large set of requirements often composed based on the wishes of multiple stakeholders. Decomposing requirements, thereby creating workable sub-sets, is one of the strategies to deal with complexity. In the model transformation process two components may be affected by a decomposition of requirements: the source model and the transformation definition.
The first case is shown in Figure 2. We assume that an initial set or requirements is decomposed into two sub-sets and that based on these subsets two models S1 and S2 are derived. There are two possibilities to compose these two different source models into one target model: the composition of the source models before they are transformed (Figure 2a) or by first transforming S1 and S2 to T1 and T2 which in turn are composed to form the result target model (Figure 2b). Kurtev notes that the composition of the models may be implemented as a transformation that takes two models as input.

Decomposition and composition of the source model

Figure 2 – Decomposition and composition of the source model: composition of source models before transformation (a) and composition of target models after transformation of source models (b) (Kurtev, Adaptability of Model Transformations, 2005).

Like models describing a system, transformation models can also be very complex. To deal with this complexity they can be separated into different models. This lead us to the cases shown in Figure 3. The first case shows (Figure 3a) how transformation models TM1 and TM2 are composed into one transformation model TM before they are used to transform model S into target model T. The second case, shown in Figure 3b, is almost the same except that the source model is also derived from composing two models (S1 and S2) into one model (S).

Decomposition and composition of transformations

Figure 3 – Decomposition and composition of transformations: decomposed transformation definition (a) and decomposed transformation definition and source model (b) (Kurtev, Adaptability of Model Transformations, 2005).

Evolution of software systems

Software systems usually change during their life time. We call this the evolution of a software system. In literature it is also called maintenance and comes with three different reasons (Swanson, 1976):

  • Corrective maintenance indicates the changes made in a system to solve processing, performance or implementation failures.
  • Adaptive maintenance is the change of a software system triggered by changes in the business or technical environment.
  • Perfective maintenance is used to improve the quality (processing inefficiency, performance enhancement, etc.) and maintainability of a system.

In principle three scenarios of evolution exist: additive evolution, replacement of a system component and subtractive evolution (Kurtev, Adaptability of Model Transformations, 2005). These scenarios describe the lifetime of a system component, once it is added it can change during its lifetime till it is removed.

Additive evolution

In the additive evolution scenario a new system component is added to an existing software system. Figure 4 shows a possible scenario when using Model Driven Engineering. At moment t1 the initial system is shown. Moment t2 shows an addition of a source model S1 which is composed into one source model S’ with S before it is transformed to a new target model T’. Moment t3 shows an addition of a target model T1 to the existing system T’ resulting in a new system T”.

MDE evolution scenario

Figure 4 – Implementation of additive changes in the transformation pattern by adding new models: moment t1 shows the initial state, moment t2 shows an addition of a source model S1, moment t3 shows an addition of a target model T1 (Kurtev, Adaptability of Model Transformations, 2005).

In Figure 4 only addition by composition is visualized. It is of course possible to define much more scenarios based on the addition of source, target or transformation models using composition or transformation.

Replacement of a system component

Corrective or perfective maintenance mostly leads to replacements of system components by a changed version of that component. Changes in a component can be made by the adaption of the source model, but also by changing the transformation definition or by directly changing the target model. Changing a component by changing the source model can ask for so-called change propagating transformations in contrast to stateless transformations which only support rerunning a transformation from scratch after the initial run. Change propagating transformations support the non-destructive propagation of changes from the source model to the already existing target model (Tratt, 2008). 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 a domain model (the source model) without losing data. This, of course, isn’t possible for every change.

Software components in a system can evolve different over their lifetime. The most prominent types, which are not mutually exclusive, are listed below (Lanza, 2001):

  • Pulsar. A Pulsar grows and shrinks repeatedly during its lifetime. The growth phases are due to additions of functionality, while the shrinking phases are most probably due to refactoring and restructuring of the component.
  • Supernova. A Supernova is a component which suddenly explodes in size. The reasons for this can vary, some possibilities are a major refactoring of the whole system or because it was a so-called sleeper-component which is defined a long time ago and in a short moment is filled with functionality.
  • White Dwarf. A White Dwarf is a component who used to be of a certain size, but due to varying reasons lost the functionality it defined to other components and now trundles along in the system with no real meaning.
  • Red Giant. A Red Giant is a very big component which keeps being very large over several versions. Red Giants tend to implement too much functionality and are quite difficult to refactor.
  • Stagnant. A Stagnant component is one which doesn’t change over several versions of the software system it belongs to. The reasons can be, by example, dead code, good design or because it belongs to a part of the system which isn’t under change.
  • Dayfly. A Dayfly has a very short lifetime, it often only exists in one version of the system. Such components may have been created to try out an idea which is dropped afterwards.
  • Persistent. A Persistent component has the same lifespan as the system as a whole. It has been there from the beginning and is part of the original design. Persistent components can contain dead code no developer dares to remove as there is no one being able to explain the purpose of the component.

Subtractive evolution

At the end of a component’s lifetime it is removed from the software system. The scenario’s for subtractive evolution are the opposite’s of the ones for additive evolution, so no additional explanation is needed.


Although the MDA acknowledge things like a richer modelling space than just the dichotomy between PIM and PSM and the automation of transformations between models, they stay far from defining a real engineering approach. Model-Driven Engineering (MDE) is wider in scope than MDA, it combines process and analysis with architecture.

The goal of MDE is to increase both the short-term productivity, e.g. the amount of functionality delivered by a software artefact, and the long-term productivity, e.g. reducing the software artefacts’ sensitivity for changes in personnel, requirements, development platforms and deployment platforms. To reach this goal additional modelling dimensions are needed next to the abstract/concrete (PIM/PSM) dimension. We have described two additional categories of dimensions, the various dimensions of concern and the organizational dimensions.

The artefacts (models) needed in MDE only constitutes the part of what is required. There need to be an engineering process to come to and maintain a software system. The lifecycle of a software system including its development and maintenance is in the general case a sequence of steps that apply the scenarios described in this article. Different software development methods handle these scenarios in a different way. Depending on the number of models, the macro processes describing the order in which models are created, composed and transformed, can become very complex. The micro processes, describing the guidelines for producing a particular model, depend on the definition of that model. Such a definition can be formally defined using Domain-Specific Languages.

Read more:
MDE and DSLs combined

Read more: MDE, MDA, DSL, UML, explained and compared

Read more: MDE reference guide


Aksit, M. (2004). The C’7 for Creating Living Software: A Research Perspective for Quality-Oriented Software Engineering. Turkish Journal of Electrical Engineering , vol. 12 (2).

Atkinson, C., & Kühne, T. (2002). Model-Driven Development: A Metamodeling Foundation. IEEE Softw. , 20 (5), 36-41.

Bézivin, J. (2004). In Search of a Basic Principle for Model Driven Engineering. UPGRADE , Vol. V (No. 2), 21-24.

Favre, J.-M. (2004). Towards a basic theory to model driven engineering. Third Workshop in Software Model Engineering (WiSME@UML).

Kent, S. (2002). Model Driven Engineering. Proceedings of IFM2002, LNCS 2335 (pp. 286-298). Springer.

Kurtev, I. (2005). Adaptability of Model Transformations. University of Twente. Enschede: Febodruk BV.

Kurtev, I., Bézivin, J., & Aksit, M. (2002). Technological Spaces: an Initial Appraisal. CoopIS, DOA’2002, Industrial track.

Lanza, M. (2001). The evolution matrix: recovering software evolution using software visualization techniques. Proceedings of the 4th International Workshop on Principles of Software Evolution (pp. 37-42). Vienna, Austria: ACM.

Lethbridge, T. C., & Laganière, R. (2005). Object-Oriented Software Engineering. New York: McGraw-Hill.

OMG. (2003, 06 12). MDA Guide Version 1.0.1. Retrieved from Object Management Group:

Swanson, E. B. (1976). The dimensions of maintenance. Proceedings of the 2nd international conference on Software engineering (pp. 492-497). San Fransisco: IEEE Computer Society Press.

Tratt, L. (2008). A change propagating model transformation language. Journal of Object Technology , vol. 7 (no. 3), 107-126.

6 Comments Added

Join Discussion
  1. James Taylor March 15, 2008 | Reply

    Tried to trackback but it did not seem to work so here’s the link to my post:
    Author of Smart (enough) Systems
    blog at

  2. Johan den Haan March 15, 2008 | Reply

    Hi James,
    You’re definitely right! Just one sentence “If possible it should take a form which is understandable by all interested stakeholders including customers.” is way to less to underline the importance of involving the non-technical user in the process. In the part about modelling dimenstions I’ve talked about the stakeholder-modelling-dimension. My opinion is that different models are needed to create a software artefact. Most models should be at the point of the business expert on the stakeholder-modelling-dimension, but there are some models which can’t be there (like a security model).
    Anyway, the business user should be in a central position! That’s also the focus we have at Mendix (the company I work for). The primary user of our MDE tooling is the business analist.

  3. Petras March 16, 2009 | Reply

    In the MDA Guide Revision Draft Version 0.1.5 (29 June 2006) OMG does talk about viewpoint and viewpoint models. “Viewpoints provide a technique for making explicit the separation of
    concerns when modeling. Each of several viewpoints focuses on particular concerns, while leaving other concerns to other viewpoints.” Viewpoint models are models “of the system that focus on different concerns”. Thus in this revision they shifted from bare abstract/concrete dimension of models they defined in MDA Guide Ver 1.01 towards dimensions described by Kent (Kent, 2002) and cited in your article. Therefore the gap between MDA and MDD becomes not so clear.

  4. Petras March 16, 2009 | Reply

    Sorry, I meant the gap between MDA and MDE. And well yes, MDE promotes DSL as their modeling language, which could be simpler than UML. That makes quite a difference 🙂

  5. Johan den Haan March 17, 2009 | Reply

    Hi Petras,
    Thanks for the tip! I didn’t know that document exist. For other readers: you can find the document at
    If this document is going to be standardized as the next version of the MDA, MDA and MDE as defined above will become more or less the same.
    The document is from 2006, do you know if they are still working on it?

  6. Tjerk W April 20, 2010 | Reply

    I also posted a article about MDE, maybe interesting for some readers:

Leave a Reply