Eric Kenseth
 History
 Terminology
 Aspect Oriented Programming
 Analysis
 Design
 Patterns
 Testing
 Maintenance
 Conclusion
 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
 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
 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
• 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
• 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
 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?
• 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
 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
 Not well supported by UML
 For now no formally accepted answer
 Several extensions proposed
 Some suggest separating base code from aspects in
design
 Very useful when designing with aspects
 Demonstrates when aspects are invoked
 Can help spot where pointcuts need to be set
 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
 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
 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
 Language
 Specialty language needed.
 Compiler/Interpreter needs to support aspects
 Most languages only have minor changes to them
 AspectJ
 Dozens of other Java-based
 C/C++/C# based languages
 Many other languages have Aspect-supporting versions
of them
 Even Cobol
 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
 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
 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.
 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
 New and emerging
 Still needs refining in ways
 Designing
 Testing
 Shows promise in certain situations
 Big, Complex, with multiple user-roles
 Patching and Extending
 [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.), AspectOriented Software Development (pp.380-398). Boston:
Addison-Wesley.
 [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
 Questions?