Metrics for AOP: Do Aspects...
Transcript of Metrics for AOP: Do Aspects...
Technion
Israel
1
Metrics for AOP:
Do Aspects Help?
© A. Garcia (2007)
Shmuel Katz
From slides of Alessandro Garcia
Lancaster University, UK
Lecture at AOSD Summer School, Genoa, July 2007
Technion
Israel
2
Does AOP scale up in realistic
scenarios?
• Common assumption: implementation of certain
crosscutting concerns are always better
modularized by aspect-oriented programming (AOP)
– often cited in introductory AOP texts as "killer applications"
of aspect-orientation
– E.g. exception handling (EH), some design patterns,
security, persistence
• How does AOP scale in more realistic
scenarios?
– aspectual composition of design patterns
– aspectization of varied EH strategies
?
Technion
Israel
3
We have not yet …
• … addressed many burning research questions!
– Positive and negative influences of AOP on fundamental principles?
• coupling, cohesion, and simplicity
• open-closed principle, and stability of module interfaces
– Are the aspectual modules reusable entities?
• can aspectized handlers and patterns be reused?
– Is it always beneficial to aspectize the “traditional” crosscutting concerns (CCCs)?
– Is modularity preserved in intricate aspectual compositions?
• ... involving interaction of multiple CCCs
• ... involving 3 or more design patterns
• ... involving changes of a diverse nature
Technion
Israel
4
Design Assessment • How to assess designs or implementations with respect to external
attributes?
Reusability Understandability
Flexibility Maintainability
Size
Coupling
Cohesion
Separation of Concerns
Factors Internal Attributes Qualities
VS
LOC
NOA
WOC
CBC
LCOO
CDC
CDO
CDLOC
Metrics
DIT
Reusability Understandability
Flexibility Maintainability
Size
Coupling
Cohesion
Separation of Concerns
Factors Internal Attributes Qualities
VS
LOC
NOA
WOC
CBC
LCOO
CDC
CDO
CDLOC
Metrics
DIT
Technion
Israel
5
Experimental Procedures
- Measurement: 9 used metrics
– supported by our tool: AJATO
Size
Coupling
Cohesion
Separation of Concerns
Attributes
LOC
NOA
NOC
CBC
LCOO
CDC
CDO
CDLOC
Metrics
DIT
Concern Difusion over Components
Concern Difusion over Operations
Concern Difusion over LOC
Lines of Code
Number of Attributes
Number of Operations
Coupling between Components
Lack of Cohesion in Operations
C. Sant’Anna, A. Garcia, C. Chavez, C. Lucena, A. Staa. “On the Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework” . Proc. of the ACM Sigsoft XVII Brazilian Symposium on Software Engineering, Manaus, Brazil, October 2003, pp. 19-34.
Depth of Inheritance Tree
Technion
Israel
6
Coupling
• Measures the number of components which are coupled to a
given component (class or aspect)
– coupling -> easier to change
CBC (Coupling between
Components)
<<crosscuts>>
[CK94] Chidamber, S., Kemerer, C. “A Metrics Suite for Object Oriented Design”. IEEE Transactions on Software Engineering, 20 (6), June 1994, pp. 476-493.
OO AO
Technion
Israel
7
Cohesion Measures
LCOM (Lack of cohesion): measures how much internal methods of a class are
interconnected
LCOM value -> easier to change
Aspect A Class B
Method
Relationship
Class C Aspect D
Low cohesion High cohesion
Advice/IT declarations
Technion
Israel
8
Other Conventional Metrics
• Lines of code
• Number of attributes
• Number of methods
– might help identification of replicated code
• Weighted methods per class
– compute the number of parameters in method declarations
– might help identification of “wide” interfaces due to the
presence of crosscutting concerns
• Higher the measure, higher the complexity
Technion
Israel
9
Concern Metrics (for aspects)
• Three concerns: figure, subject,
observer
• Concern: “Subject”
getX
getY
addObserver
removeObserver
notify
setX
setY
getP1
getP2
addObserver
removeObserver
notify
setP1
setP2
Figure 1 *
update
Display
Screen
update
<<interface>>
Observer
addObserver
removeObserver
notify
<<interface>>
Subject FigureElement
Line Point
Role “subject”
CDC - # Classes = 3
CDM - # Methods = 13
CDLOC - # Transition Points = 10
public class Point
implements Subject {
private HashSet observers;
private int x;
private int y;
public Point(int x, int y, Color color) {
this.x=x;
this.y=y;
this.observers = new HashSet();
}
public int getX() { return x; }
public int getY() { return y; }
public void setX(int x) {
this.x=x;
notifyObservers();
}
public void setY(int y) {
this.y=y;
notifyObservers();
}
public void addObserver(Observer o) {
this.observers.add(o);
}
public void removeObserver(Observer o) {
this.observers.remove(o);
}
public void notifyObservers() {
for (Iterator e = observers.iterator() ; e.hasNext() ;) {
((Observer)e.next()).update(this);
}
}
}
Technion
Israel
10
display
addObserver
removeObserver
notify
update
Lack of Concern-based
Cohesion • Counts the degree of tangling
• Concerns: Subject, Observer and Figure
getX
getY
addObserver
removeObserver
notify
setX
setY
getP1
getP2
addObserver
removeObserver
notify
setP1
setP2
Figure 1 *
Screen
update
<<interface>>
Observer
addObserver
removeObserver
notify
<<interface>>
Subject FigureElement
Line Point
Class Screen
LCC - # Concerns = 3
(“Figure”, “Subject” and “Observer”)
Class Point
LCC - # Concerns = 2
(“Figure” and “Subject”)
public class Screen implements Subject, Observer {
private HashSet observers;
private String name;
public Screen(String s) {
this.name = s;
observers = new HashSet();
}
public void display (String s) {
System.out.println(name + ": " + s);
notifyObservers();
}
public void addObserver(Observer o) {
this.observers.add(o);
}
public void removeObserver(Observer o) {
this.observers.remove(o);
}
public void notifyObservers() {
for (Iterator e = observers.iterator() ; e.hasNext() ;) {
((Observer)e.next()).update(this);
}
}
public void update(Subject s) {
display("update received from a "+s.getClass().getName()+" object");
}
}
Technion
Israel
11
Empirical Studies “Aspectization”
Case Studies
1st: Qualitative Studies
R e
p l i c
a t i o
n
Multi-Agent
Systems
(S:P&E 04)
Metrics
(SoC, Coupling, Cohesion, Size)
Bro
ad
ly-s
coped
an
d localized
cro
sscu
ttin
g c
on
cern
s
Design
Patterns
(OOPSLA.02)
Exception
Handling
(ICSE.00)
Persistence &
Distribution
(OOPSLA.02)
Multi-Agent
Systems
Design
Patterns
Exception
Handling
Persistence &
Distribution
2nd: Quantitative Studies
reduction of more than 85% in
the number of handlers
SoC improvements = 17 patterns
composition transparency = 15 patterns
reusable solutions = 12 patterns
…
reduction of 20% of code
Technion
Israel
12
The Chosen Crosscutting Concerns
• Exception Handling (EH) – broadly-scoped CCCs
– explore dedicated AspectJ constructs
• softening exceptions and around advice
• 23 GoF Design patterns – more localized CCCs, recurring design solutions
– multiple forms of aspectization
• multiple inheritance and role-based collaborations
• Evolving N-tier software architecture
– multiple architecturally-relevant CCCs
– transaction management, distribution, and concurrency control
N. Cacho, C. Sant'Anna, E. Figueiredo, A. Garcia, and T. Batista. “Composing Design Patterns: a Scalability Study of Aspect-Oriented Programming”. In Proc. Of AOSD '06, March 2006.
P. Greenwood et al. “On the Impact of Aspectual Decompositions on Design Stability: An Empirical Study”. 21st European Conf. on Object-Oriented Programming (ECOOP.07), July 2007, Germany.
F. Filho, N. Cacho, E. Figueiredo, A. Garcia, and C. Rubira. “Exceptions and Aspects: The Devil is in the
Details”. In Proc. of FSE-14, 14th Intl. Conf. on Foundations of Soft. Engineering, November 2006.
Technion
Israel
13
Experimental Procedures
• Selection of case studies
– We partially or totally considered the implementation of:
• Telestrada: traveller information system
– 3350 LOC, > 200 modules
• Pet Store: e-commerce demo for Java EE
platform
– 17500 LOC, > 330 modules
• Eclipse CVS Core Plugin
– 20000 LOC, > 170 modules
• Health Watcher: web-based information
systems for healthcare complaints
– 6630 LOC, > 134 modules
JA
VA
A
SP
EC
TJ
Technion
Israel
14
Aspectization of Handlers
• Aspectization strategy
– Moved try-catch, try-catch-finally, and try-finally blocks to aspects
– Handler implementation
• whenever possible -> after advice: simpler ones; raise exceptions
• otherwise -> around advice
• “softened” checked exceptions
– For each target system: different form for structuring EH aspects
– Method signatures (throws) and exception raising not considered
– Looked for reuse opportunities
handler
protected
region
Technion
Israel
15
Results - Separation of Concerns
difference is granted to the
distinct EH aspectization strategies
no reuse & many operations with more
than one try-catch block reuse was exceptionally high
Technion
Israel
16
Results - Size Contradicting the general intuition that AOP
makes programs smaller…
some reuse of handlers
some reuse was compensated by the overhead of using AspectJ
Technion
Israel
17
Lessons Learned - I • Separation of EH concerns
– comparing our findings and the ones in the LL study • our study confirms the improved textual separation
• Coupling – no major influence of aspectization
– however, a closer examination in the code...
• subtle kind of coupling – use of exception softening creates an implicit, compile-time
dependency of the base code on the EH aspect
• in addition, softening exceptions is not a safe mechanism
– Exception and Throwable should never be softened
– AspectJ renders Java’s static checks useless
• Size – increased number of operations (join point exposition)
• new operations: 3.3% Telestrada, 2.9% in the Java Pet Store,
0.79% in the CVS Plugin, 1.7% in the Health Watcher
• negative result: many cases did not state the developer intent
Technion
Israel
18
Lessons Learned - II
• Is Exception Handling a Reusable Aspect?
– reusing handlers is harder than is usually advertised
• HW system: reduction of CDO – 45%
– very simple handlers
– contrasts strongly with the findings of Lippert and
Lopes (85% reduction in the number of handlers)
Technion
Israel
19
The Chosen Crosscutting Concerns
• Exception Handling (EH) – broadly-scoped CCCs
– explore dedicated AspectJ constructs
• softening exceptions and around advice
• 23 GoF Design patterns – more localized CCCs, recurring design solutions
– multiple forms of aspectization
• multiple inheritance and role-based collaborations
• Evolving N-tier software architecture
– multiple architecturally-relevant CCCs
– transaction management, distribution, and concurrency control
N. Cacho, C. Sant'Anna, E. Figueiredo, A. Garcia, and T. Batista. “Composing Design Patterns: a Scalability Study of Aspect-Oriented Programming”. In Proc. Of AOSD '06, March 2006.
P. Greenwood et al. “On the Impact of Aspectual Decompositions on Design Stability: An Empirical Study”. 21st European Conf. on Object-Oriented Programming (ECOOP.07), July 2007, Germany.
F. Filho, N. Cacho, E. Figueiredo, A. Garcia, and C. Rubira. “Exceptions and Aspects: The Devil is in the
Details”. In Proc. of FSE-14, 14th Intl. Conf. on Foundations of Soft. Engineering, November 2006.
Technion
Israel
20
Pattern compositions are
everywhere
• Design patterns are recognized as useful and important – 23 Gang-of-Four (GoF) patterns [Gamma95]
• assignment of roles to their participants
– they are applied to most software systems
• means to achieve modularity
• Composition of design patterns – heterogeneous compositional forms
• simple forms, e.g. method invocations
• complex forms, e.g. shared participants – pattern modularity should be preserved in the presence of
pattern interactions
[Gamma95] Gamma, E. et al. “Design Patterns: Elements of Reusable Object-Oriented Software”. Addison-Wesley, 1995.
Technion
Israel
21
We already know that… • A number of patterns exhibit crosscutting concerns
– Pattern roles vs. participant classes [HK02]
[HK02] Hannemann, J., Kiczales, G. “Design Pattern Implementation in Java and AspectJ”, Proceedings of OOPSLA’02, November 2002 , pp. 161-173.
Members exclusively dedicated to the pattern
Methods including some code relative to the pattern
observers
getX
getY
getColor
addObserver
removeObserver
notify
setX
setY
setColor
Point Line
FigureElement Figure 1 *
update
Display
Screen
update
<<interface>>
Observer
addObserver
removeObserver
notify
<<interface>>
Subject
observers
getP1
getP2
getColor
addObserver
removeObserver
notify
setP1
setP2
setColor
*
*
*
*
Technion
Israel
22
We already know that…
• AOP seems to…
– improve the modularization of the pattern roles
– enhance pattern composability
• Example:
observers
getX
getY
getColor
addObserver
removeObserver
notify
setX
setY
setColor
Point Line
FigureElement Figure 1 *
update
Display
Screen
update
<<interface>>
Observer addObserver
removeObserver
notify
<<interface>>
Subject
observers
getP1
getP2
getColor
addObserver
removeObserver
notify
setP1
setP2
setColor
*
*
*
*
getX
getY
getColor
setX
setY
setColor
Point Line
FigureElement Figure 1 *
Display
Screen getP1
getP2
getColor
setP1
setP2
setColor
ObserverProtocol
CoordinateObserver
<<crosscut>>
Composable
Aspect
Technion
Israel
23
Heterogeneous Pattern Compositions
Selection of the 62 pair-wise pattern compositions
– each pattern participated at least in 2 compositions
– minimum of 9 different compositions per category
9
11
17
25
Category List of Compositions
Invocation - based Builder + Command, COR + Prototype, Facade + Memento, Facade + Singleton,
Iterator + Singleton, AbstractFactory + State, Interpreter + Iterator, Interpreter + State,
Proxy + Interpreter
Class - level interl acing
CoR + Observer, AbstractFactory + Interpreter, Observer + Bridge, Observer +
Memento, Observer + Prototype, Observer + Strategy, Observer + TemplateMethod,
Observer + Visitor, Proxy + Singleton, Proxy + Singleton (2) , Mediator + Observer
Method - leve l interlacing
Decorator + Observer, Decorator + Prototype, Decorator + State, FactoryMethod +
Memento, Mediator + CoR, Mediator + Prototype, Mediator + Proxy, Mediator + State,
Observer + Composite, Prototype + Strategy, Prototype + TemplateMethod, State +
Observer, State + Strategy, State + TemplateMethod, Interpreter + Composite
Overlapping
CoR + FactoryMethod, Command + Flyweight, Command + Proxy, Composite +
Visitor, Decorator + Bridge, Decorator + Strategy, FactoryMethod + Bridge,
FactoryMethod + Comm and, FactoryMethod + Composite, FactoryMethod +
Flyweight, FactoryMethod + Observer, FactoryMethod + Visitor, Flyweight + Adapter,
Mediator + Decorator, Mediator + Strategy, Mediator + TemplateMethod, Proxy +
Adapter, Proxy + Builder, Proxy + Flyweight, St ate + Prototype, TemplateMethod +
Bridge, Proxy + Composite, Strategy + TemplateMethod, Decorator +
TemplateMethod, TemplateMethod + Strategy
Technion
Israel
24
Lessons Learned - I
• Results per composition category – more details in
the paper…
• Does AOP enhance pattern composability?
– in this study, “good composability” means
• pattern can be directly reused and smoothly
extended to different composition contexts
– extension of abstract pointcuts and methods
• the core pattern implementation should not be
aware of the composition specificities
• pattern compositions should not impact
negatively on modularity attributes
N. Cacho, C. Sant'Anna, E. Figueiredo, A. Garcia, and T. Batista. “Composing Design Patterns: a
Scalability Study of Aspect-Oriented Programming”. In AOSD '06: Proc. of the 5th Intl. Conf. on Aspect-oriented software development, pages 109-121, New York, 2006. ACM Press.
Technion
Israel
25
Lessons Learned - II
• Does AOP enhance pattern composability?
– AspectJ succeeded when the two involved patterns
• took part in invocation-based compositions, OR
• having one or more classes in common
– However, extensive modifications to the core pattern
implementations and modularity problems were found
• compositions with intra-method interlacing and field/method
overlapping
Technion
Israel
26
Lessons Learned…
• Did the separation of
aspectized patterns scale?
Previous Studies This Study Pattern
HK
Stu
dy
(L
oca
lity
)
Our
Fir
st S
tudy
(S
oC
)
Sep
arat
ion o
f
Conce
rns
Num
ber
of
Com
posi
tion
Ori
gin
al
Im
ple
men
tati
on
s
Abstract Factory no OO = 2 yes
Adapter yes AO = 2 yes
Bridge no OO = 7 no*
Builder no OO = 2 yes
CoR yes AO = 6 yes
Command yes AO = 4 yes
Composite yes AO AO+ 6 yes
Decorator yes AO AO+ 7 yes
Façade Same Implementation for
Java and AspectJ
2 yes
Factory Method no OO OO 8 yes
Flyweight yes OO = 4 yes
Interpreter no = AO 4 no
Iterator yes AO AO 4 yes
Mediator yes AO = 7 no*
Memento yes AO AO 3 yes
Observer yes AO AO+ 11 yes
Prototype yes AO AO 7 yes
Proxy yes AO AO 8 yes
Singleton yes AO AO 4 yes
State yes = AO 8 yes
Strategy yes AO AO 7 no
Template Method yes OO AO 7 no*
Visitor yes AO AO 4 yes
(+) indicates the AO solutions that achieved the best results in all
compositions
(*) indicates the patterns which was not aspectized in this study
Java is clearly superior
17 13
9 “no clear benefits of AspectJ”
Four reasons:
(i) typical OO patterns (same results)
(ii) non-aspectized patterns
(iii) the composition particularities
(iv) the pattern instance size
(v) aspectization approach
(vi) other application-specific
requirements
Technion
Israel
27
The Chosen Crosscutting Concerns
• Exception Handling (EH) – broadly-scoped CCCs
– explore dedicated AspectJ constructs
• softening exceptions and around advice
• 23 GoF Design patterns – more localized CCCs, recurring design solutions
– multiple forms of aspectization
• multiple inheritance and role-based collaborations
• Evolving N-tier software architecture
– multiple architecturally-relevant CCCs
– transaction management, distribution, and concurrency control
N. Cacho, C. Sant'Anna, E. Figueiredo, A. Garcia, and T. Batista. “Composing Design Patterns: a Scalability Study of Aspect-Oriented Programming”. In Proc. Of AOSD '06, March 2006.
P. Greenwood et al. “On the Impact of Aspectual Decompositions on Design Stability: An Empirical Study”. 21st European Conf. on Object-Oriented Programming (ECOOP.07), July 2007, Germany.
F. Filho, N. Cacho, E. Figueiredo, A. Garcia, and C. Rubira. “Exceptions and Aspects: The Devil is in the
Details”. In Proc. of FSE-14, 14th Intl. Conf. on Foundations of Soft. Engineering, November 2006.
Technion
Israel
28
Design Stability Study
• Aim: assessing various facets of design stability on
object-oriented and aspect-oriented designs
– focus on typical software maintenance tasks
• Multi-dimensional analysis
– modularity sustenance
– ripple effects
– satisfaction of basic design principles
Technion
Israel
29
Experiment Design: Study Phases
(1) Development and alignment of the system versions
– Java and AspectJ versions previously created
– Added CaesarJ implementation
– Aligned functionalities
– Aligned code style
(2) Implementation of 9 change scenarios
– Added, removed, changed and composed modules
– Performed step 1
(3) Assessment of the three versions
– Applied software metrics (SoC, Coupling, Cohesion, Size)
– Analyzed change impact and stability
– Analyzed concern interaction
P. Greenwood et al. “On the Impact of Aspectual Decompositions on Design Stability: An Empirical Study”. 21st European Conf. on Object-Oriented Programming (ECOOP.07), July 2007, Germany.
Technion
Israel
31
HW
Arc
hit
ec
ture
: A
O
View Layer
Business Layer
Data Layer
Distribution Aspect
Concurrency Aspect
Persistence Aspect
Technion
Israel
32
HW
Arc
hit
ec
ture
: O
O View
Layer
Distribution Layer
Business Layer
Data Layer
~S3:
use Observer to
monitor object updates
Technion
Israel
33
HW
Arc
hit
ec
ture
: O
O View
Layer
Distribution Layer
Business Layer
Data Layer
~S8:
inclusion of use cases
to support new queries
to date types
~S9:
more robust error
handling strategies
Technion
Israel
34
Coupling and Cohesion
• Better coupling and cohesion in AO
• AO Version 3 required empty hook
methods to be inserted
– Reduces scattering but at cost of cohesion
• Version 4 introduces the Observer pattern
– Pointcuts and declare parents reduce coupling
• Difference in Version 5 due to introduction
of the Distribution Adapter pattern
– Allows distribution mechanism to be pluggable
– Optional compilation of aspects already allows
this
• CCCs aspectized upfront were stable
– Exception: again EH
• refactoring methods to expose context
open-closed
principle
Avera
ge C
ouplin
g
Avera
ge C
ohesio
n
Technion
Israel
35
• Note the drop in CDLOC for
V5 in OO
– Related to applying the
distribution adapter pattern
Persistence Variation Use of pointcut expressions
improves stability in SoC
– Large increase in OO Version 9
– Some associated problems
(Fragile Pointcuts)
SoC
Lines of Code
SoC
Components
Technion
Israel
36
Architecture Design
Stability • Similar approach to the implementation analysis
• Significant difference in the architectural structure of the
persistence concern
– Present in many more OO architectural elements
– Propagation of exception events from Data to View layer
– AO catches these exceptions in the Data layer
• Largest change occurred in Version 9
– Resulted in adding a number of operations to the interfaces
between layers
– Each operation added required had to address persistence related
exceptions
Technion
Israel
37
Arc
hit
ectu
re D
es
ign
Sta
bilit
y
View Layer
Distribution Layer
Business Layer
Data Layer
Technion
Israel
38
Related work
• Persistence, transactions, and distribution – Kienzle & Guerraoui, ECOOP’02
– Soares et al., OOPSLA’02
– Rashid & Chitchyan, AOSD’03
• Design patterns – Hannemann & Kiczales (HK), OOPSLA’02
– Garcia et al., AOSD’05
• Exception handling – Lippert & Lopes (LL), ICSE’00
• Existing studies mainly focus on – qualitative assessments
– focus on separation of concerns
– do not assess scalability of AOP
Technion
Israel
39
New Challenges • SoC cannot be taken as the only factor to conclude for the use
of aspects
• “The Devil is on the Details”
– complexity of handlers and their interactions with normal behaviour
(dependency on local variables and nesting of handlers)
– composition particularities also influence the results
• even for patterns that are recognized as typical
applications of AOP
• New challenges
– more sophisticated studies involving aspect interactions
– improve EH mechanisms in AO languages
– metrics that cover other modularity dimensions
– implementation and assessment of the patterns in other AO
programming languages: Hyper/J and ObjectTeams