Aspect-Oriented Programming

1. Aspect-Oriented Programming An Introductory Presentation Mike Landi MSCS Candidate Union University

2. Objectives • Evolution of Programming Paradigms • AOP as a Next Step • Tools • Additional Information • Discussion

3. Evolution of Programming Paradigms

4. Programming Paradigms • Machine Code • Assembly Language Programming • Procedural Programming • Functional Programming • Logic Programming • Object-Oriented Programming

5. Assembly Languages • Provide Mechanism for Abstraction of the Underlying Machine

6. Procedural Language Programming • Structured Programming • Functional Units are Implemented as Procedures or Functions • Modularity • Reusability of Code

7. Object-Oriented Programming • Coding that Mimics Real World • Based on the Notion of an Object • Functional Units are Represented as Objects • Objects most often Implemented as Classes • Principles of Inheritance, Encapsulation, and Polymorphism • Enhanced Modularization • Enhanced Code Reuse

8. Historical Perspective • Each new Programming Paradigm has provided us with additional mechanisms for abstraction and composition.

9. Design and Implementation • Design Processes • Enable us to Break a System Down into Smaller Units • Programming Languages • Provide Mechanisms that allow us to … • Define Abstractions of System Sub-Units • Compose Abstractions in different ways to Produce the Overall System

10. Design and Implementation • Design Processes and Programming Languages work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design process breaks the system into.

11. Generalized-Procedure Languages • OOP, Procedural, and Functional Languages • Support Functional Decomposition • Break Systems Down in Terms of Units of Behavior or Function • Software Engineering Concept introduced by Parnas

12. Limitation of GP Languages • GP Languages do not adequately address Non-Functional Units of a System • Co-composition of Functional and Non-Functional Units must be done manually • Leads to Complexity, and Tangling and Scattering of the Code

13. AOP as a Next Step

14. Origin of AOP • AOP was developed during the 1990s by researchers at Xerox PARC • Borne out of research to extent OOP capabilities

15. What is AOP? • AOP is a programming methodology for addressing crosscutting concerns in a system, at both the design and implementation levels. • AOP seeks to separately specify the various concerns of a system, and then to "weave" or compose them together into a coherent program. • AOP is an additional technique, not a replacement for OOP.

16. What is a Concern? • A particular Goal, Concept, Behavior, or Area of Interest … • Two Types of Concerns • Basic Concerns • Specify what is really important to an application • AKA … Functional, Common, Core or Domain Specific Concerns • Special Concerns • Used to manage or optimize Basic Concerns • AKA … Non-Functional or Crosscutting Concerns

17. Separation of Concerns • Emerging Paradigm Discussed by Cristina Lopes, Northeastern University, 1995 • Two Types of Concerns • Basic - Relevant to Application Domain • Special Purpose - Crosscutting • Seeks to Formally Separate the Basic Algorithm from Special Concerns • Prior to AOP • Functional Decomposition only Separated Basic Concerns from other Basic Concerns

18. Concept of Composition • Once concerns are separated and independently implemented, all of the associated code has to be composed into one coherent final program • OOP uses Object Reference, Inheritance, and Message Sending for Composition • AOP Systems Use One of the Following Techniques for Composition • Meta-Level Programming • Composition Filters • Pattern-Oriented Programming

19. What is a Crosscutting Concern? • Concerns that Cut Across Typical Divisions of Responsibility • Concerns that Cut Across Functional Decomposition • Concerns that Affect Multiple Classes

20. Logging & Debugging Error Handling Performance Optimizations Minimizing Network Traffic Synchronization Caching and Buffering Security Resource-Pool Management Transaction Management Design by Contract Examples of Crosscutting Concerns

21. What is an Aspect? • An AOP Programming Construct • Allows programmers to handle Crosscutting Concerns as Separate Single Entities

22. Properties of Aspects • Robust • Change to one aspect should have a limited impact on other aspects • Systemic • Aspects should affect the target program at many different places • Cross-Cutting Each Other • Information about one aspect will be mixed with information about other aspects in target program

23. Properties of Aspects • Loosely Coupled • An aspect should not know the details of other aspects • Contain Join Points • Used to weave the aspects with target programs

24. Crosscutting Concern Detailed Example • Information Delivery Service • Music • Pay-Per-View TV • Magazines • Charges Made Differently by Content Type • Song – Charge after 51% Saved or 100% Played • Show – Charge after First Episode Delivered • Magazine – Charge after Article Printed and Mailed

25. Crosscutting Concern Detailed Example

26. Crosscutting Concern Detailed Example • OOP Implementation of Crosscutting Concerns Results in … • Tangled and Scattered Code • Poor Traceability • Lower Programmer Productivity • Less Code Reuse • Poor Code Quality • Less Evolvable Code

27. Crosscutting Concern Detailed Example • An AOP Alternative … • Separate the Payment Crosscutting Concern from the Application Domain Classes • Remove Charge Methods from Song, Show and Magazine Classes • Capture Code from All Charge Methods in a Single Aspect • Establish rules for Composition of the Aspect with the OOP Classes • Join Points, Pointcuts and Advices

28. Structural Elements of AOP System • Component Language • OO Language (or not) • Aspect Language • Language Aspects are Programmed In • Aspect Weaver • Accepts Component and Aspect Programs as Input • Performs Co-composition of the two into one Combined Final Program

29. How AOP Works • Join Point Model • Model that Specifies How Composition Will Be Done • Which AOP Composition Mechanism Will Be Used • Makes It Possible for Combined Program to Execute Properly • Join Points • Well Defined Points in the Execution of Component Program • Examples: Method Call or Exec, Constructor Call or Exec, Field Reference, Field Assignment, others …

