Aspect-Oriented Software Development

1. Aspect-Oriented Software Development Eric Kenseth

2. Contents • History • Terminology • Aspect Oriented Programming • Analysis • Design • Patterns • Testing • Maintenance • Conclusion

3. History • Early 90s, U of Twente, Netherlands • Subject-Oriented • 1993, IBM Researched similar subjects • Feature-Oriented • 1997-2000, Xerox PARC develops AspectJ • True birth of Aspect-Oriented

4. Terminology • Concern • Anything any stakeholder wants the system to do. • Anything, any stakeholder • Cross-cutting Concern • Far-reaching concern • Applies to many subsections of the system • The reason for Aspect Oriented to exist • Separation of Concerns • Removal of sections in a module that deals with other concerns

5. Terminology • Joinpoint • Location where aspects can take over execution • Depends on language as to where is supported • Method Calls • Method Returns • Exception Throws • Reading/Writing to a field

6. Terminology • Advice • The code of a cross-cutting concern • Needs to be executed in many places • Pointcut • Points in the program where the advice needs to be executed • Joinpoints • Inter-Type declaration • Declared member of another class in an aspect • Visible only to classed declared to have access

7. Terminology • Aspect • A class-like structure to encapsulate cross-cut concerns • Can be static or dynamic • Can have fields and methods as members • Can be abstract or not • Can be instantiated • Can have pointcuts, advice, and inter-type declairations • May be ‘privileged’ to access private members of other types

8. Aspect Oriented Programming • Pointcut defines where to execute the Advice • Advice may modify program flow • Advice may access values in the context of the cut • Aspects encapsulate a cross-cut concern • Why? • Modularization • Tangling • Scattering • How?

9. Requirements Analysis • What are the concerns? • Which of these are core concerns? • Which are cross-cutting concerns? • Logging • Caching • Security concerns • Error detection • Error correction • Memory management • Real-time issues • Synchronization • Mutual exclusion • Complex rule monitoring

10. Use Cases • Aspect use cases • Generalized in situation • Detailed in steps • Not useful for the client, only the designers • Other use cases include the aspect cases a lot

11. Design • Not well supported by UML • For now no formally accepted answer • Several extensions proposed • Some suggest separating base code from aspects in design

12. Class Diagrams

13. Sequence Diagrams • Very useful when designing with aspects • Demonstrates when aspects are invoked • Can help spot where pointcuts need to be set

14. Patterns • Spectator Pattern • ‘Harmless advice’ • Doesn’t modify the other concerns, just watches it • Loggers, Tracers, Profilers • Regulator Pattern • Enforces requirements on the system state • May control the flow if errors occur • Security Authorization, System Constraints

15. Patterns • Patch Pattern • Enhances or Modifies features being Reused • Aspects act as methods for a class • Add new methods to classes you don’t have access to rewrite • Modify methods • Allows updating the reused asset without re-modification • Must be careful about breaking assertions

16. Patterns • Extension Pattern • Making an extendable system is problematic • Aspect solution: Create extension points • Empty method calls where the system will be extended • Extension aspects use these points to add to the system • Independent evolution of base code vs. extensions

17. Implementation concerns • Language • Specialty language needed. • Compiler/Interpreter needs to support aspects • Most languages only have minor changes to them

18. Languages • AspectJ • Dozens of other Java-based • C/C++/C# based languages • Many other languages have Aspect-supporting versions of them • Even Cobol

19. Testing • Development aspects can help test and debug base code • Logging • Tracing • Profiling • Performance Monitoring • These aspects have several advantages • Easier to add/remove to the system as aspects

20. Testing • Aspects require different testing means • Lack independent identity • May be coupled to context • New ways for aspects to cause faults • Incorrect pointcut patters • Incorrect aspect ordering • Incorrect context checking in pointcuts • Systematic testing means are lacking

21. Maintenance • Add new features without disturbing code. • Separation makes modifying cross-cut concerns much easier • Untangling makes modifying primary concerns safer • Unlikely to break other concerns while modifying. • Modifying Joinpoints may be dangerous still.

22. Reuse • Code is modular • No tangling with cross-cut concerns in components • No scattering of cross-cut concerns in other concerns • Many aspects are features useful in almost all systems • Logging • Tracing • Profiling

23. Conclusion • New and emerging • Still needs refining in ways • Designing • Testing • Shows promise in certain situations • Big, Complex, with multiple user-roles • Patching and Extending

24. Resources • [1] O. Aldawud, T. Elrad, and A. Bader. (2003) UML profile for aspect-oriented software development. In Proceedings of the AOM workshop at AOSD, 2003 • [2] Hachani, O., Bardou, D. (2002) Using Aspect-Oriented Programming for Design Patterns Implementation. In: OOIS 2002 Workshop on Reuse in Object-Oriented Information Systems Design • [3] Blair, G., Blair, L., Rashid, A., Moreira, A., Araujo, J., Chitchyan, R. (2005). Engineering Aspect-Oriented Systems. In Fillman, Elrad, Clark, Aksit (Eds.), Aspect-Oriented Software Development (pp.380-398). Boston: Addison-Wesley.

25. Resources (cont.) • [4] James Noble, Arno Schmidmier, David J Pearce, Andrew P Black (2007) Patterns of Aspect-Oriented Design. In Proceedings of European Conference on Pattern Languages of Programs. Irsee • [5] Filman, R. & Friedman, D. (2005). Aspect-Oriented Programming Is Quantification and Obliviousness. In Fillman, Elrad, Clark, Aksit (Eds.), Aspect-Oriented Software Development (pp.1-7). Boston: Addison-Wesley. • [6] R. T. Alexander, J. M. Bieman, and A. A. Andrews. (2004) Towards the systematic testing of aspect-oriented programs. Technical Report CS-4-105, Department of Computer Science, Colorado State University, Fort Collins, Colorado. • [7] AspectJ. (n.d.). Retrieved October 31, 2009 from Eclipse website, www.eclipse.org/aspectJ

26. Thank you for your time • Questions?