Metrics for AOP: Do Aspects Help?

Transcription

1 Metrics for AOP: Do Aspects Help? Shmuel Katz From slides of Alessandro Garcia Lancaster University, UK Lecture at AOSD Summer School, Genoa, July 2007 A. Garcia (2007) 1

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? 2

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 3

4 Design Assessment How to assess designs or implementations with respect to external attributes? Qualities Factors Internal Attributes Metrics Reusability Understandability Separation of Concerns CDC CDO CDLOC VS Size LOC NOA WOC Maintainability Flexibility Coupling Cohesion CBC DIT LCOO 4

5 Experimental Procedures - Measurement: 9 used metrics supported by our tool: AJATO Attributes Separation of Concerns Size Coupling Cohesion Metrics CDC CDO CDLOC LOC NOA NOC CBC DIT LCOO Concern Difusion over Components Concern Difusion over Operations Concern Difusion over LOC Lines of Code Number of Attributes Number of Operations Coupling between Components Depth of Inheritance Tree 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 5 Engineering, Manaus, Brazil, October 2003, pp

6 Coupling OO AO <<crosscuts>> CBC (Coupling between Components) Measures the number of components which are coupled to a given component (class or aspect) coupling -> easier to change [CK94] Chidamber, S., Kemerer, C. A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, 20 (6), June 1994, pp

7 Cohesion Measures Method Aspect A Class B Advice/IT declarations Relationship Class C Low cohesion Aspect D High cohesion LCOM (Lack of cohesion): measures how much internal methods of a class are interconnected 7 LCOM value -> easier to change

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 8

9 Concern Metrics (for aspects) Three concerns: figure, subject, observer Concern: Subject public class Point implements Subject { private HashSet observers; <<interface>> Subject addobserver removeobserver notify Figure 1 * FigureElement <<interface>> Observer update 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; } Point Line Screen public void setx(int x) { this.x=x; notifyobservers(); } getx gety addobserver removeobserver notify setx sety getp1 getp2 addobserver removeobserver notify setp1 setp2 update Display public void sety(int y) { this.y=y; notifyobservers(); } public void addobserver(observer o) { this.observers.add(o); } Role subject CDC - # Classes = 3 CDM - # Methods = 13 CDLOC - # Transition Points = 10 } public void removeobserver(observer o) { this.observers.remove(o); } public void notifyobservers() { for (Iterator e = observers.iterator() ; e.hasnext() ;) { ((Observer)e.next()).update(this); } } 9

10 Lack of Concern-based Cohesion Counts the degree of tangling Concerns: Subject, Observer and Figure public class Screen implements Subject, Observer { private HashSet observers; <<interface>> Observer update <<interface>> Subject addobserver removeobserver notify Figure 1 * FigureElement private String name; public Screen(String s) { this.name = s; observers = new HashSet(); } public void display (String s) { System.out.println(name + ": " + s); notifyobservers(); } Screen display addobserver removeobserver notify update Point getx gety addobserver removeobserver notify setx sety Line getp1 getp2 addobserver removeobserver notify setp1 setp2 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) { Class Screen LCC - # Concerns = 3 ( Figure, Subject and Observer ) } } display("update received from a "+s.getclass().getname()+" object"); Class Point LCC - # Concerns = 2 ( Figure and Subject ) 10

11 Broadly-scoped and localized crosscutting concerns R e p l i c a t i o n Empirical Studies SoC improvements = 17 patterns composition transparency = 15 patterns reusable solutions = 12 patterns 1 st : Qualitative Studies Aspectization Case Studies 2 nd : Quantitative Studies Multi-Agent Systems (S:P&E 04) Multi-Agent Systems Design Patterns (OOPSLA.02) Design Patterns Exception Handling (ICSE.00) Exception Handling reduction of more than 85% in the number of handlers Persistence & Distribution (OOPSLA.02) Persistence & Distribution reduction of 20% of code Metrics (SoC, Coupling, Cohesion, 11 Size)

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 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 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 P. Greenwood et al. On the Impact of Aspectual Decompositions on Design Stability: An Empirical 12 Study. 21st European Conf. on Object-Oriented Programming (ECOOP.07), July 2007, Germany.

13 ASPECTJ JAVA 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 LOC, > 330 modules Eclipse CVS Core Plugin LOC, > 170 modules Health Watcher: web-based information systems for healthcare complaints 6630 LOC, > 134 modules 13

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 protected region handler 14

15 Results - Separation of Concerns difference is granted to the distinct EH aspectization strategies no reuse & many operations with more reuse was exceptionally high than one try-catch block 15

16 Results - Size Contradicting the general intuition that AOP makes programs smaller some reuse was compensated by the overhead of using AspectJ some reuse of handlers 16

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 17

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) 18

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 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 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 P. Greenwood et al. On the Impact of Aspectual Decompositions on Design Stability: An Empirical 19 Study. 21st European Conf. on Object-Oriented Programming (ECOOP.07), July 2007, Germany.

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,

