Phased Construction

This is a Modularisation pattern.

Summary

This pattern decomposes a transformation into phases or stages, based on the target model composition structure. These phases can be carried out as separate sub-transformations, composed sequentially. Each phase consists of a rule which creates objects of only one target language entity type, and does not navigate across more than one level of a fixed composition hierarchy of either the source or target languages.

This restricted form of rule structure enables the simplification, analysis and modularisation of transformation definitions, and the potential partitioning of large input models into separate parts relevant to each sub-transformation.

Application conditions

Several warning signs in a transformation specification can indicate that this pattern should be applied: (i) if a transformation rule refers to entities or features across more than two levels of a metamodel composition hierarchy; (ii) if a rule contains, implicitly or explicitly, an alternation of quantifiers forAll exists forAll or longer alternation chains; (iii) if it involves the creation of more than one target instance.

These are possible signs of a lack of a coherent processing strategy within the transformation, and of excessively complex rules which can hinder comprehension, verification and reuse.

Problems (i), (ii) and (iii) are inter-related: if a rule is attempting to construct target elements at more than one hierarchical level, corresponding to more than one level in the source language, then it will (for example) be navigating from a higher to a lower level and referring to the features of lower-level objects, a double navigation. Alternation of quantifiers arise because such rules express ``For all s : Si, create a t : Tj, and for all s' contained in s create a t' contained in t".

Solution

The identified rule should be split into separate rules, each relating one source model element (or a group of source model elements) to one target model element, and navigating no further than one step higher or lower in the language composition hierarchies (and not both upwards and downwards).

The figure shows a case of the pattern where a transformation relates part of a source language metamodel (on the LHS) to part of a target language metamodel (on the RHS). Source entity type Si is considered higher in the source composition hierarchy structure than SSub, and likewise Tj in the target language is considered higher than TSub. A rule (rule2) at the Si level maps an Si instance satisfying SCond to a Tj instance satisfying TCond, and the rule also navigates down one level to lookup TSub elements previously mapped (by rule1) from SSub elements in order to set the tr feature of the Tj instances.

There are two basic variations on this pattern: (i) Bottom-up Phased Construction builds a target model starting from entities at the base of the composition hierarchy of the target language, then successively builds composite elements using their part elements; (ii) Top-down Phased Construction instead starts from the entities at the top of the target language hierarchy and builds downwards.

The choice of one or other variation depends on the structure of the target model. It is generally desirable to maintain the validity of the target model during the transformation (e.g., to simplify verification and composition of the transformation). This means that where there are mandatory associations T1 *---1 T2 in the target model, construction of T2 instances should precede construction of T1 instances. For T1 *---* T2 associations either order of construction can be chosen, whilst in the case of T1 1..*---* T2 associations, T1 instances should be created before T2 instances.

Benefits

The pattern improves the modularity of a specification by separating the creation of a composite target entity instance and the creation of its components into separate rules, which also makes the specification more comprehensible. It assists in the scheduling/control of rules, by specifying possible orders for rule execution, based upon the data dependencies of the rules. The pattern enables the decomposition of a transformation into phases, and assists in the definition of an inverse transformation if one exists. Verification of the transformation is also facilitated, since it enables decomposition of proofs based on the phases.

Phased Construction potentially enables large input models to be split into two or more smaller models, on the basis of the entity type hierarchy of the source language, and for these models to be separately processed, thus reducing memory requirements. This leads to the Phased Model Construction architectural pattern.

Disadvantages

The number of rules will increase, and some mechanism is needed by which a later rule can look-up elements that were produced by earlier rules, e.g., by some implicit or explicit tracing mechanism, or by Object Indexing. This may increase the execution cost of the transformation in terms of time and memory.

Applications and examples

The pattern is applicable to all categories of transformation except model-to-text (for which case there is no composition heirarchy structure in the target model). It may not be appropriate for refactoring or other update-in-place transformations, since their rules may be inherently inter-dependent and so need to be implemented together as parts of a single fixed-point iteration.

A large transformation using the bottom-up version of the Phased Construction pattern is the migration transformation case solution of TTC 2010 in UML-RSDS. The UML to relational mapping is also specified using the top-down version of this pattern in the Viatra manual, using explicit tracing to look up transformed model elements.

The UML to relational database example in QVT-R can be expressed using this pattern by using QVT-R top relations instead of invoked relations (relations which are only executed when invoked from the where clause of another relation):

top relation Package2Schema
{ checkonly domain uml p: Package { name = pn }
enforce domain rdbms s: Schema { name = pn }
}

top relation Class2Table
{ checkonly domain uml c : Class
{ package = p : Package {}, name = cn }
enforce domain rdbms t : Table
{ schema = s : Schema {}, name = cn }
when
{ Package2Schema(p,s); }
// p already mapped to s
}

top relation Attribute2Column
{ checkonly domain uml a : Attribute
{ owner = c : Class {}, name = an }
enforce domain rdbms cl : Column
{ table = t : Table {}, name = an }
when
{ Class2Table(c,t); }
// c already mapped to t
}

Reverse rules for an inverse transformation t~ can be deduced from transformations t in phased construction form.

Related patterns

The pattern is closely related to the concept of transformation phases and the concept of layers in AGG.

One motivation for applying the Phased Construction pattern is that it provides improved modularity compared to versions of a transformation without the pattern. In particular, many transformation languages such as QVT-R, ATL and ETL adopt a `recursive descent' style of specification, in which top-level rules apply to the entities at the top of a composition hierarchy in a source language metamodel (such as Packages in the UML to relational database transformation) and these then invoke subordinate rules at successively lower levels of the source language composition hierarchy.

Analysis of the semantics of QVT-R transformations has shown that these typically follow the recursive descent specification style, with top relations invoking non-top relations. Each such invocation may introduce a further implicit alternation of quantifiers. Our observation is that a Phased Construction approach would be a preferable alternative in many cases.