// $Id: reviews.txt,v 1.10 2005/12/06 18:43:46 kitty Exp $ This document includes reviewers' comments on the initial submission and our responses on how the reviewers' concerns have been addressed. > --------------------------------------------------------------- > Reviewer 1 > Detailed comments for revision, or reasons for rejection > (please attach additional pages if necessary): > The paper would be substantially stronger if it is more clearly defined > as an experience paper or case study using a particular language and > tool set. Taking this approach, the paper needs to include much more > detail about the example, including its implementation. We illustrate that the crosscutting concerns described in the paper actually emerge in any MDD approach to component-based distributed systems development, i.e., the concerns described are not unique to any specific modeling language, but common to all such approaches. We then showcase these in the context of our DSML, which is PICML. > Alternatively, additional theoretical depth is needed: > - include the weaving algorithm (definition and proof of correctness) We did not address this issue in this specific paper for the following reasons: 1. We do recognize the important issue of ensuring some level of quality in the modeling aspects. As such, in the conclusion we allude to ongoing work that addresses the issue of testing the correctness of a model transformation. 2. The formal mechanisms of the weaving are not the focus of the paper - our focus is a discussion on how model weaving is applied to modeling of distributed components. 3. An adequate proof of correctness would require a large amount of page-space that would divert attention to a peripheral concept as it relates to the overall goal of the paper. 4. We feel the suggestion is somewhat unfair - it is not the case in papers on weavers at the programming language level that proof of correctness is required, so we feel it is not justified in the specific context of this paper. > - provide the five tuple definition of PICML or describe clearly We have added the five tuple definition of PICML. > where this can be found > - define/present the metamodel We have included a more detailed discussion of the metamodel. We have also cited the paper which gives a much more in-depth walkthrough of the features in PICML, since including that discussion here will result in adding things which are not the primary focus of this paper. > Need to clarify the limitations of this approach. In the concluding remarks section we have outlined the lessons learned. In this we have explained the limitations of our approach. > Need to clarify the level of abstraction being modeled (requirements, > analysis, architecture, detailed design) By including a more detailed discussion on PICML and referring to our published work on PICML, which shows even more details, we have provided the reader with enough information to understand the capabilities of PICML. > What would need to change if CCM not selected (for example, CORBA used?) We have added comments that discuss how the same issues that emerge in CCM would also appear in J2EE or .NET. The goal behind the development of PICML has been on making it platform independent. As we gain more experience using a variety of component middleware (e.g., J2EE and .NET), we are enhancing PICML to be truly platform independent. In general, we expect very similar crosscutting concerns to manifest in MDD appraoches across all these standard component middleware since many of the concepts of composition, integration, configuration and deployment are common across all these middleware platforms. > Does the tool support automated code generation or does it interface > with a tool that does this? We have tried to address this concern by discussing the model interpreters that exist in PICML. Different interpreters in PICML synthesize different artifacts (e.g., configuration descriptors, deployment descriptors, benchmarking code). PICML does not generate code for the business logic within each component. This issue is explained in more detail in the revision. > Related work section needs additional depth. A body of work is > available in the literature that considers translating and weaving > aspect oriented requirements and design models. One of the co-authors is also an organizer of the long-standing workshop on aspect-oriented modeling and is familiar with the depth in this area. Additional details on that workshop and other issues of aspects at the modeling level have been provided. This is becoming a very deep area with perhaps hundreds of papers already published at various workshops and special issues, so it is difficult to cover everything. The revision has been modified to provide a broader summary of the related work in this area, including new papers that have been published after the initial submission of this paper. The related work describes the general work in aspect modeling as notational conventions to specify crosscutting concerns, which is different from the goals of this paper which focus on transformations of models in the style of an aspect weaver at the modeling level. > Additional minor comments > - try to make writing style more consistent (reduce or remove the > style: 1) xxxx and 2) xxx from the Introduction > - add a legend to Figure 1 > - Figures 2, 3 too difficult to read > - Figure 6 is not meaningful - cannot read > - check each figure for readability and its contribution to the paper We made the writing style consistent as suggested. A legend has been added to Figure 1. Figures 2 has been enlarged and refocused. Original figures 4,5,6 have been removed - the accompanying text providing an adequate summary of what the figure illustrated. --------------------------------------------------------------- > Reviewer 2 > Detailed comments for revision, or reasons for rejection > (please attach additional pages if necessary): > This paper proposes application of aspect-oriented techniques to > model-driven component-based development of distributed systems. In > particular, the authors argue that crossing-cutting concerns may appear > in model-driven development in the context of a domain-specific > modeling language, PICML, and propose to apply C-SAW to address these > crossing-cutting concerns. The proposed approach is illustrated by its > application to a joint-emergency response system. > > Integration of aspect-oriented concepts and techniques into model-driven > development is welcome. The paper certainly has merits that are worth > publishing. The current writing of the paper is sufficient for a > conference paper. However, for a journal publication, the reviewer > would expect more. Below are two examples. > 1. The authors' argument on the challenges of cross-cutting concerns > in model-driven development seems closely tie to the modeling > language, PICML, which the authors use. It will be very helpful if > the authors can consider other domain-specific modeling languages and > show that the challenges of cross-cutting concerns also appear in these > languages. The authors Jeff Gray and Aniruddha Gokhale in the past have published papers in this area where they have showcased crosscutting challenges in other DSMLs, such as those used in the embedded systems. For example, the GPCE 2003 paper cited in this paper illustrates one such language. The primary purpose of this paper is to illustrate the crosscutting challenges that manifest themselves in DSMLs used for component-based systems, and how aspect oriented model weaving can be used to address these concerns. We believe that any modeling language that addresses deployment concerns of distributed components will encounter the same problems. The revision asserts reasons why we believe these problems are not unique to PICML. > 2. The proposed approach incurs the overhead of identifying > cross-cutting concerns, developing aspects and strategies that > address these concerns, and validating the correctness of these > aspects and strategies. The reviewer would like to see evaluation > of the proposed approach which shows how cost-effective the approach > is in addressing the challenges of cross-cutting concerns. It is not clear to the authors whether the reviewer is seeking some metrics to justify when these techniques are to be used. Although we do not have such metrics, a developer of component-based systems will very soon realize as he/she is developing the system using MDD techniques that changes made to one element affects numerous layers and views of the models. This becomes increasingly tedious as the number of components and the assemblies/packages in the system increase. Clearly, a system with only a handful of components will probably not justify using all these tools. We are concerned with larger-scale systems, with say 50+ components, where issues of scale clearly indicate the need for automation. However, we realize that there is a trade-off and that the investment in the time needed to create the aspects is not justified in the presence of models with few components. We acknowledge this in the conclusion. > In addition, the screenshots in the paper are not readable and have no > contributions to helping readers to understand the example and the paper. We have enlarged the figures. --------------------------------------------------------------- Reviewer 3 > Detailed comments for revision, or reasons for rejection > (please attach additional pages if necessary): > Ths paper presents an aspect-oriented approach to addressing > the crosscutting issues in the deployment of component-based > software. The problem definition sounds reasonable and the > work is interesting. As detailed below, however, I have > the following major concerns > (1) The solution presented in subsection 3.3 is very sketchy. It is > highly desirable to include more details on how the challenges are > addressed. As this is the key contribution of this paper, space > constraints are not a reasonable excuse for not doing so. The section > stops when I am still expecting more. We have addressed this concern by adding additional level of detail in the explanation of the different listings provided in the paper. We also add more comment on how the approach helps address the crosscutting concerns. We now provide line numbers in our listing and explain the approach by explaining each line of the code. There still are space limitations such that we cannot show all of the ECL for every level of detail. > (2) The listings in subsection 3.3 appear to be part of a general > solution, other than a domain-specific one. There is no evidence > that it actually has anything to do with the UAV application. The > names like foo do not make sense to the UAV example. Probably this is > not merely a naming issue. This is true. The strategies that are listed in the solution are valid for all applications built using PICML, i.e., they are not constrained to the UAV example. Thus the "foo" that appears in the listing is indicative of the fact the strategies are not specific to this UAV example. However, the strategies are "platform-specific", i.e., they solve concerns that are applicable to CCM only. The C-SAW aspect weaver itself is "domain-independent" since it operates at the metamodel level. Additional comments in the text have been added to help clarify this concept. > (3) More details on the different models of the UAV application are > necessary for demonstrating the solution. More detailed explanation is provided for each challenge. > (4) The crosscutting concerns in Aspect Listing 1 on page 12 > are not clear. What are they, how do they crosscut, > and how are they handled? Does C-SAW use pointcuts at all? The listings are provided with more detailed descriptions. We feel that the paper already addresses the issue of pointcuts. In fact, the paper states that the specification aspect is similar to a pointcut in that it identifies the principled places in the model where the aspect is to be applied. > (5) Line 3 under the strategy listing 1 on page 13: "- which > are necessary to solve the challenges ..." > Are they sufficient and effective? Why and how? All of the listings have been rewritten with improved details. > (6) 'scalable' is mentioned several times. > What does it exactly mean? > How do you justify the scalability of your approach? > through theroetical analysis or empirical study? The revision offers improved discussion on what is meant by scalability, in terms of the ability to enlarge a model from a base specification to a model with many common elements replicated. > (7) The figures 2-5 are not readable at all. Each figure is now shown separately making them larger and more clear. > (8) I agree that there are problems as discussed in the paper. > Yet some of them sound like a naming issue. Why are the > problems non-trivial - are they real challenges? We have now explained all the challenges in more detail, and have tied it back to the UAV example. We have also added examples from other component middleware platforms like .NET, to emphasize the fact that the naming issues are universal and applicable across different middleware platforms. > (9) Related work: More on aspect-oriented (UML) modeling can be > discussed and compared. While the paper shows an application of > aspect-oriented modeling, I cannot tell to what extent it has > improved the tasks of aspect-oriented modeling in general > as claimed in the paper. This comment was addressed by a reply to Reviewer 1. In general, a large majority of aspect modeling is primarily about notational/diagramattic conventions with little thought to what it means to have an actual weaver at the modeling level. Much of the notational focus results from the difference between UML software models, and the type of domain-specific models in this paper. The related work clarifies this distinction while also offering a broader summary of related work.