MDA and Model Transformation

As seen in MDA, Model Driven Architecture, basic concepts the key challenge of model-driven development is in transforming higher-level models into platform-specific models, that can be used to generate implementation level models. Transforming a model into another model means, as visualized in Figure 1, 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.

MDA transformation rules

Figure 1 – MDA transformation process


1. Classification of model transformation approaches

Before going into the different methods for model transformation an overview is given of the main differentiators between the model transformation approaches. The major points of variation in model transformation are: transformation rules, rule application scoping, source-target relationship, rule application strategy, rule scheduling, rule organization, tracing, directionality. They will be shortly described in the following paragraphs. For a full overview with use of feature diagrams see (Czarnecki & Helsen, 2003).

1.1. Transformation rules
Transformation rules describe how elements of a source model should be translated into elements of a target model. A transformation rule consists of two parts: a left-hand side (LHS) and a right-hand side (RHS). The LHS accesses the source model, whereas the RHS expands in the target model. They can both be described by variables, patterns, logic, queries, etc. Model transformation approaches differ in how they define rules.

1.2 Rule application scoping
Rule application scoping allows a transformation to define the target scope of a transformation. A restriction can be made about the parts of a model that participate in the transformation. Both a source and a target scope can be defined. Scoping can be important for performance reasons or advance transformation structures.

1.3 Relationship between source and target
When talking about model transformation the implicit conclusion made is that a new target model is created based on the information in the source model. However, approaches exist which do not create new target models but update existing ones or just update the source model. These in-place update approaches can be destructive, e.g. they can remove elements, or they can only made extensions to the existing model.

1.4 Rule application strategy
A rule need to be applied to a specific location within its scope. Since there may be more than one match for a rule in a given source scope, an application strategy is needed. The strategy can be deterministic, non-deterministic or interactive.

1.5 Rule scheduling
In more complex model transformation the amount of rules will be very high. A scheduling mechanism can be used to determine the order in which individual rules are applied. In some approaches users have no explicit control on the scheduling algorithm. Approaches can also differ in the way rules are selected, how rule iteration is done and if they make use of different transformation phases.

1.6 Rule organization
Rules can be composed and structured in different ways. Model transformation approaches mainly have three areas of variation: modularity mechanisms (packaging rules into modules), reuse mechanisms (defining rules based on one or more other rules) and organizational structure (organizing rules based on the source or target language or another independent organization).

1.7 Traceability links
Transformations may record links between their source and target elements. These links can be useful in performing impact analysis, synchronization between models, model-based debugging and determining the target of a transformation.

1.8 Directionality
The last differentiator between model transformation approaches is directionality. Transformation may be unidirectional or bidirectional. Unidirectional transformations can be only executed in one direction. So, the source model can be transformed into a target model, but not the other way around. Bidirectional transformation can be executed in both directions. This can be useful for synchronizing models, by example for applying round-trip engineering.

2. Model transformation approaches in the MDA

The OMG presents a couple of approaches that are used for transforming models in their MDA guide (OMG, 2003). They are briefly explained in the following paragraphs and classified according to the classification described in part 1. This classification isn’t complete because the approaches of the OMG are presented as general idea’s, they are not completely worked out. However, using this formal classifications gives a good overview of the differences among the model transformation idea’s.

2.1 Marking
The process of transforming a PIM into a PSM by marking the PIM is shown in Figure 2. First a platform is chosen. A mapping for this platform can be available or has to be prepared. This mapping defines a set of marks which are used to mark elements of the PIM. These marked elements guide the mapping of the marked PIM into a PSM.

MDA, marking a model

Figure 2 – Marking a model

This model transformation approach uses transformation rules with a LHS which defines a source element with a specific mark and a RHS which defines a certain target element. It also has to define rules for marking the elements. This can be done by hand or automatic. In the latter case all possible approaches can be chosen, the OMG doesn’t define specific choices.
Rules are scheduled into two phases, the marking phase and the mapping phase. In the marking phase the rule application scope is the full model. In the second phase the scope is defined by the marks. In most cases the marking phase is an in-place conversion, while in the mapping phase a new target model is created.

2.2 Model
In Figure 3 a model transformation approach is shown based on the mapping of platform independent types on platform specific types. The elements in the PIM are subtypes of the types specified in a platform independent type model. The elements in the PSM are subtypes of the types specified in a platform dependent type model.

MDA, model transformation approach

Figure 3 – Model transformation

The transformation rules defined in the transformation specification directly map platform independent types on platform specific types. The LHS of a rule selects a platform independent type, while the RHS selects a platform specific type. No specific rule application scoping is needed, the mapping holds for the whole model. In most cases a new target model will be created based on the source model. The rule application strategy is deterministic, unless complex mappings are defined in which one platform independent type has more than one possible platform specific types. If the mapping is more or less one-to-one it isn’t difficult to make it bidirectional.

2.3 Metamodel
A subtle difference exists between the subtype mapping approach and the metamodel approach. The basic structure of both methods are the same. In Figure 4 the metamodel model transformation approach is visualized. The PIM is expressed in the language defined in the platform independent metamodel. The PSM is expressed using a platform dependent language specified by a metamodel. The transformation specification defines the mapping between the metamodels.


MDA, metamodel transformation approach

Figure 4 – Metamodel transformation

In principle this approach can’t be classified, it is too general. Each differentiator presented in part 1 can be applied in all possible options. While in the subtype mapping approach types are defined and mapped onto each other, this approach defines concepts in a metamodel which are mapped. The difference is that in first case domain objects are modeled based on which a PIM can be specified. In the second case a general purpose language is defined (by example UML) in which the PIM is expressed.

