QVTR2 : a Rational and Performance-aware Extension to the Relations Language? Mauro Luigi Drago, Carlo Ghezzi, and Raffaela Mirandola Politecnico di Milano DeepSE Group - Dipartimento di Elettronica e Informazione Piazza Leonardo Da Vinci, 32 - 20133 Milano, Italy (drago|ghezzi|mirandola)@elet.polimi.it WWW home page: http://deepse.dei.polimi.it Abstract. Model transformations glue together models in an MDE pro- cess and represent the rationale behind it. It is however likely that in a design/development process different solutions (or alternatives) for the same problem are available. When alternatives are encountered, engi- neers need to make a choice by relying on past experience and on quality metrics. Several languages exist to specify transformations, but all of them bury deep inside source code rational information about perfor- mance and alternatives, and none of them is capable of providing feed- back to select between the different solutions. In this paper we present QVT-Relations Rational (QVTR2 ), an extension to the Relations lan- guage to help engineers in keeping information about the design rationale in declarative transformations, and to guide them in the alternatives se- lection process by using performance engineering techniques to evaluate candidate solutions. We demonstrate the effectiveness of our approach by using our QVTR2 prototype engine on a modified version of the common UML-to-RDBMS example transformation, and by guiding the engineer in the selection of the most reasonable and performing solution. 1 Introduction Model Driven Engineering (MDE) envisions a shift in the software development process by posing the attention on models instead of source code. Models become first class citizens and the theory and practice of software development should be ported to this new paradigm. The MDE paradigm should simplify the tasks of the engineer; however, developing a complete application still remains complex. Several models at different abstraction levels are required to describe all the facets of a system, and consistency between them should be maintained. The MDE paradigm and the availability of system abstractions, also in the early stages of development, support different new kinds of software engineering tasks. For example, models can be used to predict the non-functional attributes of software artifacts and prevent performance issues which would otherwise be ? This research was partially founded by the European Commission, IDEAS-ERC Project 227977-SMScom and EU FP7 Q-ImPrESS project. 2 discoverable only after the system has been implemented, when the application is running. Balsamo et al. in [1] give an overview of the many approaches pro- posed in literature to tackle performance analyses. More recent work can also be found in the proceedings of WOSP [2]. Almost all the approaches translate high-level models annotated with appropriate information about non-functional aspects into performance related formalisms, like Queueing Networks (QNs) or Markov Chains (MCs). Analyses are then performed on these low-level models by using already existing tools. However, it is still entirely up to the engineer to understand what numbers mean and what changes to apply. Existing approaches provide poor or no support at all to interpret results, to relate them from low- level abstraction layers to high-level layers, and to identify appropriate solu- tions when requirements are not met. Methodologies for feedback provision to engineers are already available in literature; example are the meta-heuristic ap- proaches described in [3][4][5] or the rule based approaches described in [6][7][8]. Indeed, meta-heuristic approaches work only in particular contexts (e.g., compo- nent based engineering) and provide solutions only for specific performance issues (e.g., finding an optimal allocation for components). Rule-based approaches are more generic and can be potentially applied to a wide variety of performance engineering tasks; our research concentrates on them. Rules to identify problems and propose alternatives are specific to each appli- cation domain, and must still be manually written by domain experts. However, in an MDE development setting, experts are also responsible for capturing the engineering domain and embed into model transformations, as much as possible, the rationale behind the development process. Several languages exist to specify transformations [9], which may be classified along different dimensions. A first distinction can be made by considering the specification style, i.e., imperative or declarative. Imperative languages operationally specify how elements should be transformed and are more familiar to end-users given their familiarity with the paradigm of common programming languages. Examples of purely imperative languages may be QVT-Operational [10] or Kermeta [11]. Declarative languages instead specify how model elements relate to each other and what should be transformed into what. Some languages exhibit a purely declarative style, such as QVT-Relations [10], Triple Graph Grammars (TGG) [12] or Tefkat [13]. Oth- ers instead adopt an hybrid style, such as ATLAS [14], which combines declar- ative and imperative constructs. Another distinction can be made by consider- ing bi-directional capabilities. Languages which provide imperative constructs are usually uni-directional, i.e., a transformation specification may be executed only to transform a model A into a model B but not in the opposite direc- tion. Bi-directional transformations instead may be executed both forward and backwards. We argue that bi-directional transformations are advantageous when several models are used, consistency must be enforced, and performance indexes must be related to high-level abstractions. Indeed, in this paper we concentrate on them and, specifically, on the QVT-Relations language. Our intuition is that the rationale behind rules to provide feedback to en- gineers is already available in transformations. This has been already pointed 3 out by Hettel et al. in [15]: “transformations are also definitions of the engi- neering process”. For example, let us consider the recurring problem of mapping components onto the hardware resources. Each component may be mapped onto multiple replicas deployed on different resources. The choice of replicating (or not) and the number of replicas constitute different alternative solutions for the same problem. The engineer, guided by past experience and by the performance requirements, makes a choice and solves the variability. Transformations, if ex- tended with suitable constructs to elicit that rationale, can be used both to automate the development process and to close the feedback loop. However, none of the currently available transformation languages provides i ) appropriate constructs to express (and keep track of) performance decisions, but buries them deep inside the source code, and ii ) mechanisms to assist engineers in the evaluation/selection of the different alternatives. In this paper we present QVT-Relations Rational (QVTR2 ), an extension of the QVT-Relations language to tackle the afore-mentioned issues. The contribution of this paper is two-fold: – We add new constructs to QVT-Relation, in the form of annotations similar to the ones already available for the Java language, to elicit alternatives and performance concepts inside transformation specifications. – We provide a prototype engine to execute QVTR2 transformations which partially automates — human intervention is still required by our engine — the feedback loop. Whenever an alternative is identified, the engine eval- uates (by using standard performance engineering techniques) the possible solutions, and shows the gathered results to the end-user, who in turn can be guided in the selection of the most reasonable candidate. The rest of this paper is organized as follows. In Section 2 we introduce some basic concepts and the running example we use in the rest of the paper. In Section 3 we describe the extensions we made to the language. Section 4 shows how we aid the developer, while transforming, when a choice needs to be made. In Section 5 we show QVTR2 in action, by running the reference example. Sections 6 and 7 describe related work and new research ideas, respectively. 2 Preliminaries In this section we describe some basic concepts needed in the rest of the paper and we introduce the running example we use to describe QVTR2 . 2.1 Background Terminology We tackle the issue of providing feedback to engineer when multiple alternatives are available for the same artifact but with different non-functional attributes. Indeed, the concepts of alternative, when/where they occur, and of deciding between them have been already addressed in literature about Software Product Line (SPL) [16]. In this section we introduce the concepts we borrow from this research area in order to provide a widely accepted formal terminology for the 4 rest of this paper. In terms of SPLs, what we call alternatives correspond to variants, while the point at which they occur is encapsulated by variation points. Many definitions have been given in the past for these terms. For variation points, we stick to the definition given by Jacobson in [17]: “A variation point identifies one or more locations at which the variation will occur”. Indeed, a variation point defines what varies or the context in which the variability happens. A variant instead represents how software artifacts vary; indeed, it specifies which are the possible available alternatives. For example, let us consider the problem of allocating a component onto one or more hardware resources. The allocation problem is the what (or the variation point), the different possible allocations are the how (or the variants). 2.2 QVT-Relations QVT-Relations is a declarative transformation language with bidirectional ca- pabilities. A transformation between two or more candidate models is a set of relations which specify the constraints that must hold between model entities. Each relation has two or more domains and may contain when and where clauses. An example is shown in Listing. 1.1. Domains define the object patterns used to match/create entities in the models. For example, the uml domain (line 10) matches entities of type Class while the rdbms domain (line 14) matches Par- titions containing at least a Table with the same name of the Class. The when clause defines the pre-conditions for the relation; the where clause instead spec- ifies the predicates that must hold when this relation holds (post-conditions). Predicates define constraints either on entities matched by the domain patterns or on other relations. The latter case is used to define precedence between rela- tions, if the predicate belongs to the when clause, or a simple call-out semantics if the predicate belongs to the where clause. In the example, the AllClassAt- tributesToSingleTable relation (line 33) is invoked in the where clause to force the mapping of all the attributes of the matched class onto columns of the matched table. Transformation can be executed in checkonly or enforce mode. In checkonly mode, the input models are not modified but only consistency is verified, by checking that all the top relations hold. In enforce mode, a direction domain must be specified and the target model is modified in order to respect the transformation relations. If an entity compliant with the enforce domain pattern is not matched in the target model, a new one is created as defined by the pattern specification. To avoid polluting models with duplicate objects, it is possible to specify keys for model entities. In the example, we specified that Tables are identified by their name, their partitionId and by the schema to which they belong. 2.3 The Running Example We based our running example on the Simple UML Class model to RDBMS model mapping described in the QVT specification [10], which we reduced and tailored to our needs. Here we describe it briefly by concentrating on the modified 5 parts; for further information refer to the QVTR2 website1 . The example tack- les the Object Relational Mapping of a domain entity model to an underlying database. The Simple UML Class meta-model has been taken as is; it allows for the definition of entities, attributes of entities, and associations between them. The RDBMS meta-model (whose relevant part is shown in Figure 1) has been instead extended to allow the definition of data partitions and generation poli- cies for record identifiers. Tables may either live on their own inside a schema, or they can belong to a partition. If this is the case, each table is identified in the transformation by its name and by the partitionId attribute. Table columns are described by an extra generationPolicy attribute, which defines the strategy to generate identifiers for new data entries. Fig. 1: The RDBMS meta-model. To add some performance-related alternatives in the example, we took inspi- ration from performance anti-patterns [18]. Anti-patterns state what a designer should not do in order to avoid potential problems. Performance anti-patterns concentrate on performance issues, and have been widely studied in the litera- ture. Smith et al. in [18] list the most common anti-patterns found in industrial applications. For the example, let us focus on the One-Lane Bridge anti-pattern. It occurs when “at a point in the execution only one, or a few, processes may continue to execute concurrently”. For databases, this happens when multiple clients concurrently access and insert/modify records in the same table. Different solutions have been proposed. Changing the policy to generate record identifiers may mitigate the problem. When default sequential algorithms are used, sequen- tially inserted records share the same storage location (or memory page). When inserting a new record, the database engine locks the entire page used to store the new entry, and other clients must wait for such lock to be released. If iden- tifiers are generated randomly, clients are diverted to different storage locations and may proceed concurrently. Another, more general, possibility consists in partitioning data onto multiple tables. Each client can be then redirected onto a different table, and mutual exclusion occurs less frequently. 1 http://code.google.com/p/qvtr2/ 6 We extended the example transformation by adding the mappings for these possible solutions. In particular, we defined three kinds of variation points. One implements the mapping of table keys onto sequential or randomly-generated identifiers. The others tackle data partitioning. A variation point handles map- ping of classes onto single tables or partitions. If partitioning is chosen, the last variation point decides how many tables should belong to the partition. 3 The Language The Relations language already provides constructs to implement alternatives in transformations. However, current implementations lack runtime support (i.e., existing engines make a non-deterministic choice between viable solutions) and features to include rational information. In this section we concentrate on the latter issue. Runtime support is discussed subsequently. We propose to use Java- like annotations for transformation predicates to include such information. Using annotations instead of modifying the grammar with new constructs brings to an important consequence: QVTR2 transformation are also valid QVT-Relations specifications, hence we can use existing engines to interpret and execute trans- formations. When building a transformation in which multiple alternative output models are viable, we express variants through relations, while we let variation points correspond to boolean predicates, in the post-condition of a relation, over the possible alternatives. To be sound, such definitions must satisfy some conceptual and syntactic criteria. Alternatives are defined by relations, and each relation is composed of several domains. When executing a transformation, one of the domains is the target, i.e., it is used to create from scratch a new output model or to check its consistency. The remaining domains are instead used to match elements in input models, and they specify the subject of the variability. Concep- tually, the subject of a variability must be unique; hence we require the patterns defined for such domains to be equal. More formally, we require that given a vari- ation point definition and a direction, the remaining domains of all its variant relations must be equal (Rule 1). We also distinguish between mutually exclusive, optional and recursive vari- ation points. According to this classification, the predicates defining a variation point must comply with the following conditions. Before proceeding, we need to recall that boolean operators in the Relations language are short-circuited, and our definitions work under this assumption. Mutually exclusive variation points are expressed through predicates xor-ing the possible alternatives, in the other case the or operator must be used (Rule 2). Optional variation points are non-mutually exclusive variation points, or-ing a unique variant with the true boolean value (Rule 3). Recursive variation points are optional variation points, and the alternative must be the same relation in which the variation point resides (Rule 4). Recursive variation points are useful in situations when an entity may be mapped several times onto the same type of objects. An example is shown in Listing 1.1 (lines 43-44): a class may be mapped onto multiple tables of the same data partition, each one with a different partition identifier. 7 Listing 1.1: The NumberOfTables variation point. 1 @variant { 2 name := ” AnotherTable ” , 3 d e s c r i p t i o n := ”Adds a n o t h e r t a b l e t o p a r t i t i o n ” , 4 e x c l u d e s := { I d G e n S t r a t e g y ( RandomPolicy ) } 5 } 6 relation ClassToAnotherTableInPartition { 7 className , pkeyName : S t r i n g ; 8 intId : Integer ; 9 10 checkonly domain uml c : C l a s s { 11 name = className 12 }; 13 14 enforce domain rdbms p : P a r t i t i o n { 15 t a b l e = t : Table { 16 name = className , 17 schema = p . schema , 18 partitionId = intId , 19 hasKey=k : Key { 20 name = pkeyName 21 } 22 } 23 } default values { 24 pkeyName = className + ’ pk ’ ; 25 }; 26 27 primitive domain c u r I d : I n t e g e r ; 28 29 when { i n t I d = c u r I d ; } 30 31 where { 32 IdAttributesToPkeyCols ( c , k ) ; 33 AllClassAttributesToSingleTable (c , t ) ; 34 35 ClassToTableInPartition ( c , t ) ; 36 t . p a r t i t i o n −>s i z e ( ) = 1 ; 37 38 @varpoint { 39 name := ” NumberOfTables ” , 40 d e s c r i p t i o n := ” D e c i d e s t h e number o f t a b l e s ” , 41 a n a l y z e r ( f u l l ) := QnAnalyzer ( $vp , $ c h o i c e , ” u s a g e . xmi ” ) 42 } 43 ClassToAnotherTableInPartition ( c , t . p a r t i t i o n , curId + 1) 44 o r true ; 45 } 46 } 8 3.1 The Annotations QVTR2 provides two types of annotations for variabilities. The varpoint anno- tation can be used for relational predicates implementing variation points, and supports the following properties: Name and Description properties serve as documentation aids. Name speci- fies the unique identifier of the variation point. It is used for cross-references both in annotations and in design documents. Description provides a quick synoptic of the variability, and helps engineers in understanding what trans- formations do. Analyzer specifies how to evaluate the candidate variants, i.e., how to com- pute information to guide engineers while selecting alternatives. Analyzers are domain dependent: each application domain and design process may use specific meta-models, transformations, and analysis techniques to ex- tract feedback information. We support their definition and implementation through Java classes, whose fully qualified name constitutes the value of this property. Parameters can be passed to the analyzer. Both user-specific pa- rameters and special parameters can be specified with the standard method invocation notation. Examples of special parameters are $vp and $choice, respectively pointing to objects containing information about the variation point and about the variant being evaluated. A mode (i.e., full or lazy) can also be specified to regulate how the analysis is carried out and to speed-up execution when computations may take long. The full mode instructs ana- lyzers to ignore timing issues and to consider the whole candidate output model. Lazy execution mode instead forces consideration only of the locally- changed elements, elements created or modified by the candidate alternative. Lazy execution is usually faster, but may provide only partial and imprecise information. The variant annotation can be instead used to annotate relations, and supports the following properties: Name and Description properties absolve to documentation needs. Excluding and Including specify dependency relations between alternatives. It is a list of variation points and variants, and serves the purpose of express- ing cross-reference constraints on variabilities. In detail, excluding specifies which solutions for other variation points should be a priori excluded when the annotated alternative is selected. Exclusion dependencies between vari- ants are symmetric by definition, so engineers need to define them only on one of the endpoints. Including defines which solutions must be picked up when the annotated alternative is selected, and is not symmetric. Listing 1.1 shows how annotations can be used to define alternatives. In de- tail, we show the recursive variation point to decide the number of replicas inside data partitions. Candidate variants will be evaluated by a full mode analyzer, which requires an extra parameter (i.e., ”usage.xmi”) to specify the location of 9 a usage profile model. The candidate database model in conjunction with infor- mation about the workload to sustain is used to generate a Queueing Network, useful to predict the performance of the solution. More details about generation of QNs will be given in Section 5. An exclusion dependency is also specified in the variant annotation. Data contained in tables is usually partitioned according to row identifiers, which are automatically managed by the underlying database engine. Specifying a random generation policy for identifiers would then conflict with partitioning, hence we mutually excluded the two solutions. 4 Runtime Support Although a QVTR2 transformation is also a syntactically valid QVT-Relations transformation, it cannot be executed as-is. Alternatives introduce non-determi- nism — for the same input multiple outputs are possible — and this leads to conceptual and practical problematic consequences. QVT-Relations does not tackle properly non-determinism. Its specification clearly states that, when mul- tiple choices are available, then they should be equivalent, which is not true from a non-functional point of view. The practical consequence is that any viable al- ternative can be taken while transforming. Actually, existing engines make a deterministic selection of the first possibility, as boolean operators are short- circuited. The QVTR2 prototype we built allows the transformation engine to discriminate among variants by evaluating them automatically and providing feedback to software engineers at runtime. The prototype modifies the trans- formation cycle and leverages standard language constructs to intercept when variation points occur. The advantage of this solution is that we can use exist- ing transformation engines without modifying them. The Relations language is relatively new and few (partial) implementations are available. To the best of our knowledge, only two working transformation engines are available: Medini- QVT [19] and ModelMorf [20]. We tried both and we selected ModelMorf for its reliability and number of language features implemented. In the following we give further details about how QVTR2 transformations may be executed. First the execution cycle is presented, then we deepen inside the most critical steps. 4.1 The QVTR2 Cycle The abstract execution cycle of a QVTR2 transformation is depicted in Figure 2. Dashed boxes represent steps in the cycle, solid arrows stand for control flows and dashed lines connect steps with produced artifacts. Annotated transformations undergo two analysis stages before real execution. The Alternatives Analysis parses relations, builds an abstract representation of them and searches for an- notations. The outcome is a model including information about found variation points, their properties, and the predicates used in the source code to express them. Information to uniquely identify elements in source models (which we need in the following steps) is instead extracted by the homonymous analysis, by searching for key definitions in the transformation source in conjunction with 10 input models. Once these pieces of information are extracted, real execution can proceed by intercepting occurrence of variation points. QVTR2 Alternatives Analysis Identifiers Analysis Input ALTs IDs Input QVTR2 Engine QVT-Relations Choices Build Intercepting Transformation I.T. Engine Variation Point Detected Explore Alternatives Output F.T. F.T. F.T. Output Output Output Evaluate Alternatives Fix Choice Fig. 2: The QVTR2 Execution Cycle. Intercepting Variation Points. Given a variation point definition and the predicate used to express it, we say that it occurs when we reach the predicate during the execution of the transformation, and the engineer has not previously selected one of the viable alternatives. To intercept these events we create inter- mediate transformations — which we call Intercepting Transformation (IT) — leveraging the possibility to provide black-box implementations for relations. The original QVTR2 transformation is modified by adding, for each variation point, a new black-box relation compatible with the domains of the variant relations. Let’s consider the example shown in Listing 1.1. The only viable alternative ac- cepts three domains for the class, the partition and the current identifier. The new relation we create is shown in Listing 1.2. The original predicates used to express variation points are also modified, in order to point to the new relation. Listing 1.2: The black-box interceptor for the AnotherReplica variation point. relation NumberOfTables interceptor { checkonly domain uml c : umlMM : : C l a s s { } ; enforce domain rdbms p : rdbmsMM : : P a r t i t i o n {} implementedby bbox NumberOfTables ( c , c u r I d , p ) ; primitive domain c u r I d : I n t e g e r ; } Note that we must only intercept the occurrence of variation points for which an alternative has not been selected. To discern between the two cases, we use nested if constructs invoking selected alternatives for fixed variabilities, or point- ing to interceptors. Let’s consider our reference variability and let’s suppose that the engineer has already decided to map MyClass onto at least three tables. Listing 1.3 shows the substitutio predicate. We intercept the variability only if conditions on line 1 and 2 evaluate to false. PartitionId s start from 0 and two 11 tables are created by default when the partitioning strategy is selected; hence, the conditions evaluate to false only when we are trying to create the fourth table in the partition. Listing 1.3: The substitution predicate. 1 i f ( c u r I d + 1 = 2 and c . namespace . name = ’ MyNamespace ’ 2 and c . name = ’ MyClass ’ ) then 3 ClassToAnotherTableInPartition ( c , t . p a r t i t i o n , curId + 1) 4 else 5 NumberOfTables interceptor ( c , t . p a r t i t i o n , curId + 1) 6 endif How black-box implementations are handled is still a matter specific to each transformation engine. ModelMorf handles them by using user-supplied Java im- plementations, which we automatically generate. When an Intercepting Transfor- mation is executed two things may happen. Either no variation point occurred, the transformation ends regularly, and the model produced corresponds to the final output; or a variation point occurs and we start exploring the available alternatives. Exploring, Evaluating and Choosing. When a variation point occurs, we ex- plore it by generating the models corresponding to each possible variant. First we compute an intermediate transformation for each variant — which we call Fixing Transformation (FT) —, then we execute them to generate candidate models. Fixing transformations are modified versions of the original QVTR2 transforma- tion. As we did for ITs, variation point expressions are substituted with pred- icates similar to the one shown in Listing 1.3. When alternatives have been already selected, we fix them in the predicate. If this is not the case, the variant picked up in the else branch (line 5) depends on whether we are substituting the predicate for the variation point being explored or not. If this is the case, the FT fixes the associated variant; otherwise we automatically select one of the possible solutions. Alternatives are consistently selected across FTs for non-fixed variation points: for each variation point, the same alternative is fixed in all FTs. Hence, generated models differ only for the variation point being explored and evaluation results are consistent. This corresponds to a local search strategy, which may not be practical in every case, but has the advantage of giving re- sults fast — complete exploration of the state space is not required —. Once models are generated, we evaluate them by invoking the analyzers as specified in annotations. The output of the analyses may be of any kind. For example, it may be textual information, a chart, or a spreadsheet. We do not interpret it automatically; this task is still left to the engineer. When the most appropriate solution has been selected by the designer, we keep track of the choice by saving it into the Choices model for future use. The Choices model is used during the next iteration over the QVTR2 cycle, to incrementally build the new fixing and intercepting transformations, and is useful to keep track of decisions, and change them, between multiple executions. 12 5 Enacting the Example In this section we demonstrate QVTR2 in action by using our reference exam- ple2 . For space and comprehension reasons, we use a naive Simple UML Class in- stance model as input for the transformation. The input Class model we consider blueprints a simple cart application: Persons are associated to Carts, and Carts may contain Items. To evaluate alternatives (i.e., candidate RDBMS models) we use a full mode analyzer that automatically generates from database mod- els a Queueing Network, which we then solve by using the JMT tool [21]. The analyzer also requires usage profile information for the QN, shown in Table 1. For each class of the input model we define two QN customer classes (and their relative parameters), one for read operations and one for insert/update opera- tions. Database tables are represented by service centers; if a class is mapped onto multiple tables then multiple service centers will exists in the QN serving the same type of requests. Service times for jobs are fixed to 0.05s for read op- erations and to 0.1s for write operations. If a table uses the random generation policy for identifiers, the analyzer discounts the write service time by a 0.2 fac- tor. Required response times — to discern between candidate solutions — are also shown in the table, although they are not required to generate the QN. The analyzer computes global response times for each customer class, and reports back the estimations to the designer. We are aware that this methodology to estimate the performance of databases is simple and does not take into account important facets (e.g. query involving multiple tables). Indeed, more precise and complex estimation techniques [1] may be adopted instead, and we recall that, in this paper, our target is not the prediction techniques per se, but showing how model transformations and prediction techniques can be mixed to improve engineering tasks. Table 1: The usage profile. Class Operation Wkld. Type Arrival Service Required Rate [s] Time [s] Response Time [s] Read Open 1 0.05 0.2 Person Write Open 10 0.1 0.2 Read Open 0.5 0.05 0.1 Cart Write Open 1 0.1 0.1 Read Open 0.1 0.05 0.15 Item Write Open 0.1 0.1 0.15 Running the transformation on the simple cart model results in many passes through the QVTR2 cycle. An overview of what happens at runtime is shown in Figure 3a. Solid boxes correspond to the occurrence of a variation point, and lead to generation/evaluation/selection of candidate models (the round boxes). The performance indices computed during model evaluation are shown in Fig- ure 3c. These values, in conjunction with requirements, are used to select one of the viable alternatives. For example, the solid diamond C corresponds to the 2 Further details, models and source code are available on the QVTR2 web site. 13 occurrence of the identifiers generation policy variation point for class Cart, and leads to the generation of the candidate models 5 and 6. The corresponding lines in the table show the estimated response times for the Cart table, for the two solutions respectively. The sequential solution is not compatible with the requirements; hence we select the random generation policy. Note that models 7 and 8 are not included in the table. The random generation policy selected for the Cart entity conflicts with the partitioning solution. Only one alternative (model 7) is viable, hence, no evaluation is required. The final solution we obtain is model 16: a random policy has been selected to generate identifiers for Cart entities, and 3 tables are used for the Item partition. Identi- fying this solution — which respects requirements and is minimal — would have required, without the provided automation, manual exploration and evaluation. Root Decision Exploration Person A Model Random 1 2 Sequential Policy V.P. B Single 3 Partition V.P. 4 Partition Table V.P. C Sequential 5 6 Random Cart (b) Decision Tree Legend D Single 7 8 Partition Entity Model Response Time [s] {read,write} E Random 9 10 Sequential 1 {0.054, 0.086} Person 2,3 {0.053, 0.101} F 4 {0.048, 0.102} Partition 11 12 Single Item 5 {0.067, 0.118} Cart G 6 {0.061, 0.095} No 13 14 Another Table 9 {∞, ∞} 10,12 {∞, ∞} H Item Another Table 15 16 No 11,13 {0.152, 0.202} 14,16 {0.064, 0.109} End 15 {0.053, 0.1065} (a) Decision Tree (c) Evaluation Information Fig. 3: Running the transformation. 6 Related Work Concerning rule-based approaches, Xu describes in [8] a feedback provision sys- tem for the PUMA framework, in which rules are derived from performance anti-patterns [18] and implemented with the Jess language. However, solutions are proposed only for trivial performance issues and, if this is the case, changes apply to the lowest abstraction layer without propagation along the modeling stack. Parsons in [7] describes a similar approach tailored to enterprise Java application. More recent work is also available in [6], where a methodology is 14 proposed to rank performance anti-patterns and identify the most reasonable cause of a performance problem after a design of the system has been created. We instead anticipate this task during system design and, given our generative approach, all performance problems have an implicit associated solution. In the context of SPLs for performance engineering, it is worth citing the ap- proach described by Tawhid et al. in [22]. They use UML and the MARTE profile to design SPLs with parametric performance information. The SPL specification is transformed into a model of the final product enriched with performance anno- tations. Layered-QNs are generated and analyzed; performance indices are then derived to guide engineers. Their approach is tailored to UML+MARTE mod- els and to performance analysis with Layered-QN. We are instead more generic by giving to engineers the freedom of choosing the preferred analysis approach. Indeed, we have to admit that we lack such an holistic support for parametric performance properties. In the area of transformation languages, Petter et al. in [23] propose to extend QVT-Relations with constructs to express constraint satisfaction problems, which may be used to model some types of variabilities. In- deed, not all variabilities can be expressed, and they lack appropriate constructs to embed rational information. In [24] and in [25], high-order transformations are used to support variability. Also our approach uses high-order transforma- tions to generate intercepting and fixing transformation; however, [24] and [25] lack support for performance engineering, and rely completely on the engineer’s expertise to select and evaluate alternatives, which we instead support. 7 Conclusions In this paper we presented an extension to the QVT-Relations language to represent rational information about alternative designs, and to provide per- formance feedback to engineers while transforming. Non-obtrusive annotations have been used to embed directly into transformations information about vari- ation points, variants, dependencies between solutions, and how to gather non- functional information about them. We also described our prototype implemen- tation of QVTR2 , based on an existing QVT-Relations transformation engine. A sample transformation mapping UML Class models to RDBMS has been run, and we showed how the possible solutions may be evaluated using performance engineering techniques, and how the engineer is involved in the selection of the most reasonable solution. For future work, we plan to extend our annotations in order to represent explicitly performance indices and parametric performance properties. We also plan to add automatic exploration of the decision space and concurrent evaluation of multiple dependent variants, in order to find global optima instead of local ones. As a conclusion, we also plan to use QVTR2 at runtime to tackle evolution when performance estimation requires runtime data. References 1. Balsamo, S., Marco, A.D., Inverardi, P., Simeoni, M.: Model-based performance prediction in software development: A survey. IEEE TSE 30(5) (2004) 295–310 15 2. International Workshop on Software and Performance (WOSP) proceedings, ACM 3. Martens, A., Koziolek, H., Becker, S., Reussner, R.: Automatically improve soft- ware architecture models for performance, reliability, and cost using evolutionary algorithms. In: WOSP/SIPEW. (2010) 4. Canfora, G., Di Penta, M., Esposito, R., Villani, M.L.: An approach for qos-aware service composition based on genetic algorithms. In: GECCO, ACM (2005) 5. Grunske, L.: Identifying ”good” architectural design alternatives with multi- objective optimization strategies. In: ICSE, ACM (2006) 6. Cortellessa, V., Martens, A., Reussner, R., Trubiani, C.: A process to effectively identify ”guilty” performance antipatterns. In: FASE. (2010) 7. Parsons, T.: A framework for detecting performance design and deployment an- tipatterns in component based enterprise systems. In: DSM, ACM (2005) 8. Xu, J.: Rule-based automatic software performance diagnosis and improvement. In: WOSP, ACM (2008) 9. Czarnecki, K., Helsen, S.: Feature-based survey of model transformation ap- proaches. IBM Systems Journal 45(3) (2006) 621–646 10. Object Management Group (OMG): MOF QVT Specification. (April 2008) 11. Muller, P., Fleurey, F., Drey, Z., Pollet, D., Fondement, F.: On executable meta- languages applied to model transformations. In: Model Transformations in Practice Workshop at MoDELS 2005. (2005) 12. Schürr, A.: Specification of graph translators with triple graph grammars. In: 20th International Workshop on Graph-Theoretic Concepts in Computer Science (WG). Volume 903 of LNCS., Springer (June 1994) 151–163 13. Lawley, M., Steel, J.: Practical declarative model transformation with tefkat. In: Model Transformations in Practice Workshop at MoDELS 2005. Volume 3844 of LNCS., Springer (2005) 139–150 14. Jouault, F., Kurtev, I.: Transforming models with atl. In: Model Transformations in Practice Workshop at MoDELS 2005. Number 3844 in LNCS, Springer (2005) 15. Hettel, T., Lawley, M., Raymond, K.: Model synchronisation: Definitions for round- trip engineering. In: ICMT. Volume 5063 of LNCS. (2008) 31–45 16. Pohl, K., Böckle, G., Linden, F.J.v.d.: Software Product Line Engineering: Foun- dations, Principles and Techniques. Springer (2005) 17. Jacobson, I., Griss, M., Jonsson, P.: Software Reuse: Architecture, Process and Organization for Business Success. ACM Press (1997) 18. Smith, C.U., Williams, L.G.: More new software antipatterns: Even more ways to shoot yourself in the foot. In: Int. CMG Conference. (2003) 717–725 19. IKV++ technologies ag: Medini-qvt. http://projects.ikv.de/qvt 20. Tata Research: Modelmorf. http://121.241.184.234:8000/index.php 21. Bertoli, M., Casale, G., Serazzi, G.: Jmt: performance engineering tools for system modeling. SIGMETRICS Perform. Eval. Rev. 36(4) (2009) 10–15 22. Tawhid, R., Petriu, D.C.: Integrating performance analysis in the model driven development of software product lines. In: MoDELS. Volume 5301 of LNCS., Springer (2008) 490–504 23. Petter, A., Behring, A., Mühlhäuser, M.: Solving constraints in model transforma- tions. In: ICMT. Volume 5563 of LNCS., Springer (2009) 132–147 24. Avila-Garcı́a, O., Estévez, A., Rebull, E.V.S.: Using software product lines to manage model families in model-driven engineering. In: SAC, ACM (2007) 25. Oldevik, J., Haugen, Ø.: Higher-order transformations for product lines. In: SPLC, IEEE (2007) 243–254