Modularizing Design Patterns with Aspects: A Quantitative Study

1
Modularizing Design Patterns with AspectsA
Quantitative Study

• Alessandro Garcia1 Cláudio SantAnna2
  Eduardo Figueiredo2
• Uirá Kulesza2 Carlos Lucena2 Arndt von
  Staa2
• Lancaster University, UK
• PUC-Rio, Brazil

8 August 2005
2
Motivation

• Design patterns are recognized as useful and
  important
• 23 Gang-of-Four (GoF) patterns
• patterns assign roles to their participants
• roles define the functionality of the
  participants in the pattern
• A number of patterns exhibit crosscutting
  concerns
• Pattern roles vs. participant classes
• Recent studies (e.g. HK02)
• OO abstractions are not able to modularize those
  concerns

HK02 Hannemann, J., Kiczales, G. Design
Pattern Implementation in Java and AspectJ,
Proceedings of OOPSLA02, November 2002 , pp.
161-173.
?
3
Motivation An Example

• The Observer Pattern
• role subject
• holds reference to observers
• notifies them about changes

FigureElement
Figure
ltltinterfacegtgt Subject
addObserver removeObserver notify
1


observers getX getY getColor addObserver removeObs
erver notify setX setY setColor
Point
Line
update Display
Screen
observers getP1 getP2 getColor addObserver removeO
bserver notify setP1 setP2 setColor

Members exclusively dedicated to the pattern

Methods including some code relative to the
pattern
4
The Problem

• There is a need for investigating the suitability
  of AOP for improving the modularization of design
  patterns
• qualitative and quantitative studies OO vs. AO
• replication
• Towards empirical evidence
• impact of the aspectization of design patterns
  on well-established attributes
• separation of concerns
• coupling, cohesion, and size
• improved reusability
• scalability of aspect-oriented solutions for
  design patterns

5
Limitations of Related Work

• Hannemann and Kiczales (HK) have developed the
  only systematic study
• Explicitly investigated the use of AspectJ in the
  implementation of the GoF patterns
• However
• A qualitative investigation
• Focus on separation of concerns
• Attributes not very well defined in empirical
  software engineering
• E.g. composability and (un)pluggability
• Scalability not explored

HK02 Hannemann, J., Kiczales, G. Design
Pattern Implementation in Java and AspectJ,
Proceedings of OOPSLA02, November 2002 , pp.
161-173.
?
6
Our Quantitative Study

• Complementation of the HK study
• replication of the study, supplementing it with
  empirical data
• improvement of our knowledge about the
  aspectization of design patterns
• Quantitative assessments based on metrics for
• Separation of Concerns (SoC)
• Coupling
• Cohesion
• Size

7
Outline

• The Problem
• Hannemann Kiczales Study
• Our Study Setting
• Metrics
• Assessment Procedures
• Results
• Separation of Concerns
• Coupling, Cohesion and Size
• Discussions
• General Analysis
• Study Constraints
• Conclusion

8
Hannemann Kiczales Study

• Goals
• develop and compare Java and AspectJ
  implementations of the 23 GoF design patterns
• improve the modularization of the pattern roles

9
Hannemann Kiczales Study

• Goals
• develop and compare Java and AspectJ
  implementations of the 23 GoF design patterns
• improve the modularization of the pattern roles
• Example

Reusable Aspect

• Some results
• SoC improvements in 17 patterns
• superior reusability achieved in 12 patterns

10
Outline

• The Problem
• Hannemann Kiczales Study
• Our Study Setting
• Metrics
• Assessment Procedures
• Results
• Separation of Concerns
• Coupling, Cohesion and Size
• Discussions
• General Analysis
• Study Constraints
• Conclusion

11
Our Study Setting

• Goal compare AspectJ and Java implementations of
  the GoF patterns in a quantitative manner
• Assessment of the HK implementations
• Organized in 4 phases
• Alignments
• addition of functionalities
• removal of functionalities
• similar coding styles
• alignments of tracing statements
• ...

