Chapter 21

Aspect-Oriented Software
Engineering (AOSE)

Chapter 21 Aspect-Oriented Software Engineering Slide 1

Topics covered
 Introduction and motivation
 The separation of concerns
 Core vs. cross-cutting concerns
 Aspects, join points, and pointcuts
 Information hiding vs. AOSE
 Problems with AOSE
(Note: we will NOT cover 21.3, “SE with aspects,”
except for 21.3.3, “Verification and Validation”)

Chapter 21 Aspect-Oriented Software Engineering Slide 2

Introduction and motivation
 In most systems, the mapping between require-
ments (“concerns”) and components is not 1:1.
 To illustrate, suppose we have “requirements” with
just two attributes: color and shape.
 Requirements are either red or green, and are
either square ( ) or circular ( ).
 How should we distribute the requirements among
two components if our goal is to minimize the cost
of change?

(cont’d)
Chapter 21 Aspect-Oriented Software Engineering Slide 3
Introduction and motivation (cont’d)

(cont’d)
Chapter 21 Aspect-Oriented Software Engineering Slide 4
Introduction and motivation (cont’d)
 Thus, implementing a requirements change
may involve understanding and changing
more than one component.
 Aspect-Oriented Software Engineering
(AOSE) is an approach to SE intended to
address this problem.
 It is based on a relatively new type of
abstraction - an aspect, and is normally used
together with OO software engineering.

(cont’d)
Chapter 21 Aspect-Oriented Software Engineering Slide 5
Introduction and motivation (cont’d)
 Aspects encapsulate functionality that cross-
cuts other functionality.
 R&D in this area has primarily focused on
aspect-oriented programming.
 Languages such as AspectJ have extended OO
languages to include aspects, and have been
used in major companies.
 AOSE’s focus on separating concerns is an
important way of thinking about and structuring
software systems, but it is not yet mainstream
SE. AspectJ was developed at Xerox PARC
and made available in 2001.

Chapter 21 Aspect-Oriented Software Engineering Slide 6

The separation of concerns
 The principle of separation of concerns states
that software should be organized so that each
program element does one thing and one thing
only.
 Each program element should therefore be
understandable without reference to other
elements.
 Program abstractions (subroutines, procedures,
objects, and aspects) support the separation of
concerns.

Chapter 21 Aspect-Oriented Software Engineering Slide 7

What are concerns?
 Concerns reflect system requirements and
the priorities of system stakeholders.
 Examples of concerns are performance,
security, specific functionality, etc.
 Programs that reflect the separation of
concerns in a program  clear traceability
from requirements.
 This facilitates program understanding and
the implementation of requirements change.

Chapter 21 Aspect-Oriented Software Engineering Slide 8

Types of concerns (programming
and otherwise)
 Functional: related to specific functionality to be
included in a system.
 Quality of service: related to the non-functional
behaviour of a system (e.g., performance,
reliability, availability).
 Policy concerns: related to the overall policies
that govern the use of the system.
 System: related to attributes of the system as a
whole (e.g., maintainability, configurability).
 Organizational: related to organizational goals
and priorities (e.g., staying within budget, using
existing software assets).
Chapter 21 Aspect-Oriented Software Engineering Slide 9
Core vs. cross-cutting concerns
 Core concerns relate to a system’s primary
purpose and are normally implemented
within separate procedures, objects, etc.
 Cross-cutting concerns are those whose
implementation cut across a number of
program components, resulting in problems
when changes are required due to:
• tangling (a component implements multiple
requirements), and
• scattering (a requirement’s implementation is
scattered across more than one component).

Chapter 21 Aspect-Oriented Software Engineering Slide 10

 Cross-cutting concerns
Core concerns

New customer Account Customer

reqmts reqmts. management reqmts
(tangling)

Security reqmts
Cross-cutting
concerns
Recovery reqmts

Internet Banking System

Chapter 21 Aspect-Oriented Software Engineering Slide 11

 Cross-cutting concerns
Core concerns

New customer Account Customer

reqmts reqmts. management reqmts

tangling
(tangling)

Security reqmts
Cross-cutting
concerns
Recovery reqmts

Internet Banking System

Chapter 21 Aspect-Oriented Software Engineering Slide 12

 Cross-cutting concerns
Core concerns

New customer Account Customer

reqmts reqmts. management reqmts

tangling
(tangling)

Security reqmts
Cross-cutting
concerns
Recovery reqmts

Internet Banking System

scattering
Chapter 21 Aspect-Oriented Software Engineering Slide 13
Tangling of buffer management
and synchronization code
synchronized void put (SensorRecord rec )
{
// Check that there is space in the buffer; wait if not

if ( numberOfEntries == bufsize)
wait () ;

// Add record at end of buffer

store [back] = new SensorRecord (rec.sensorId,
rec.sensorVal) ;
back = back + 1 ;
ensures mutual
// If at end of buffer, next entry is at the beginning
if (back == bufsize) exclusion
back = 0 ;
numberOfEntries = numberOfEntries + 1 ;
// indicate that buffer is available

notify () ;

} // put
Chapter 21 Aspect-Oriented Software Engineering Slide 14
Scattering of methods implementing
secondary concerns

code associated with secondary

statistics collection concern

Chapter 21 Aspect-Oriented Software Engineering Slide 15

Aspects, join points, and pointcuts
 An aspect is an abstraction which implements
a cross-cutting concern.
 It includes the code (advice) to be executed
and a statement (a pointcut) that defines the
events for which the advice is woven into the
program.
 The program events specified by the pointcut
are called join points.

Chapter 21 Aspect-Oriented Software Engineering Slide 16

Summary of terminology
Term Definition

