A Survey on Incremental Model Transformation
Approaches
Angelika Kusel1 , Juergen Etzlstorfer1 , Elisabeth Kapsammer1 , Philip Langer2 ,
Werner Retschitzegger1 , Johannes Schoenboeck3 , Wieland Schwinger1 , and
Manuel Wimmer2
1
Johannes Kepler University Linz, Austria
[firstname].[lastname]@jku.at
2
Vienna University of Technology, Austria
[lastname]@big.tuwien.ac.at
3
University of Applied Sciences Upper Austria, Campus Hagenberg, Austria
[firstname.lastname]@fh-hagenberg.at
Abstract. Steadily evolving models are the heart and soul of Model-
Driven Engineering. Consequently, all dependent model transformations
have to be re-executed to reflect changes in related models, accordingly.
In case of frequent, but only marginal changes, the re-execution of com-
plete transformations induces an unnecessary high overhead. To over-
come this drawback, incremental model transformation approaches have
been proposed in recent years. Since these approaches differ substantially
in language coverage, execution, and the imposed overhead, an evaluation
and comparison is essential to investigate their strengths and limitations.
The contribution of this paper is a dedicated evaluation framework for
incremental model transformation approaches and its application to a
representative subset of recent approaches. Finally, we report on lessons
learned to highlight past achievements and future challenges.
1 Introduction
In Model-Driven Engineering (MDE), models are first-class artifacts throughout
the software life-cycle [3]. Transformations of these models are comparable, in
role and importance, to compilers for high-level programming languages, since
they allow, e. g., to bridge the gap between design and implementation [14]. Like
any other software artifact, models are subject to constant change, i. e., they
evolve, caused by, e. g., changing requirements. Therefore, dependent models,
which have been derived from the original models by means of transformations,
have to be updated appropriately. A straight-forward way is to re-execute the
transformations entirely, i. e., in batch mode. In case of minor changes on large
models consisting of several thousand elements [21], however, re-execution of a
complete transformation is not efficient [12, 13, 18]. Consequently, it is of utmost
importance, to transform those elements that have been changed, only, which is
commonly referred to as incremental transformation [8, 17].
Several incremental model transformation approaches focusing on different
transformation languages have been proposed recently. Although all of them
aim at the efficient propagation of changes, they differ substantially, not only
since basing on different transformation languages. However, no dedicated survey
has been brought forward so far, which would be essential to highlight past
achievements as well as future challenges. To alleviate this situation, in this
paper, first, a dedicated evaluation framework is proposed (cf. Section 2), whose
criteria are not only inspired by the MDE domain (cf., e. g., [8]), but also by
related engineering domains like data engineering, e. g., in terms of incremental
maintenance of materialized views (cf., e. g., [10]), where incremental approaches
are used since decades. Second, this framework is applied to a carefully selected
set of incremental transformation approaches to achieve an in-depth comparison
(cf. Section 3). Third, lessons learned are derived from this comparison and
presented in Section 4 to highlight past achievements and future challenges.
Finally, Section 5 concludes the paper.
2 Evaluation Framework
In this section, the proposed criteria for the evaluation of incremental model
transformation approaches are presented. The set of criteria for evaluating the
incremental transformation approaches has been derived in a bottom-up manner
by examining dedicated approaches as well as in a top-down manner by review-
ing surveys in related engineering domains (cf., e. g., [10]) – methodologically
adhering to some of our previous surveys, e. g., [24]. This process resulted in
an evaluation framework (cf. Fig. 1), comprising the three categories of (i) lan-
guage coverage for explicating those parts of a transformation language that are
considered for incremental execution (cf. Section 2.1), (ii) execution phases for
highlighting how incrementality is achieved at run-time (cf. Section 2.2), and (iii)
overhead for pointing out the additional efforts needed to achieve incrementality
(cf. Section 2.3).
Incremental Model Transformations
Language Coverage Execution Phases Overhead
Declarative Parts Change Detection Impact Analysis Change Specification
• Number of Input Elements • Source Minimality • Required Knowledge of Propagation Run-time
• Number of Output Elements • Type & Number Transformation Specification • Time Memory
• Conditions - Atomic Changes - Black Box • Coverage
- Negative Application Conditions - Composite Changes - White Box • Granularity
- Positive Application Conditions • Granularity • Trace • Direction
• Assignments • Change Log - Model2Model • Strategies
• Rule Inheritance Optimization - Model2Transformation
Imperative Parts • Auxiliary Information
Fig. 1. Evaluation Criteria for Incremental Model Transformation Approaches
2.1 Language Coverage
The first set of criteria reveals the language coverage, i. e., which parts of a trans-
Change Detection Dependency Detection Change Propagation
formation language may be•Time
•Type
executed incrementally. In•Timegeneral, model trans-
•Granularity
formations are specified by•Generated
a set Information •Coverage
of rules that comprise input patterns with
•Change Log Optimization •Trace Minimality? •Granularity
•Source Minimality •Directionality
•Strategies
conditions that match source model elements, and output patterns that pro-
duce elements of the target model. Thereby, source and target models have to
conform to their corresponding metamodels. Furthermore, transformation rules
may be inherited for reuse (cf. [23] for an overview). Such transformation spec-
ifications may comprise declarative and imperative transformation parts. Since
current incremental transformation approaches mostly focus on the support of
incremental execution of declarative language parts [15], this category has been
further broken down into the criteria number of input and output elements, condi-
tions, assignments, and rule inheritance. Among those, conditions play a special
role in incremental model transformations, since negative application conditions
(NACs) may lead to non-monotonicity, e. g., insertion of elements in the source
model entails a deletion of elements in the target model [11, 20], and positive
application conditions (PACs) may cause non-continuity, i. e., a non-uniform
treatment of model elements, e. g., new elements in a container may be trans-
formed differently than previously added elements to the same container [20].
2.2 Execution Phases
Any incremental approach may be characterized by three dedicated execution
phases, comprising (i) change detection, i. e., detection of changes in the source
model, (ii) impact analysis, i. e., detection of parts of the transformation that
must be executed to reflect the changes, and (iii) change propagation, i. e., the
actual execution of the affected transformation parts as well as the update of
the target model.
Criteria for Change Detection. For detecting changes, basically two ap-
proaches may be followed, comprising (i) state-based comparison of the changed
source model to its previous version, and (ii) operation-based detection of changes
by directly recording each change [7]. Although (i) may allow for tool indepen-
dence, run-time performance depends on the size of the source model. Thus, with
regard to run-time performance, (ii) is preferable and is referred to as source
minimality [8], representing the first criterion. Change detection may be further
characterized by the type of the detected changes, including atomic operations,
i. e., insert and delete, and composite operations, e. g., update and move, which
may be composed by combining atomic operations and may allow for reducing
the number of change propagation operations to be executed, by substituting
insert and delete operations. Another criterion is the granularity of the detected
changed elements, ranging from coarse granularity, i. e., on the level of objects,
only, to fine granularity, i. e., on the level of values and links, which is preferable,
since it allows for a more precise detection. Finally, change detection may be ca-
pable of detecting single or multiple changes at once, whereby the latter utilizes
a change log and may allow to reason on inter-dependencies between changes,
thereby facilitating change log optimization. In this context, for instance, change
operations that cancel others may be detected and optimized, e. g., a rename
operation for an element that is subsequently deleted may be removed.
Criteria for Impact Analysis. For impact analysis, the impact of changes on
target models must be detected by (i) utilizing knowledge from the transforma-
tion specification and (ii) employing information that relates the transformations
and the models during execution. Concerning the knowledge of the transfor-
mation, approaches, which require white-box knowledge, i. e., insights into the
internal structure, may allow for a more precise detection of affected transfor-
mation parts compared to those, where black-box knowledge, i. e., the inputs and
outputs, are considered, only. For (ii), it is of utmost importance to recognize
those transformation parts that must be executed, requiring a Model2Trans-
formation (M2T) trace. Such a trace may be either created at compile-time by
analyzing the bound metamodel types or at run-time by keeping track of the ex-
ecution of the transformation. Additionally, a dynamically created Model2Model
(M2M) trace is obligatory to relate the elements of the source model to those
in the target model. Besides these traces, additional auxiliary information, such
as internal execution states or intermediate results may be utilized, to further
improve incrementality.
Criteria for Change Propagation. Finally, changes detected in the first phase
have to be propagated to the target model utilizing dependency information ex-
posed in the second phase. Change propagation may differ in (i) time, i. e., when
the changes are propagated, (ii) coverage, i. e., the amount of changes to be
propagated, (iii) granularity, i. e., the degree of transformation code to be re-
executed, (iv) directionality, i. e., the direction of change propagation between
source and target, and, finally, (v) strategies, i. e., different plans to propagate
the changes. Concerning time, eager means that changes in the source model are
propagated synchronously to the target model, whereas lazy induces an asyn-
chronous propagation. Propagation may cover either the complete set of changes
at once or a part of it, only, e. g., single changes. The propagation of single
changes is useful to allow for change propagation on demand, i. e., only when
the affected target model elements are accessed. According to the granularity of
the change propagation, either a complete rule or a single binding (or assign-
ment) has to be re-executed, whereby the latter case results in modifying fewer
elements in the target model. Furthermore, changes may be either propagated
from a dedicated source to a target model, i. e., unidirectional or also vice versa,
i. e., bidirectional. Bidirectionality can be either achieved by utilizing dedicated
bidirectional model transformation languages (e. g., TGGs [22] or JTL [6]) or by
connecting source and target model elements via traces and potentially restrict-
ing transformation language expressiveness to enable bidirectional propagation.
Therefore, this criterion is included in the propagation phase. Finally, different
strategies for updating the target model may be applied, e. g., executing mul-
tiple updates sequentially or in parallel, that may be selected automatically or
manually.
2.3 Overhead
The final set of criteria aims at pointing out overheads that result from incre-
mentality. Such overheads may arise with respect to three different areas, being
(i) specification, i. e., whether the transformation designer must use a dedicated
syntax resulting in a new specification, (ii) run-time, i. e., whether additional
run-time is consumed in contrast to batch transformations, and (iii) memory,
i. e., whether additional memory is consumed compared to batch transforma-
tions.
3 Comparison of Approaches
After having presented the evaluation framework in the previous section, in this
section it is applied to selected approaches. The results of the application are
summarized in Table 1. The selection of approaches for incremental model trans-
formations comprises approaches that facilitate incremental execution of user-
specified transformations. Hence, approaches that e. g., aim at efficient batch
transformations or support incrementality for specific applications, only, are not
covered in the comparison (e. g., [5, 6, 19]). Eight approaches across different
transformation languages that meet these criteria have been identified in the lit-
erature and, therefore, participate in the evaluation. Three of them are of declara-
tive nature, whereby two base on Triple Graph Grammars (TGGs) [9,16] and one
on the Tefkat transformation language [11]. The remaining five approaches allow
for hybrid transformation code, i.e., declarative and imperative parts. Among
them, one approach bases on the Atlas Transformation Language (ATL) [13],
three on the graph-transformation-based Viatra2-framework [1, 2, 18], and one
approach enables incrementality by abstracting from the actual transformation
specification and by relating source and target model elements, only [20].
3.1 Language Coverage
In the context of declarative language parts, six of the eight approaches [1, 2, 9,
11, 16, 18] support an arbitrary number of input and output elements, i. e., M:N
mappings. One approach [13] restricts itself to a single input element, but allows
for an arbitrary number of output elements, i. e., 1:N mappings, and another
approach [20] may handle 1:1 mappings, only. Interestingly, NACs and PACs,
although quite challenging, are supported by all except one approach [20]. While
assignments are naturally supported by all approaches, support for rule inheri-
tance is not that widespread. Only one approach may handle rule inheritance in
incremental transformations, since the transformation specification is regarded
as black-box and, therefore, inherited rules do not impact the approach [20]. The
remaining approaches do either exclude rule inheritance for incremental trans-
formation [11, 16], explicitly refer to the support of rule inheritance as future
work by flattening the inheritance hierarchy [13], do not support rule inheri-
tance at all [9], i. e., also not in batch mode, or support rule inheritance for
the pattern matching part in transformation rules, only [1, 2, 18]. In contrast
to the comprehensive support for declarative language parts, imperative parts
are either completely re-executed [1, 2, 18], thereby resigning the advantages of
incrementality, regarded as black box [20], which may violate correctness, or not
allowed at all [13].
In summary, one may see that incremental model transformation approaches
suffer from restricted language coverage in terms of rule inheritance and imper-
ative parts, and thus, not all potential for incremental execution is exploited so
far.
3.2 Execution Phases
Change Detection. Regarding change detection, all approaches detect changes
operation-based and, therefore, comply with source minimality. Atomic changes
are supported by all approaches. Concerning composite changes, six approaches
support update operations [1, 2, 9, 13, 18, 20]. Move operations are explicitly sup-
ported by two approaches [2, 9]. Four approaches are able to detect multiple
change operations [2, 9, 16, 18]. However, only one of them actually supports an
optimization of the change log [18]. One approach, although being able to de-
tect multiple changes, considers the model difference instead of a change log,
and, therefore, eludes the need for change log optimization [16], while for an-
other approach the optimization effort is usually higher than the actual propa-
gation effort, and, therefore, change log optimization is omitted [9]. Considering
the granularity of changes, all approaches enable the detection of fine-grained
changes.
Summing up, current approaches mostly lack the detection of multiple, com-
posite change operations and a change log optimization. Support for those cri-
teria would favor an optimized change propagation resulting in fewer operations
on the target model.
Impact Analysis. Seven of the eight approaches require white-box knowl-
edge of the transformation for analyzing rules and generating trace informa-
tion [1, 2, 9, 11, 13, 16, 18], while one approach considers the specification of the
batch transformation as a black box [20]. The M2T trace is generated by seven
approaches [1, 2, 9, 11, 13, 16, 18] at run-time, while two of them generate parts
of this trace at compile-time [1, 13]. One approach does not generate any M2T
trace at all [20], but lacks comprehensive language coverage. All approaches dy-
namically generate M2M traces. Concerning auxiliary information, one approach
stores the complete transformation context in terms of an SLDNF-tree (Selective
Linear Definite clause with Negation as Failure) [11], one generates dedicated
rules for change propagation at compile-time [13], and in [2] so-called Change
History Models are used as input for the change propagation. One approach [1]
creates database tables for each match pattern in a transformation specification
and employs triggers for change detection, while in [20] a so-called Concept Pool
is utilized, which holds similar concepts between source and target models to
enable bidirectional change propagation.
In summary, one may see that all approaches require trace information and
most approaches rely on auxiliary information to further leverage incrementality.
Change Propagation. Three approaches propagate changes in an eager man-
ner [1, 11, 18]. Four approaches allow for lazy propagation by letting the user
decide when to apply the changes on the target model [2, 9, 13, 16]. Finally,
one approach allows for both, synchronous and asynchronous, change propa-
gation [20]. The same approach also supports partial propagation. Five of the
eight approaches re-execute a complete rule [1, 2, 9, 16, 18], while two approaches
are capable of re-executing a single binding, only [11, 13]. Those two rely on
auxiliary information, being the complete execution context [11] or fine-grained
compiler-generated rules [13]. One approach does not consider rules or bindings
of the batch transformation specification to be re-executed, since the transfor-
mation is regarded as a black-box [20]. Concerning directionality, TGGs support
bidirectionality [9, 16], while other approaches allow for unidirectional change
propagation, only [1, 2, 11, 13, 18]. One approach aims at deriving a bidirectional
model transformation from a unidirectional transformation specification, but is
limited in terms of language coverage [20]. Solely the approaches that build on
the Viatra2-framework offer manual selection of strategies in terms of sequen-
tial or parallel execution of change propagation [1, 2, 18].
Summing up, current incremental model transformation approaches mostly
propagate changes synchronously with a predefined strategy. Thereby, situations
that may require different execution strategies for efficient incremental execution
may not be handled satisfactorily.
3.3 Overhead
Regarding the induced overheads, two of the eight approaches require a new spec-
ification by the transformation designer to allow for incremental execution [2,18].
Concerning run-time overheads, three approaches state, that even in the worst
case (i. e., the complete source model has been changed) incremental execution is
as fast as batch transformation, i. e., no run-time overhead occurs [2,9,16], while
the remaining approaches lack any statement on this fact. Finally, all approaches
accept memory overheads in terms of traces and auxiliary information.
In summary, one may see that most approaches introduce incrementality by
changes to the execution engine instead of requiring a new syntax for transforma-
tion specifications, which is favorable, since then incrementality is transparent
to the transformation designer. All approaches induce memory overheads due
to the generation of traces and auxiliary information, which are, nevertheless,
essential for incremental execution [12].
4 Lessons Learned
In this section, lessons learned gained from the evaluation and comparison of
approaches are discussed along the different evaluation categories.
Insufficient Support for Imperative Parts. While all examined approaches
support declarative language parts, they lack sufficient support for imperative
parts, which are either disregarded at all or treated as black box, i. e., executed
completely, instead of breaking them down into fine-grained parts. Consequently,
extensive support for imperative parts, e. g., by exploiting incremental evaluation
of conditions and bindings [4], may further leverage incrementality.
Language Coverage Execution Phases Over-
Declarative Parts Change Detection Impact Analysis Change Propagation head
Req.
Different Execution Strategies
Condi- Granu- Cover- Granu- Direc- Strat-
Type & Number Know- Trace Time
Number of Output Elements
tions larity age larity tion egy
No Specification Overhead
Revisions of Target Model
Number of Input Elements
ledge of
Change Log Optimization
Model
Language / Framework
Transfor-
No Run-time Overhead
No Memory Overhead
Com- 2
Eager (Synchronous)
Lazy (Asynchronous)
mation
Live Transformation
Atomic
Auxiliary Information
Conflict Resolution
posite Specifi- Trans-
Source Minimality
Imperative Parts
Rule Inheritance
cation form.
deterministic r
Unidirectional
Model2Model
Compile-time
Bidirectional
Assignment
Approach
White Box
Complete
Black Box
Selection
Run-time
Number
Binding
Update
Object
Partial
Delete
NACs
PACs
Value
Insert
Move
Rule
Link
example used for evaluat
1..* 1..* n.a. n.a. 1..* 1..* 1..* 1..* - - - 1 - -
Declarative
[9] TGG - - - - - - - - -
[16] TGG 1..* 1..* - n.a. 1..* 1..* - - n.a. - - - - - - - 1 - -
SLDNF
[11] Tefkat 1..* 1..* - n.a. 1 1 - - n.a. - - - - - - 1 - u. -
tree - - - - class2relational
Compiler
[13] ATL 1 1..* - - 1 1 1 - n.a. - Generated - - - - 1 - u. -
Hybrid (Decl. + Imp.)
Rules - - - - class2relational
[18] VIATRA2 1..* 1..* ~ 1..* 1..* 1..* - - - - - - - - 2 m. - u. - - - ~ -
Change
[2] VIATRA2 1..* 1..* ~ 1..* 1..* 1..* 1..* - - - History - - - - 2 m. - -
Models - - -
Database
[1] VIATRA2 1..* 1..* ~ 1 1 1 - n.a. - - - - - 2 m. u. -
Tables
Arbi- Concept
[20] 1 1 - - ~ 1 1 1 - n.a. - - - n.a. n.a. - 1 - u. -
trary Pool - - - - java2wsdl axis trafo
Legend: ... supported - ... not supported ~ ... partially supported * ... multiple n.a. ... not applicable m. ... manual u. ... unknown
Tratt PMT
Table 1..*
1.1..*Comparison
? Table
1..* 1..* 1..* - -
of Incremental - Transformation
Model - - - Approaches
- - 2 m. - ? -
Hass QVT 1 1 - - n.a. n.a. (1) 1 1 n.a. - KB - - n.a. n.a. - 1 - - -
-
Gie
se2
3 009 TGG, Fuj ? 1 1 1 - - - - - - - - - - - - sld blocks to class diagram
8 Varr graph trafo ? ? ? ? ? ? - - - - - incr. graph tra
Focus on Basic Change
7 RazaQVT-OM Operations.
- - -
Atomic
- -
change operations are sup- - - books2libr efficient batch
ported by all -
approaches. However, support for composite change operations,
8 Tisi2ATL * - - - - - - class2relat lazy transform
such QVT- as update and move, is not that widespread, but would allow for a more
Relatio
efficientnal, change propagation by utilizing according change propagation opera-
tions. medini
9 SongQVT - spec. incr. eng
10 VogeTGG, runtime monitoring? based on Gies
Trace
Joh
Information is Mandatory. All approaches rely on trace information.
ann IBM
Furthermore, the more trace information is generated to relate elements of source
200 Rationa
and
11 4 target
l Rose models as well as model elements and the transformation specification, framework for
12 Cicc hybrid multi-view modelling hybrid multi-v
the more accurateness in change propagation may be achieved. Of course, this
13 Emo future work
is the general trade-off between space and time in computing.
Lack of Appropriate Propagation Strategies. Current incremental model
propagation granularity: +approaches
transformation filter, + imperative teiledo not provide different propagation strategies ac-
wie unterscheiden sich ansätze?
cording
was könnentosie NICHT?
a given change
(siehe outlook situation.
und conclusion von versch. In case of many changes, re-execution of a
paper)
batch transformation
einschränkungen der ansätze in tabelle may
aufnehmenoutperform the run-time performance of incremental
execution in certain cases. An automatic selection of an appropriate propaga-
tion strategy could be achieved by analyzing the changes, the transformation
specification, and the traces.
Lack of Proof of Correctness. Apart from one approach [16], correctness
of the incremental model transformation approaches is not proven. Thus, for-
mal proofs for correctness would be highly beneficial for the confidence of the
incremental transformations.
5 Conclusion
In this paper, we presented a survey on incremental model transformation ap-
proaches. Therefore, criteria for evaluating and comparing incremental model
transformation approaches have been proposed. Eight recent approaches have
been compared according to the criteria and lessons learned have been presented.
Summing up, although several approaches for incremental model transfor-
mations exist, there is still space for improvements including (i) better support
for imperative language parts, (ii) more efficient change propagation with ded-
icated change operators, (iii) provision and automatic selection of appropriate
propagation strategies, and (iv) proving correctness of incremental model trans-
formations.
Acknowledgements
We would like to thank Stephan Hildebrandt, Marius Lauder, Anthony Anjorin,
Ali Razavi, István Ráth, Gábor Bergmann, Salvador Martı́nez Pérez, and Mas-
simo Tisi for their helpful comments on the paper.
This work has been funded by the Austrian Federal Ministry for Transport,
Innovation and Technology (bmvit) under grant ffg bridge 832160 and ffg
fit-it 825070 and 829598, ffg Basisprogramm 838181, and by öad under grant
AR18/2013 and UA07/2013.
References
1. Bergmann, G., Horváth, D., Horváth, A.: Applying Incremental Graph Transfor-
mation to Existing Models in Relational Databases. In: 6th Int. Conf. on Graph
Transformations. Springer (2012)
2. Bergmann, G., Ráth, I., Varró, G., Varró, D.: Change-driven model transforma-
tions. SoSym 11(3) (Jul 2012)
3. Bézivin, J.: On the Unification Power of Models. SoSym 4(2) (May 2005)
4. Cabot, J., Teniente, E.: Incremental Evaluation of OCL Constraints. In: 18th Int.
Conf. on Advanced Information Systems Engineering. Springer (2006)
5. Cicchetti, A., Ciccozzi, F., Leveque, T.: Supporting Incremental Synchronization
in Hybrid Multi-view Modelling. In: Int. Conf. on Models in SE. Springer (2012)
6. Cicchetti, A., Di Ruscio, D., Eramo, R., Pierantonio, A.: JTL: A Bidirectional
and Change Propagating Transformation Language. In: Int. Conf. on Software
Language Engineering. Springer (2011)
7. Conradi, R., Westfechtel, B.: Version Models for Software Configuration Manage-
ment. ACM Comp. Surv. 30(2) (Jun 1998)
8. Czarnecki, K., Helsen, S.: Feature-Based Survey of Model Transformation Ap-
proaches. IBM Systems Journal 45(3) (Jul 2006)
9. Giese, H., Hildebrandt, S., Neumann, S.: Model Synchronization at Work: Keeping
SysML and AUTOSAR Models Consistent. In: Graph Transformations and Model-
Driven Engineering. LNCS, vol. 5765. Springer (2010)
10. Gupta, A., Mumick, I.S.: Maintenance of Materialized Views: Problems, Tech-
niques, and Applications. IEEE Data Eng. Bull. 18(2) (1995)
11. Hearnden, D., Lawley, M., Raymond, K.: Incremental Model Transformation for
the Evolution of Model-Driven Systems. In: 9th Int. Conf. on Model Driven Engi-
neering Languages and Systems. Springer (2006)
12. Johann, S., Egyed, A.: Instant and Incremental Transformation of Models. In: 19th
Int. Conf. on Automated Software Engineering. IEEE (2004)
13. Jouault, F., Tisi, M.: Towards Incremental Execution of ATL Transformations. In:
3rd Int. Conf. on Theory and Practice of Model Transformations. Springer (2010)
14. Kappel, G., Langer, P., Retschitzegger, W., Schwinger, W., Wimmer, M.: Model
Transformation By-Example: A Survey of the First Wave. In: Conceptual Mod-
elling and Its Theoretical Foundations. Springer (2012)
15. Kolovos, D., Paige, R.F., Polack, F.A.: The Grand Challenge of Scalability for
Model Driven Engineering. In: Models in SE. Springer (2009)
16. Lauder, M., Anjorin, A., Varró, G., Schürr, A.: Efficient Model Synchronization
with Precedence Triple Graph Grammars. In: 6th Int. Conf. on Graph Transfor-
mations. Springer (2012)
17. Mens, T., Van Gorp, P.: A Taxonomy of Model Transformation. ENTCS 152 (Mar
2006)
18. Ráth, I., Bergmann, G., Ökrös, A., Varró, D.: Live Model Transformations Driven
by Incremental Pattern Matching. In: 1st Int. Conf. on Theory and Practice of
Model Transformations. Springer (2008)
19. Razavi, A., Kontogiannis, K.: Partial Evaluation of Model Transformations. In:
Proc. of the 2012 Int. Conf. on Software Engineering. IEEE Press (2012)
20. Razavi, A., Kontogiannis, K., Brealey, C., Nigul, L.: Incremental Model Synchro-
nization in Model Driven Development Environments. In: Conf. of the Center f.
Adv. Studies on Collab. Research. IBM (2009)
21. Scheidgen, M., Zubow, A., Fischer, J., Kolbe, T.H.: Automated and Transparent
Model Fragmentation for Persisting Large Models. In: 15th Int. Conf. on Model
Driven Engineering Languages and Systems. Springer (2012)
22. Schürr, A.: Specification of Graph Translators with Triple Graph Grammars. In:
Graph-Theoretic Concepts in Computer Science. Springer Berlin Heidelberg (1995)
23. Wimmer, M., Kappel, G., Kusel, A., Retschitzegger, W., Schönböck, J., Schwinger,
W., Kolovos, D., Paige, R., Lauder, M., Schürr, A., Wagelaar, D.: Surveying Rule
Inheritance in Model-to-Model Transformation Languages. Journal of Obj. Techn.
11(2) (Aug 2012)
24. Wimmer, M., Schauerhuber, A., Kappel, G., Retschitzegger, W., Schwinger, W.,
Kapsammer, E.: A Survey on UML-Based Aspect-Oriented Design Modeling. ACM
Comp. Surv. 43(4) (Oct 2011)