Jan Hannemann

Problem

The paper provides an approach for replacing OO code fragments with corresponding AOP constructs. The approach consists of an iterative four-step process and is mostly realized in a prototype refactoring tool (note that the tool does not generate code). Given a properly marked program, the tool uses TXL rules to identify potential move-to-aspect refactorings for the marked code (discovery). The user then specifies which refactorings to apply (selection), or can alternatively apply object-oriented code transformations to help make the original code conform to what the refactoring step expects (transformation). Once refactorings are selected, the code is transformed (refactoring).

Contributions

The main contributions of this work are the iterative approach for the transformation of OO code fragments into AO equivalents, and the supporting tool. The approach is independent of the structure of the target cross-cutting concern, which has both advantages (it's generally applicable) and disadvantages (the resulting code has little structure, consisting of many unrelated pointcut-advice pairs. For example, the single concern investigated in the paper would consist of 151 such pairs). A manual "refinement" of the generated code seems unavoidable.

The work is novel in that the individual refactorings are semantics-preserving (not explicitly shown), which is an important consideration for refactorings in general.

Further of interest are five the OO-to-AO refactorings presented in the paper (note that two of them are already mentioned in Monteiro's work [20]; the other three target very specific cases).

Weaknesses

Unfortunately, the paper has a number of weaknesses. First, the approach is not implemented completely. In particular, the integration with aspect-mining approaches is not realized, and the tool requires the developer to "mark" the sections of code to refactor. Finding code pertaining to the implementation of a cross-cutting concern is not trivial, so the burden on the developer is (currently) considerable. The integration of mining techniques appears feasible, but the paper would have been much stronger if the tool would actually support it.

Similarly, the tool does not actually generate aspect code, so the fourth step of the approach (refactoring) is not completely implemented (yet it is described as "fully automated"). The authors' claim that "the generation [...] poses no conceptual difficulty" assumes that the five refactoring mechanics they provide are in fact applicable in all cases, which is not convincing: the authors themselves point out a few complications that can arise when performing the refactorings under certain conditions. For example, for the Call Before refactoring the developer has to manually check preconditions, for multiple refactorings special considerations are required when local variable are used, and the Extract Wrapper refactoring does not appear to work when a single object is wrapped multiple times (X x = new X(); Y y = new Y(x); Z z = new Z(y);).

The case study is disappointing: a single concern (albeit a complex one) on a single system has been investigated. It is questionable in how far the results are generalizable. For example, the investigated JHotDraw undo concern uses object wrappers extensively. This appears to be a problem-specific implementation; other concerns will likely see much less applications of the Extract Wrapper refactoring. Another issue is the evaluation of the quality of the resulting code (one of the aims of the case study, see section 5.2): the lone criterion for the resulting code quality is the number of Extract Method transformations utilized. This is questionable indicator for code quality at best. The actual resulting code is never considered, most likely due to the fact that their tool does not generate aspect code in the first place. One means to evaluate code quality would be to compare their AOP solution to that of Marin [18], who also aspectified the undo concern in JHotDraw.

Overall, a number of not quite accurate claims detract from the credibility of the paper. For example, the JHotDraw version in question has less than 30k LOC, not 40k. The integration of mining techniques and the generation of code are not realized (as mentioned above), although they are integral to the approach as presented. This makes it questionable whether the case study can really be considered an "end-to-end" migration. Some of the refactorings presented (Especially the Extract Beginning refactoring) are already mentioned in (multiple) other works.

The related work section has a few minor weaknesses. There is an unnecessary focus on aspect-mining (which is not supported by the tool), and several works on AOP refactoring are not mentioned, especially alternative approaches for the partial automation of concern refactorings. Hanenberg's work on making existing OO refactorings work in an AO context is very different from the work presented in the paper, but raises the question if the two OO refactoring the tool provides are actually "aspect-aware", or whether they can break existing aspects.

Another minor point is that the language of the paper is sometimes misleading. For example, phrases like "the second step applies ..." and "the [...] third step chooses ..." imply that these steps are at least partially automated, while in fact they are performed by the developer: Although the code transformations in step 2 are automated, the developer has to pick which ones to apply and how. Step 3 is not automated at all. In section 4.3 the last paragraph sounds as if the tool would play thorugh all potential OO transformation to determine which ones will enable further refactorings, but this is not the case.

Questions

Both in section 4.1 and 5.2 the authors claim that the Extract Method transformation is problematic due to it's "deep" impact on the code structure and should therefore be used sparingly as a "last resort". It is not clear why an impact on the structure of the program is so problematic.

The last section of 4.3 and the description of phase 2 of the approach seem to be at odds: how is the second modifier calculated if the tool does not play though all potential OO transformations to see which ones enable alternative refactorings?

Belief

This work represents an interesting approach to the refactoring of arbitrary crosscutting concerns into aspects. Unfortunately, the paper has a number of weaknesses that distract from the contributions. In particular the "lessons learned" from the case study are unconvincing. It appears as if the paper is slightly premature; if the tool would actually integrate an aspect-mining approach and generate aspect code, it would match it's own claims more closely.

---

Shawn Minto

Problem:

Refactoring OO code to AOP code can be difficult while maintaining the original behavior, so a semi-automated tool is required.

Contributions:

• Refactorings from OO to AOP
• combining OO transforms with refactoring to automate refactoring
• tool to perform these refactorings

Weaknesses

• Only tested with a medium sized program and specific functionality
• No mention of the time it took to do this
• Whoever performs this needs to understand the whole codebase, OO programming and AOP programming
• Widespread changes make developers relearn all of the code

Questions

• Why no include a way of aspect mining in the tool?
• How is the human guidance presented to the user?

Belief

I think that this is useful to help move codebases to AOP.

---

Mik Kersten

Problem

The increasing popularity of AOP is resulting in a need to facilitate moving from object-oriented to aspect-oriented implementations. Some of this process can be automated by defining transformations from a language like Java to AspectJ. Automating AOP refactoring could be faster and less error prone than doing the transformations manually.

Contributions

The authors describe semantics preserving transformation rules for extracting advice. The refactorings they propose seem novel, as does their process for iteratively transforming the OO code until the tangling is extracted into aspects. I also thought that the discussion on Priorities (4.3) was also a useful contribution. A big part of the problem of automatically refactoring to AOP is that not enough information is encoded in the OOP code and additional information from the user is needed. But they demonstrate that some precedence information is implicit in the code and can be used for ‘prioritizing’ advice, and could potentially be use for generating precedence ordering of aspects.

Weaknesses

This paper didn’t succeed at doing what I thought it set out to, which was to describe a human-guided approach to refactoring aspect-oriented programs. It failed to outline that space, and place it’s contribution within it. The breadth of aspect-oriented semantics relevant to refactoring was never discussed—and the approach appears to work for a very limited set of join points (call, execution, no handlers, etc) and only seems to suppor simple advice (no ITDs, little discussion on join point context). The limitations or space are not discussed and the reader is left to assume that what’s presented sufficiently covers what’s important in AOP refactoring.

A bigger weakness was that the “human-guided” and discovery parts were introduced, but seemed to be ignored by the work. If I recall (Jan should correct me) previous work has outlined that some of the information to refactor code from OOP to AOP can be automated. But the hard part about this is figuring out how to get the additional information that’s not encoded in the OOP code, and how to create a refactoring process and mechanism that can gather this information from the user and incorporate it in the transformations. So it seemed like they focused on the easy part and almost completely ignored the hard part, which makes the approach much less convincing. It was also hard to tell which parts of their tool actually worked.

Questions

Is TXL a good language for describing these kinds of transformations?

Belief

In my opinion tool support needs to be a first class participant in AOP refactoring tools. Too much of the crosscutting that’s in programmers’ heads gets lost when they write the OOP code. Also, my experience with OOP refactorings is that while it’s good to have tools that make them semantics-preserving, refactoring is a good time to improve the structure of the program, and as such a good time to be gathering this information from the user.

---

-- Main.jan - 14 Nov 2005