CSC/ECE 517 Fall 2009/wiki2 9 SN

Aspect-Oriented Programming

THIS WILL BE TAKEN OUT In writing a program, you must handle the many concerns of the system. A *concern* is a requirement of, or action that must be performed by, the system. For example, concerns for a banking system include making deposits, making withdrawals, handling account inquiries, transferring funds between accounts, authenticating and authorizing the user, and synchronizing and logging all transactions. The concerns at the end of the list are secondary, and are required across many of the core modules. For this reason they are referred to in AOP as cross-cutting concerns. Discuss AOP in general, and touch briefly on AspectJ and AspectR, which facilitate it in Java and Ruby, respectively

Aspect Oriented Programming

Traditional software development has focused on developing systems into units of primary functionality, while recognizing that there are other issues of concern that do not fit well into the primary decomposition. This process leaves it to the programmers to code modules corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keep in mind all the things that need to be done, how to deal with each issue, the problems associated with the possible interactions, and the execution of the right behavior at the right time. When all these things are taken into account, this often results in serious issues being raised during the development and maintenance of a large software system.

Aspect-Oriented programming focuses on the identification, specification and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system.

What is AOP?

Introduction

Software design processes and programming languages exist in a mutually supporting relationship. Design processes break a system down into smaller and smaller units. Programming languages provide mechanisms that allow the programmer to define abstractions of system sub-units, and then compose those abstractions in different ways to produce the overall system. A design process and a programming language 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. From this perspective, many existing programming languages, including object-oriented languages, procedural languages and functional languages, can be seen as having a common root in that their key abstraction and composition mechanisms are all rooted in some form of generalized procedure.

Terminology

Cross-cutting concerns

Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

Advice

This is the additional code that you want to apply to your existing model.

Point-cut

This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied.

Aspect

The combination of the point-cut and the advice is termed an aspect.

Overview

AOP encapsulates crosscutting concerns into a single program module called an aspect, which can add behavior to a program and verify or change its static structure. The aspect specifies join points in the running program using point-cuts, and permits advice code to run around the join point, to join the advice behavior to the program semantics. The aspect can also declare members and supertypes of other classes if the declarations are type-safe, binary-compatible and respect access rules. The combination of advice and inter-type declarations enables one to implement the correct associations and behaviors for many objects in one aspect.

Mechanisms for defining and composing abstractions are essential elements of programming languages. The design style supported by the abstraction mechanisms of most current languages is one of breaking a system down into parameterized components that can be called upon to perform a function. But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components.

While they can be thought about and analyzed relatively separately from the basic functionality, programming them using current component-oriented languages tends to result in these aspects being spread throughout the code. The source code becomes a tangled mess of instructions for different purposes.

This phenomenon is at the heart of much needless complexity in existing software systems. A number of researchers have begun working on approaches to this problem that allow programmers to express each of a system's aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form. These approaches have been called aspect-oriented programming.

Example of Aspect

HERE IS WHERE AN EXAMPLE IS GOING (Not Done Yet)

AspectJ

AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these 'crosscutting concerns'. Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems.

AspectJ is a simple, practical, and compatible aspect-oriented extension to Java.

• Upward compatibility — all legal Java programs must be legal AspectJ programs.

• Platform compatibility — all legal AspectJ programs must run on standard Java virtual machines.

• Tool compatibility — it must be possible to extend existing tools to support AspectJ in a natural way; this includes IDEs, documentation tools, and design tools.

• Programmer compatibility — Programming with AspectJ must feel like a natural extension of programming with Java.

AspectR

AspectR is the AOP Language for Ruby. It was modeled after and resembles a lot like AspectJ.

There are some differences which AspectR does not have that AspectJ does:

• Join points: method/constructor called, method/constructor executes (?), exception handler executes

• Most of the point-cut designator primitives

• Composition of point-cut designators

• 'around' advices

• precedence/specificity among advices/aspects

• reflection by sending join-point object to advices with context of join point etc

• control-flow based crosscutting