12
Phase 2 Evolution

• Inclusion of new participants in the pattern
  implementations
• Application of the metrics
• original implementation vs. evolved
  implementation
• verify the scalability of the solutions

13
Phase 2 Evolution

• Inclusion of new participants in the pattern
  implementations
• Application of the metrics
• original implementation vs. evolved
  implementation
• verify the scalability of the solutions

FigureElement
Figure
1

getX getY getColor addObserver removeObserver noti
fy setX setY setColor
Point
update Display
Screen
14
Phase 2 Evolution
15
Measurement

• 9 used metrics

Metrics
Concern Difusion over Components
Attributes
CDC
Phase 3
Concern Difusion over Operations
CDO
Separation of Concerns
Concern Difusion over LOC
CDLOC
Lines of Code
LOC
Size
Number of Attributes
NOA
Coupling
Weighted Operations per Component
WOC
Phase 4
Cohesion
Coupling between Componentes
CBC
Depth of Inheritance
DIT
Lack of Cohesion in Operations
LCOO
C. SantAnna, 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.
?
16
Metrics - Separation of Concerns

• Viewpoint Concern
• Concerns investigated roles of each design
  pattern

Role subject CDC - Components 3 CDO -
Operations 13 CDLOC - Transition Points 10
17
Metrics - Coupling

• Viewpoint Component
• It extends the CBO metric CK94
• Measures the number of components which are
  coupled to a given component
• ? coupling -gt easier to maintain and reuse

AO
OO
ltltcrosscutsgtgt
CBC (Coupling between Components)
CK94 Chidamber, S., Kemerer, C. A Metrics
Suite for Object Oriented Design. IEEE
Transactions on Software Engineering, 20 (6),
June 1994, pp. 476-493.
?
18
Outline

• The Problem
• Hannemann Kiczales Study
• Our Study Setting
• Metrics
• Assessment Procedures
• Results
• Separation of Concerns
• Coupling, Cohesion and Size
• Discussions
• General Analysis
• Study Constraints
• Conclusion

19
Results

• Graphics illustrate the measurement results

system viewpoint
CDC
20
Results

• Separation of Concerns (SoC)
• Increased Separation
• Decorator, Adapter, Prototype, Visitor, Proxy,
  Singleton
• Mediator, Composite, Observer, Command, Iterator
• CoR, Strategy, and Memento
• Decreased Separation
• Template Method, Abstract Factory, Factory Method
• Bridge, Builder
• Flyweight
• No Effect 3 patterns
• Interpreter, State, Façade

14
6
21
Results

• Separation of Concerns (SoC)
• Increased Separation
• Decorator, Adapter, Prototype, Visitor, Proxy,
  Singleton
• Mediator, Composite, Observer, Command, Iterator
• CoR, Strategy, and Memento
• Decreased Separation
• Template Method, Abstract Factory, Factory Method
• Bridge, Builder
• Flyweight
• No Effect 3 patterns
• Interpreter, State, Façade

14
22
Results - SoC

• Increased Separation for CDC, CDO, CDLOC
• E.g. CDLOC measures

CDLOC
23
Results

• Separation of Concerns (SoC)
• Increased Separation 14 patterns
• Decorator, Adapter, Prototype, Visitor, Proxy,
  Singleton
• Mediator, Composite, Observer, Command, Iterator
• CoR, Strategy, and Memento
• Decreased Separation 6 patterns
• Template Method, Abstract Factory, Factory Method
• Bridge, Builder
• Flyweight
• No Effect 3 patterns
• Interpreter, State, Façade

best results
24
Results - SoC
25
Results - SoC
The measures of the AspectJ version do not
change as new elements are introduced superior
scalability
26
Results

• Separation of Concerns
• Increased Separation 14 patterns
• Decorator, Adapter, Prototype, Visitor, Proxy,
  Singleton
