There is increasing interest in the use of design patterns for model transformations, and a number of such patterns have been proposed. In this paper we survey previous work on transformation design patterns, discuss one pattern in detail, and identify priorities for future research. { Transformations involve complex structured data (models) and navigation through and manipulation of such data. { Transformations involve unconventional processing such as graph rewriting and partially-specified execution orders. { Hybrid MT languages involve a mix of declarative and imperative language elements. { Languages supporting bidirectional transformations (bx) involve complex processing to synchronise or transform models in either source to target or target to source directions.
Design patterns have proved to be an effective concept to improve the quality of software systems, with classic patterns such as Iterator, Facade and MVC now part of the standard vocabulary of software developers and provided as essential elements of programming languages and of software development environments. Model transformation (MT) development should also be able to benefit from the standardised solutions and expertise embedded in design patterns: currently such development is often carried out in an ad-hoc manner because of the novel nature of the languages and processing involved.
Transformation development requires new or adapted specification and
design patterns because of the specialised features of MT programming and
languages:
The first works on MT design patterns identified language-specific patterns for
the ATL [
QVT-R: In [
In some cases, such patterns simply gave techniques for circumventing limitations of the specific MT languages.
Subsequently, work was carried out to identify language-independent MT
design patterns, based on generalisations of the language-specific patterns or
adaptions of classical design patterns for MT: in [
In [
Model-to-text patterns: Model Visitor; Text Templates; Replace Abstract by Concrete Syntax.
Expressiveness patterns: Simulating Multiple Matching; Simulating Universal Quantification; Simulating Explicit Rule Scheduling.
Architectural patterns: Phased Model Construction; Target Model Splitting; Model Merging; Auxiliary Models; Filter Before Processing.
Patterns for specific categories of transformation have also been identified:
Bidirectional transformation (bx) patterns: Auxiliary Correspondence Model;
Cleanup before Construct; Unique Instantiation; Phased Construction for bx;
Entity Merging/Splitting for bx; Map Objects Before Links for bx [
Auxiliary Correspondence Model is an inbuilt and essential language feature of TGG and QVT-R. Unique Instantiation is an inbuilt language feature of QVT-R and UML-RSDS, and Object Indexing and Omit Negative Application Conditions are also inbuilt into UML-RSDS.
Figure 1 (based on [
This pattern has been identified in several bx examples. The pattern defines a two-phase approach in both forward and reverse transformations associated with a bx with relation R: the forward transformation R! first removes all elements from the target model n which fail to satisfy R for any element of the source m, and then constructs elements of n to satisfy R with respect to m. The reverse transformation R operates on m in the same manner.
Bene ts: The pattern is an effective way to ensure the correctness of separatemodels bx: all target elements which invalidate R are removed.
Disadvantages: There may be efficiency problems because for each target model
element, a search through the source model for possibly corresponding source
element(s) may be needed. Elements may be deleted in the Cleanup phase only to
be reconstructed in the Construct phase: use of Auxilliary Correspondence Model
[
Related Patterns: This pattern is a variant of the Construction and Cleanup
pattern of [
Examples: An example is the Composers bx [
Assume that the transformation rules Cn are of the form: Si →forAll (s | SCond (s) ⇒
Tj →exists (t | TCond (t ) & Pi,j (s; t ))) for source entity types Si and target entity types Tj . Then if identity attributes are used to define the source-target correspondence (so that target model element t : Tj corresponds to source model element s : Si when the respective identity attributes are equal: s:sId = t :tId ), then Cn can be expressed as the constraints (i):
Tj →forAll (t | TCond (t ) & t :tId ̸∈ Si →collect (sId ) ⇒ t →isDeleted ()) which deletes t if there is no corresponding s with the same identity, and (ii): Tj →forAll (t | TCond (t ) & t :tId : Si →collect (sId ) & s = Si [t :tId ] & not (SCond (s)) ⇒ t →isDeleted ()) which deletes t if such an s exists but it is not in the domain of the transformation (relation R). (ii) is omitted if SCond is the true predicate.
In the case that TCond (t ) and SCond (s) hold for corresponding s, t , but Pi,j (s; t ) does not hold, t should not be deleted, but Pi,j (s; t ) should be established by updating t (iii):
Si →forAll (s | s:sId : Tj →collect (tId ) & t = Tj [sId ] &
SCond (s) & TCond (t ) ⇒ Pi,j (s; t )) For a transformation , the cleanup transformation has the above Cn constraints (i), (ii), (iii) as its postconditions, in the same order as the Cn occur in the Post of . The forward direction ! of the bx is then ; .
A change-propagation version ∆ of can also be defined, to operate on source model increments m (finite collections of deletion, creation and modification updates). ∆ is ; where the rules of are only applied for deletion (i) and modification (ii), (iii) updates in m, and the rules of are only applied for modification and creation updates in m. 4
Because of the novelty of the MT field, there is as yet insufficient evidence for the effectiveness of most of the identified patterns. Work is needed to survey applications of MT patterns in practice and to evaluate their utility. Work is also needed to identify appropriate classifications for MT patterns, to identify connections between patterns, and useful compositions of patterns. Techniques and guidelines for the selection of MT patterns need to be developed and incorporated into MT engineering environments. Patterns for new types of transformation, such as transformations at runtime or streaming transformations, are also needed. Finally, research into transformation anti-patterns and techniques for the identification of ‘bad smells’ in transformation specifications is needed.