Talk:Aspect-oriented software development

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computer science (Rated C-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.

Missing figures[edit]

Figure 4 is missing. Keybounce (talk) 20:46, 1 October 2008 (UTC)

Figure 5 is missing too. There is a jump from Figure 3 to Figure 6. —Preceding unsigned comment added by (talk) 15:00, 26 July 2009 (UTC)

Figures 1, 2 are also missing.

Move various items not belonging in main space to back matter[edit]


Fragile Pointcuts[edit]

Coupling between Aspect and Base Modules[edit]

Aspect-Orientation in the Software Development Life cycle[edit]

Aspect Mining and Refactoring[edit]

Testing of Aspect-Oriented Programs[edit]

Maintenance of Aspect-Oriented Programs and Refactoring[edit]

Applications of Aspect-Oriented Software Development[edit]

Technological Neutrality[edit]

Since AOSD is an umbrella term for a variety of ways of realizing similar solutions to the problems of scattering and tangling introduced by the cross-cutting of concerns, it is important to try to describe concepts etc. in the most inclusive terms practical. Recognizing that there are deep differences among approaches that will show throug in terminology, we should also recognize that the lack of a sufficiently agreed terminology provides difficulty.

I would make a few suggestions:

  • use the term "approach" instead of "language". Not all aspect-oriented support requires building specialized languages, and some may work with respect to aspects written in non-aspect-oriented languages
  • try to avoid "crosscutting concern" when "concern" will do. A single concern is not really crosscutting, and whether concerns cut across one another may depend on which ones are used in building a system.
  • try to deal sensitively with the symmetric vs. asymmetric issue. This issue is fundamentally about whether a system is thought of as specially designated "base" concern into whose execution the aspects are woven or whether all concerns are treated in the same fashion and whose aspects are all also bases that are woven together.
  • be aware that the concept originally called 'join point' was redefined for some approaches and that a subsequent need for the original meaning caused the term 'join point shadow' to be coined. A phrase like "point in the execution of the program" is more inclusive than "execution of a point in the program".

However, coming up with a completely inclusive description that encompasses the already published literature is not always easy. Likewise, creating a restrictive description and terminology may merely drive away software developers and users who can not see their work as fitting into that description. If you can find ways to rework some of the remaining non-neutral material, I believe it would be to the benefit of all.CSProfBill (talk) 10:25, 16 September 2009 (UTC)

Quantification and obliviousness[edit]

The page says that "The best known definition of the nature of AOSD is due to Filman and Friedman". I would argue this is incorrect, and thankfully so. Google Scholar shows 588 citations for quantification and obliviousness. By contrast it shows 6498 for the Aspect-Oriented Programming paper by Kiczales Lamping, Mendhekar, Maeda, Lopes, Loingtier, and Irwin. The second number is muddled a bit with citations for the patent, but even 1/2 of 6498 is well over 588.

This is fortunate, because the quantification and obliviousness never been a good intellectual grounding for AOP. At best it explains pointcuts and advice, which is one of the two join-point models in AspectJ. It never explained the other half of AspectJ, or RG, AML, Hyper/J, Demeter traversals and so on.

I propose to entirely strike this section and replace it by improving the material on join point models, which are the fundamental idea in all AOP systems. (Term originally due to Harrison, concept generalized later by Masuhara to make it support a wider range of systems.)

GregorKiczales (talk) 22:37, 17 February 2011 (UTC)