advice The code implementing a concern.

aspect A program abstraction that defines a cross-cutting

concern. It includes the definition of a pointcut and the
advice associated with that concern.
join point An event in an executing program where the advice
associated with an aspect may be executed.
join point model The set of events that may be referenced in a pointcut.

pointcut A statement, included in an aspect, that defines the join

points where the associated aspect advice should be
executed.
weaving The incorporation of advice code at the specified join
points by an aspect weaver.

Chapter 21 Aspect-Oriented Software Engineering Slide 17

AspectJ join point model
 Call events: calls to a method or constructor
 Execution events: execution of a method or
constructor
 Initialization events: class or object initialization
 Data events: accessing or updating a field
 Exception events: the handling of an exception

Chapter 21 Aspect-Oriented Software Engineering Slide 18

An “authentication” aspect
aspect authentication
{
bef ore: call (public void update* (..)) // this is a pointcut
{
// this is the advic e that should be executed when woven into
// the exec uting sys tem
int tries = 0 ;
st ring us erPass word = Pass word.G et ( tries ) ;
while (tries < 3 && us erPassword ! = thisUs er.pass word ( ) )
{
// allow 3 tries to get the pass word right
tries = tries + 1 ;
userPassword = Pas sword.Get ( tries ) ;
}
if (us erPassword ! = thisUs er.pass word ( )) then
//if password wrong, assume us er has forgotten to logout
Sys te m.Logout (thisUser.uid) ;
}
} // authentic ation

Chapter 21 Aspect-Oriented Software Engineering Slide 19

An “authentication” aspect
Meaning: Before executing any method whose
aspect authentication name starts with “update,” execute the advice.
{
bef ore: call (public void update* (..)) // this is a pointcut
{
// this is the advic e that should be executed when woven into
// the exec uting sys tem
int tries = 0 ;
st ring us erPass word = Pass word.G et ( tries ) ;
while (tries < 3 && us erPassword ! = thisUs er.pass word ( ) )
{
// allow 3 tries to get the pass word right
tries = tries + 1 ;
userPassword = Pas sword.Get ( tries ) ;
}
if (us erPassword ! = thisUs er.pass word ( )) then
//if password wrong, assume us er has forgotten to logout
Sys te m.Logout (thisUser.uid) ;
}
} // authentic ation

Chapter 21 Aspect-Oriented Software Engineering Slide 20

Pointcuts versus join points
 Summarizing the info provided on slides 16-
18…
• A pointcut is a statement in an Aspect that
defines (identifies) one or more join points
(events in an executing program) where the
Aspect’s advice (code) should be executed.
• In AspectJ, the join points that may be
identified in a pointcut are: call events,
execution events, initialization events, data
events, and exception events.

Chapter 21 Aspect-Oriented Software Engineering Slide 21

Aspect weaving
 Aspect weavers process source code and
weave advice into a program at the join
points defined in pointcuts.
 Three approaches to aspect weaving
• Source code pre-processing
• Link-time weaving
• Dynamic, execution-time weaving

(cont’d)
Chapter 21 Aspect-Oriented Software Engineering Slide 22
Aspect weaving (cont’d)

Chapter 21 Aspect-Oriented Software Engineering Slide 23

Information hiding vs. AOSE
Information Hiding:
isolating potentially changeable design
decisions (core concerns) in separate
program components
AOSE:
isolating potentially changeable “cross-
cutting concerns” (design decisions that
cut across program components) in separate
program aspects.

Chapter 21 Aspect-Oriented Software Engineering Slide 24

Problems with AOSE
 AO programs can be “black-box tested”
using requirements to design the tests.
 But program inspections and “white-box
testing” can be problematic, since you can’t
always tell from the source code alone where
an aspect will be woven and executed.
 “Flattening” an aspect-oriented program (to
make it readable sequentially from top to
bottom) is problematic.

Chapter 21 Aspect-Oriented Software Engineering Slide 25

White-box testing
 White-box or structural testing uses control flow
knowledge to systematically design defect tests.
 The aim is to provide some level of code cover-
age (statement coverage, branch coverage, path
coverage, etc.)
 But deriving a control flow graph of a program
with aspects is problematic.
 And it may be difficult to design tests to cover all
combinations of program joint points and aspects.

Chapter 21 Aspect-Oriented Software Engineering Slide 26

AOSE white-box testing issues
 What does test coverage mean in AOSE?
 How should aspects be specified so that
tests may be designed?
 How can aspects be tested independently of
the base system?
 How can aspect interference (when two or
more aspects use the same pointcut speci-
fication) be tested?

Chapter 21 Aspect-Oriented Software Engineering Slide 27

Key points
 AOSE supports the separation of concerns…
 By representing cross-cutting concerns as
aspects, individual concerns can be
understood, reused and modified without
changing other parts of the program.
 Tangling occurs when a module in a system
includes code that implements different
system requirements.

(cont’d)
Chapter 21 Aspect-Oriented Software Engineering Slide 28
Key points (cont’d)
 Scattering occurs when the implementation
of a concern is scattered across several
components.
 Aspects include a pointcut statement that
defines where the aspect will be woven into
the program, and advice – the code to
implement the cross-cutting concern.
 Join points are the events specified in a
pointcut.
(cont’d)
Chapter 21 Aspect-Oriented Software Engineering Slide 29
Key points (cont’d)
 The problems of inspecting and designing
structural tests for aspect-oriented programs
are significant barriers to the adoption of
AOSE in large software projects.

Chapter 21 Aspect-Oriented Software Engineering Slide 30

 Chapter 21

Aspect-Oriented Software
Engineering (AOSE)

Chapter 21 Aspect-Oriented Software Engineering Slide 31