Improving maintenance in AOP through an interaction specification framework

Munoz, Freddy; Baudry, Benoît; Barais, Olivier

doi:10.1109/icsm.2008.4658056

Cited by 11 publications

(19 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Thus, it seems that the abstractions that AOP has provided to solve some of the evolution problems with traditional software, actually introduce a series of new evolution problems. This phenomenon has been called the evolution paradox of AOP [39], [28].…”

Section: Discussionmentioning

confidence: 99%

See 1 more Smart Citation

Systems Evolution and Software Reuse in Object-Oriented Programming and Aspect-Oriented Programming

Przybyłek

2011

Objects, Models, Components, Patterns

View full text Add to dashboard Cite

Abstract. Every new programming technique makes claims that software engineers want to hear. Such is the case with aspect-oriented programming (AOP). This paper describes a quasi-controlled experiment which compares the evolution of two functionally equivalent programs, developed in two different paradigms. The aim of the study is to explore the claims that software developed with aspect-oriented languages is easier to maintain and reuse than this developed with object-oriented languages. We have found no evidence to support these claims.

show abstract

Section: Discussionmentioning

confidence: 99%

“…Munoz et al [28] showed that aspects offer efficient mechanisms to implement crosscutting concerns, but that aspects can also introduce complex errors in case of evolution. To illustrate these issues, they implemented and then evolved a chat application.…”

Section: Related Workmentioning

confidence: 99%

Systems Evolution and Software Reuse in Object-Oriented Programming and Aspect-Oriented Programming

Przybyłek

2011

Objects, Models, Components, Patterns

View full text Add to dashboard Cite

show abstract

“…Moreover, the quantification and obliviousness properties of AO languages, which are the very advantage offered by AOP, turned out to be a source of difficulties for reasoning about the behavior of AO programs (Griswold et al 2006;Munoz et al 2008). Since aspects can modify data structures or control flow in non-local places, they undermine a programmer's ability to reason locally about the behavior of the module (Dantas and Walker 2006).…”

Section: Motivationsmentioning

confidence: 99%

“…The resulting feature code was hard to understand and maintain due to strong and implicit coupling and fragile pointcuts. Munoz et al (2008) showed that aspects offer efficient mechanisms to implement crosscutting concerns, but that aspects can also introduce complex errors in case of evolution. To illustrate these issues, they implemented and then evolved a chat application.…”

Section: Other Studiesmentioning

confidence: 99%

See 1 more Smart Citation

An empirical study on the impact of AspectJ on software evolvability

Przybyłek

2017

Empir Software Eng

View full text Add to dashboard Cite

Since its inception in 1996, aspect-oriented programming (AOP) has been believed to reduce the effort required to maintain software systems by replacing cross-cutting code with aspects. However, little convincing empirical evidence exists to support this claim, while several studies suggest that AOP brings new obstacles to maintainability. This paper discusses two controlled experiments conducted to evaluate the impact of AspectJ (the most mature and popular aspect-oriented programming language) versus Java on software evolvability. We consider evolvability as the ease with which a software system can be updated to fulfill new requirements. 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 noninvasive 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.Empir Software Eng

show abstract

An approach for testing pointcut descriptors in AspectJ

Delamare

Baudry

Ghosh

et al. 2011

Software Testing Verif & Rel

Self Cite

View full text Add to dashboard Cite

Aspect‐oriented programming (AOP) promises better software quality through enhanced modularity. Crosscutting concerns are encapsulated in separate units called aspects and are introduced at specific points in the base program at compile time or runtime. However, aspect‐oriented mechanisms also introduce new risks for reliability that must be tackled by specific testing techniques in order to fully benefit from the use of AOP. This paper focuses on the pointcut descriptor (PCD) that declares the set of points in the base program's execution where the crosscutting concern must be woven. A fault in the PCD can have a ripple effect and result in many different faults. New behavior may be added in unexpected places, or places where new behavior should be added may be missed. When implementing aspect‐oriented programs with AspectJ, JUnit is most commonly used to test the program. However, JUnit does not offer any mechanism to look for faults specifically located in the PCD. As a consequence, these faults can be detected only through complex test scenarios and side effects that are difficult to trigger and observe. This paper proposes to monitor the execution of advices in an aspect‐oriented program and use this information to build test cases that target faults in PCDs. The AdviceTracer tool has been developed to automatically monitor and store all information related to advice executions. It also offers a set of operations that can be used to check the presence or absence of advices at specific points in the execution. These operations improve the definition of an oracle for PCD test cases. An empirical study is performed to compare JUnit and AdviceTracer for testing PCDs in terms of the complexity of test cases and their ability to detect faults. The study is performed on a Healthwatcher system that has 93 classes and 19 PCDs. It reveals that test cases that use AdviceTracer to test PCDs are easier to write (shorter test cases and written in less time than with JUnit) and detect more faults. Copyright © 2011 John Wiley & Sons, Ltd.

show abstract

Improving maintenance in AOP through an interaction specification framework

Cited by 11 publications

References 9 publications

Systems Evolution and Software Reuse in Object-Oriented Programming and Aspect-Oriented Programming

Systems Evolution and Software Reuse in Object-Oriented Programming and Aspect-Oriented Programming

An empirical study on the impact of AspectJ on software evolvability

An approach for testing pointcut descriptors in AspectJ

Contact Info

Product

Resources

About