=Paper=
{{Paper
|id=Vol-1500/paper4
|storemode=property
|title=Transformation Reuse: What is the Intent?
|pdfUrl=https://ceur-ws.org/Vol-1500/paper4.pdf
|volume=Vol-1500
|dblpUrl=https://dblp.org/rec/conf/models/SalayZC15
}}
==Transformation Reuse: What is the Intent?==
Transformation Reuse: What is the Intent?
Rick Salay
Department of Computer Science, University of Toronto,
Toronto, Ontario, Canada M5S 3G4,
rsalay@cs.toronto.edu
Steen Zschaler
Department of Informatics, King's College London,
London, UK, WC2R 2LS,
szschaler@acm.org
Marsha Chechik
Department of Computer Science, University of Toronto,
Toronto, Ontario, Canada M5S 3G4,
chechik@cs.toronto.edu
Abstract
The ability to reuse transformations across a range of related meta-
models is highly desired for many model-driven approaches. For ex-
ample, it would be useful to be able to reuse standard transformations
like state-machine attening across models instantiating dierent meta-
models of hierarchical state-machines, instead of having to reimplement
the same fundamental algorithm just because of small syntactic (or
semantic) variations. Typing typically captures the question of iden-
tifying models for which a given transformation can be successfully
applied. Type compatibility between meta-models (or the related notion
of sub-typing), is intended to ensure that a transformation dened over
one type can be successfully executed over any model instantiating a
compatible meta-model. However, compatibility mechanisms have not
explicitly addressed the question of what it makes for a transformation
to be successfully applied. In this paper, we argue that answering
this question is central to a meaningful notion of transformation reuse
and must take into account the intent of a transformation and seek to
preserve it in reuse. We describe how current denitions of type com-
patibility fail to satisfy this criterion and propose a research agenda for
addressing it.
1 Introduction
Model transformations are complex artifacts that require careful engineering. To reduce development eort and
increase reliability, transformation reuse is an important tool for transformation developers. Consequently, there
has been a good bit of research focus on supporting transformation reuse [1].
A substantial amount of work has focused on notions of model typing. Specic notions of type compatibility
such as subtyping [2] or type matching [3] have been proposed to determine if a given model M2 of type T2 (an
instance of a meta-model M M2 ) can be provided as an input to a given transformation F accepting models of
type T1 (instances of a meta-model M M1 ). In each case, type compatibility is dened by a number of syntactical
constraints at the meta-model level. For example, typically, for every meta-class c1 in M M1 there must be a
corresponding meta-class c2 in M M2 such that all attributes and associations of c1 have a corresponding match
in c2 .
Interestingly, there are small variations between the specic constraint sets proposed, but it is not clear which
of the variations works better for a given situation. We believe this is in no small part due to a lack of clarity of
what it means to successfully reuse a model transformation. Clearly, transformation reuse requires preservation
of at least some properties of the original transformation F , yet the existing literature does not discuss the goal
of transformation reuse at all.
In this paper, we explore the meaning of successful transformation reuse and how such a denition would
inuence the requirements on our notion of type compatibility. After a brief overview of some of the key existing
work on transformation reuse and model typing in Sect. 2, in Sect. 3, we rst show through an example what
problems are caused if a clear notion of successful transformation reuse is missing. We then provide, in Sect. 4,
a tentative denition based on a notion of transformation intent [4] and explore its implications. We describe
one way of constructing valid type-compatibility relations in Sect. 5. It turns out that a completely formal and
(potentially) automatable treatment is non-trivial and will require substantial further research. In Sect. 6, we
outline the principal shape of any such solution and discuss key research challenges on the way.
2 Existing approaches
Typing has been an important aspect of model-driven engineering (MDE) from the very start. Models are
typed by meta-models which dene the set of modelling concepts available as well as their relationships and
valid combinations. More specic notions of typing have initially been introduced in relation to transformation
composition, in particular, to external composition or chaining where transformation signatures were used to
decide whether two given transformations could be composed safely, as we discuss below.
Initial work on external composition [5, 6] dened transformation signatures by two sets of metamodels: one
typing the models that the transformation consumed and another typing the models produced by the transfor-
mation. Later research [7] found that this information is not always sucient information for safely composing
transformations. In particular, endogenous transformations transform between models of the same metamodel,
but may well address only particular elements within this metamodel. Information about the metamodel thus
becomes useless when composing a set of endogenous transformations. In addition, some endogenous transfor-
mations may be intended to be used with a xpoint semantics (invoking them until no more changes occur),
which makes composing them even more complex. It was concluded in [7] that the metamodel needs to be aug-
mented with the particular subset of model elements that are used or aected by the transformation. In parallel
to this work, [8] also identied a need to include information about the technological space [9] of models (e.g.,
MOF or XML) into the transformation signature. Alternatively, some of this information has been encapsulated
by wrapping models as components themselves, providing interfaces for accessing and manipulating the model
independently of its technical representation [5].
Typing of models has also been studied in relation to transformation reuse. Here, sub-typing or type matching
are used to determine if a given model M1 (an instance of a meta-model M M1 ) can be provided as an input to
a given transformation T (typed over a meta-model M M2 ). Two notable approaches have been studied in this
area: model (sub-)typing and model concepts.
In his thesis and in [10], Steel introduces the notion of model typing to specify generic types for model
transformations. In this work, a model type is just another meta-model, without any distinguishing properties.
Steel then provides a set of type-checking rules dening a `matching' relationship [11] between meta-models. If
a meta-model M M1 matches a meta-model M M2 , Steel allows instances of M M1 to be passed as parameters to
transformations expecting instances of M M2 . The matches relationship is dened through a number of syntactic
rules over meta-models.
At a later stage, [2] identied some problems with Steel's matching rules, proposing a slightly more restrictive
isomorphic
set of rules instead as well as dening a number of variants of the strict matching relationship, called
model subtyping : non-isomorphic sub-typing allows the denition of an explicit model adaptation function to
translate instances of M M1 into instances of M M2 . Of particular interest are bi-directional model adaptations.
The paper further distinguishes (on a separate dimension) total and partial sub-typing, where partial sub-typing
establishes a sub-typing relationship between two meta-models only for the context of specic transformations
which are to be applied to the models. This allows matching with a generalized model type that is constructed
by keeping only those elements that are explicitly required for the execution of a model-management operation
or for access to a particular feature. Partial sub-typing is realized by providing an eective model type which is
a sub-set of the elements of a given model type and, thus, a super-type of that type. The denition of partial
sub-typing is somewhat vague in [2]. In particular, no conditions are given constraining what can or cannot be
generalized in an eective model type. Sen et al. [12, 13] present an algorithm for deriving eective model types
through static analysis of a model transformation's code. However, it is not clear what level of transformation
reuse is supported by partial sub-typing base on their algorithm.
De Lara et al. [3] and Rose et al. [14] have proposed an alternative to model typing, which they call model
concepts, consisting of the following:
1. Explicit binding model. In model typing [10], mapping a meta-model to a model type is automatic and
based on name identity. Model concepts require an explicit binding model to express which elements in
a meta-model match which elements in a model concept. This is similar to the notions of non-isomorphic
sub-typing and adaptation transformations from [2], but provides a more constructive description of the
rules governing such an adaptation.
2. Usage decorations / OCL constraints. [14] allows elements in model concepts to be decorated as either
`create' or `delete' to indicate that a model-management operation will create or delete instances of this
model element. Usage decorations imply constraints on valid bindings to ensure that multiplicity constraints
are not violated. [3] does not propose usage decorations, but instead allows model concepts to be annotated
with arbitrary OCL constraints. It remains somewhat unclear whether these constraints could be used to
address the same problem.
These ideas are usually discussed only for the input models of a model-management operation, but Cuadrado
et al. [15] also briey discuss an extension to input and output models. Cuadrado et al. [16] present a simple
component model for chaining-based reuse of model transformations based on the notion of model concepts.
In previous work [17], one of the authors has argued that typing of model transformations should explicitly
include the syntactic constraints that a transformation expects to hold rather than providing a xed meta-model.
Kuehne [18, 19] gives a theoretical discussion of sub-typinglike relationships between meta-models. Most
importantly, he notes that the validity of such relationships is often relative to context and introduces two
notions to describe such contexts: (i) observers (called referees in [19]) which provide syntactic rules, and
(ii) contexts which dene more general semantic conditions. The exact construction, in particular, of contexts,
is left somewhat open by this work.
To summarize, multiple model type compatibility relations have been proposed, diering in the degree of
automation (model sub-typing uses automated type inference, while concepts require explicit bindings to be
provided) and in the specic constraints they impose to distinguish compatible types from incompatible ones.
However, no attempts have been made to understand whether any of the approaches are valid and which ones
are better than others.
3 The validity of type compatibility
In this section, we attempt to develop criteria for checking the validity of a type compatibility relation by studying
its impact on transformation reuse. We begin by assuming that the purpose of a type compatibility relation is
reuse, i.e., types T1 and T2 are type compatible i all transformations designed for T1 are reusable for T2 . We
formalize this below:
Denition 1 (Type compatibility relation) Given a set of model types T , a type compatibility relation S
over T consists of a pair hRS , FS i, where
• RS ⊆ T × T is the relation that identies compatible types;
• FS = {Γ(T2 ,T1 ) |T1 , T2 ∈ T and RS (T2 , T1 )} is a family of higher order transformations where for every
transformation F : T1 → T 0 , we get transformation Γ(T2 ,T1 ) (F ) : T2 → T 0 .
If RS (T2 , T1 ), we say that type T2 is compatible with type T1 . We write Γ(T2 ,T1 ) as Γ when the context is clear.
In this denition, the higher order transformations Γ provide the reuse mechanism that comes with type
compatibility. In this paper, we assume Γ only aects the source model type of a transformation and leave the
more general case where it can aect both source and target types for future work. Note that in order to reuse
any transformation F : T1 → T 0 for models typed over T2 , we must rst transform it because transformations
LTS Graph
states * * transitions nodes * * edges
State src out Transition Node src out Edge
label : String 1 * label : String name : String 1 * name : String
1 * 1 *
tgt in tgt in
(a) LTS model type (b) LGraph model type
Figure 1: Two dierent model types.
are strongly typed. The literature [20] typically considers two ways of implementing Γ: (i) (conversion-based)
Γ may compose F with a transformation converting the input model from an instance of T2 into an instance of
T1 ; or (ii) (rewrite-based) Γ may rewrite the specication of F so that it works directly on models typed by T2 .
However, this denition of Γ is too simplistic as we illustrate below.
Example 1. Assume that the model type LGraph of labelled graphs is given as compatible with type LTS of
labeled transition systems by some compatibility relation S . The two types can be seen in Fig. 1. These types
are deemed compatible by the current state-of-the-art approaches:
1. Model Sub-typing [2]. There is no isomorphic sub-typing relationship between these two model types in
either direction. However, a simple bi-directional renaming model adapter can be provided (mapping LTS to
Graph, State to Node, Transition to Edge, and label to name, respectively). As a result, a non-isomorphic
sub-typing relationship could be established in either direction.
2. Model concepts [3]. Concepts are bound by providing a morphism between the meta-model M M2 and
the concept M M1 . Given that LTS and LGraph are structurally identical, such a morphism can easily be
established and is identical to the model adapter provided for the model sub-typing case.
0
Since S gives us the reuse transformation Γ, we can convert any transformation F : LTS → T into Γ(F ) :
LGraph → T 0 .
Assume that we are given the LTS transformation camelCase that changes all transition labels to camel
case (i.e., every word starts with capital letter). Aiming to apply this transformation to labeled graphs, we get
Γ(camelCase) : LGraph → LTS. Yet this is not what we wanted: camelCase was an endogeneous transformation
that manipulates LTSs while Γ(camelCase) is an exogeneous transformation that converts labeled graphs into
LTSs! Thus, clearly applying Γ to a transformation should preserve its endogeneous/exogeneous character. We
formalize this observation as a rule:
Rule 1 (Character preservation) Let types T1 , T2 ∈ T where RS (T2 , T1 ) holds be given. RS is character
preserving i for any transformation f : T1 → T 0
• (exo) If T 0 6= T1 then Γ(f ) has type T2 → T 0 .
• (endo1)If T 0 = T1 then Γ(f ) has type T2 → T2 .
• (endo2) If T 0 = T2 then Γ(f ) is undened.
By adjusting the denition of Γ to conform to Rule 1, the problem with camelCase is xed since we now get
Γ(camelCase) : LGraph → LGraph as the result of transformation reuse.
Example 2. Now consider a transformation minimize : LTS → LTS that maps an LTS to one that is be-
haviourally equivalent to it but has a minimum number of states. Reusing this transformation as Γ(minimize) :
LGraph → LGraph for labelled graphs yields a problem. While minimize has a well-dened intent for LTSs
to minimize size while maintaining behavioural equivalence this intent is not preserved by Γ(minimize).
In fact, there is no corresponding transformation for LGraph that has this intent because labeled graphs have
no semantics! Although we can technically reuse minimize, the resulting transformation is meaningless. So,
clearly, applying Γ to a transformation should preserve its intent.
We explore the implications of this observation in the next section.
4 Preservation of transformation intent
In this section, we explore what it means to preserve transformation intent. In previous work [4], we cataloged
some general transformation intents such as Refactoring, Translation, Analysis, etc. that seemed to recur in
MDE practice and characterized each intent using a set of mandatory properties. That is, every transformation
with a given intent must satisfy the corresponding mandatory properties. Since these properties must be applied
to many dierent transformations, they can be abstract and require concretization to be checkable for a specic
transformation. In the current paper, our objective is not to dene general intents but instead to capture the
intent of a particular transformation that we wish to reuse. Thus, we approach intent from a dierent perspective,
but as we shall see, we reach similar conclusions.
4.1 Intent as transformation properties
A given transformation F can be characterized by a set of properties a specication it satises that captures
its important characteristics. Given such properties, a natural way to determine what makes a transformation
F -like is that it satises the properties that characterize F . Thus, in order to support transformation reuse,
we require our higher order transformation Γ to preserve such characterizing properties. We formalize this rule
as follows:
Rule 2 (Intent preservation (rst attempt)) A type compatibility relation S is valid i for all T2 , T1 ∈ T ,
if RS (T2 , T1 ) then for all transformations f : T1 → T 0 characterized by some property Pf , the condition Pf (Γ(f ))
holds.
Unfortunately, this rule has a problem. A characterizing property like Pf is typically too specic to a given
type T1 and thus cannot be checked for transformations on other types. We illustrate this using a more detailed
analysis of transformation properties.
Although some holistic properties such as injectivity or surjectivity may in part characterize a transformation,
most transformation-specic characteristics focus on the input / output behaviour. Assume that we are interested
0
in transformations of the form f : T1 → T . The general form of a characterizing I/O property is
P (f ) := ∀x : T1 · C(x, f (x)),
where predicate C expresses a constraint that must hold between the input and output models.
For example, the transformation minimize discussed above, is characterized by the property
0 0 0
PLTS
min (f ) := ∀x : LTS · BisimLTS (x, f (x)) ∧ (∀x : LTS · BisimLTS (x , f (x)) ⇒ |x | ≤ |f (x)|))
which checks that f (x) is behaviourally equivalent to x using an LTS bisimilarity relation and then ensures that
there is no other LTS behaviourally equivalent to x that is smaller than f (x).
LTS LTS
It is clear that Pmin (minimize) holds, but when we attempt to check Pmin (Γ(minimize)), we run into a prob-
lem. Since this property is quantied over models of type LTS, it cannot be directly applied to a transformation
over models of type LGraph. To make it work we need to translate PLTS LGraph
min to some property Pmin that represents
the same intent for labeled graphs. However, as we observed above, no such property exists.
Now assume that our compatibility relation also says that state machine models (SM) are compatible with
LTSs using higher-order transformation Γ(SM,LTS) . In this case, the transformation minimize can be meaningfully
reused for state machines but we must make sure that Γ(SM,LTS) produces a transformation with the correct intent.
We can dene the characterizing property that represents the intent of minimize for state machines as follows:
0 0 0
PSM
min (f ) := ∀x : SM · BisimSM (x, f (x)) ∧ (∀x : SM · BisimSM (x , f (x)) ⇒ |x | ≤ |f (x)|))
SM
Thus, for Γ(SM,LTS) to preserve intent in this instance, we require that Pmin (Γ(SM,LTS) (minimize)) holds.
4.2 Intent as families of properties
The above discussion showed that specic characterizing properties are not sucient to dene preservation of
intent. Instead, we need something more general: a family of properties that realize the given intent for each
type of a model. In [4], we suggested that such a family can be characterized using a parameterized property that
can be concretized by lling in the parameters. For example, we might characterize the model minimization
intent as the parameterized property
hT i
Pmin (f ) := ∀x : T · BisimT (x, f (x)) ∧ (∀x0 : T · BisimT (x0 , f (x)) ⇒ |x0 | ≤ |f (x)|))
This still assumes that T is a state-based behavioural modeling language where bisimulation can be used to
check equivalence. An even more general version of the intent could be
hT i
Pmin (f ) := ∀x : T · SemEquivT (x, f (x)) ∧ (∀x0 : T · SemEquivT (x0 , f (x)) ⇒ |x0 | ≤ |f (x)|)),
where SemEquivT is the semantic equivalence relation for models of type T .
Based on these considerations, we revise the intent preservation rule:
Rule 3 (Intent preservation) Type compatibility relation S is valid i for all T2 , T1 ∈ T , transformations
f : T1 → T 0 and intents I with parameterized characteristic property PI , the following condition holds:
hT i
if RS (T2 , T1 ) and PIT1 (f ) and PIT2 exists then PIT2 (Γ(f ))
T2 hT i
Note that this rule only requires PI (Γ(f )) to hold when PIT2 exists to take into account cases such as Pmin
that does not exist for T = LGraph. This can be interpreted either as saying that the value of Γ(f ) is irrelevant
does not exist, or that Γ(f ) is undened when it does not exist (i.e., Γ is partial). In general, the
T2
when PI
latter interpretation seems more informative but may be harder to achieve in practice. That is, if Γ is a partial
transformation then an undened output can be used to indicate when a transformation cannot be reused.
5 Towards an approach for dening a valid compatibility relation
As discussed in Sect. 3, one way to dene Γ [20] is to assume that the compatibility relation between T2 and
T1 induces a transformation get(T2 ,T1 ) : T2 → T1 (or just get when the context is clear) that converts a model
of type T2 into a corresponding model of type T1 . The use of conversion (and coercion) functions is a standard
technique of type theories [21] used in programming and we adopt them for model type compatibility. Given
this conversion transformation, we can dene Γ(f )(x) := f (get(x)) for the exogenous case.
To address the endogenous case (endo1), we dene a bidirectional transformation [22] for conversion between
T1 and T2 . Following the lenses approach to bidirectional transformations [23], we dene this as a pair of
transformation hget, puti, where get is as dened as above and put has the type T1 × T2 → T2 . Bidirectional
transformations are a generalized approach to the view-update problem a T2 model is rst viewed as a
T1 model using get, then this T1 mode is updated manually or by a transformation and nally put reects this
update back in the original T2 model which it takes as one of its inputs. Thus, for the endogenous case, we dene
Γ(f )(x) := put(x, f (get(x))).
We now give the denition for a compatibility relation based on conversion transformations.
Denition 2 (Conversion-based type compatibility relation) A compatibility relation hRS , FS i is con-
version based if it provides a family of bidirectional conversion transformations {hget(T2 ,T1 ) : T2 → T1 , put(T2 ,T1 ) :
T1 × T2 → T2 i|T1 , T2 ∈ T and RS (T2 , T1 )}, and for Γ(T2 ,T1 ) ∈ FS and transformation f : T1 → T 0 , the following
hold:
• Γ(T2 ,T1 ) (f )(x) = put(x, f (get(x))), if T 0 = T1 ;
• Γ(T2 ,T1 ) (f )(x) is undened, if T 0 = T2 ; and
• Γ(T2 ,T1 ) (f )(x) = f (get(x)), otherwise.
For example, assume that we have a conversion-based compatibility relation Sbi that is limited to bijective
conversion transformations and we dene the bidirectional transformation between LGraph and LTS as follows:
• get : LGraph → LTS converts a labeled graph into an LTS by changing nodes into states, edges into
transitions and names into labels.
• put : LGraph × LTS → LGraph converts an LTS into a labeled graph by changing states into nodes,
transitions into edges and labels into names.
Note that put ignores its rst input argument (i.e., the original labeled graph) since both it and get are simple
bijective transformations and thus the original model is not needed to construct the update.
At this point, we can ask whether Γ dened as in Defn. 2 preserves the intent of particular LTS transformations.
We have seen that the transformation minimize has no corresponding transformation for labeled graphs, so the
action of Γ on this transformation is irrelevant. Unfortunately, Γ cannot tell us that this is not a case of good
reuse by being undened on this input since the conversion transformations get and put are total, and so Γ is
total as well. This points to one weakness of Sbi the conversion transformations will be total for any pair of
types dened as compatible by Sbi because they are restricted to being bijective and so we cannot rely on the
partiality of Γ to indicate when a transformation cannot be reused.
Now consider the transformation camelCase. It can be characterized by the following parameterized property:
hT i
Pcc (f ) := ∀x : T · CamelizehT i (x, f (x))
0
where CamelizehT i (x, y) holds when model x is isomorphic to model y and for each pair he, e i of elements
0
mapped by the isomorphism, the attribute of e representing its name (if one exists) is the camel case version
LTS
of the corresponding attribute of e. It is easy to see that Pcc (camelCase) holds, as we have described it and
LGraph
that Pcc (Γ(camelCase)) also holds. Thus, the intent of camelCase is preserved for this instance, but is it
preserved for any pair of compatible types in Sbi ?
The characteristic of the transformations get and put that allow this preservation is the fact that they are
bijective but also that named elements are always mapped to named elements, i.e., the meta-attribute of an
element being named is preserved by the conversion transformations. Thus, Sbi as currently dened is not
guaranteed to preserve the intent of camelCase. However, it can be xed to do so by adding the constraint that
conversion transformations must preserve named elements.
In the above example, the intent of the conversion transformations in the xed Sbi is characterized by the
property of being bijective and preserving named elements. In the general case, since Γ is formed as the com-
position of conversion transformations with the reused transformation, the problem of coming up with a good
conversion-based compatibility relation can be expressed in terms of the composition of transformation intents.
That is, we want to determine the intents of get and put so that when we compose these with a transformation f
as in Defn. 2, the intent of the result is the same as the intent of f . It should be clear that we can achieve this in
specic cases, e.g., we can determine the required intent of get and put to guarantee the intent preservation for
camelCase. It is less clear whether we can ensure the preservation of intent for a broad class of transformations.
We leave this investigation to future work.
6 Research Agenda
From our analysis in the previous sections, we have seen that intent preservation should be the driving factor
behind deciding whether a type compatibility relationship is valid. It would thus be highly benecial to provide
a simple and easily checkable (ideally, automatically) criterion of whether two model types are type-compatible
to each other. Below, we explore what is required to accomplish this.
In Sect. 5, we have discussed how Γ could be realized as a conversion transformation composed with the
transformation to be reused. We have briey discussed that for this to work, we would need to reason about
the composition of transformation intents. How to perform such a reasoning remains a research challenge. Two
things will need to be understood to this end:
1. We require a precise technique for describing transformation intents. In Sect. 4.2, we made a rst attempt at
describing transformation intent as a family of properties specied by a parameterized formula. It remains
to be understood how to correctly instantiate such a a parameterized formula, e.g., what are the constraints
for instantiating BisimT ? How can these constraints be eectively expressed and veried?
2. We require a calculus for deriving transformation intents from the composition of other transformation
intents as induced by the composition of the transformations themselves. Such a calculus can then be
employed for implementing the reasoning employed in Sect. 5.
There is another issue here as well: It seems likely that no type-compatibility relation S could preserve
0
every intent of every transformation T1 → T . Moreover, there will be weaker type-compatibility relations that
only preserve a certain subset of transformation intents, but allow more types to be considered compatible.
Consequently, we argue with Kuehne [19] that type-compatibility needs to be considered as a contextual notion
type compatibility with respect to a class of intents (perhaps written as SI for a given class I of transformation
intents). For example, we may consider LGraph and LTS compatible for intents that only consider the syntactical
structure of a model, but not for intents that refer to a model's semantics. If this is the case, then a substantial
amount of research is required to
1. Identify suitable classes of intents;
2. Identify suitable type-compatibility relations to go with each class of intents;
3. Understand whether there are classes of transformation intents for which no suitable type-compatibility
relation exists; and
4. Understand the relationships between these intent classes. For example, is there a lattice of increasingly
more constrained notions of type compatibility that provide increasing assurances while decreasing exibility
of reuse? If so, where is the sweet spot in this tradeo ?
Note that, in particular, the goal cannot be to require transformation reusers to provide a full proofat the point
of reuse that the type-compatibility relation they chose maintains the specic intent of the transformation to be
reused. Instead, they should be able to identify the class of transformation intent and reuse a type-compatibility
relation for which it has been previously proved that it maintains intents of that class. In this way, the hard
work of proving validity of type-compatibility relations can be reused.
7 Conclusion
In this paper, we aimed to assess the validity of the current proposals for model type compatibility relations [3,
2, 17] and the essence of dierences between them. In so doing, we have understood that current approaches
miss a key ingredient, namely, the intent of the transformations to be reused. While transformation intent has
been studied in other contexts [4], we have explored the potential impact of intent on transformation reuse
and our notion of type compatibility. Although we have added some more clarity to the discussion, the main
contribution of the paper is the identication of a new research agenda: we believe there is a need to explore
formal representations of transformation intent, as well as the precise relationship between transformation intent
and reuse-oriented type-compatibility relations. We invite workshop participants to join us in working on this
research agenda.
References
[1] A. Kusel, J. Schönböck, M. Wimmer, G. Kappel, W. Retschitzegger, and W. Schwinger, Reuse in
model-to-model transformation languages: are we there yet? SoSyM, vol. 14, no. 2, pp. 537572, May
2015. [Online]. Available: http://dx.doi.org/10.1007/s10270-013-0343-7
Proc. 8th
[2] C. Guy, B. Combemale, S. Derrien, J. R. Steel, and J.-M. Jézéquel, On model subtyping, in
European Conf. on Modelling Foundations and Applications (ECMFA'12), ser. LNCS, A. Vallecillo, J.-P.
Tolvanen, E. Kindler, H. Störrle, and D. Kolovos, Eds., vol. 7349. Springer, 2012, pp. 400415.
[3] J. de Lara and E. Guerra, From types to type requirements: Genericity for model-driven engineering,
SoSyM, vol. 12, no. 3, pp. 453474, 2013.
[4] L. Lúcio, M. Amrani, J. Dingel, L. Lambers, R. Salay, G. M. Selim, E. Syriani, and M. Wimmer, Model
transformation intents and their properties, Software & Systems Modeling, pp. 138, 2014.
[5] R. Marvie, A transformation composition framework for model driven engineering, University of Lille 1,
Tech. Rep., 2004, lIFL technical report 2004-n10.
Proc. 2nd
[6] A. Vignaga, F. Jouault, M. C. Bastarrica, and H. Brunelière, Typing in model management, in
Int'l Conf. on Theory and Practice of Model Transformations (ICMT'09), ser. Lecture Notes in Computer
Science, R. Paige, Ed., vol. 5563. Springer-Verlag, 2009, pp. 197212.
[7] R. Chenouard and F. Jouault, Automatically discovering hidden transformation chaining constraints, in
Proc. Int'l Conf. on Model Driven Engineering Languages and Systems (MoDELS'09), ser. LNCS, A. Schürr
and B. Selic, Eds., vol. 5795. Springer, 2009, pp. 92106.
[8] B. Vanhoo, D. Ayed, S. V. Baelen, W. Joosen, and Y. Berbers, UniTI: A unied transformation infras-
tructure, in Proc. 10th Int'l Conf. Model Driven Engineering Languages and Systems (MoDELS'07), ser.
Lecture Notes in Computer Science, G. Engels, B. Opdyke, D. C. Schmidt, and F. Weil, Eds., vol. 4735.
Springer, 2007, pp. 3145.
[9] I. Kurtev, J. Bézivin, and M. Aksit, Technological spaces: An initial appraisal, in CoopIS, DOA'2002
Federated Conferences, Industrial track, 2002. [Online]. Available: http://www.sciences.univ-nantes.fr/lina/
atl/www/papers/PositionPaperKurtev.pdf
[10] J. Steel and J.-M. Jézéquel, On model typing, SoSyM, vol. 6, no. 4, pp. 401413, 2007.
[11] K. B. Bruce, L. Petersen, and A. Fiech, Subtyping is not a good match for object-oriented
languages, in Proc. 11th European Conf. on Object-Oriented Programming (ECOOP'97), ser. LNCS,
M. Ak³it and S. Matsuoka, Eds., vol. 1241. Springer, 1997, pp. 104127. [Online]. Available:
http://dx.doi.org/10.1007/BFb0053376
Proc. Int'l Conf. on Model
[12] S. Sen, N. Moha, B. Baudry, and J.-M. Jézéquel, Meta-model pruning, in
Driven Engineering Languages and Systems (MoDELS'09), ser. LNCS, A. Schürr and B. Selic, Eds., vol.
5795. Springer, 2009. [Online]. Available: http://www.irisa.fr/triskell/publis/2009/Sen09b.pdf
[13] S. Sen, N. Moha, V. Mahé, O. Barais, B. Baudry, and J.-M. Jézéquel, Reusable model transformations,
SoSyM, vol. 11, no. 1, pp. 115, 2010. [Online]. Available: http://dx.doi.org/10.1007/s10270-010-0181-9
[14] L. Rose, E. Guerra, J. de Lara, A. Etien, D. Kolovos, and R. Paige, Genericity for model management
operations, SoSyM, 2011, published on-line rst.
[15] J. S. Cuadrado, E. Guerra, and J. de Lara, Flexible model-to-model transformation templates: An
application to ATL, Journal of Object Technology, vol. 11, no. 2, pp. 4:128, 2012. [Online]. Available:
http://dx.doi.org/10.5381/jot.2012.11.2.a4
[16] , A component model for model transformations, IEEE Trans. Software Eng., vol. 40, no. 11, pp.
10421060, 2014.
[17] S. Zschaler, Towards constraint-based model types: A generalised formal foundation for model genericity,
in Proc. 2nd Workshop on View-Based, Aspect-Oriented and Orthographic Software Modelling (VAO'14),
C. Atkinson, E. Burger, T. Goldschmidt, and R. Reussner, Eds., 2014.
Proc. Int'l Conf. on Model Driven Engineering
[18] T. Kühne, An observer-based notion of model inheritance, in
Languages and Systems (MoDELS'10), ser. LNCS, D. Petriu, N. Rouquette, and Ø. Haugen, Eds., vol. 6394.
Springer, 2010, pp. 3145.
[19] , On model compatibility with referees and contexts, Software & Systems Modeling, vol. 12, no. 3, pp.
475488, 2013.
[20] J. de Lara and E. Guerra, Towards the exible reuse of model transformations: A formal approach based
on graph transformation, Journal of Logical and Algebraic Methods in Programming, vol. 83, no. 56,
pp. 427458, 2014, 24th Nordic Workshop on Programming Theory (NWPT 2012). [Online]. Available:
http://dx.doi.org/10.1016/j.jlamp.2014.08.005
[21] Z. Luo, S. Soloviev, and T. Xuea, Coercive subtyping: Theory and implementation, Information and
Computation, vol. 223, pp. 1842, 2013. [Online]. Available: http://dx.doi.org/10.1016/j.ic.2012.10.020
[22] Z. Hu, A. Schürr, P. Stevens, and J. F. Terwilliger, Bidirectional transformation" bx"(dagstuhl seminar
11031). Dagstuhl Reports, vol. 1, no. 1, pp. 4267, 2011.
[23] J. N. Foster, M. B. Greenwald, J. T. Moore, B. C. Pierce, and A. Schmitt, Combinators for bi-directional
tree transformations: a linguistic approach to the view update problem, ACM SIGPLAN Notices, vol. 40,
no. 1, pp. 233246, 2005.
Proc. Int'l Conf. on Model Driven Engineering Languages and Systems (MoD-
[24] A. Schürr and B. Selic, Eds.,
ELS'09), ser. LNCS, vol. 5795. Springer, 2009.