30. How AOP Works • Pointcuts • Syntactic Construct Used to Detect Join Points • Specifies a Set of Join Points • Can Optionally Specify Values in Execution Context of those Join Points • Advices • Method-Like Mechanisms to Declare Code that Should Run at Specified Join Points • Code Runs when Join Point Reached at Runtime • AspectJ Advices … Before, After, and Around

31. How AOP Works • More on Pointcuts and Advices (AspectJ) • Associated Parameter Mechanism • Allows Advice to See Subset of Values in Execution Context of Join Points • Access to Return Values (of Methods in Component Program) • Inheritance and Overriding of Advices and Pointcuts

32. System Development With AOP • Aspectual Decomposition • Decompose Requirements to Identify Crosscutting and Common Concerns • Concern Implementation • Common Concerns in Component Language • Crosscutting Concerns in Aspect Language • Aspectual Re-composition • Specify Re-composition Rules (Join Points, Pointcuts, Advices) for Use by Aspect Weaver

33. System Development With AOP

34. Crosscutting Concern Detailed Example

35. Crosscutting Concern Detailed Example • More Detailed Outline for AOP Solution • Remove all charge methods from OOP Classes • Create a Payment Aspect to contain the specialized code for the Payment Crosscut charge methods for the Song, Show, and Magazine classes • Add four Pointcuts to the Aspect to define Join Points • Two for Song (51% Played or 100% Saved) • One each for Show & Magazine • Add the specialized code for charge specifics for Song, Show, and Magazine to the Aspect • Each piece of specialized code has an Advice of its own that will execute when its Join Point is reached at Runtime

36. Crosscutting Concern Detailed Example

37. Crosscutting Concern Detailed Example public aspect Payment { pointcut song_play_charge(): execute(void Song.play*(..)); pointcut song_save_charge(): execute(void Song.saveToDisk*(..)); pointcut show_charge(): execute(void Show.delivered*(..)); pointcut magazine_charge(): execute(void Magazine.mail*(..)); after():song_play_charge() { { // Song play charge specialized code here … } after():song_save_charge() { { // Song save charge specialized code here … } after():show_charge() { { // Show charge specialized code here … } after():magazine_charge() { { // Magazine charge specialized code here … } }

38. AOP Simple Logging Example

39. AOP Simple Logging Example • AspectJ Compile Commands • Aspects can be easily plugged into or out of an application • Compile App with Aspect • ajc Point.java ShowAccesses.java • Compile App without Aspect • ajc Point.java • To get some info on what ajc is doing • ajc –preprocess Point.java ShowAccesses.java

40. AOP for Design By Contract • DBC Requires Explicit Contracts Hold True at Various Execution Points • Before an Operation • After an Operation • AOP can enforce DBC … • Create Aspects Containing Pointcuts and Advices • Advices Check Contracts at Execution Points • Execution Points Defined by Pointcuts

41. AOP Versus OOP • Where they are Related and Similar • AOP Works in Conjunction With OOP • AOP is an Additional Technique Not a Replacement for OOP • AOP does for crosscutting concerns what OOP has done for object encapsulation and inheritance

42. AOP Versus OOP • Where they are Different • AOP works on Crosscutting Concerns, OOP on Common Concerns • AOP attempts to realize scattered concerns as first-class elements, and ejects them horizontally from the Object Structure … OOP finds commonality among classes and pushes it vertically up in the Inheritance Tree • Modularization Unit of AOP is an Aspect, Modularization of OOP is a Class

43. Benefits of AOP • Modularization of Crosscutting Concerns • Implementation Looks More Like Design • Easier Development and Maintenance • Simplifies Code (Rmv Tangling Scattering) • Greater Potential for Reuse of Code • Smaller Software • More Evolvable Software

44. Quantifying the Benefits

45. The Power of the AOP Approach • Application code is easier to reason about • Easier to understand components and how they compose • They are not cluttered with Aspects • Easier to understand Aspects and how they compose • They are not tangled with other Aspects in Component Code • Easy to understand the effect of Aspects on Combined Output Code • Aspect Weaver handles details of Integration of Component and Aspect Code • Changes to Aspect Code are easily integrated by Re-Weaving

46. Long-term Promise of AOP • Easier coding and maintenance of crosscutting concerns, and elimination of scattered and tangled code surrounding such concerns, will make way for less buggy upgrades, shorter product cycles, and ultimately better and less expensive software.

47. Does AOP Work? • Easier to Build AOP System when Interface Between Aspects and Component Code is Narrow and Unidirectional • Narrow – Aspect Code has well-defined effect on points in Component Code • Unidirectional – Aspect Code Refers to Component Code but not vice versa • Have Determined Situations Where AOP Benefits Developers • More Studies Needed to Qualify and Quantify Benefits of AOP

48. Issues • Component Programs must not preempt Aspect Programs • Component Program must avoid handling any concerns being handled by Aspect Program • What Composition Mechanisms are provided? • Can Aspects be applied to different types of concerns? • Is the Aspect Language Domain Specific or General-Purpose? • Are Aspect Visible to Each Other?

49. Issues • Aspect Precedence • What mechanisms provided to resolve conflicts among multiple aspects advising same Join Point? • How are Aspects Specified? • Interactions between Aspects and Components • How Join Points are defined • Component Program requirements for specifying points to be joined to

50. Issues • Implementation Mechanisms • Are Compositions determined statically at compile time or dynamically at runtime? • Can compilations be done incrementally? • Does the compiler require source code or can it work with byte code? • Are there mechanisms for verifying compositions? • Reusability of Aspects • Need to develop ways to work with large numbers of Aspects and to build large libraries of Aspects