Dear Amogh and Aniruddha, I regret to inform you that your paper, titled "Templatized Model Transformations: Enabling Reuse in Model Transformations" has *not* been accepted for MODELS 2008, the ACM/IEEE 11th International Conference on Model Driven Engineering Languages and Systems. Attached you will find the reviewers' comments. This year's competition was exceptionally high. We had 274 submissions and each of them went through a rigorous review process. We have accepted 58 papers, giving an acceptance rate of 21%. I hope that you will nevertheless consider attending the conference or actively participating in one of the collocated workshops, symposia, or tutorials. Information about conference program, venue, registration and related events can be found at http://www.modelsconference.org. Hope to see you in Toulouse. Best regards, Krzysztof Czarnecki MODELS 2008 Program Chair *=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*= First reviewer's review: >>> Summary of the submission <<< In this paper, the problem of automatic generation of family of applications is studied. The solution presented uses templatized model transformation and proposes a mechanism and a technology (named MTS) to automate the specialization of the model transformation to generate each application of a family. The principle is based on the generation of a variability metamodel. Variability models can then be written to automatically generate a transformation designed to produce an application. >>> Evaluation <<< This paper addresses an interesting problem and proposes a solution to modularize the development of product lines on the basis of a mechanism of templatized model transformation. The paper presents an interesting solution that is evaluated with two case studies. Unfortunately, I think that the presentation of this work is not precise enough and does not contain sufficient explanations about several elements of the methodology proposed. The use of a metamodel to build models which express the variabilities in the different VMM models is interesting. It is a good idea to use the MDE techniques to tackle the problem presented. However, I have two major concerns that are not clarified in the paper: - what kind of model transformations can and cannot be considered by this method? The creation of a family of applications can require complex treatments made in the transformations. Can this method generate such complex transformation? - what is the importance of the manual work? The initial input, the templatized transformation is not presented, nor in the global explanations, neither in the case studies. It seems important to me to have at least an excerpt of a templatized transformation : it is the main element of the process because it is the one which is transformed. Moreover I would like to know how complex is the creation of such an original templatized transformation. The section 3.3 is too short. An example of one VMM model is necessary since this is the input of the next step (section 3.4) and because it would help to understand the full process. I suggest that VMM models corresponding to the examples given in the table 1 (at least two of them to highlight their differences) could be provided. I was disapointed to read so few explanations about the way the VMM models are used to produce the transformations. It was possible for me to understand the process to this point. But this last step really lacks explanations and details. What is exactly in the Fig 5? What are the specialized transformations produced? How are the generated transformations used? It is possible that the authors did not have enough space to provide these elements. I suggest that it is not necessary to "partly" develop two case studies but "completely" develop one is more important. A second case study can be briefly introduced to be used only in the section 4. In the last paragraph of section 5, it is written that MTS automates the entire process. This is not strictly wrong, but I think that the entire process should be considered larger: with the definition of the original templatized transformation, the definition of the constraints and the creation of the VMM models. I agree that the evaluation made in the section 4 is interesting and that these manual steps are difficult to evaluate. But I believe that these manual steps could be discussed because they are costly. Other elements complicate the comprehension: In the illustration of this paper, sometimes excerpts are provided (Fig 1, Fig 3), sometimes full elements are provided (Table 1, Fig 4). Therefore I found that it was difficult to follow the entire process. For instance, in the Fig 4 there is a Topic Class but it doesn't appear in the Fig 3. Moreover the metamodel of the Fig1 (a) is so simplified than it doesn't contain the attribute cited 4 lines before (invitation_info). The page 6 is confused. The table 1 is not enough explained especially the Qualitative column. It is possible to use "Response::suggest_alternate" for example despite "suggest_alternate". In the last paragraph of this page, I read sometimes "may have different values", sometimes "may be present", sometimes "not applicable": that could be clarified. _____________ Minor remarks The text in the Fig 1, 2, 5 is too small. In the section 3.2, third paragraph a "Line 41" is mentionned but it doesn't exist. In the algorithms, I suggest to add "endif". In the Fig 4, there is a class named "Compositional" when the text talks about a class named "Structural" (in the paragraph before the picture) In the page 7, first paragraph "be exemplified be" -> "be exemplified by" In the page 6, first paragraph "may be either be" -> "may be either" *=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=* Second reviewer's review: >>> Summary of the submission <<< The paper sketches and evaluates an approach to make model transformations reusable between different applications in one product family. The basic idea is to use an explicit variability model to represent the differences between the applications, and to generate specialized transformations from this. >>> Evaluation <<< The basic idea of the paper is interesting; however, the presentation has major shortcomings. The main problem is that the paper does not give a single example of a templatized model transformation, but assumes that the reader is familiar with the concept. This makes it very hard to understand the entire argument. I would suggest to focus on either of the two application studies, give one or more examples of TMTs, and spend more space on explaining the different notations. A second problem is that the purpose of the evaluation remains unclear. Section 4.1 claims to measure the "reduction in development effort", but proceeds to give results of executing two unspecified transformations using GReAT -- this is not "development effort" as I would understand it. It would be nice to see instead (or additionally) some data about the effectiveness of the approach -- which fraction of the rules can be reuse, how much developer time does it take to templatize them etc. Details: - p2: "contemporary tools [2-6]": all of these are more than five years old, which isn't really contemporary anymore. - p3: invitation_info attributes --> detail_invitation_info attributes - p3: Fig 1 is very small; the fonts in 1b are broken. - p4: Fig 2 is close to unreadable. Remove the eye-candy and use a more schematic diagram. - p4: "As shown in step 1" -- you are still describing Step 1, so you can't say that. - p5: Qualitative variabilities: I'm not sure this is the right term - I would expect "quantitative" since it refers to the data values. - p6 / Tab 1: "suggest_alternate and amend_invitation...omitted": Shouldn't this be a structural variability then? Or are qualitative variabilities restricted to entire classes rather than attributes? Please explain why this is a qualitative variability. - p6 / Tab1: Several attributes are used here but not defined in the metamodel in Fig 1a (eg claim_date) - p7: Fig3 doesn't use the attributes given in the model; the fonts are broken in Fig 3b. It remains unclear whether the constraint specs are complete (eg claim_date). - p7: "there is an association between...": please explain what that means, and how this is represented in the constraint spec. - p7: "The above spec. can thus be exemplified...": I don't understand this - please rephrase. - p7: "in the previous rule as" --> in the previous rule are - p8: Line 41 -- the algorithm only has 28 lines. - p8: Structural element --> Fig 4 uses Compositional - p8: "attributes is dependent" --> attributes are dependent - p9: Fig 9, "Attributes can be modified" -- please explain this in more detail. - p9, Sect 3.3: This remains unclear; please provide more details. - p11, Fig5: the figure is unreadable. Related work: - Rewriting languages such as Stratego allow building rewrite systems from individual rules; it would be interesting to see how your approach compares to that. - How does your approach compare to Hongming Liu, Lizhang Qin, Xiaoping Jia, Adam Steele: Model Transformation Based on Meta Templates. Software Engineering Research and Practice 2006:547-553 *=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=* Third reviewer's review: >>> Summary of the submission <<< This paper introduces a novel template based model transformation reusability framework. It presents the whole development cycle of templatized transformation generations from the scope, commonality and variability (SCV) to the automatic application specialization. It is achieved by introducing (i) a variability metamodel which decouples and modularizes the variabilities of the model transformation and (ii) two high order transformations that automatically derives the application specific transformation instances. At the end of the paper a benchmark is presented to demonstrate how the automatic transformation generation performs and fastens the development cycle. >>> Evaluation <<< On one hand, the paper addresses a relevant problem in a convincing way. On the other hand, some critical parts are vaguely presented and critical details are missing related to the proper definition of its constraint language. Positive aspects: - The paper presents a promising approach - It is validated by some benchmarks. - The related work mentions all important techniques in the problem domain Negative aspects: - Details of the constraint language are missing - Some parts are vaguely presented - The claim on the save in development effort is not really justified Further questions and comments: - The paper presents a promising approach and the approach is nicely outlined in the beginning, and an overall vision is given. However, this overall vision becomes somewhat "blurry" in the central sections when the reader has the feeling that the presented approach lacks generality, and it is very specific to the metamodeling and transformation framework used in the background. - Some readers might be GME and GReAT non-experts, and for them, explanations are hard to follow here and there, especially due to the lack of introduction / overview for the metamodeling framework and transformation rules. - The constraint language is not properly defined. What is the expressive power of the constraint language used to capture the variabilities of a metamodel? Is it possible to define a subgraph variability point where, for example, in one case we use only one model element and in an other case a whole graph? (It is not easy to see at first sight, why your variability constraint language is really a constraint language). - The benchmark in Sec. 4 focuses on the overall execution time of the generation process, which is misleading, as it tries it to sell a gain in development time. It would be better to focus on a comparative benchmark with other hand coded versions rather than on the performance of the generation algorithm. Concerning development time, you need to create variability models, which are not included there. - The overall quality of the figures should be improved. The size of the characters on almost all figures are unreadable and some of them contains information that is irrelevant to the reader (e.g. Fig. 4. is a full featured screenshot with the frameworks menu and toolbar). Minor things: - P6: "may be either be" ??? - ''as shown in Line 41'' -> Algorithm 1. is only 28 lines long - ''modeled and contained in the Structural'' -> in Fig 4. there is no such element as Structural. I think it is Compositional - ''model transformation itself) need NO change *=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*