Auxiliary Models
This is an architectural pattern.
Summary
Decompose a
transformation sequentially by
introducing a new auxiliary or
intermediate model to simplify
transformation processing.
Application conditions
This pattern can be applied to simplify
transformations which operate on
complex input models by adding a
preliminary transformation which
produces an intermediate representation
upon which the main transformation
can more effectively operate (e.g.,
by deriving a semantically-oriented
representation from a syntax-oriented
representation, or by re-expressing some
complex constructs in terms of simpler
ones). It may also
be introduced to facilitate evolution of
a transformation to adapt an existing
transformation to an enlarged source
metamodel without changing the
existing transformation.
It can be used to sequentially decompose
a transformation into subtransformations
which can be specified and
implemented using different transformation
languages and technologies, appropriate
for the subtransformations.
Solution
Introduce an
intermediate language S1 and
divide tau into a preliminary
transformation tau1 which produces
an intermediate auxiliary model
m1 : S1, and a main transformation
tau2 operating on
m1 : S1 to achieve the effect of the
original transformation:
Benefits
The transformation
is made more modular and its
processing is potentially simplified.
The auxiliary
model may be used by additional
transformations.
Disadvantages
Model management is complicated by the
additional model and metamodel.
Applications and examples
The
concept of an intermediate language
or interlingua is an example of this pattern,
whereby M*N pairwise mappings
between M sources and N targets are
replaced by M mappings from the
sources to a common intermediate
representation, and N mappings from
this representation to the targets.
An example is given in (Paige et al., 2010)
of an application of this pattern, to
factor a complex UML-to-PROMELA
translation into two sequential
steps, using a simplified intermediate
representation of the UML source
model semantics to facilitate the
translation.
A UML to Java translation could be
simplified by using a preliminary stage
to reduce complex constructs such as
association classes or multiple
inheritance to constructs in
a simpler UML sublanguage which
can be more directly mapped to Java.
In the UML-RSDS toolset, the translation
from UML to B uses an intermediate
representation in a metamodel for B,
as an intermediate step in generating
B textual models. The translation from
UML to Java uses an intermediate
activity model representation, this
activity model is
also used as the source for
mappings to
C\# and C++.
Related patterns
The pattern is a further progression of
Auxiliary Metamodel: in
Auxiliary
Metamodel
the auxiliary metamodel language
is used internally within a
transformation, whilst in this pattern
it is defined externally as a separate
language which is used as an input
and output for subtransformations of
the transformation.
The Model-Driven Architecture (MDA)
concept
of successive PIM to PSM and PSM to
code transformations is related to this
pattern.
(Paige et al., 2010) E. Guerra, J. de Lara, D. Kolovos, R. Paige, O. Marchi dos Santos,
transML: A family of languages to model model transformations, MODELS 2010, LNCS vol. 6394, Springer-Verlag, 2010.