• Mediator, Composite, Observer, Command, Iterator
• CoR, Strategy, and Memento
• Similar characteristics
• Superior even in simple pattern instances
• Most of these patterns are directly supported by
  AspectJ features (e.g. Adapter)

best results
27
Results

• Separation of Concerns
• Increased Separation 14 patterns
• Decorator, Adapter, Prototype, Visitor, Proxy,
  Singleton
• Mediator, Composite, Observer, Command, Iterator
• CoR, Strategy, and Memento
• Decreased Separation 6 patterns
• Template Method, Abstract Factory, Factory Method
• Bridge, Builder
• Flyweight
• No Effect 3 patterns
• Interpreter, State, Façade

improved SoC only after the changes
28
Results - SoC
AspectJ implementations were superior only after
the introduced changes
Number of Components
Number of Operations
Number of Transition Points
29
Results - SoC
The measures of the AspectJ version do not
change as new elements are introduced
Number of Components
Number of Operations
Number of Transition Points
30
Results

• Separation of Concerns
• Increased Separation 14 patterns
• Decorator, Adapter, Prototype, Visitor, Proxy,
  Singleton
• Mediator, Composite, Observer, Command, Iterator
• CoR, Strategy, and Memento
• Similar characteristics
• Superior only in complex pattern instances
• Richer reusable aspects
• more of operations
• more of LOCs

improved SoC only after the changes
31
Results - SoC

• Separation of Concerns
• Increased Separation 14 patterns
• Decorator, Adapter, Prototype, Visitor, Proxy,
  Singleton
• Mediator, Composite, Observer, Command, Iterator
• CoR, Strategy, and Memento
• Decreased Separation 6 patterns
• Template Method, Abstract Factory, Factory Method
• Bridge, Builder
• Flyweight
• No Effect 3 patterns
• Interpreter, State, Façade

overall improvements with exceptions
32
Results - SoC

• Separation of Concerns
• Increased Separation 14 patterns
• Decorator, Adapter, Prototype, Visitor, Proxy,
  Singleton
• Mediator, Composite, Observer, Command, Iterator
• CoR, Strategy, and Memento
• Decreased Separation 6 patterns
• Template Method, Abstract Factory, Factory Method
• Bridge, Builder
• Flyweight
• No Effect 3 patterns
• Interpreter, State, Façade

33
Results

• Separation of Concerns
• Decreased Separation 6 patterns
• Template Method, Abstract Factory, Factory
  Method,Bridge, Builder
• Flyweight
• Similar characteristics
• The pattern roles are nicely realized in OO
• Similar structure
• an additional aspect to replace abstract classes
  with interfaces
• not intended to separate the pattern roles

few differences
34
Results - SoC

• Separation of Concerns (SoC)
• Decreased Separation 6 patterns
• Template Method, Abstract Factory, Factory
  Method,Bridge, Builder
• Flyweight
• Characteristics
• The AO structure is similar to the OO structure
• no advice/pointcut
• the generic aspect could be implemented as a
  simpler class

high superiority for the OO design more than 33
35
Results

• Coupling, Cohesion and Size
• Better Results for AO Solutions 5 patterns
• Composite, Observer, Adapter, Mediator, and
  Visitor
• Better Results for AO Solutions with Exceptions
  4 patterns
• Decorator, Proxy, Singleton, and State
• Better Results for OO Solutions with Exceptions
  4 patterns
• CoR, Command, Prototype, and Strategy
• Better Results for OO Solutions 8 patterns
• Template Method, Abstract Factory, Bridge,
  Interpreter,
• Factory Method, Builder, Memento, and Flyweight
• No Effect 2 patterns
• Iterator and Façade

9
12
36
Results

• Coupling, Cohesion and Size
• Better Results for AO Solutions 5 patterns
• Composite, Observer, Adapter, Mediator, and
  Visitor
• Better Results for AO Solutions with Exceptions
  4 patterns
