Chapter 8: Aspect Oriented Programming

Omar Meqdadi

SE 3860 Lecture 8

Department of Computer Science and Software Engineering University of Wisconsin-Platteville

2

Topic Covered

Introduction Aspect Oriented Programming

Goals Terms

Examples Code Example Real-World Example

3

Introduction

OO mechanisms collect related data and operations and encapsulate them into objects.

Ideally, objects have high cohesion and low coupling. There are times when objects with their low coupling just

don’t work or can lead to problems.

4

Introduction

Possible Problems with OO can occur when: Implementing High level, system wide requirements Implementation of Enterprise wide Security

Role based authentication to multiple application within a company

Access login Application (system level) logging or journaling System security requirements Other policy level requirements

Handling messages among multiple applications and domains

5

Solution1

The problem with supporting these application or enterprise wide requirements is We want to support them with objects, but cannot

encapsulate them in a single object The functionality must be many objects.

6

Solution2

An alternative might be multiple inheritance – but this solution Increases object complexity Increases maintenance Possibly not be allowed in the current source level

programming language.

We have an employee record system implemented as a large collection of objects 401K accounts: Home address, family members, accounts (bills), payroll

data, stock options, vacation time, medical records, drug testing, awards, etc.

For security purposes We want to add the capability of logging any transaction that modifies

data in this database. We don’t want someone changing pay rates or adding vacation days or

modifying other financial records! We would need to add this code to all classes/objects that contain

writes/updates.

Requirements Example

It would be major work adding update journaling for each of the data fields in each of these objects. We would need to crawl though each of the objects looking

for specific transactions that relate to this data and then insert the code as needed.

If we needed to enhance this logging functionality we would need to crawl through all of the code to update each of these objects – major pain! High Coupling! And hopefully we wouldn’t miss any places!

Also we a lowering the Cohesion of each object that we are adding this security code

Requirements Example: Problems

Goals: Want to add all of the new journaling functionality in a

single location. This simplifies implementation and maintenance.

Want to specify what functionality is invoked based on event conditions and/or rules

Don’t want to crawl though all the existing code to find extension points (locations where this functionality would need to be inserted).

Don’t want to miss finding a place that needs to be covered. Don’t want to duplicate functionality in multiple objects

Aspect Oriented Programming

Aspect Oriented Programming will allow us to: Create a central collection of operations responsible for

logging Specify that when an employee database modification

happens the object data will be journalized

Aspect Oriented Programming

Terms: Cross-Cutting Concern – Some aspects of

implementation, like logging, error handling, standards enforcement, tracing are difficult to implement in a modular way. This results in code tangled and scattered across the entire system. This is called Cross-Cutting!

Advice – this is the code that we need to add to implement the features like those that we have discussed above, like logging.

Aspect Oriented Programming

Aspect Oriented Programming

Terms: Point Cut – is the place in the existing code that we want

to insert the new functionality. We may want a point cut in at the beginning of the code that modifies a student record and another point to cut out when it finishes the modification.

Aspect – it the combination of the point-cut and the advice. We want to add logging to our student record system when any transaction attempts to modify data

Code Example

Code Example: Analysis

Point-cut named “LogEmployeeChange: Specifies specific points where employee object is

changed. Line 13 indicates that we will refer to this point cut as

LogEmployeeChange, and that it takes an object ‘e’ of type Employee

Point-cut named “LogEmployeeChange: In line 14, 15, 16, and 17 it specifies that the point cuts

occur in methods: setName( ), setAddress( ), setSalary( ), …

Line 14 explicitly says, “for any ‘public’ method of class ‘Employee’ with any type of return parameter (‘*’), a name of ‘setName’, and a parameter set of anything (‘..’), execute the corresponding Advice. Lines 15 through 17 can be interpreted in a similar manner and are additional point-cuts

Code Example: Analysis

Point-cut named “LogEmployeeChange: The wildcards ‘*’ and “(..)” allow coverage of overloaded

functions. We could have other Point-Cuts for any of the other objects

in the system that modify data

Code Example: Analysis

Advice – what we want to perform at a Point-cut Before Advice

Line 19 says, “Since the LogEmployeeChange point-cut has been triggered, execute the code in its “before” advice block before executing the method which triggered the point-cut.”

The actual instance of the Employee class, before it is written will be passed into the before Advice as “Employee e” for logging

Code Example: Analysis

Advice – what we want to perform at a Point-cut After Advice

After executing before Advice, the method, which triggered the point-cut is executed; this method could be “setName”, “setAddress”, . . .

Once execution returns from this method, the after Advice for LogEmployeeChange is executed, which logs the new Employee object’s data

Code Example: Analysis

Open-source implementation of Java Servlet and JavaServer Pages developed at the Apache Software Foundation

Real-World Example

The bars represent system objects Red Shows encapsulated XML Parser in Tomcat

Nicely contained in one object

Real-World Example

Red Shows encapsulated URL Pattern Matching in Tomcat Not too bad, functionality contained in two system objects

Real-World Example

Consider the following figure

Real-World Example

From previous figure Red Shows Tomcat Logging

The logging functionality is scattered across almost every object in the system.

This is NOT good! What happens if we wanted to reengineering this logging?

This would be an excellent opportunity for Aspect Oriented Programming

Increase Cohesion Greatly decrease Coupling Increase Maintainability Remove duplicate logging code that is scattered across the whole system

Real-World Example