Upload
latham
View
56
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Aspect-Oriented Software Development. Eric Kenseth. Contents. History Terminology Aspect Oriented Programming Analysis Design Patterns Testing Maintenance Conclusion. History. Early 90s, U of Twente, Netherlands Subject-Oriented 1993, IBM Researched similar subjects - PowerPoint PPT Presentation
Citation preview
Eric Kenseth
HistoryTerminologyAspect Oriented ProgrammingAnalysisDesignPatternsTestingMaintenanceConclusion
Early 90s, U of Twente, NetherlandsSubject-Oriented
1993, IBM Researched similar subjectsFeature-Oriented
1997-2000, Xerox PARC develops AspectJTrue birth of Aspect-Oriented
ConcernAnything any stakeholder wants the system to
do.Anything, any stakeholder
Cross-cutting ConcernFar-reaching concernApplies to many subsections of the systemThe reason for Aspect Oriented to exist
Separation of ConcernsRemoval of sections in a module that deals with
other concerns
JoinpointLocation where aspects can take over
executionDepends on language as to where is supported
Method CallsMethod ReturnsException ThrowsReading/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 AdviceAdvice may modify program flowAdvice may access values in the context of the
cutAspects encapsulate a cross-cut concernWhy?
ModularizationTanglingScattering
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 casesGeneralized in situationDetailed in stepsNot useful for the client, only the designers
Other use cases include the aspect cases a lot
Not well supported by UMLFor now no formally accepted answerSeveral extensions proposedSome suggest separating base code from
aspects in design
Very useful when designing with aspectsDemonstrates when aspects are invokedCan help spot where pointcuts need to be set
Spectator Pattern‘Harmless advice’Doesn’t modify the other concerns, just
watches itLoggers, Tracers, Profilers
Regulator PatternEnforces requirements on the system stateMay control the flow if errors occurSecurity Authorization, System Constraints
Patch PatternEnhances or Modifies features being ReusedAspects act as methods for a class
Add new methods to classes you don’t have access to rewrite
Modify methodsAllows updating the reused asset without re-
modificationMust be careful about breaking assertions
Extension PatternMaking an extendable system is problematicAspect 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
LanguageSpecialty language needed.
Compiler/Interpreter needs to support aspectsMost languages only have minor changes to them
AspectJDozens of other Java-basedC/C++/C# based languagesMany other languages have Aspect-supporting
versions of themEven Cobol
Development aspects can help test and debug base codeLoggingTracingProfilingPerformance Monitoring
These aspects have several advantagesEasier to add/remove to the system as aspects
Aspects require different testing meansLack independent identityMay be coupled to context
New ways for aspects to cause faultsIncorrect pointcut pattersIncorrect aspect orderingIncorrect context checking in pointcuts
Systematic testing means are lacking
Add new features without disturbing code.Separation makes modifying cross-cut
concerns much easierUntangling makes modifying primary
concerns saferUnlikely to break other concerns while
modifying.Modifying Joinpoints may be dangerous still.
Code is modularNo tangling with cross-cut concerns in
componentsNo scattering of cross-cut concerns in other
concernsMany aspects are features useful in almost all
systemsLoggingTracingProfiling
New and emergingStill needs refining in ways
DesigningTesting
Shows promise in certain situationsBig, Complex, with multiple user-rolesPatching 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.), Aspect-Oriented 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?