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 case studies and controlled experiments to find out the circumstances, in which AOP improves software modularity, evolvability and reusability.

Schedule:

  • The project started in 2007 and is expected to be completed by 2014.

  • In 2011 a PhD thesis, which summarizes partial results of the research, was submitted.
    Further steps include:
  • Defining a quality model for assessing the modularity of AO systems
  • Refactoring OO programs, that involve lots of crosscutting concerns, to AspectJ / PostSharp / AspectC++
  • Conducting controlled experiments in which both versions (OO and AO) are evolved by introducing maintenance/reuse scenarios
  • Implementing AoUML as an Eclipse plugin
  • Developing the guidelines outlining what is acceptable usage of AOP

Results so far:

  • We have discussed the novel kinds of coupling dependencies introduced by AOP and proposed the CBOAO metric. CBOAO can be applied to AO as well as OO software and generates comparable results. At the same time, we have 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 have compared OO and AO implementations of 11 real-life systems and the 23 GoF design patterns. In only one case we have 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 have 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 have 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.

  • Moreover, we have performed some experiments on software reuse and evolution. Firstly, we have compared OOP with AOP on a small program that undergoes five functionality increments. The superiority of AOP has been observed only when detaching crosscutting concerns and when implementing logging, which is a flagship example of AOP usage. OOP has fared better in implementing crosscutting concerns in three out of four scenarios. The lessons learned from this study are as follows. In a AO system, one cannot tell whether an extension to the base code is safe simply by examining the base program in isolation. All pointcuts referring to the base program need to be examined as well. In addition, when writting a pointcut definition a programer needs a global knowledge about the structure of the application. This is due to the fact that pointcuts try to define intended conceptual properties about the base program, based on structural properties of the program. As a consequence it may lead to the pointcut fragility problem that causes ripple effects during system evolution. In most cases, aspects cannot be made generic, because pointcuts as well as advices encompass information specific to a particular use, such as the classes involved, in the concrete aspect. As a result, aspects are highly dependent on other modules and their reusability is decreased. Futhermore, we have confirmed that the reusability of aspects is also hampered in cases where “join points seem to dynamically jump around”, depending on the context certain code is called from.

  • Secondly, we have explored the existing AO implementations of the GoF patterns according to applying generics and reflective programming. We have 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.

  • Furthermore, we have 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 have improved the traceability from design to implementation by reducing the semantic gap between these development phases. We have used AoUML in our other papers to illustrate the structure of AO programs.

Publications:

  1. 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)
  2. Download PDF (202 kB)

  3. 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)
  4. Download PDF (202 kB)

  5. Przybylek, A. Impact of aspect-oriented programming on software modularity, In: Doctoral Symposium at 15th European Conference on Software Maintenance and Reengineering, Oldenburg, 2011
  6. Download PDF (202 kB)

  7. Przybylek, A. What is wrong with AOP?, In: 5th International Conference on Software and Data Technologies, Athens, 2010
  8. Download PDF (202 kB)

  9. Przybylek, A. Design Patterns with AspectJ, generics, and reflective programming, In: 5th International Conference on Software and Data Technologies, Athens, 2010
  10. Download PDF (202 kB)

  11. 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
  12. Download PDF (202 kB)

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

  15. 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
  16. Download PDF (202 kB)

  17. Przybylek, A. The Decorator pattern revisited: an aspect-oriented solution, In: 7th International Conference on Perspectives in Business Informatics Research, Sopot, 2008
  18. Download PDF (202 kB)

  19. Przybylek, A. Post object-oriented paradigms in software development: a comparative analysis, In: International Multiconference on Computer Science and Information Technology, Wisła, 2007
  20. Download PDF (202 kB)