Aspect Oriented Software Development
Download
Report
Transcript Aspect Oriented Software Development
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?