Transcript Aspect-Oriented Software Development

Shanghai Jiao Tong University
Object Oriented Analysis and Design
Aspect-Oriented Software
Development (AOSD)
上海交通大学软件工程中心
Introduction
 Evolution of Programming Languages
 Assembly/Machine Languages
 Formula Translation
 Procedural Programming
 Structured Programming
 Functional Programming
 Logic Programming
 Programming with abstract data types
 Evolution of Software Design
 Monolithic ---> Modular
Object Oriented Analysis and Design
2
Design Principles  Modularity
 Abstraction
 Focus only on relevant properties
 Decomposition
 Divide software into separately named and addressable modules
 Encapsulation
 Group related things together.
 Information Hiding
 Hide implementation details from the outside
 Separation of Concerns
 Ensure that each module only deals with one concern
 Low Coupling
• aim for low coupling among the modules
 High Cohesion
• aim for high cohesion within one module
Object Oriented Analysis and Design
3
What is a Concern?
 Are properties or areas of interest
 Can be functional or nonfunctional
(quality, systemic)
 At different abstraction levels:
 Problem domain concerns vs. solution
domain concerns
 Requirements vs. design
 Design vs. implementation
Object Oriented Analysis and Design
4
Separation of Concerns
 The ability to identify, encapsulate and
manipulate concerns
 A key principle of SW engineering
 Concerns are primary criteria for
decomposing SW
Object Oriented Analysis and Design
5
Separation of Concerns (Cont.)
“clean” separation can help:
 Reduce complexity, improve comprehensibility
 Simplify evolution of SW
 Local, easy changes
 Smaller impact of change
 Facilitate reuse
 developers aren’t burdened by extraneous
parts
 Simplify component integration
Object Oriented Analysis and Design
6
Dijkstra: Separate Program in Layers...
 E. W. Dijkstra (1968-2002):
 ‘’...Correct arrangement of the
structure of software systems
before simple programming...‘’
 Layered Structure
 Programs are grouped into layers
 Programs in one layer can only
communicate with programs in
adjoining layers
 Conceptual integrity
 Each layer has its own goal
 With easier development and
maintenance
Object Oriented Analysis and Design
7
Parnas - Design Principles for Decomposition
 Information hiding modules (1972)
 Identify design decisions that are likely to
change
 Isolate these in separate modules (separation
of concerns)
 Different design decisions might require
different decompositions.
 D. Parnas, "On the Criteria to Be Used in
Decomposing Systems into Modules.“, Comm.
ACM 15, 12 (December 1972), 1053-1058.
1972.
Object Oriented Analysis and Design
8
Separation of Concerns applied
 Separate software development into phases
each dealing with specific activities (e.g.
requirements, analysis, design,
implementation)
 Separation of different artifacts: class,
subsystems, attributes.
 Separation of different design views (static,
dynamic, implementation, ...)
 Separation of different roles
 ...
Object Oriented Analysis and Design
9
Benefits of Separation of Concerns
 Supports high cohesion among
components
 Supports low coupling among
components
 Increases modularity
Object Oriented Analysis and Design
10
Advantages of Separation of Concerns
 Understandability
 Maintainability
 Extensibility
 Reusability
 Adaptability
 Separation of Concerns directly supports
quality factors.
 Lack of separation of concerns directly
negatively impact quality factors.
Object Oriented Analysis and Design
11
Example - Figure Editor
 A figure consists of several figure elements.
