Subject: FASE'09 notification From: "FASE'09" Date: Fri, 12 Dec 2008 22:47:19 +0000 To: Amogh Kavimandan Dear author, We regret to inform you that your paper was not accepted by the program committee for presentation at FASE 2009. The competition has been tough: we have accepted only 30 out of 124 regular paper submissions, and only 2 out of 8 tool paper submissions. The reviews of your paper can be found below. We hope that you find them useful for rewriting your paper for submission to other venues. On behalf of the program committee, we would like to thank you for your submission and hope to see you in York in March 2009. Best regards, Marsha Chechik & Martin Wirsing FASE 2009 program committee co-chairs --------------------------------------------- Paper: 150 Title: Templatized Model Transformations: Enabling Reuse in Model Transformations -------------------- review 1 -------------------- PAPER: 150 TITLE: Templatized Model Transformations: Enabling Reuse in Model Transformations OVERALL RATING: -2 (reject) REVIEWER'S CONFIDENCE: 3 (high) ----------------------- REVIEW -------------------- The paper proposes an approach to enhance the reuse of model transformations. In particular, the authors introduces a notation to specify the variability of transformations and to obtain corresponding variability metamodels which will be used later to “instantiate” previously defined “templatized” transformation rules. The paper presents an interesting approach even though it has presentation problems which compromise the overall quality of the work. In fact, the paper is really difficult to follow, I had to go through certain parts of it several times in order to understand what the authors meant. For instance, i) in Section 2 the motivating case studies are not well illustrated. The authors give too much details of the metamodels instead of simpler models able to give an intuition of the challenges which will be addressed in the rest of the paper. Currently, the reader does not understand what is the problem which has to be solved; ii) in Section 3 - the description of Structural and Quantitative variabilities has to be improved. In this respect, instead of presenting all the possible results of the SCV analysis (see Table 1) I would have preferred a more clear discussion about how to obtain them. For instance, the reader does not understand why only three configurations have been obtained and what are the differences between Config_2 and Config_3 - the notation for specifying constraints is not clear. Figure 5 does not help in this respect, and the meaning of the presented values (I1, O1, etc) is completely obscure - often the authors gives some details (like the “AttributeMapping” element of GReAT) or reach some conclusions (like the data values {10, 20, 50}, or {5,2,15}) which are difficult to catch - the authors should provide the reader with a brief overview of GReAT. In fact, the authors report some transformation rules expressed in GReAT without a proper introduction of the language. This compromises the readability and the comprehension of key parts of the paper In summation, even though the paper presents an interesting approach it has serious presentation problems. Both the running example and the MTS approach are presented in an unbalanced way: sometimes too much details are given and sometimes the discussion is not enough to convince the reader. -------------------- review 2 -------------------- PAPER: 150 TITLE: Templatized Model Transformations: Enabling Reuse in Model Transformations OVERALL RATING: 0 (borderline paper) REVIEWER'S CONFIDENCE: 2 (medium) ----------------------- REVIEW -------------------- The paper presents a technique to write reusable, templatized model transformations. The technique has been implemented in the Generic Modeling Environment using the Great graph transformation language. The use of the technique is illustrated on two case studies. A preliminary evaluation of the technique is given. The topic of the paper is relevant and interesting. Its technical content appears sound (however, I did find some of the details hard to follow -- see below). However, I have the following concerns: 1) Presentation: the use of a running example is laudable; however, I found some of the details hard to follow; this is because the description of the approach is quite tied to a particular implementation and either assumes some knowledge of the technology used (e.g., Fig 6 contains, I think, a transformation rule in Great; since its format is not standard and some parts are not readable, I could not follow it), or the figures are actually not readable (e.g., in Fig 6, 7, and 9, some text is too faint or too small); most figures were not very helpful. Overall, I would have preferred a description of the approach in more general terms. This also would have made the claims of generality more convincing. 2) Claims of generality: The paper says that the "approach can easily be extended to other model transformation tools as long as they provide the means to develop higher order transformations"; it is hard for the reader to assess the truth of this statement; moreover, how harsh a restriction actually is the need for higher order transitions, i.e., are the many transformation tools that feature higher order transformations or not? 3) Evaluation: The paper measures the computational overhead introduced by the approach; however, little is said about the difficulity of the manual steps; also, some attempt at least to also quantify the potential savings would have been helpful. 4) Limitations: What are limitations or potential problems with the approach? Detailed comments: - abstract: "indicates" -> "indicate" - page 1: "diversity in" -> "diversity of" - page 4: "from fixed_priority_service_execution" -> "from the fixed_priority_service_execution" - page 4: "Lane object" -> "the Lane object" - page 4: "BandedConnection" is refered to here, but not shown in the figure - page 5: "of SCV" -> "of the SCV" - page 5, bottom: how exhaustive is your categorization of variabilities? E.g., what about variabilities in the *constraints* of a model? how would these fit in? - page 6: "are same" -> "are the same" - page 6, text under Table 1: the description jumps from "transformations" and "variabilities" to "dependencies"; please clarify. - page 6: "in Structural block which is created in target model" -> "in the Structural block which is created in the target model" - page 6: "Our approach can easily be extended...": The description of the technique appears quite specific to the implementation framework used (GME and Great); I would have preferred a description that makes it clearer how the technique can be applied to other transformation tools - page 7, Fig 6: . the contents of the two classes on the left is way too faint to be readable in the paper copy; even on the electronic copy it is hardly readable . the caption says this is a rule; however, I have trouble reading it, because its format does not follow the standard "LHS -> RHS" pattern; please explain - page 7: "between" -> "between the" - page 7: "of Lane" -> "of the Lane" - page 7: "for Lane" -> "for the Lane" - page 7: "in composition" -> "in the composition" - page 7: where do the data values come from? - page 9, Fig 7: Again, the contents of this figure is barely readable; in particular, I cannot see/follow in which sense this figure corresponds to Figure 6 - page 9, "developers use the generated VMM to create": how difficult is this step? how much time does it take? - page 9, "To realize a complete transformation ... must combine ...": is this combination an instance of "model merge"? is this combination always possible? - page 10: what is the complexity of these two algorithms? - page 11: "from source model" -> "from a source model" - page 12: "reduces by a fraction of" -> "is reduced to" - page 12: "placed by" -> "incurred by" - page 13, Fig 10: what are the conclusions that you draw from these graphs? - page 13: "Reflective model driven" -> "The reflective model driven" References: - [9]: remove "and"s -------------------- review 3 -------------------- PAPER: 150 TITLE: Templatized Model Transformations: Enabling Reuse in Model Transformations OVERALL RATING: 1 (weak accept) REVIEWER'S CONFIDENCE: 4 (expert) ----------------------- REVIEW -------------------- The authors present so-called templatized model transformations to increase the reuse of model transformations. They define a variability meta model defining structural and quantitative variants in model transformations for product lines. Based on two small examples, they show how to define model transformations rules with variants and explain how they can be flattened to normal rules for different application families. This work is clearly motivated and the approach is straight forward. However, looking closer the approach is not that clearly presented. The examples in Sec. 2 are well chosen, but the description of their meta models could be improved (e.g. cardinalities in the meta model in Fig. 1 are not consistent with the description of this meta model). The presentation of some sample rules showing variability for different platforms would be helpful. Sec. 3 describes the templatized model transformation approach. Fig. 3 is by far too small, source and target DSMLs as well as transformation instance are not readable. But a readable example would be helpful in understanding better the approach. Moreover, the corresponding source instance is missing in this figure. Fig. 4 contains the main approach and is not explained in the text. The explaining text in the figure is too small to be readable. Fig. 5 seems to be important and is explained in the text. It describes the constraint specification notation for one example. However, all its variable names are not explained. And also the allowed structure of these constraints remain unclear. In Fig. 6 attribute computations are not shown. Moreover, constraints are not really formulated. The Quantitative part contains dependencies of attribute values only. Thus, the variability is stated but not defined. In the subsequent paragraph concrete values are given. How are they incorporated into the specification? Algorithm 1 is quite clearly described, however, it is not clear what S is. Finally, in Fig. 9 an example for a rule using MTS is shown. The text should clearly hint to this figure. Sec. 4.2 discusses the performance overhead of using MTS. Two examples are by far too few to establish an empirical study. Thus, I propose to shorten this section for having more space to explain the proper approach in more detail. Related work: In contrast ot other approaches, especially ViaTra, this approach presents higher-order transformations in a different form than normal transformations. Why do the authors do not use the same mechanism on both levels. Lateron, the MTS approach is compared with an aspect-oriented approach to managing transformation variability. The authors argue that MTS does not require an additional learning curve. This is not true, since at least the constraint notation has to be learned. Summarizing the presented approach looks promising, but the approach itself as well as its merits compared to others should be described more explicitly and its limits should also be discussed.