2.4 Pattern application
An addition to the subtype mapping approach can be the use of patterns. Patterns are used to indicate groups of elements in the source model and to map them on groups of elements in the target model. This addition only changes the rule application scoping. Instead of applying rules to the whole model, rules can be defined only applicable to specific patterns.

2.5 Other approaches
Besides the approaches presented by the OMG a couple of other methods exist which are used in practice. Direct-manipulation approaches offer an internal model representation plus some API to manipulate it. They are usually implemented as an object-oriented framework (Czarnecki & Helsen, 2003). structure driven approaches are based on two distinct phases: the first phase is used to create the hierarchical structure of the target model, whereas the seconds phase sets the attributes and references in the target model.

3. Desirable characteristics of a model transformation language

The choice for a particular model transformation approach highly depends on the situation in which it is intended to use. The differentiators mentioned in part 1 all have their own advantages and disadvantages. However, besides these differentiators a number of general characteristics can be defined which are desirable to have for a model transformation language.

If a language is to have general utility and acceptance, then it should have full expressive power for the chosen purpose. General purpose transformations as a consequence would probably need to be Turing-complete (Sendall & Kozaczynski, 2003). A good balance is needed in a language, it should be easy-to-understand, yet precise and unambiguous. It should be concise and easy-to-modify, yet complete.

Sendall & Kozaczynski (Sendall & Kozaczynski, 2003) state: It is recommendable for a model transformation language which supports model-driven software development to:

  • Be executable;
  • Be implementable in an efficient way;
  • Be fully expressive, yet unambiguous, for transformations that modify existing models as well as create completely new models;
  • Facilitate developer productivity with precise, concise and clear descriptions:
    • The language should clearly differentiate the description of the source model selection rules from the rules for producing the target model;
    • The language should offer graphical constructs in the cases that the concepts represented are more concise and intuitive in graphical form compared to a textual one;
    • The language should be declarative by making implicit any concepts or mechanisms that can be intuitively interpreted from the context;
  • Provide a means to combine transformations to form composite ones, offering at least operators for sequencing, conditional selection and repetition of transformations; and
  • Provide a means to define the conditions under which the transformation is allowed to execute.

4. Selecting the right MDA approach

Based on the information presented in this article the following steps are needed for selecting the right MDA approach for a software development project.

Step 1: choose a way to present the PIM and PSM. This choice can be based on one of the MDA approaches presented by the OMG (see part 2).

Example: make use of a metamodel to describe the language in which the PIM is defined.

Step 2: choose the desired characteristics for the model transformation from the classification presented in part 1.

Example: the model transformation should be bidirectional.

Step 3: choose a model transformation approach complying to the selected characteristics. This choice can be based on one of the MDA approaches presented by the OMG. If step one already was based on an approach, the same approach should be chosen in this step.

Example: the model transformation approach is based on the metamodel approach defined by the OMG.

Step 4: implement the model transformation language, keep in mind the chosen characteristics in step two and the general characteristics presented in part 3.

Example: besides the general characteristics presented in part 3 the language also should support bidirectional usage. This can be done by making the rules bidirectional or by defining rule pairs (rules for both directions, being each other’s opposite).

In a software engineering approach it is important to define how different models and model transformation are combined to build a software artefact. For more information about this topic see the post about Model-Driven Engineering


Czarnecki, K., & Helsen, S. (2003). Classification of Model Transformation Approaches. OOPSLA’03 Workshop on Generative Techniques in the Context of Model-Driven Architecture. Anaheim, CA, USA.

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

Sendall, S., & Kozaczynski, W. (2003). Model Transformation – the Heart and Soul of Model-Driven Software Development. IEEE Software (vol. 20, no. 5), 42-45.

4 Comments Added

Join Discussion
  1. software developer October 14, 2009 | Reply

    That was an inspiring post,
    thanks for the the diagrams, they are very helpful…
    Keep up the good work

  2. Rakesh September 29, 2011 | Reply

    All your articles on MDA/MDE are excellent. I’m new to MDA and from your article the most i could make out was that MDA is
    *An architecture which builds your code from business representation/ requirements.
    *There is a layer of transformation where we write rules which transform the business representations/requirements into a Programming language/framework.
    *This creates a way to improve the understandability of the application and thus helping the extensibility in terms of enhancing the application.
    Please correct me if i’m wrong as i would want to learn about MDA.

  3. Johan den Haan October 4, 2011 | Reply

    Hi Rakes,
    Thanks for your kind words!
    Nothing to correct, you are thinking along the right lines. If you are thinking about the advantages of MDA / MDD / MDE please also read:

  4. Muhammad Sohail October 11, 2012 | Reply

    Hi,! How are you? I am Sohail from Pakistan. Need your help in exploring the code generator part of the Language Workbench that generate the Layered enterprise applications. My question is following
    Code generation involving big enterprise applications results in huge code generation template library. These templates generate the code files related to the database, data access, business logic, UI, Unit testing, cross cutting concerns of enterprise applications, documentation and many more. I have survey many code generation template libraries. The code generation template are monolithic and they tend to generate either the code snippets or the whole enterprise application in a single code generation process. What are your thoughts on
    “how to organize or structure” the huge code generation template repository for enterprise applications. How we can maintain a code generation template library that is modular, maintainable, separation of concerns, no repetition of code generation logic, layers, cross cutting concerns of code generation logic and things like that.
    I need references, web reference, your thoughts, blog references regarding that.

Leave a Reply