Aspect-oriented programming Laura Ricci A.A. 2001-2002.
-
date post
21-Dec-2015 -
Category
Documents
-
view
217 -
download
3
Transcript of Aspect-oriented programming Laura Ricci A.A. 2001-2002.
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:
Object orientation is a clever idea, but has
certain limitations
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
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 level-notion
can be functional or nonfunctional (systemic) back
Example of crosscutting concerns
Consider:
This requires every method that moves a figure element to do the notification
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
It is taken from C. of the ACM
Example of crosscutting concerns
Display
Figure FigureElement*
Point LinegetX()
getY()
getP1
setP1
DisplayUpdating
setX(int)
setY(int)
setP1(Point)
setP2(Point)
2
The red box is drawn around every method that must implement this concern
DisplayUpdating fits neither inside of nor around the other boxes in the figure
DisplayUpdating cuts across the other boxes
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 cross-cut components
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
It is taken from AOP document
Examples of how aspects cross-cut 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
Then, the approach enables several kinds of aspect materialization through different frameworks
Concerns are initially mapped to architectural construct
AOP technologies example
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
It is taken from C. of the ACM
AOP technologies exampleRelevant aspects in TCS
Aspect
It refers to how the simulated entities should run
Relationships
Synchronization
Scheduling
It basically involves access to shared variables and race condition
Description
It works together with scheduling
It works together with synchronization
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:
What composition mechanisms the system provides:
join points
aspect parameterization
dominant decomposition
visibility
mechanism provided
AOP issues Implementation mechanisms:
Software process:
static/dinamic distinction
modular compilation
target representation
methodology or framework (the system provides for organizing the system-building activity)
reusability
domain-specificity
AspectJ Aspectj is:
Aspectj enables the modular implementation of a wide range of crosscutting concerns
a general-purpose Ao extension to Java
Java platform compatible
easy to learn and use
freely available under an Open Source license
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:
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
to begin with development aspects
other paths are possible,depending on the needs of the projects
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.html http://www.cs.ubc.ca/labs/se/papers/1999/icse99-aop.html http://www.eclipse.net/~tomo/pisa/oopsla2000/
p_netinant.html
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
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
It is taken from C. of the ACM
AspectJ exampleAspect SimpleTracing {
pointcut traced() :
call (void Display.update () ) ||
call (void Display.repaint (..) );
before() : traced () {
println(“Entering:” + thisJoinPoint);
}
void println (String str) {
<write to appropriate stream> } }
Traced identifies calls to several key methods on Display
Before advice on this pointcut uses a helper method of the aspect to print a message
Advice uses the thisJoinPoint special variable to an object that describes the current join point
back