Lazy Execution of Model-to-Model Transformations Massimo Tisi, Salvador Mart´ınez,Fr´ed´ericJouault, and Jordi Cabot AtlanMod, INRIA & Ecole´ des Mines de Nantes, France fmassimo.tisi, salvador.martinez perez, frederic.jouault, [email protected] Abstract. The increasing adoption of Model-Driven Engineering in in- dustrial contexts highlights scalability as a critical limitation of several MDE tools. Most of the current model-to-model transformation engines have been designed for one-shot translation of input models to output models, and present efficiency issues when applied to very large models. In this paper, we study the application of a lazy-evaluation approach to model transformations. We present a lazy execution algorithm for ATL, and we empirically evaluate a prototype implementation. With it, the elements of the target model are generated only when (and if) they are accessed, enabling also transformations that generate infinite target models. We achieve our goal on a significant subset of ATL by extending the ATL compiler. 1 Introduction Several Model-Driven Engineering (MDE) tools, when adopted in industrial con- texts, show critical effeciency limitations in handling very large models (VLMs). When these tools are built around model-to-model (M2M) transformations, the efficiency of the transformation engine risks to become a performance bottleneck for the whole MDE environment. While specific M2M transformation languages and engines have been developed since several years [12,8,3], optimizing the transformation of VLMs is just becoming a compelling research task. Lazy evaluation is one of the classical approaches that can provide, under specific conditions, a significant speed-up in program execution, especially when manipulating large data structures. When a programming language performs lazy evaluation, the value of an expression is calculated only when it is needed for a following computation (in contrast with eager evaluation, where expressions are evaluated as soon as they occur). This avoids the computation of unnecessary intermediate values. The useful part of large data structures is only calculated on-demand, even allowing for infinite-size data structures. For this reason lazy evaluation is a commonly used technique in several programming paradigms (for instance functional programming languages are classified in lazy or eager, depending on their evaluation strategy). Lazy evaluation would significantly speed-up the execution of MDE tools based on M2M transformations, e.g., in cases where only part of the VLMs 2 involved in the transformations is actually used. Unfortunately, all the M2M transformation engines we are aware of support only eager computation of the target models. Models are always completely generated according to the trans- formation logic and it is not possible to automatically avoid the computation of model elements that will not be consumed afterwards. This paper wants to provide the following contributions: 1) the study of the application of lazy evaluation to M2M transformation languages as a twofold problem, encompassing lazy navigation of the source model and lazy generation of the target model; 2) the implementation of an engine for lazy generation of the target model; 3) a practical evaluation of the lazy approach to model generation. Our approach has been implemented in a prototype of a lazy transformation engine for the ATL [8] language, obtained by adapting the standard ATL engine. Our experimentation shows that M2M transformation languages like ATL, with an explicit representation of the transformation logic, can be naturally provided with an efficient lazy evaluation strategy. Moreover, our approach to lazy generation allows the construction of an engine that can be plugged into existing tools consuming EMF models, without requiring modifications to the tools. The model is accessed like a normal EMF model, but its elements are computed on demand. Finally the lazy generation approach can be naturally applied to transfor- mations that generate an unbounded target model. Only the part of the model explicitly requested by the consumer is generated. In this way finite computa- tions can make use of infinite intermediate models generated by transformation. This represents a significant extension of the application space of existing trans- formation languages. The paper is structured as follows: Section 2 introduces the problems moti- vating the paper, by providing two running examples. Section 3 describes our approach to lazy execution of model transformations, in Section 4 we describe the implementation of a lazy engine for ATL and in Section 5 we experimentally evaluate its behavior; Section 6 discusses related work and, finally, in Section 7 we conclude the paper and propose further challenges. 2 Motivating Scenarios In this section we provide two application scenarios that are the motivation for our work, running examples of the paper and subject of our experimental evaluation. 2.1 Scenario 1: Large Models To illustrate how laziness addresses the performance problems of handling VLMs, we introduce an ideal database schema editor based on M2M transformations, whose structure is shown is Fig 1. This tool provides the user with an editor of the conceptual model of the database (in the form of a UML Class Diagram) 3 Fig. 1. A model-driven database schema editor. Fig. 2. Class and Relational metamodels. and with a transformation that generates a corresponding relational model. The user can check the relational model by using a read-only model browser. The tool uses a M2M transformation to generate the relational model from the Class diagram (the well-known Class2Relational transformation). In Fig. 2 we show the source and target metamodels of the transformation. The Class- Diagram metamodel represents a very simplified UML Class diagram. In this metamodel, Packages are containers of Classifiers that are either Datatypes or Classes. Classes can, in turn, be containers of Attributes, which can be multi- valued. The Relational metamodel describes simple relational schemas. Schema contains Tables that are composed of Columns. Finally, Columns have a type that characterizes the kind of elements they can hold. Listing 1.1 shows the main rules of the Class2Relational ATL transformation. Listing 1.1. ATL Class2Relational transformation. 1 2 rule Package2Schema f 3 from 4 p : ClassDiagram ! P a c k a g e 5 to 6 out : R e l a t i o n a l ! S c h e m a ( 7 ownedElements <− p . ownedElement −> 8 s e l e c t ( e j e . oclIsTypeOf ( ClassDiagram ! Class )) 9 ) 10 g 11 12 rule Class2Table f 13 from 14 c : ClassDiagram ! Class 15 to 16 out : R e l a t i o n a l ! Table ( 17 name <− c . name , 18 col <− Sequence f keyg−> 4 19 union ( c . attr−>s e l e c t ( e j not e . multiValued )), 20 key <− Set f key g 21 ), 22 key : R e l a t i o n a l ! C o l u m n ( 23 name <− 'objectId' , 24 type <− t h i s M o d u l e . objectIdType 25 ) 26 g 27 28 rule DataType2Type f 29 from 30 dt : ClassDiagram ! D a t a T y p e 31 to 32 out : R e l a t i o n a l ! Type ( 33 name <− dt . name 34 ) 35 g 36 37 rule DataTypeAttribute2Column f 38 from 39 a : ClassDiagram ! A t t r i b u t e ( 40 a . type . oclIsKindOf ( ClassDiagram ! D a t a T y p e ) and not a . multiValued 41 ) 42 to 43 out : R e l a t i o n a l ! C o l u m n ( 44 name <− a . name , 45 type <− a . type 46 ) 47 g 48 49 rule ClassAttribute2Column f 50 from 51 a : ClassDiagram ! A t t r i b u t e ( 52 a . type . oclIsKindOf ( ClassDiagram ! Class ) and 53 not a . multiValued 54 ) 55 to 56 f o r e i g n K e y : R e l a t i o n a l ! C o l u m n ( 57 name <− a . name + 'Id' , 58 type <− t h i s M o d u l e . objectIdType 59 ) 60 g The ATL transformation constitutes a set of rules that describe how parts of the input model generate parts of the target model. These rules must have an input pattern and an output pattern. E.g., in the rule ClassAttribute2Column input model elements of type Attribute are selected to be transformed into out- put elements of type Column. Rules can have filters and bindings. Filters are used to impose conditions on the input elements selected by the input pattern and bindings are used to initialize values of the elements created by the out- put pattern. In the rule ClassAttribute2Column, a filter is introduced to select only Attributes that are not multivalued and whose type is Class. Two bindings are then used to initialize the name and type of the created Column. The rule Class2Table creates a Table for each Class, adds a key Column and initializes the list of columns with the respectively transformed Attributes. Finally, rule Package2Schema transforms a Package into a relational Schema and initializes the list of Tables. The ATL transformation is executed in two steps. In the first step all the rules are matched creating all the corresponding target elements. Additionally, matching a rule creates, in the internal structures of the transformation engine, 5 Fig. 3. A model-driven visualizator for method-call trees. a traceability link that relates three components: the rule, the match (i.e. source elements) and the newly created target elements. In the second step, the created elements are initialized as described in the rule bindings. To perform the inizial- ization, ATL relies on a resolution algorithm that has been explained in details in [8]. Even with the very simple mapping of this scenario, when the Class dia- gram is large enough the transformation execution time can be significant.