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

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

3. 3 Evolution of Programming Paradigms

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

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

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

7. 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. 8 Historical Perspective Each new Programming Paradigm has provided us with additional mechanisms for abstraction and composition.

9. 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. 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. 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. 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. 13 AOP as a Next Step

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

15. 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. 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. 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. 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. 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. 20 Examples of Crosscutting Concerns Logging & Debugging Error Handling Performance Optimizations Minimizing Network Traffic Synchronization Caching and Buffering Security Resource-Pool Management Transaction Management Design by Contract

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

22. 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. 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. 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. 25 Crosscutting Concern Detailed Example

26. 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. 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. 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. 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. 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. 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. 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. 33 System Development With AOP

34. 34 Crosscutting Concern Detailed Example

35. 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. 36 Crosscutting Concern Detailed Example

37. 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. 38 AOP Simple Logging Example

39. 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. 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. 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. 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. 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. 44 Quantifying the Benefits

45. 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. 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. 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. 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. 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. 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

51. 51 Issues Decoupling Obliviousness – Does Component Program need to be aware that Aspects are being applied to it? Intimacy – What has to be done to prepare Component Code for Aspects? Globality vs Locality – Do Aspects apply to the Component Program as a whole or only to parts of it? Software Development Process Need to devise a complete AOP Software Engineering Process How does AOP impact Overall Design Complexity?

52. 52 Tools

53. 53 AspectJ First Production Quality General Purpose AOP Language Release 1.0 Made Available June 2001 Seamless Extension to Java Compiler Produces Standard Java Byte Code Maintains Java’s Advantages Compiler Can Be Used to Easily Plug Aspects Into or Out of Overall Application

54. 54 AspectJ Component Language is Java Aspect Language is AspectJ Aspect Weaver is AspectJ Compiler ajc

55. 55 AspectJ

56. 56 Other Tools AspectC++ A Set of C++ Language Extensions to Facility AOP with C++ AspectC AOP Extension to C Support OS and Embedded System Programming Taken From Non-OO Subset of AspectJ FEAT Tool to locate, describe, and analyze concerns in existing source code Engineering of aspects from existing code

57. 57 Additional Information

58. 58 The People Behind AOP Gregor Kiczales Professor of Computer Science - University of British Columbia (Since 1999) Graduate of M.I.T. (1983) Research Scientist at Xerox PARC (1984-1999) Co-Founder of Group that Developed AOP and Started Aspectj.Org http://www.cs.ubc.ca/cgi-bin/userinfo/user/gregor

59. 59

60. 60 The People Behind AOP Cristina Lopes Professor of Computer Science – University of California (Since Fall 2002) PhD in Philosophy, Northeastern University (1997) Wrote First PhD Thesis on AOP Research Scientist at Xerox PARC Co-Founder of Group that Developed AOP and Started Aspectj.Org http://www.ics.uci.edu/~lopes/

61. 61

62. 62 Conferences Aspect-Oriented Software Development (AOSD) European Conference for Object-Oriented Programming (ECOOP) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA) International Conference on Software Engineering (ICSE) International Symposium on Object Technologies for Advanced Software (ISOTAS)

63. 63 Topics Discussed at AOSD 2003 Making the Code Look Like the Design Architectural Views of Aspects Modularization and Composition of Aspectual Requirements AspectC++ Back to the Future: A Retroactive Study of Aspect Evolution in OS Code AspectJ FEAT – A Tool for Locating, Describing, and Analyzing Concerns Source Code

64. 64 M.I.T. Technology Review Top 10 Brain-Machine Interfaces Flexible Transistors Data Mining Digital Rights Management Biometrics Natural Language Processing Microphotonics Untangling Code (AOP) Robot Design Microfluidics

65. 65 Discussion