Talk:Aspect-oriented software development
|WikiProject Computer science||(Rated C-class, Mid-importance)|
- 1 Missing figures
- 2 Move various items not belonging in main space to back matter
- 3 Aspect-Orientation in the Software Development Life cycle
- 4 Applications of Aspect-Oriented Software Development
- 5 Technological Neutrality
- 6 Quantification and obliviousness
Figures 1, 2 are also missing.
Move various items not belonging in main space to back matter
Coupling between Aspect and Base Modules
Aspect-Orientation in the Software Development Life cycle
Aspect Mining and Refactoring
Testing of Aspect-Oriented Programs
Maintenance of Aspect-Oriented Programs and Refactoring
Applications of Aspect-Oriented Software Development
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
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.)