Contemporary Modularisation Mechanisms: A Multi-Dimensional Quality Analysis

1. Contemporary Modularisation Mechanisms: A Multi-Dimensional Quality Analysis Francisco Dantas | fneto@inf.puc-rio.br Alessandro Gurgel | agurgel@inf.puc-rio.br Alessandro Garcia | afgarcia@inf.puc-rio.br

2. The Original Project Proposal - 2008 • Assessment of individual “advanced” (post-OO) modularity mechanisms • Pointcut-advice (e.g., pointcut designators and types of advice) • Intertypes, mixin composition, etc… • Assessment focus: stability vs. error-proneness • Progress – 2008 – 2009: without explicit funding • Partially done for AspectJ mechanisms only • Findings, examples: • Programmers do not introduce more bugs when using pointcut-advice [ICSE 2010] • Programmers introduce more bugs in code when using after advice [ICSE 2010] • AspectJ-based code face ripple effects when the number of interacting aspects increase [ICSE 2008] (more than a Java+CC implementation)

3. The Original Project Proposal - 2008 • Assessment of individual “advanced” (post-OO) modularity mechanisms • Pointcut-advice (e.g., pointcut designators and types of advice) • Intertypes, mixin composition, etc… • Tradeoff: stability vs. error-proneness • Progress – 2008 – 2009: without explicit funding • Partially done for AspectJmechanisms only • Findings, examples: • Programmers introduce more bugs in code when using after advice [ICSE 2010] • Programmers do not introduce more bugs when using pointcut-advice [ICSE 2010] • AspectJ-based code face severe ripple effects when the number of interacting aspects increase [ICSE 2008]  

4. Need for Changing some Project Directions • No longer work on assessment of error-proneness due to the following problems • achieving high test coverage (>80%) in medium-sized systems is very time-consuming • faced problems in using testing tools with AspectJ • e.g. these tools need to inject instrumentation code in the application being tested • expectation for statistically-relevant results is higher • Replaced error-proneness with reuse • easier to measure than error-proneness • the reasons are…

5. Why stability vs. reuse? • Sources of inspiration for this “tradeoff” analysis • most AOP studies focus on one quality attribute • ideally, software maintainability should satisfy bothreuse and stability [1] • our experience has shown that reusing (AspectJ) aspects is very hard: e.g. many modifications in abstract aspects implementing design patterns • stability and reuse are key requirements for systems that are strategic to organizations • Libraries, product lines, etc… [1] Mohagheghi, Conradi, Killi, Schwarz: An Empirical Study of Software Reuse vs. Defect-Density and Stability. ICSE 2004: 282-292 Francisco Dantas et. al @ OPUS Group

6. Why stability vs. reuse? • ICSE paper [1] : analysis of OO systems – abstract (reusable) classes were more stable • Is this always true with advanced modularization languages? • They are complementary and their simultaneous achievement should be maximized: • stability measures can help us to compute the effort to realize the reuse of a module • E.g. a severe instability (e.g. interface modification) is an indicator that reusing the module was hard • are always abstract modules (using a programming technique) more stable (than using others)? • E.g. abstract aspects vs. abstract composition filters

7. Goals: assessing stability and reuse • General • Provide the means to empirically understand the impact of contemporary modularisation mechanisms on program stability and reuse • Specifics • Executionofempiricalstudies to perform a multi-criteria assessment of contemporary modularity mechanisms • Acquired knowledge will be documented in the form of best design/programming practices

8. Specific Directions for our Study? • Some alternatives 1. What is the impact of different module decompositions on stability and reuse of pointcuts (or module interfaces)? • different decompositions = those yielded by specific programming techniques (CaesarJ, Compose*, EJPs, etc…) • does “CaesarJ-based design” improve stability and reuse of pointcuts (and/or module interfaces)? 2. Take some of your claims about CaesarJ mechanisms – that somehow are related to stability and reuse – and test them • by comparing with other techniques, such as: Compose*

9. Specific Directions for our Study? 3. Take some of our previous findings about AspectJ stability problems and replicate the empirical tests with CaesarJ • now also considering reuse… • compare with AspectJ and/or other techniques, such as: Compose* • e.g. are CaesarJ implementations more stable and reusable in the presence of aspect interactions 4. Take some of Apel’s findings about the advantages of AspectualMixinLayers and test it in CaesarJ • problems: • we need to grasp AspectualMixinLayers • not sure if we will be able to use his technique, compiler, etc… • his claims were not exactly related to reuse and/or stability What do you think? Which suits best? Other suggestions?

10. Vaidas (and Mira)’s interests • assessing virtual classes, family polymorphism, pointcuts, interfaces between families in realistic case studies • how often particular features are exploited • how much benefit they bring when used • find limitations of the existing features and… • identify directions for further improvement of the language, or even need for new language features • we think these goals can fit well in all the objectives of the previous slides Francisco Dantas et. al @ OPUS Group

11. Vaidas (and Mira)’s interests • Also consider other languages • ECaesarJ • EScala • How stable their compilers are? Francisco Dantas et. al @ OPUS Group

12. Once we set the goal of the study… • … there are some specific issues to think about: • Does the comparison of CaesarJ against X make sense? • X = Compose*, EJP, etc… • Which applications to use? • Ideally, select applications that we have implementations available already (see next slides for initial candidates) • Which specific metrics/indicators of stability and reuse to use? (see next slides for initial candidates) • Format of the study? • Exploratory study – implementations made by us? • Controlled experiment = involving subjects • Both

13. Initial Applications • Do youhave candidates of applications (partially) implementedalreadywithCaesarJ? • Existingimplementations in Java, AspectJ, XPIs, EJPsandCompose* (*) Initial versions in CaesarJ (**) Just some compositions in Compose*

14. Initial Applications – Why CaesarJ? • Othersuggestions?

15. Candidate Metrics

16. Candidate Metrics • Language-dependent • SeparationofConcerns • Coupling, CohesionandSize • Language-independent • Numberofchanges • Specific Reuse Metrics • Reuse Level (measuring in functionoflinesofcode) • Reuse Density (measuring in functionofreusedparts to the total numberoflinesofcode)

17. AnotherCurrentStudy : Design PatternComposition • Quantitative study that compares aspect-based solutions for the compositions of GoF patterns in AspectJ, Compose* and CaesarJ approaches • Focusing on Stability and Reuse • Developed on the top of OpenOrb Application • Use of the well known AspectJ Idioms in order to implement the patterns: abstract pointcut, template advice and so forth • Are there proposed implementations of design patterns with CaesarJ?

18. AnotherCurrentStudy : Design PatternComposition • CaesarJ bindings can be useful to improve the SoC instead of intertype declarations in design patterns context? • Which are the best candidates of design patterns to be implement in CaesarJ?

19. Study Restrictions and Open Issues • Lackofsupportof CaesarJ to Java genericstypes • Thissupport is availablefrom Java 1.5

20. Assessing Contemporary Modularisation Mechanisms: A Multi-Dimensional Quality Analysis Francisco Dantas | fneto@inf.puc-rio.br Alessandro Gurgel | agurgel@inf.puc-rio.br Alessandro Garcia | afgarcia@inf.puc-rio.br