aspect-oriented programming an introductory presentation mike landi mscs candidate union university

Aspect-Oriented ProgrammingAspect-Oriented Programming

An Introductory Presentation

Mike Landi

MSCS Candidate

Union University

2

ObjectivesObjectives

Evolution of Programming ParadigmsAOP as a Next StepToolsAdditional InformationDiscussion

3

Evolution of Programming ParadigmsEvolution of Programming Paradigms

4

Programming ParadigmsProgramming Paradigms

Machine CodeAssembly Language ProgrammingProcedural ProgrammingFunctional ProgrammingLogic ProgrammingObject-Oriented Programming

5

Assembly LanguagesAssembly Languages

Provide Mechanism for Abstraction of the Underlying Machine

6

Procedural Language ProgrammingProcedural Language Programming

Structured Programming Functional Units are Implemented as Procedures

or Functions

ModularityReusability of Code

7

Object-Oriented ProgrammingObject-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 PerspectiveHistorical Perspective

Each new Programming Paradigm has provided us with additional mechanisms for abstraction and composition.

9

Design and ImplementationDesign 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 ImplementationDesign 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 LanguagesGeneralized-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 LanguagesLimitation 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 StepAOP as a Next Step

14

Origin of AOPOrigin 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?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?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 ConcernsSeparation 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 CompositionConcept 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?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

Examples of Crosscutting ConcernsExamples 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

What is an Aspect?What is an Aspect?

An AOP Programming Construct

• Allows programmers to handle Crosscutting Concerns as Separate Single Entities

22

Properties of AspectsProperties 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 AspectsProperties 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 ExampleCrosscutting 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


26


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


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 SystemStructural 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 WorksHow 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


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


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 AOPSystem 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 AOPSystem Development With AOP

34


35


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


37


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 ExampleAOP Simple Logging Example

39

AOP Simple Logging ExampleAOP 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 ContractAOP 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 OOPAOP 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 OOPAOP 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 AOPBenefits of AOP

Modularization of Crosscutting ConcernsImplementation Looks More Like DesignEasier Development and MaintenanceSimplifies Code (Rmv Tangling Scattering)Greater Potential for Reuse of CodeSmaller SoftwareMore Evolvable Software

44

Quantifying the BenefitsQuantifying the Benefits

45

The Power of the AOP ApproachThe 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 AOPLong-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?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

IssuesIssues

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

IssuesIssues

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

IssuesIssues

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

IssuesIssues

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

ToolsTools

53

AspectJAspectJ

First Production Quality General Purpose AOP Language

Release 1.0 Made Available June 2001Seamless Extension to Java

• Compiler Produces Standard Java Byte Code

• Maintains Java’s AdvantagesCompiler Can Be Used to Easily Plug

Aspects Into or Out of Overall Application

54

AspectJAspectJ

Component Language is JavaAspect Language is AspectJAspect Weaver is AspectJ Compiler

• ajc

55

AspectJAspectJ

56

Other ToolsOther 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

Additional InformationAdditional Information

58

The People Behind AOPThe 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

60

The People Behind AOPThe 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/

62

ConferencesConferences

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

Topics Discussed at AOSD 2003Topics 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

M.I.T. Technology Review Top 10M.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

DiscussionDiscussion

aspect-oriented programming an introductory presentation mike landi mscs candidate union university

Documents