Assessment of Aspect-Oriented Software Development

Objectives:

Over a decade ago, aspect-oriented programming (AOP) was proposed [Kiczales et. al., 1997] as a paradigm to implement the concerns that cannot be modularized either in procedural programming or in OOP because of the limited abstractions of the underlying programming languages. Nowadays, the aspect-oriented paradigm pervades all areas of software engineering. With its growing popularity, practitioners are beginning to wonder whether they should start looking into it. The aim of this project is to investigate the impact of AOP on software modularity, evolvability and reusability in comparison to OOP.

Contact:

The contact for this research project is here.

PhD Thesis:

The research project has been partially summarized in a PhD thesis submitted to the Gdansk University of Technology in 2011.

Adam Przybyłek:
"Analysis of the impact of aspect oriented programming on source code quality"
(The Polish title: "Analiza wpływu paradygmatu aspektowego na jakość kodu źródłowego”)
Download PDF (2.7 MB)

Rationale:

After over a decade of research, AOP is still an active topic of discussion in the research community. On the one hand, AOP is glorified and considered as a milestone in programming language development:

  • AOP offers a way to separate concerns and to ensure a good modularization [Guyomarc'h et al., 2005];

  • AOP is a programming paradigm that increases modularity” [Hovsepyan et al., 2010];

  • Given the power of AspectJ to modularize the un-modularizable, I think it’s worth using immediately” [Lesicki, 2002];

  • AO software “is supposed to be easy to maintain, reuse, and evolution” [Zhao, 2004];

  • AOP “increases understandability and eases the maintenance burden, because modules tend to be more cohesive and less coupled” [Lemos et. al., 2006].

On the other hand, “disciples of Dijkstra” believe that “AO programs are ticking time bombs, which, if widely deployed, are bound to cause the software industry irreparable harm” [Dantas & Walker, 2006]. However, both viewpoints are not backed up by empirical evidence.

In addition, some significant vendors of software like IBM, Motorola, Siemens, and SAP are interested in understanding, evaluating, and applying aspect-oriented techniques. SAP scientists presented a road map to adopting AO Software Development at SAP for productive use [Pohl et al., 2008]. Siemens developed a large-scale hospital information system (Soarian) that supports seamless access to patient medical records and the definition of workflows for health provider organizations. Aspect were used to implement architecture validation, caching, auditing, and performance monitoring [Rashid et al., 2010].

Approach:

Several studies [Figueiredo et. al., 2008; Filho et. al., 2006; Garcia et. al., 2005; Greenwood et. al., 2007; Sant’Anna et. al., 2003; Soares et. al., 2002] suggest that AOP is successful in modularizing crosscutting concerns. Unfortunately, these studies either are based on intuition and gut feelings, rather than scientific evidence; or wrongly identify modularization with the lexical separation of concerns offered by AOP; or wrongly measure coupling in AO systems. Moreover, many unsupported claims have been made about the impact of AOP on software maintainability and reusability. In this project, we are going to conduct controlled experiments to find out the circumstances, in which AOP improves software modularity, evolvability and reusability.

Schedule:

  • The project started in 2007.

  • In 2011 a PhD thesis, which summarizes partial results of the research, was submitted.

  • In 2012 the project received funding from the Institute of Computer Science, Polish Academy of Sciences.

  • The project was finished in 2017 due to declining interest in AOP in the software engineering community.

Results:

  • We discussed the novel kinds of coupling dependencies introduced by AOP and proposed a coupling metric that is an aspect-oriented counterpart to CBO. Our metric can be applied to AO as well as OO software and generates comparable results. At the same time, we argued that since the existing coupling metrics for AOP do not cover all the possible kinds of coupling dependencies, the results obtained with these metrics are underestimated. To know the real results, we have re-evaluated the existing systems. We compared OO and AO implementations of 11 real-life systems and the 23 GoF design patterns. In only one case we found evidence that the AO implementation results in lower coupling than its OO counterpart. Since our metrics do not cover all aspects of software modularity, we also surveyed other criteria and found that AOP is fundamentally at odds with the basic principles on which software engineering has depended for the last 50 years. We found that AOP: promotes unstructured programming, breaks information hiding, leaves interfaces implicit, makes modular reasoning difficult, breaks the contract between a base module and its clients, escalates coupling.

  • We conducted two experiments to evaluate the impact of AspectJ versus Java on software evolvability. Since a minor language was compared to the mainstream, the experiments were designed so as to anticipate that the participants were much more experienced in one of the treatments. The first experiment was performed on 35 student subjects who were asked to comprehend either Java or AspectJ implementation of the same system, and perform the corresponding comprehension tasks. Participants of both groups achieved a high rate of correct answers without a statistically significant difference between the groups. Nevertheless, the Java group significantly outperformed the AspectJ group with respect to the average completion time. In the second experiment, 24 student subjects were asked to implement (in a non-invasive way) two extension scenarios to the system that they had already known. Each subject evolved either the Java version using Java or the AspectJ version using AspectJ. We found out that a typical AspectJ programmer needs significantly fewer atomic changes to implement the change scenarios than a typical Java programmer, but we did not observe a significant difference in completion time. The overall result indicates that AspectJ has a different effect on two sub-characteristics of the evolvability: understandability and changeability. While AspectJ decreases the former, it improves one aspect of the latter.

  • We explored the existing AO implementations of the GoF patterns according to applying generics and reflective programming. We found that Decorator and Proxy are suitable to use with generics, while Prototype is suitable to use with reflection. In each case, the applied programming techniques enhanced reusability of not only the application core part but also the design pattern part. Moreover our solutions make an application independent of the design patterns which can be plugged or unplugged depending on the presence or absence of aspects.

  • We presented an approach to integrate aspect orientation with the current state-of-the-art in modelling languages. The elaborated metamodel (AoUML) enriches UML with constructs for visualizing aspects. Thus, we improved the traceability from design to implementation by reducing the semantic gap between these development phases. We used AoUML in our other papers to illustrate the structure of AO programs.

Publications:

  1. Przybylek, A. An empirical study on the impact of AspectJ on software evolvability, In: Empirical Software Engineering
  2. Download PDF

  3. Przybylek, A. Quasi-controlled Experimentations on the Impact of AOP on Software Comprehensibility, In: 17th European Conference on Software Maintenance and Reengineering, Genova, 2013
  4. Download PDF

  5. Przybylek, A. Analysis of the impact of AOP on source code quality (PhD thesis), In: LAP LAMBERT, 2012
  6. Download PDF

  7. Przybylek, A. Systems Evolution and Software Reuse in Object-Oriented Programming and Aspect-Oriented Programming, In: Bishop, J., Vallecillo, A. (eds.): TOOLS 2011. LNCS 6705, pp. 163-178. Springer, Heidelberg (2011)
  8. Download PDF

  9. Przybylek, A. Where the truth lies: AOP and its impact on software modularity, In: Giannakopoulou, D., Orejas, F. (eds.): ETAPS 2011. LNCS 6603, pp. 447-461. Springer, Heidelberg (2011)
  10. Download PDF

  11. Przybylek, A. Impact of aspect-oriented programming on software modularity, In: Doctoral Symposium at 15th European Conference on Software Maintenance and Reengineering, Oldenburg, 2011
  12. Download PDF

  13. Przybylek, A. What is wrong with AOP?, In: 5th International Conference on Software and Data Technologies, Athens, 2010
  14. Download PDF

  15. Przybylek, A. Design Patterns with AspectJ, generics, and reflective programming, In: 5th International Conference on Software and Data Technologies, Athens, 2010
  16. Download PDF

  17. Przybylek, A. An empirical assessment of the impact of AOP on software modularity, In: 5th International Conference on Evaluation of Novel Approaches to Software Engineering, Athens, 2010
  18. Download PDF

  19. Przybylek, A. Beyond object-oriented software development, In: (eds.) Hussain, M.A.: Advances in Computer Science and IT, In-Tech, 2009
  20. Download PDF

  21. Przybylek, A. Separation of crosscutting concerns at the design level: An extension to the UML metamodel, In: International Multiconference on Computer Science and Information Technology, Wisła, 2008
  22. Download PDF

  23. Przybylek, A. The Decorator pattern revisited: an aspect-oriented solution, In: 7th International Conference on Perspectives in Business Informatics Research, Sopot, 2008
  24. Download PDF

  25. Przybylek, A. Post object-oriented paradigms in software development: a comparative analysis, In: International Multiconference on Computer Science and Information Technology, Wisła, 2007
  26. Download PDF