• Decorator, Proxy, Singleton, and State
• Better Results for OO Solutions with Exceptions
  4 patterns
• CoR, Command, Prototype, and Strategy
• Better Results for OO Solutions 8 patterns
• Template Method, Abstract Factory, Bridge,
  Interpreter,
• Factory Method, Builder, Memento, and Flyweight
• No Effect 2 patterns
• Iterator and Façade

37
Results
a decorator aspect is coupled to all other
decorator aspects declare precedence

• ? AO Solutions exceptions

38
Results

• Coupling, Cohesion and Size
• Better Results for AO Solutions 5 patterns
• Composite, Observer, Adapter, Mediator, and
  Visitor
• Better Results for AO Solutions with Exceptions
  4 patterns
• Decorator, Proxy, Singleton, and State
• Characteristics
• good separation of concerns (exception State)
• ? positive impact
• overall improvements for coupling,
  inheritance,complexity of operations...

39
Results

• Coupling, Cohesion and Size
• Better Results for OO Solutions with Exceptions
  4 patterns
• CoR, Command, Prototype, and Strategy
• Better Results for OO Solutions 8 patterns
• Template Method, Abstract Factory, Bridge,
  Interpreter,
• Factory Method, Builder, Memento, and Flyweight

40
Results

• Coupling, Cohesion and Size
• Better Results for OO Solutions with Exceptions
• CoR, Command, Prototype, and Strategy
• Characteristics
• good separation of concerns
• no improvements for coupling, cohesion,inheritanc
  e,...

41
Results

• Coupling, Cohesion and Size
• Better Results for OO Solutions with Exceptions
  4 patterns
• CoR, Command, Prototype, and Strategy
• Better Results for OO Solutions 8 patterns
• Template Method, Abstract Factory, Bridge,
  Interpreter,
• Factory Method, Builder, Memento, and Flyweight

42
Results
these patterns are already nicelyrealized in OO

• ? OO Solutions

43
Outline

• The Problem
• Hannemann Kiczales Study
• Our Study Setting
• Metrics
• Assessment Procedures
• Results
• Separation of Concerns
• Coupling, Cohesion and Size
• Discussions
• General Analysis
• Study Constraints
• Conclusion

44
General Analysis

• Separable and Inseparable Concerns
• SoC Improvements
• Our study 14 patterns
• HK study 17 patterns
• Contradictions Template Method, Flyweight, and
  State
• Template Method it does not seem reasonable or
  even possible to isolate the pattern roles
• Flyweight the AO and OO implementations are
  similar
• State the differences are not expressive
• Roles are expressed as aspects, but it remains
  non-trivial to specify the combination in a
  simple manner
• E.g. Memento, Strategy, and CoR
• HK claims qualified the AspectJ implementations
  as superior

45
General Analysis

• Reducing Coupling and Increasing Cohesion
• aspects succeeded in the patterns with high
  interaction between the roles
• aspects modularize the collaboration protocol
  involving the roles
• E.g. Mediator, Observer, State, Composite, and
  Visitor
• Expressive Reusability only 4 patterns
• The HK study has found that 12 AspectJ versions
  of the patterns are reusable

46
General Analysis

• Aspects vs. Size Attributes
• 10 patterns fewer attributes in the AO version
• 12 patterns reduced of operations and
  parameters
• Metrics were useful to detect opportunities for
  refactoring
• Prototype interface declaration in the business
  classes
• CoR and Memento initializations
• Flyweight OO AO

47
Study Constraints

• Limitations of some traditional metrics
• LOC
• Limited size and complexity of the examples
• Restrict the extrapolation of the results
• Assessment specific to the pattern instances at
  hand

48
Conclusion

• Most AspectJ implementations improved separation
  of pattern-specific concerns
• Aspect-oriented solutions of the patterns
  significantly impacted on
• Coupling and cohesion
• Size attributes of components, of
  operations, of parameters, of attributes, ...
