Bidirectional model transformations in QVT:
semantic issues and open questions
Perdita Stevens
?
School of Informatics, University of Edinburgh
Abstract. We consider the OMG’s Queries, Views and Transforma-
tions (QVT) standard as applied to the specification of bidirectional
transformations be tween models. We discuss what is meant by bidirec-
tional transformations, and the model-driven development scenarios in
which they are needed. We analyse the fundamental requirements on
to ols which support such transformations, and discuss some semantic
issues which arise. We argue that a considerable amount of basic re-
search is needed before suitable tools will be fully realisable, and suggest
directions for this future research.
Keywords: bidirectional model transformation, QVT
1 Introduction
The central idea of the OMG’s Model Driven Architecture is that human intelli-
gence should be used to develop models, not programs. Routine work should be,
as far as possible, delegated to tools: the human developer’s intelligence should be
used to do what tools cannot. To this end, it is envisaged that a single platform
independent model (PIM) might be created and transformed, automatically,
into various platform specific models (PSMs) by the systematic application of
understanding conce rning how applications are best implemented on each spe-
cific platform. The OMG’s Queries, Views and Transformations (QVT) standard
[12] defines languages in which such transformations can be written.
In this paper we will discuss bidirectional transformations, focusing on basic
requirements which such transformations should satisfy.
The structure of the paper is as follows. In the remainder of this section, we
motivate bidirectional transformation, and especially, the need for non-bijective
bidirectional transformations; we then discuss related work. Section 2 briefly
summarises the most relevant aspects of the QVT standard. Sec tion 3 discusses
key semantic issues that arise. Section 4 proposes and motivates a framework
and a definition of “coherent transformation”. Finally Section 5 concludes.
In order to justify the considerable cost of developing a model transformation,
it should ideally be reused; perhaps a vendor might sell the same transformation
to many customers. However, in practice a transformation will usually have to
be adapted to the needs of a particular application. Similarly, whilst we might
?
Email: perdita@inf.ed.ac.uk. Fax: +44 131 667 7209
like to argue that only the PIM would ever need to be modified during develop-
ment, with model transformation being treated like compilation, the transformed
model never being directly edited, nevertheless in practice it will b e necessary
for developers to modify both the source and the target models of a transforma-
tion and propagate changes in both directions. The interesting albeit unfinished
document [14] makes these and other points, emphasising especially that bidi-
rectional transformations are a key user requirement on QVT, and that ease of
use of the transformation language is another key requirement.
Even in circumstances where it is in principle possible to make every change
in a single source model, and roll changes down to target models by reapplying
unidirectional transformations, in practice this is not desirable for a number of
reasons. A human reason is that different developers are familiar with different
models, and even different modelling languages. Developers are les s likely to
make mistakes if they change models they are comfortable with. A technical
reason is that some changes are most simply expressed in the vocabulary, or
with respect to the structure, of one model. For example, a single change to
one model might correspond, semantically, to a family of related changes in the
other.
Given the need for transformations to be applied in both directions, there are
two possible approaches: write two separate transformations in any convenient
language, one in each direction and ensure “by hand” that they are consistent, or
use a language in which one expression can be read as a transformation in either
direction. The second is very much preferable, because the checking required
to ensure consistency of two separate transformations is hard, error-prone, and
likely to cause a maintenance problem in which one direction is updated and the
other not, leaving them inconsistent. QVT Relational takes this second approach:
a transformation written in QVT Relational is intended to be able to be read
as a specification of a relation which should hold between two models, or as a
transformation function in either direction.
1.1 Bidirectional versus bijective transformations
A point which is vital for the reader to understand is that bidirectional trans-
formations need not be bijective. A transformation between metamodels M and
N given by a relation R is bijective if for every model m conforming to M there
exists exactly one model n conforming to N such that m and n are related by R,
and vice versa (for every model n conforming to N there exists exactly one ...).
This is an important special case because there is then no choice about what
the transformation must do: given a source model, it must return the unique
target model which is correctly related to the source. Ideally, the developer writ-
ing a bijective transformation does not have to concern herself with how models
should be transformed: it should suffice to specify the relation, which will in fact
be a bijective function. (In practice, depending on exactly how the relation is ex-
pressed, it might be far from trivial for a tool to extract the functions, however.)
Modulo information encoded in the transformation itself, both source and target
models contain exactly the same information; they just present it differently. The
classic example in the QVT standard of transformation between a UML class
diagram and a database schema is a case where both models contain almost (but
not quite) the same information, so it happens not to be a clear illustration of
the inadequacy of bijective transformations. More realistically we might express
the requirement as the synchronisation of a full UML model, including dynamic
diagrams, with a database schema, which makes it obvious that there will be
many UML models which might be related to a given schema. More generally,
bijective transformations are the exception rather than the rule: the fact that one
model contains information not represented in the other is part of the reason for
having separate models. The QVT standard [12] is somewhat ambivalent about
whether it intends all bidirectional QVT transformations to be bijective. On the
one hand, the requirements of MDD clearly imply that it should be possible
to write non-bijective transformations (see also [14]): for example, in general,
the development of a PSM will involve the addition of information concerning
design decisions on a particular platform. On the other hand, it is technically a
consequence of statements made in the QVT Relations chapter that all “valid”
transformations expressed in that language must be bijective, as we will show
below. We take the latter to be a bug in the document, or at least, a restriction
which needs to be relaxed for the promise of MDD to b e fully realised.
1.2 Related work
In the c ontext of model transformations, almost all formal work on bidirectional
transformations is based on graph grammars, especially triple graph grammars
(TGGs) as introduced by Sch¨urr (see, for example, [7]). Indeed, the definition
of the QVT core language was clearly influenced by TGGs. A master’s thesis
by Greenyer [4] studies the relationship b etween QVT (chiefly QVT core) and
TGGs, defining a translation from (a simplified subset of) QVT core into a
version of TGGs that can be input into a TGG tool. More broadly, the field of
model transformations using graph transformation is very active, with several
groups working and tools implemented. We mention in particular [8, 13]. Most
recently, the paper [2] by Ehrig et al. addresses questions about the circumstances
in which a set of TGG rules can indeed be used for forward and backward
transformations which are information preserving in a certain technical se nse. It
is future work to relate our approach to TGGs.
In this context, it may seem foolhardy to write a paper which approaches
semantic issues in bidirectional model transformations from first principles. How-
ever, there is currently a wide gap between what is desired for the success of MDD
and what is known to be soundly supportable by graph transformations; the use
of QVT-style bidirectional transformations has not spread fast, despite the early
availability of a few tools, partly (we think) because of uncertainty among users
over fundamental semantic issues; and moreover, there is a large body of quite
different work from which we may hope to gain important insights. Here we give
a few pointers.
Benjamin Pierce and colleagues in the Harmony group have explored bidirec-
tional transformations extensively in the context of trees [3], and more recently
in the context of relational databases [1]. In their framework, a lens, or bidirec-
tional transformation, is a pair of functions (a “get” function and a “putback”
function) which are required to satisfy certain properties to ensure their coher-
ence. They define a number of primitive lenses, and combinators with which to
build more complex le nses . Thus, they define a programming language operating
on trees in which a program can be read either forwards or backwards. Coherence
of the forward and backward readings of the program follows from properties of
the primitives and combinators. Their framework is asymmetric, however: their
forward transformation is always a function on the source model only, which,
in conjunction with their coherence conditions, implies that the target m odel is
always an abstraction of the source model: it contains less information. This has
advantages and disadvantages. It is insufficiently flexible to serve as a framework
for MDA-style model transformations in general, but the restriction permits cer-
tain constructs, especially composition, to work in a way which does not seem
to be possible in the more general setting. We shall return to this work later in
the paper.
Bidirectional programming languages have been developed in various areas,
and a survey can be found in [3]. Notably Lambert Meertens’ paper [9] addresses
the question of developing “constraint maintainers” for use in user interface de-
sign, but his approach is far more general. His maintainers are essentially model
transformations which, in terms we shall introduce below, are required to be
correct and hippocratic, but not undoable. In [6], Kawanaka and Hosoya develop
a bidirectional programming language for XML. In Tokyo, Masato Takeichi and
colleagues Shin-Cheng Mu and Zhenjiang Hu have also worked extensively on
an algebraic approach to bidirectional programming: see [10, 11, 5].
2 QVT
The OMG’s Queries, Views and Transformations (QVT) standard [12] addresses
a family of related problems which arise in tool-supported model driven devel-
opment. Not all information which is modelled is relevant at any one time, so
there is a need to be able to abstract out the useful information; and models
need to be held in meaningful relationships with one another. Provided that we
permit non-bijective transformations (required to support m odel views), trans-
formations subsume views.
The QVT standard describes three languages for transformations: the Op-
erational, Relational and Core languages. The Relational language is the most
relevant here. In the Operational language, someone wishing to specify a bidi-
rectional transformation would have to write a pair of transformations and make
them consistent by hand, which we have already said is undesirable. QVT Core
is a low level language into which the others can be translated; an example trans-
lation from QVT Relational to QVT Core is given in the standard. Since we are
concerned with transformations as expressed by users, we will work with QVT
Relational.
The issue of whether transformations expressed in QVT Relational are sup-
posed to be bijective is not explicitly discussed, but it seems to be a – possibly
unintended – consequence of statements made in [12] that they must be. Specif-
ically, QVT transformations are given a “check then enforce” semantics which
means that a transformation must not modify a target model if it is already
correctly related to the source model. At the same time, [12] page 18 states:
In relations, the effect of propagating a change from a source model to a tar-
get model is semantically equivalent to executing the entire transformation
afresh in the direction of the target model.
This seems to imply that if a transformation is to propagate changes made in a
source model m to a target model n, the new target model that results must be
independent of the old one: the result of the transformation must depend only
on m, since it is equivalent to “exec uting the entire transformation” on m. In
other words given m, there is a unique target model n which must result from
executing the transformation. Now suppose that there is also a different model
n
0
which is correctly related to m. Of course, this is quite compatible with the
functional interpretation of transformation given in the above quotation: it could
happ e n that even though n
0
would be a correct target model, n is the one which
happ e ns to be produced when the transformation is run on m. In this case, if
the transformation is run in a situation where the source model is m and the
target model is n
0
, the target model must be transformed into n, even though n
0
was already correctly related to m. This, however, is exactly what is forbidden
by the “check then enforce” semantics: given that n
0
is already correctly related
to m, it must not be modified by running the transformation. If the situation of
running a transformation on models which are already correctly related seems
too artificial, the reader may prefer to consider a situation in which a target
model may be put in correct relation with a source model in two different ways:
either by making a tiny change to turn it into one correctly related model, or by
making a large change to turn it into a different correctly related model. It will
be natural to want the transformation to make the m inimal possible changes to
ensure relatedness (and, indeed, the text in [12] immediately following the above
quotation suggests that this is intended). Interpreting the quoted text literally,
though, forbids the transformation to give different results depending on how
close the existing target model is to each correctly related target model.
It might be possible to interpret “semantically equivalent” in the above quo-
tation so as to resolve this problem, but this seems forced (since it would require
being able to regard models which contained very different information as being
“semantically equivalent”). A better solution seems to be to assume that the
above quotation is unintentionally restrictive, and disregard it.
3 Semantic issues
In this section we raise a variety of issues which we consider to need further
study: they are settled neither by the QVT s tandard, nor as far as we know by
existing related work.