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.
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.
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.
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.
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.
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.
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.
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.
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: http://www.omg.org/mda
Sendall, S., & Kozaczynski, W. (2003). Model Transformation – the Heart and Soul of Model-Driven Software Development. IEEE Software (vol. 20, no. 5), 42-45.