Avoiding Code Pitfalls in Aspect-Oriented Programming

Alves, Péricles; Figueiredo, Eduardo; Ferrari, Fabiano Cutigi

doi:10.1007/978-3-319-11863-5_3

Cited by 2 publications

(3 citation statements)

References 24 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Reuse (Long, 2001) Architecture (Garcia et al, 2009), Design (Suryanarayanaet al, 2014, Aspect-Oriented (Alves et al, 2014) Table 1 summarizes the accumulation of 14 categories identified by (Sharma and Spinellis, 2018) into the 7 consolidated ones. Considering the space constraints of the article, the description about the chosen categories can be understood using respective references.…”

Section: IIImentioning

confidence: 99%

Resource Allocation Modeling Framework to Refactor Software Design Smells

Gupta

Anand

Mellal

2023

Int. j. math. eng. manag. sci.

View full text Add to dashboard Cite

The domain to study design flaws in the software environment has created enough opportunity for the researchers. These design flaws i.e., code smells, were seen hindering the quality aspects of the software in many ways. Once detected, the segment of the software which was found to be infected with such a flaw has to be passed through some refactoring steps in order to remove it. To know about their working phenomenon in a better way, authors have innovatively talked about the smell detection mechanism using the NHPP modeling framework. Further the authors have also chosen to investigate about the amount of resources/efforts which should be allotted to various code smell categories. The authors have developed an optimization problem for the said purpose which is being validated on the real-life smell data set belonging to an open-source software system. The obtained results are in acceptable range and are justifying the applicability of the model.

show abstract

Section: IIImentioning

confidence: 99%

Resource Allocation Modeling Framework to Refactor Software Design Smells

Gupta

Anand

Mellal

2023

Int. j. math. eng. manag. sci.

View full text Add to dashboard Cite

show abstract

“…As discussed in section 'Introduction', AOP is typically applied to refactor existing systems to achieve better modularisation of crosscutting concerns [2,[33][34][35][36]. Given this scenario of AOP adoption, our recent work investigated the difficulty of testing AO and OO programs, in particular when there is a migration from one paradigm to the other.…”

Section: Reuse-centred Viewpoint Analysismentioning

confidence: 99%

“…From our experience and observations, when adopted, AOP is applied to refactor existing objectoriented (OO) systems to achieve better modularisation of behaviour that appears intertwined or spread across the system modules (these are the so-called crosscutting concerns [32]). Examples of AOP applied in this context can be found in the work of van Deursen et al [2], Mortensen et al [33], Ferrari et al [34] and Alves et al [35,36], not limited to particular technologies such as Java and AspectJ.…”

Section: Introductionmentioning

confidence: 99%

Testing of aspect-oriented programs: difficulties and lessons learned based on theoretical and practical experience

et al. 2015

View full text Add to dashboard Cite

Background: Since the first discussions of new challenges posed by aspect-oriented programming (AOP) to software testing, the real difficulties of testing aspect-oriented (AO) programs have not been properly analysed. Firstly, despite the customisation of traditional testing techniques to the AOP context, the literature lacks discussions on how hard it is to apply them to (even ordinary) AO programs based on practical experience. Secondly, and equally important, due to the cautious AOP adoption focused on concern refactoring, test reuse is another relevant issue that has been overlooked so far. This paper deals with these two issues. It discusses the difficulties of testing AO programs from three perspectives: (i) structural-based testing, (ii) fault-based testing and (iii) test set reuse across paradigms. Methods: Perspectives (i) and (ii) are addressed by means of a retrospective of research done by the authors' group. We analyse the impact of using AOP mechanisms on the testability of programs in terms of the underlying test models, the derived test requirements and the coverage of such requirements. The discussion is based on our experience on developing and applying testing approaches and tools to AspectJ programs at both unit and integration levels. Perspective (iii), on the other hand, consists of recent exploratory studies that analyse the effort to adapt test sets for refactored systems and the quality of such test sets in terms of structural coverage. Results: Building test models for AO programs imposes higher complexity when compared to the OO paradigm. Besides this, adapting test suites for OO programs to AO equivalent programs tends to require less effort than doing the other way around, and resulting suites achieve similar quality levels for small-sized aplications. Conclusions: The conclusion is that building test models for AO programs, as well as deriving and covering paradigm-specific test requirements, is not straightforward as it has been for procedural and object-oriented (OO) programs at some extent. Once you have test suites in conformance with programs implemented in both paradigms, the quality of such suited in termos of code coverage may vary depending on the size and characteristics of the applications under testing.

show abstract

Avoiding Code Pitfalls in Aspect-Oriented Programming

Cited by 2 publications

References 24 publications

Resource Allocation Modeling Framework to Refactor Software Design Smells

Resource Allocation Modeling Framework to Refactor Software Design Smells

Testing of aspect-oriented programs: difficulties and lessons learned based on theoretical and practical experience

Contact Info

Product

Resources

About