21 We already know that A number of patterns exhibit crosscutting concerns Pattern roles vs. participant classes [HK02] <<interface>> Subject addobserver removeobserver notify Figure 1 * FigureElement <<interface>> Observer update * * Point observers getx gety getcolor addobserver removeobserver notify setx sety setcolor * Line observers getp1 getp2 getcolor addobserver removeobserver notify setp1 setp2 setcolor * Screen update Display Members exclusively dedicated to the pattern Methods including some code relative to the pattern [HK02] Hannemann, J., Kiczales, G. Design Pattern Implementation in Java and AspectJ, Proceedings of OOPSLA 02, November 2002, pp

22 We already know that AOP seems to improve the modularization of the pattern roles enhance pattern composability Example: Composable Aspect ObserverProtocol <<interface>> Subject addobserver removeobserver notify Figure 1 * FigureElement <<interface>> Observer update * * CoordinateObserver <<crosscut>> Point observers getx getx gety gety getcolor getcolor setx addobserver sety removeobserver setcolor notify setx sety setcolor * Line observers getp1 getp1 getp2 getp2 getcolor getcolor setp1 addobserver setp2 removeobserver setcolor notify setp1 setp2 setcolor * Screen update Display Display 22

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 Category Invocation - based Class - level interl acing Method - leve l interlacing Overlapping List of Compositions Builder + Command, COR + Prototype, Facade + Memento, Facade + Singleton, Iterator + Singleton, AbstractFactory + State, Interpreter + Iterator, Interpreter + State, Proxy + Interpreter CoR + Observer, AbstractFactory + Interpreter, Observer + Bridge, Observer + Memento, Observer + Prototype, Observer + Strategy, Observer + TemplateMethod, Observer + Visitor, Proxy + Singleton, Proxy + Singleton (2), Mediator + Observer 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 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 23

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 5 th Intl. Conf. on Aspect-oriented software development, pages , New York, ACM Press. 24

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 25

26 HK Study (Locality) Our First Study (SoC) Separation of Concerns Number of Composition Original Implementations Pattern Previous Studies This Study Lessons Learned Did the separation of aspectized patterns scale? Java is clearly superior 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 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 26 compositions (*) indicates the patterns which was not aspectized in this study

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 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 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 P. Greenwood et al. On the Impact of Aspectual Decompositions on Design Stability: An Empirical 27 Study. 21st European Conf. on Object-Oriented Programming (ECOOP.07), July 2007, Germany.

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 28

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), 29 July 2007, Germany.

30 HW Architecture: OO View Layer Distribution Layer Business Layer Data Layer 30

31 HW Architecture: AO View Layer Distribution Aspect Business Layer Persistence Aspect Data Layer Concurrency Aspect 31

32 HW Architecture: OO View Layer Distribution Layer ~S3: use Observer to monitor object updates Business Layer Data Layer 32

33 HW Architecture: OO View Layer Business Layer Distribution Layer ~S8: inclusion of use cases to support new queries to date types ~S9: more robust error handling strategies Data Layer 33

34 Average Cohesion Average Coupling Coupling and Cohesion open-closed principle 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 34

35 Persistence Variation Use of pointcut expressions improves stability in SoC Large increase in OO Version 9 Some associated problems (Fragile Pointcuts) SoC Components SoC Lines of Code Note the drop in CDLOC for V5 in OO Related to applying the distribution adapter pattern 35

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 36

37 Architecture Design Stability View Layer Distribution Layer Business Layer Data Layer 37

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 38

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 39