Aspect-oriented programming

Download Report

Transcript Aspect-oriented programming

Aspect-oriented programming
Laura Ricci
A.A. 2001-2002
Index
 Introduction to AOP
 What are aspects?
 The role of aspects in software design
 AOP issues
 AspectJ
 What next?
Introduction

Currently, the dominant programming paradigm is
object-oriented programming that:
 has been presented as a technology that can
fundamentally aid software engineering
 is reflected in the entire spectrum of current
software development methodologies and tools

Object orientation is a clever idea, but has certain
limitations
Introduction

A new programming technique called aspect-oriented
programming (AOP):
 makes it possible to clearly express those programs
that OOP fail to support
 enables the modularization of crosscutting concerns
by supporting a new unit of sw modularity – aspects
– that provide encapsulation for crosscutting concerns
What are aspects?

The current working definition is (May 99, Gregor
Kiczales):
 modular units that cross-cut the structure of
other modular units
 units that is defined in terms of partial
information from other units
 exist in both design and implementation
Concerns



AOP is based on the idea that computer systems are
better programmed by separately specifying the
various concerns of a system
Separation of concerns is an important software
engineering principle guiding all stage of a sw
development methodology
Concerns:
 are properties or areas of interest
 can range from high-level notion ot low levelnotion
 can be functional or nonfunctional (systemic)
back
Example of crosscutting concerns
It is taken from C. of the ACM

Consider:
 the UML for a simple figure editor in which there
are two concrete classes of figure element, points
and lines
 the concern that the screen manager should be
notified whenever a figure element moves

This requires every method that moves a figure
element to do the notification
Example of crosscutting concerns
The red box is drawn
aroundinside
everyof nor
DisplayUpdating
fits neither
DisplayUpdating
cuts across
the other
boxes
method
that
must
implement
this
around the other boxes in the figure
concern
Display
*
Figure
Point
getX()
FigureElement
Line
2
getP1
getY()
setP1
setX(int)
setP1(Point)
setY(int)
setP2(Point)
DisplayUpdating
What are aspects?

Aspects are similar to classes because:
 have type
 can extend classes and other aspects
 can be abstract or concrete
 can have fields, methods, and types as
members
What are aspects?

Aspect are different than classes because:
 can additionally include as members pointcuts
(picks out join points), advice (code that executes
at each join point )
 do not have constructor or finalizer and they
cannot be created with the new operator
 priviliged aspects can access private members of
other types
What are aspect?


Aspects may arise at any stage of the software
lifecycle
Common example of crosscutting aspects are design
or architectural constraints, systemic properties or
behaviours and features
Examples of how aspects crosscut components
It is taken from AOP document
We wanted to implement a distributed digital library
that stores documents in many forms and provides a
wide range of operations on those documents
application
components
aspects
digital
database,
minimizing network
Library
printers,
traffic,
services
synchronization
constraints,
failure handling
Examples of how aspects crosscut components

There are several aspects of concerns, including:
 communication, by which we mean controlling the
amount of network bandwidth the application uses by
being careful about which objects get copied in remote
method calls
 coordination constraints, by which we mean the
synchronization rules require to ensure that the
component program behaves correctly
 failure handling, by which we mean handling the many
different forms of failure that can arise in a distributed
system
The role of aspects
in software design


AOP aims at providing better means of addressing
the well-known problem of separation of concerns
Three basic approaches to addressing the process of
separation of concerns:
 language-based
 framework-based
 architecture-oriented
Language-based approach



It is based on the definition of a set of language
constructs
Relevant concerns are identified at the problem
domain and translated to aspectual construct
The final application is obtained by weaving the
primary structure with the crosscutting aspects
Framework-based approach




Provides more flexible constructs
Concerns are materialized as aspectual classes at the
framework level
Developers can customize these aspects using the
mechanism supported by the framework
These types of framework are known as AO
frameworks (explicitly engineers concerns)
Architecture-oriented
approach



Early identification of concerns using architectural
organizational models
Architectural view-point involves a higher level of
abstraction than the previous approaches
It tipically comprises two stages
Architecture-oriented
approach

First, developers should determine the problem
architecture
Concerns are initially mapped to
architectural construct

Then, the approach enables several kinds of aspect
materialization through different frameworks
AOP technologies example
It is taken from C. of the ACM



Empirical analysis based on a simulation case study
of the temperature control system (TCS) of a
building ()
This comprises a building with rooms requiring
specific temperatures and a network consisting of
radiators, pipes and a boiler
To simulate TCS, a simple mathematical model of
temporal differential equations specifies the heat flow
among the different components
AOP technologies example
Relevant aspects in TCS
Aspect
Description
Relationships
Scheduling
It refers to how the simulated
entities should run
It works together with
synchronization
Synchronization
It basically involves access to
shared variables and race
condition
It works together
with scheduling
AOP technologies example

Four different groups of programmers implementing:
 typical OO view
 aspect language (AL)
 reflective AO framework (R-AO)
 event-based architectural framework (EBA)