A figure element is either a point or a line.
Figures are drawn on Display. A point
includes X and Y coordinates. A line is
defined as two points.
Object Oriented Analysis and Design
12
Example - Figure Editor - Design
Display
* FigureElement
Figure
Point
getX()
2
Line
getP1
getY()
setX(int)
setP1
setP1(Point)
setY(int)
setP2(Point)
Object Oriented Analysis and Design
Components are
- Cohesive
- Loosely Coupled
- Have well-defined interfaces
(abstraction, encapsulation)
13
Nice Modular
Design!
Crosscutting Concern - Example
Notify ScreenManager if a figure element moves
Display
*
Figure
FigureElement
Point
getX()
Line
2
getP1
getY()
setP1
setX(int)
setP1(Point)
setY(int)
setP2(Point)
Object Oriented Analysis and Design
14
DisplayTracking
Example: Display Tracking
DisplayTracker
class DisplayTracker {
static void updatePoint(Point p)
{
this.display(p);
....
}
static void updateLine(Line l)
{
this.display(l);
....
}
Display
*
Figure
Point
getX()
FigureElement
Line
2
getP1
getY()
setP1
setX(int)
setP1(Point)
setY(int)
setP2(Point)
Crosscutting
Concern
class Point {
void setX(int x) {
DisplayTracker.updatePoint(this);
this.x = x;
class Line {
void setP1(Point p1 {
DisplayTracker.updateLine(this);
this.p1 = p1;
}
}
}
Object Oriented Analysis and Design
}
15
Example - Tracing - Design
Trace the execution of all operations...
Tracer
Display
traceEntry
traceExit
*
Figure
FigureElement
Point
getX()
Line
2
getP1
getY()
setP1
setX(int)
setP1(Point)
setY(int)
setP2(Point)
Object Oriented Analysis and Design
16
Tracing
Example - Tracing
Scattered
Concern
Tracer
Tangling Code
class Tracer {
static void traceEntry(String str)
{
System.out.println(str);
}
static void traceExit(String str)
{
System.out.println(str);
}
Display
*
Figure
Point
getX()
FigureElement
Line
2
getP1
getY()
setP1
setX(int)
setP1(Point)
setY(int)
setP2(Point)
}
class Point {
void setX(int x) {
Tracer.traceEntry(“Entry Point.set”);
_x = x;
Tracer.traceExit(“Exit Point.set”);
}
}
Object Oriented Analysis and Design
class Line {
void setP1(Point p1 {
Tracer.traceEntry(“Entry Line.set”);
_p1 = p1;
Tracer.traceExit(“Exit Line.set”);
}
}
17
Crosscutting Concerns
 Concerns that naturally tend to be scattered
over multiple components
 Which connot be localized into single units
(components, objects, procedures,
functions)...
 If not appropriately coped with:
 Scattered over multiple components
 Tangled code per component
Object Oriented Analysis and Design
18
Crosscutting, Scattering and Tangling
 Crosscutting
 Concern that inherently relates to multiple
components
 Results in scattered concern and tangled code
 Scattering
 Single concern affects multiple modules
 Tangling
 Multiple concerns are interleaved in a single
module
Object Oriented Analysis and Design
19
The Cost of Crosscutting Concerns
 Reduced understandability
 Redundant code in many places
 Non-explicit structure
 Decreased adaptability
 Have to find all the code involved
 Have to be sure to change it consistently
 Have to be sure not to break it by accident
 New concerns cannot be easily added
 Decreased reusability
 Component code is tangled with specific tangling code
 Decreased maintainability
 ‘Ripple effect’
Object Oriented Analysis and Design
20
Example of Crosscutting Concerns













Synchronization
Real-time constraints
Error-checking
Object interaction constraints
Memory management
Persistency
Security
Caching
Logging
Monitoring
Testing
Domain specific optimization
...
Object Oriented Analysis and Design
21
Many crosscutting concerns may appear in one system
 Example: Distributed System Design
 Component interaction
 Synchronization
 Remote invocation
 Load balancing
 Replication
 Failure handling
 Quality of service
 Distributed transactions
Object Oriented Analysis and Design
22
What to Do...?
Object Oriented Analysis and Design
23
Historical Context
 Crosscutting concerns are new type of
concerns that have not been (appropriately)
detected/handled before.
 No explicit management until recently at
programming level
 No explicit consideration in design methods
 No explicit consideration in process
 No explicit consideration in case tools
Object Oriented Analysis and Design
24
Aspect-Oriented Software Development
 Provides better separation of concerns by explicitly
considering crosscutting concerns (as well)
 Does this by providing explicit abstractions for
representing crosscutting concerns, i.e. aspects
 And composing these into programs, i.e. aspect weaving
or aspect composing.
 As such AOSD improves modularity
 And supports quality factors such as
 Maintainability
 Adaptability
 Reusability
 Understandability
 ...
Object Oriented Analysis and Design
25
Impact of AOSD on Society...
 MIT Technology Review lists AOP as one of
the top 10 emerging technologies that will
change the world
 –(MIT Technology Review, January 2001)
Object Oriented Analysis and Design
26
Basic AOSD Technologies
 Composition Filters (since 1991)
 University of Twente, The
Netherlands
 AspectJ (since 1997)
 XEROX PARC, US
 DemeterJ/DJ (1993)
 Northeastern University, US
 Multi-dimensional separation of
Concerns/HyperJ (1999)
Object Oriented Analysis and Design
27
History of AOP languages
Scripts (Francez 81)
OO languages
MOP
(1985)
Reflection
(Smith 81)
AI
(semantic
networks 79)
Sina
interface predicates
(1988)
Law of Demeter
(1988)
CLOS-MOP
Composition Filters
(1992)
Adaptive
programming
(1992)
Crosscutting
aspects (1996)
AspectJ
(1997)
Composition Filters
with superimposition
(2001)
http://trese.cs.utwente.nl
Object Oriented Analysis and Design
AspectJ
(2000)
28
AspectJ
 A general purpose AO programming
language
 just as Java is a general-purpose OO
language
 unlike examples in ECOOP’97 paper
• domain specific languages for each aspect
 an integrated extension to Java
 accepts all java programs as input
 outputs .class files compatible with any JVM
 integrated with tools
Object Oriented Analysis and Design
29
Example – Without AOP
class Line {
private Point _p1, _p2;
class Tracer {
Point getP1() { return _p1; }
Point getP2() { return _p2; }
static void traceEntry(String str)
{
System.out.println(str);
}
static void traceExit(String str)
{
System.out.println(str);
}
void setP1(Point p1) {
Tracer.traceEntry(“entry setP1”);
_p1 = p1;
Tracer.traceExit(“exit setP1”);
}
void setP2(Point p2) {
Tracer.traceEntry(“entry setP2”);
_p2 = p2;
Tracer.traceExit(“exit setP2”);
}
class Point
{
}
private int _x = 0, _y = 0;
int getX() { return _x; }
int getY() { return _y; }
void setX(int x) {
Tracer.traceEntry(“entry setX”);
Tangling Code
_x = x;
Tracer.traceExit(“exit setX”)
}
void setY(int y) {
Tracer.traceEntry(“exit setY”);
Scattered
Concern
_y = y;
Tracer.traceExit(“exit setY”);
}
}
Object Oriented Analysis and Design
30
Example – With AOP
class Line {
private Point _p1, _p2;
Point getP1() { return _p1; }
Point getP2() { return _p2; }
aspect Tracing {
pointcut traced():
call(* Line.* ||
call(* Point.*);
void setP1(Point p1) {
_p1 = p1;
}
void setP2(Point p2) {
_p2 = p2;
}
before(): traced() {
println(“Entering:” +
thisjopinpoint);
}
class Point
void println(String str)
{<write to appropriate stream>}
{
private int _x = 0, _y = 0;
int getX() { return _x; }
int getY() { return _y; }
void
_x
}
void
_y
}
}
}
setX(int x) {
= x;
setY(int y) {
= y;
}
Object Oriented Analysis and Design
Aspect is defined in a separate module
Crosscutting is localized
No scattering; No tangling
Improved modularity
31
Aspect Language Elements
 join point (JP) model
 certain principled points in program execution
such as method calls, field accesses, and object
construction
 means of identifying JPs
 picking out join points of interest (predicate)
 pointcuts: set of join points
 means of specifying behavior at JPs
 what happens
 advice declarations
Object Oriented Analysis and Design
32
Modularizing Crosscutting
 Joinpoints: any well-defined point of execution in
a program such as method calls, field accesses,
and object construction
 Pointcut: predicate on joinpoints selecting a
collection of joinpoints.
Tracer
pointcut traced():
call(* Line.*) ||
call(* Point.*);
Display
*
Figure
Point
getX()
FigureElement
Line
2
getP1
getY()
setP1
setX(int)
setP1(Point)
setY(int)
setP2(Point)
Object Oriented Analysis and Design
33
Joinpoints
 method call join points
 when a method is called
 method reception join points
 when an object receives a message
 method execution join points
 when the body of code for an actual method executes
 field get joint point
 when a field is accessed
 field set joint point
 when a field is set
 exception handler execution join point
 when an exception handler executes
 object creation join point
 when an instance of a class is created
Object Oriented Analysis and Design
34
Some primitive pointcuts
 call(Signature)
 picks out method or constructor call based on Signature
 execution(Signature)
 picks out a method or constructor execution join point based on Signature
 get(Signature)
 picks out a field get join point based on Signature
 set(Signature)
 picks out a field set join point based on Signature
 handles(TypePattern)
 picks out an exception handler of any of the Throwable types of TypePattern
 instanceOf(ClassName)
 picks out join points of currently executing objects of class ClassName
 within(ClassName)
 picks out join points that are in code contained in ClassName
 withinCode(Signature)
 picks out join points within the member defined by methor or constructor
(Signature)
 cflow(pointcut)
 picks out all the join points in the control flow of the join points picked out by
the pointcut
Object Oriented Analysis and Design
35
Advice
 Piece of code that attaches to a pointcut
and thus injects behavior at all joinpoints
selected by that pointcut.
 example:
before (args): pointcut
{ Body }
where before represents a before advice type
(see next slide).
 Can take parameters with pointcuts
Object Oriented Analysis and Design
36
Advice Types
Advice code executes
 before, code is injected before the joinpoint
before (args): pointcut
{ Body }
 after, code is injected after the joinpoint
after (args): pointcut
{ Body }
Advice
JP
JP
Advice
 around, code is injected around (in place of) code from
joinpoint
ReturnType around (args): pointcut
{ Body }
Advice
JP
Object Oriented Analysis and Design
37
Aspect
 A modular unit of cross-cutting behavior.
 Like a class, can have methods, fields,
initializers.
 can be abstract, inherit from classes and
abstract aspects and implement
interfaces.
 encapsulates pointcuts and advices
 can introduce new methods / fields to a
class
Object Oriented Analysis and Design
AspectX
classX
AspectX
AspectY
AspectY
classY
38
x
Example - AspectJ
class Line {
private Point _p1, _p2;
Point getP1() { return _p1; }
Point getP2() { return _p2; }
aspect Tracing {
void setP1(Point p1) {
_p1 = p1;
}
void setP2(Point p2) {
_p2 = p2;
}
pointcut traced():
call(* Line.* ||
call(* Point.*);
before(): traced() {
println(“Entering:” +
thisjopinpoint);
}
class Point
{
after(): traced() {
println(“Exit:” +
thisjopinpoint);
private int _x = 0, _y = 0;
int getX() { return _x; }
int getY() { return _y; }
void
_x
}
void
_y
}
setX(int x) {
= x;
setY(int y) {
= y;
void println(String str)
{<write to appropriate stream>}
}
}
}
Object Oriented Analysis and Design
39
aspect
pointcut
advice
Code Weaving
 Before compile-time (pre-processor)
 During compile-time
 After compile-time
 At load time
 At run-time
Object Oriented Analysis and Design
40
Example - AspectJ
aspect MoveTracking {
private static boolean _flag = false;
public static boolean testAndClear() {
boolean result = _flag;
_flag = false;
return result;
}
pointcut moves():
receptions(void Line.setP1(Point)) ||
receptions(void Line.setP2(Point));
static after(): moves() {
_flag = true;
}
}
Object Oriented Analysis and Design
41
DemeterJ / DJ
 Law Of Demeter
 Each unit should only have limited
knowledge about other units: only about
units “closely” related to the current unit.
 “Each unit should only talk to its friends.”
 “Don’t talk to strangers.”
 Goal: Reduce behavioral dependencies
between classes.
 Loose coupling
Object Oriented Analysis and Design
42
Applying LoD
 A method must be able to traverse links to obtain
its neighbors and must be able to call operations
on them.
 But it should not traverse a second link from the
neighbor to a third class.
 Methods should communicate only with preferred
suppliers:
 immediate parts on this
 objects passed as arguments to method
 objects which are directly created in method
 objects in global variables
 No other calls allowed
 ---> Scattering
Object Oriented Analysis and Design
43
Solution is Adaptive Programming
 Encapsulate operation into one place
thereby avoiding scattering
 Specify traversal over (graph) structure in a
succinct way thereby reducing tangling.
 Navigation strategy
Object Oriented Analysis and Design
44
Adaptive Programming: Demeter
 Adaptive Programming: references to other
objects are replaced by traversal strategies
for the class graph
 Methods become less brittle with regard to
changes in the class structure
Object Oriented Analysis and Design
45
Adaptive Programming: Demeter (cont.)
 Instance of AOP [Lieberherr92]
 Aspects are traversal strategies
 Separate the program text and the class structure
 Program is independent of class graph
 Accomplish tasks by traversals
 Specification for what parts of received object should
be traversed
 Code fragments for what to execute when specific
object types are encountered
Object Oriented Analysis and Design
46
Object Traversals
 The heart of Adaptive Programming is
object traversals
 Traversal code is tedious to write
 Traversal code should not obstruct the view
of the “real” program logic
Object Oriented Analysis and Design
47
Use of Visitors
import edu.neu.ccs.demeter.dj.*;
// define strategy
String strategy=“from BusRoute through BusStop to Person”
class BusRoute {
// define class graph
static Classgraph cg = new ClassGraph();
int printCountWaitingPersons(){ // traversal/visitor weaving
//define visitor
Visitor v = new Visitor()
public void before(Person host){ r++; … }
public void start() { r = 0;}
…
}
cg.traverse(this, strategy, v);
...}
Object Oriented Analysis and Design
48
Advantages of DJ
 Use of reflection
 No need for source code (no code weaving)
 Can work on class files
 Purely Java (no new structure)
Object Oriented Analysis and Design
49
Conclusion
 Crosscutting concerns are typically
scattered over several modules and result
in tangled code.
 This reduces the modularity and as such
the quality of the software system.
 AOSD provides explicit abstractions
mechanisms to represent these so-called
aspects and compose these into programs
 This increases the modularity of systems.
Object Oriented Analysis and Design
50