Dear Aniruddha, I am happy to tell you that your paper "A Model-driven Development Environment for Composing and Validating Distributed Real-time and Embedded Systems: A Case Study" has been accepted to be published with the proposed revisions in "Model-driven Software Development - Volume II of Research and Practice in Software Engineering". Please revise your paper according to the attached referee comments and submit your camera-ready copy to the submission site . You can download the author kit by clicking on "download templates" in the "Conference Properties" box and then clicking on the "here" link next to the talking head icon. Your login ID for the submission tool is "reddoc-its". The deadline for submitting your camera-ready copy is December 5, 2004. With best regards, Matthias ===================================== Review Comment for the Paper's Author: The paper addresses a case study on MDD for composing and validating DRE systems. It presents 3 contributions on integrated MDD development and checking, technical difficulties encountered during integration, and issues involved in implementation. The paper is easy to read. The case study with prototyping integration seems to provide a solid ground. Some typos are as follows: * page 8, left column: missing '.' at the end. * page 14, first line of section 5: 'mode-based' -> 'model-based' ===================================== Review Comment for the Paper's Author: Authors: G. A Trombetti, et al. Title: A model-driven development environment for composing and validating distributed real-time and embedded systems: A case study. Overall comment: ---------------- This paper appears in almost identical form in the list of accepted papers for DOA 2004 (October 2004). It seems to me that the authors have attempted a parallel submission which is typically not an acceptable practice. However, the publisher of both submissions is Springer which may mean a possible a reuse of most of the text in both places. It is up to the editors of the special edition to consider this issue. Should they accept the submission as valid, I now go on to list the more detailed comments about the paper. Detailed Review Comments: ------------------------- 1. Abstract: I have difficulty finding the main contributions in the abstract. There seems to be a lot of "filling text" with no direct relation to contents of the paper. I particularly have problems with considering predicability and scalability as QoS. To me quality of service is a range of properties of the system that one might adjust at run-time in order to deal with variaous dynamic conditions (e.g. variable resource levels, varied load). Typically a QoS-enable system has to have means to "negotiate with" or adjust the application so that the best level of QoS can be delivered. In that sense, I can not see how predictability or scalability of an application can be adjusted. High predictability should a be a characteristic of all applications in this category, and scalability is not something I would normally consider as an adjustable aspect of a system. The abstract is too long and has terms like "middleware development toolsuite" and component middleware that are unclear terms (Is the goal of the tool suite is to develop middleware? The example case study contradicts this. Is the paper about middleware that supports component-based system development? It does not seem so, it is more about a development environment than the actual middleware). Page 2: - "the reusable of" - "these systems becomes" - column 1, embedded bold text, is that a subsection title? - column 2: I do not see a conflict between MDD and use of compilers - How would you suggest to further use a developed and analysed model, if not by automatic code generation? - "these analysis should be" - column 2, bullet 2: It is not the role of model checking tools "to provide mechanisms for composition, assembly, configuration a nd deployment". I can guess what you mean but what is written there does not make sense. Page 3: - column 1: under contributions: a lot of words with no clear meaning. For example: "... by addressing key production stages, such as ...model checking capabilities, increasing reliability...". Are these really production stages? The paper does not contribute by illustrating "reduction of total development cost and time-to-market"! - column 2: Here it is said that "CoSMIC ...provides ... methods to ...validate application and middleware" which contradicts the motivation for combination with Cadena, - "These methods ... and satisfy the system's ... QoS requirements". It is strange to claim that a method satisfies requirements for a system (you probably mean that the method shows that a design satisfies the requirements). Page 4: - please relate (1) to (4) in Figure 2 to the text that follows the figure. - again I have difficulty in seeing how reliability is a QoS (perhaps you have a peculiar definition of reliability. IFIP WG10.4 defines reliability as a measure of conforming to a specification of a system over an interval of time). - I do not see how hybrid control theoretic techniques [28] "assure" run-time QoS delivery. Page 5: - unclear text on PICML, is it a language or a weaver (both are mentioned in column 1). - what is "the ITS project"? - last para before 2.2, repetition and still unclear. - Figure 4 is too small to tell the reader anything. Page 6: - the acronym "Cps" is used without introduction (defined first on page 9!). "Cor" is not explained either. If they are irrelevant and not ready, I suggest you remove this bullet. - I would have liked to see the text on Cadena provide an overview of the model checking technologies - the current text only explains the files used by the tool. - "also sport useful" Page 7: - Figures 5 and 6 too small to be readable and some shades obstructing in black and white print. - Please check that source/sink and facet/receptacle is explained here or in some other chapter of the book covering CCM/UML. Page 8: Figure 7, 8, 9: text is too small to be illustrative. Syntax in Fig. 7 should be explained. - "context our robot" - column 1: last para, incoorect English - What do you mean by cycle in section 3.5? simply a cyclic call chain? Page 9: - Figure 10 is not illustrative (is the shading significant?) - middle of column 1: I cannot see how the sequence diagram of Fig. 6 is supposed to show that no deadlock can occur. It is just one scenario! - Would be useful to explain the meaning of "->" in Cadena property specs Page 10: Footnote: what is a "Bogor script"? If outside scope, the footnote can be removed. Page 11: These challenges are by far the most interesting parts of this paper. - Refrring to the related works, you seem to be unaware of the standardisation activity that goes on under ISO (AP233) with the active participation of INCOSE. This effort started in a European project SEDRES (the second phase of which ended in 2001). Page 13: - "Cadena involve the following" Pge 14-15: Related works is somewhat repetitive, and ISO/INCOSE reference still missing ===================================== Review Comment for the Paper's Author: Introduction, 1st paragraph: Term ?level? is not clear, too vague. Could mean anything. Please find a better term. What is an ?endsystem? exactly? Introduction, 5th paragraph: What is a static development and analysis technique? Conversely, what would be a dynamic technique? ?static approaches are not well suited ?? and the rest of the paragraph. This is not convincing. ?evolve more rapidly? than what? The ?desirable QoS properties? you mention are not new. It seems to me that what you call ?static techniques? have been used efficiently for a long time to achieve these goals. ?motivate the reusable of ?? shouldn?t you write ?motivate to reuse ??? ?Solution approach ->?? Why such a notation? This should be a separate paragraph: it looks like we are in the same one as the previous paragraph. Page 2, second column. ?Due to the sheer ?? Isn?t it also because MDD is a new discipline and tools are now emerging, and are thus not perfect/complete (all the issues have not been solved)? Page 2, bottom of column 2 ?What is therefore required ?? You seem to restrict MDD to the composition, configuration and deployment of components into applications. MDD is a lot more than that as it promotes the automatic transformation of models at a high level of abstraction in more detailed models in a step-wise manner, each time making analysis/design decisions (possibly selecting a COTS). So, though I do not discuss in this comment how pertinent is your contribution, you cannot say it is a ?model driven development ? application?. You only address one (set of) problems (1st paragraph in page 3). Indeed, in section 2.1 you explicitly say you address modeling of deployment and configuration only. Not analysis and design and how one can automatically translate an analysis model into a design model. ?Second, we discuss the technical difficulties ?? I do not understand (at this time in the article) why you need a case study to illustrate the challenges one faces when building such a MDD application. Would you need to adapt the MDD application each time you consider a new case study? I guess you mention the case study because with this case study you had to use specific modeling techniques/tools and then you had to make the tools communicate. If so, I think that instead of using term case study, you should rather say that you show how the cosmic architecture is tailored for a given set of modeling and model checking tools. Parts of Fig.1 are not legible at all! Consider enlarging it (it can span two columns, or 1 and a half column) Its different elements are not all discussed, thus questioning the usefulness of the figure. What are the different tools in the COSMIC toolsuite? There should be a short description for each of them and how they relate to the figure, and a reference to [5] or [6] for further details. Page 4. This looks like the list of tools in the toolsuite that you mentioned when discussing Fig.1. The question is then: since everything seems to be done by other tools (references [19] to [28]), what COSMIC is doing exactly? Does it only facilitate tools? interactions? This should be emphasized/described. This is not clear. The required description (second column in page 4) comes too late. Again, Fig. 2 is not discussed, that is its elements are not discussed: for instance, I do not see any reference to (1), (2) and (3) in the text. Since these three points are not discussed, the only legible thing I see in the figure is not a process (the caption says ?MDD process using COSMIC?) but a typical architecture of a distributed real-time software system (application, middleware, operating system, ?). So, Fig. 2 does not illustrate ?how COSMIC tools can be applied in the context of DRE middleware and applications to ?? Again, do not let the reader discover Fig. 3. Help him follow the flow of processes. The text should reference the Figure a lot more than with a simple ?as shown in?. The discussion on GME is not very clear: A reader not familiar with these notions will be lost; The discussion is of no help to a reader who is very familiar with them; A discussion does not contain enough information to convince a reader with some level of familiarity. Each sentence basically raises a question. For instance: - ?Cosmic ensures that rules of constructions and the models constructed according to these rules, can evolve together over time? What does this mean exactly? That the toolsuite does not depend on the (deployment and configuration) languages it uses? What (good) properties of GME are used to enforce that? - ?Each Cosmic tool synthesizes ?? Why middleware is important here? Do you mean the middleware of the DRE system to be developed? Or the middleware used by Cosmic? Why is discussing XML important? - PICML seems to be a language you have defined. Any reference? - What does ?artifact? of PICML mean? Language constructs? - ?PICML allows the specification of all the above concerns of component-based deployment and configuration by allowing users to model them as elements in a GMF paradigm? What does this mean? What is an ?element in a GMF paradigm?? - I do not agree when you say that you can ensure that generated models are ?semantically valid? as it basically depends on whether the original model is valid or not. How can you ensure that a UML class diagram is semantically valid for instance? You do say you ensure ?static semantics? though your definition is vague. The only thing the OCL constraint can describe (or ensure) is that the model has specific characteristics: e.g., if there is a specific relationship between model elements in the original model then you should find another specific relationship between model elements in the transformed model. The reader may not know OCL: you do not even provide the complete name. - You definition and example of ?dynamic semantics? are confusing. When I read ?dynamic semantics? I understand a property of the model. Your example however describes processes/activities: e.g., producing code. - What is the ?ITS project?? This is the first time you use the term. - ?PICML contains multiple model interpreters?. PICML is a language. How can it ?contain? interpreters? - It does not seem easy to weave the concerns. More details should be provided to convince the reader. Section 2.2 What is the point of Fig.4? Do you simply want to show a snapshot? I do not think the figure brings anything. Page 6, 1st column: ?In particular, Bogor and CADENA employ?? I think ?cadena? is missing in your sentence. ?view editor for manipulating for?? One ?for? too many. The cps file seems to contain the description of state base behaviors. Why not simply saying this? Page 6, 2nd column: ?the scenario also sUports useful?? The U is missing. Section 3. Again I do not understand why you need a case study to discuss the integration between two development tools. I think I?m misled by the title of the section. And the abstract says ?Second, we discuss the technical difficulties encountered integrating these tools in the context of a DRE application case study.? Section 3 does not do achieve this. Figures 5 and 6 are too small and barely legible. What is the notation/language used for Fig. 6? Looks like UML. I suggest you write the acronyms (e.g., MWI) in the text rather than in the figure: you will have less barely legible elements in the figure. Page 7. What is a CCM facet? ?Figure 7 shows ?? It does not show anything as I can?t read it. ?the return value of the facet?? Where in the figure? I understand your point: finding an appropriate communication mechanism. I agree that a graphical notation helps. However, the process of finding that the current communication mechanism is not appropriate is not specific to PICML, Cosmic or Cadena. The user does everything, and the only thing that is required is a graphical notation. I think one would obtain the same result with Rational Rose RT for instance. So what is specific to the integration Cosmic-Cadena here? Section 3.4 ?To evaluate this in the context OF our ?? The OF is missing. The example you use is really structure, not related to semantics, though you used it as a ?static semantics? example previously. This is where I think you should not use ?semantics?. To me there is nothing related to semantics here. Figures 8 and 9 could be anything as they are not legible! Again, Fig 10 cannot be understood. It is too small and the (relevant/interesting) notation has not been described. ?Examining the production sequence ?, however, ?? The however, in contrast to the previous sentence suggest that you can be sure there is not deadlock. However, the production sequence is also a model. It does not tell what happens in the implementation. I cannot follow you discussion of Fig 6 at the bottom of page 9 as I cannot read fig 6. You say ?the sequence diagram implicitly defines ??. The reader cannot agree or disagree. ?but it is better to specify all four semantically?? Why is it better? You provide a cadena specification on page 9. You should either describe it a little thus helping the reader understand the notation (e.g., what does ?WorkOrder -> Display? mean?) or simply remove it. Footnote 3: ?A Bogor script could be set to TO check?? How should the reader read and understand Fig 11? This is a scenario, that is a specific execution among many: what is the scenario about? Why do you choose a scenario? Cannot you reason from a model representing all the scenarios? How did you select this particular scenario? Why is it interesting? ?Only the connections that belong to the current mode will be shown.? This I do not understand as I cannot read Fig 11 and the notation has not been described. ?Since the cycle analysis will detect any cycles in any of the modes, the current model (I think you are referring to Fig11) can be validated against deadlocks.? I do not understand this. Fig.11 is a scenario, that is a particular execution of the system. If the scenario does not contain any deadlock, of course you are able to validate it. But again this is one execution (scenario) among many. In the same vein, I do not understand the point of the rest of the section. You seem to look for deadlocks in scenarios. This requires that the user defines interesting scenarios, and set parameters (as you do) correctly. It would be more interesting, but also more challenging to identify deadlocks from models that represent all possible scenarios. Section 4. ?(3) significantly increasing ?? should be ?(3) significantly increase?? Challenges 1 and 2 that you discuss are not new. They have been discussed a lot and you applied/tailored one existing solution. However, the way you present them in section 4 suggest that the identification of the challenges is a contribution, which is not true. Challenge 3. I?m not convinced by your argument on the need to ?merge the different data handled ?? You say the first scenario one could consider results in duplicate entries (the enter-twice approach). If a tool sends a data to the repository, using a general type, why couldn?t the other tool read that data? The discussion is too short. I follow the ideas presented in the rest of the section but do not grasp what you exactly mean in this last paragraph in page 12. Section 5. ?modeling and controlling much larger scale DRE systems? Do you mean validating rather than controlling? ?multi-dimensional QoS requirements? I did not see how multi-dimensional QoS requirements are handled. Vest and Aires ?have not been applied to QoS?? This does not mean one could not do it. You comparison to those two approaches is not clear. What are the commonalities and differences exactly? Conclusion. ?MDD is a software development paradigm that applies domain-specific modeling languages systematically to engineer computing systems? I do not know what this mean. This definition (?domain-specific??) could apply to any software development strategy. Your conclusion does not summarize future research directions. I?m surprised. Typos in references [23] and [24]: two ? characters instead of one. =====================================