AOP technologies example
 TCS evaluation according to the different implementation
 Analyzed features: scheduling and synchronization
 OO modeling: SS are scattered across the components
requiring these facilities (inheritance anomalies)
 EBA: SS are provided as built-in features in the
framework. It may be difficult to customize some of these
policies
 R-AO – AL: There are specific aspects dealing with SS.
They are kept separated, but some problems about the way
they interact (aspect composition) may arise
AOP technologies example


Several execution of the simulation programs are
maded
TCS performance with the different implementation:
 results were very similar except in the case of R-AO
 similarities found in the study seem to indicate that
both EBA and AL run almost like standard code
AOP technologies example
 To obtain a measure of the complexity of the
implementations, it is gathered code statistics (NCSS)
about:
 number of methods per class
 the NCSS per methods
 cyclomatic complexity (CNN per methods)
In particular, the best results were obtained with EBA (this
payoff comes mainly from the autonomy of component
and decoupling prescribed by framework).
The role of aspects
in software design
The central problem of aspect technologies,
whatever the approach we consider, is not just
about crosscutting or separation of concerns, but
it involves deeper research about how to
understand a number of software parts as
separated artifacts and then integrate some of
then into a coherent system
AOP issues


AOP must address both what the programmer can
say and how the computer system will realize the
program in a program system
AOP system:
 provides a way of expressing crosscutting concerns
 also ensures these mechanisms are conceptually
straighforward and have efficient implementations
AOP issues

How an AOP system specifies aspects:
 join points
 aspect parameterization

What composition mechanisms the system provides:
 dominant decomposition
 visibility
 mechanism provided
AOP issues

Implementation mechanisms:
 static/dinamic distinction
 modular compilation
 target representation

Software process:
 methodology or framework (the system provides for
organizing the system-building activity)
 reusability
 domain-specificity
AspectJ

Aspectj is:
 a general-purpose Ao extension to Java
 Java platform compatible
 easy to learn and use
 freely available under an Open Source license

Aspectj enables the modular implementation of a
wide range of crosscutting concerns
AspectJ



When written as an aspect the structure of a
crosscutting concern is explicit and easy to reason
about
Aspects are modular
AspectJ enables:
 name-based crosscutting (tend to affect a small
number of other classes)
 property-based crosscutting (range from small to
large scale)
AspectJ

Adoption of it into an existing project can be a
straightforward and incremental task:
 to begin with development aspects
 other paths are possible,depending on the needs
of the projects

The goals of the AspectJ project are to make AOP
technology available to a wide range of
programmers, to build and support an AspectJ user
community
Example
What next?



Software engineering researchers provide some help
to determine if it is beneficial for sw development
organization to adopt AOP for building their sw
products
A number of study have been conducted to asses the
usefulness of AOP
Two basic techniques for assessing a programming
technology:
 experiments
 case study
What next?

Three areas emerge as important in supporting the
use of AOP:
 exposing join points
 managing aspect interface
 structuring aspects
References
Communications of the ACM (October 2001-Volume 44,
Number 10)
AOP official web site:
 http://aosd.net/
AspectJ official web site:
 http://aspectj.org/
Sites from which you can find documents about conferences
and several informations:
 http://www.ccs.neu.edu/home/lieber/connection-to-aop.html
 http://www.cs.man.ac.uk/cnc/mscprojects/aspect/node1.htm
l
 http://www.cs.ubc.ca/labs/se/papers/1999/icse99-aop.html
 http://www.eclipse.net/~tomo/pisa/oopsla2000/p_netinant.h
tml

Crosscutting


Crosscutting is how to characterize a concern than
spans multiple units of OO modularity
Crosscutting concerns resist modularization using
normal OO construct
back
Pointcut


Picks out join points
Can be defined in classes or in aspects and can be
named or be anonymous
back
Advice


It is code that executes at each join point picked out
by pointcut
His power comes from the advice being able to
access value in the execution context of a pointcut
back
Join points


Are well-defined points in the execution of a program
Only those points that can be used in a disciplined
and principled manner
back
Framework


It is based on decomposition of aspects in system
design that consists of components, aspects, and
layers.
By separating the different aspects of each
component, we can separate components, aspects,
and layers from each other
back
AspectJ example
It is taken from C. of the ACM



An aspect is defined very much like a class and can
have methods, fielsd, constructors, initializers, named
pointcuts and advice
An example is tracing aspect that prints messages
before certain display operation
The overall effect of this aspect is to print a
descriptive message whenever the traced methods
are called
AspectJ example
Aspect SimpleTracing {
pointcut traced() :
Traced identifies calls to several
key methods on Display
call (void Display.update () ) ||
call (void Display.repaint (..) );
Before advice on this
pointcut uses a helper
method of the aspect
to print a message
before() : traced () {
Advice uses the
println(“Entering:” + thisJoinPoint); thisJoinPoint
special variable to
}
an object that
describes the
void println (String str) {
current join point
<write to appropriate stream> } }
back