• SoC cannot be taken as the only factor to
  conclude for the use of aspects

49
Modularizing Design Patterns with AspectsA
Quantitative Study

• Alessandro Garcia Cláudio SantAnna Eduardo
  Figueiredo
• Uirá Kulesza Carlos Lucena Arndt von Staa
• PUC-Rio, Brazil

March 2005
Now at Lancaster University, UK
50
Publications

• Assessment of 7 patterns.
• C. SantAnna, A. Garcia, U. Kulesza, C. Lucena,
  A. von Staa. Design Patterns as Aspects A
  Quantitative Assessment. XVIII Brazilian
  Symposium on Software Engineering (SBES04),
  Brasília, Brasil, October 2004. (Best Paper
  Award)
• Assessment of all the 23 patterns.
• A. Garcia, C. SantAnna, E. Figueiredo, U.
  Kulesza, C. Lucena, A. von Staa. Modularizing
  Design Patterns with Aspects A Quantitative
  Study. Intl. Conference on Aspect-Oriented
  Software Development (AOSD'05), Chicago, USA,
  March 2005.

51
References

• The Architectural Method
• TAO The Conceptual Framework

GARCIA, A. LUCENA, C. COWAN, D. Agents in
Object-Oriented Software Engineering. Software
Practice and Experience, Elsevier, May 2004, pp.
1-32.
?
GARCIA, A. et al. An Aspect-Based Approach for
Developing Multi-Agent Object-Oriented Systems.
Proceedings of the 15th Brazilian Symposium on
Software Engineering, Rio de Janeiro, Brazil,
October 2001, pp. 177-192. (Nomination for the
Best Paper Award)
?
SILVA, V. GARCIA, A. BRANDÃO, A. CHAVEZ, C.
LUCENA, C. ALENCAR, P. Taming Agents and Objects
in Software Engineering. In Software Engineering
for Large-Scale Multi-Agent Systems,
Springer-Verlag LNCS 2603, Berlin, April 2003.
?
52
References

• Empirical Studies

GARCIA, A. et al. Engineering Multi-Agent Systems
with Aspects and Patterns. Journal of the
Brazilian Computer Society, Special Issue on
Software Engineering and Databases, N. 1, Vol. 8,
July 2002, pp. 57-72.
?
GARCIA, A. et al. Separation of Concerns in
Multi-Agent Systems An Empirical Study. In
Software Engineering for Multi-Agent Systems II,
Springer-Verlag, LNCS 2940, March 2004, pp. 49-72.
?
CHAVEZ, C. GARCIA, A. LUCENA, C. Some Insights
on the Use of AspectJ and Hyper/J. Proceedings of
the Tutorial and Workshop on Aspect-Oriented
Programming and Separation of Concerns,
Lancaster, UK, August 2001
?
53
References

• The Assessment Framework
• The Aspect-Oriented Agent Architecture
• The Pattern Language

SANT'ANNA, C. GARCIA, A. CHAVEZ, C. LUCENA,
C. VON STAA, A. On the Reuse and Maintenance of
Aspect-Oriented Software An Assessment
Framework. Proceedings of 17th Brazilian
Symposium on Software Engineering, Manaus,
Brazil, October 2003.
?
GARCIA, A. et al. Separation of Concerns in
Multi-Agent Systems An Empirical Study. In
Software Engineering for Multi-Agent Systems II,
Springer, LNCS 2940, March 2004, pp. 49-72.
?
GARCIA, A. KULESZA, U. LUCENA, C. Separation of
Concerns in Open Multi-Agent Systems An
Architectural Approach. Submitted to SELMAS04
workshop at ICSE04, Edinburgh, Scotland, May
2004.
?
GARCIA, A. KULESZA, U. LUCENA, C. From Objects
to Agents An Aspect-Oriented Pattern Language.
Submitted to ACM Transactions on Software
Engineering Methodologies.
?