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


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


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















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


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


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















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


Technion

Israel

30

HW

Arc

hit

ec

ture

: O

O View

Layer

Distribution Layer

Business Layer

Data Layer

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

Metrics for AOP: Do Aspects...

Documents

Transcript of Metrics for AOP: Do Aspects...