AspectJ Language Research Papers - Academia.edu (original) (raw)

Modularity is the single attribute of software that allows a program to be intellectually manageable [29]. The recipe for modularizing is to define a narrow interface, hide an implementation detail, keep low coupling and high cohesion. Over a decade ago, aspect-oriented programming (AOP) was proposed in the literature to "modularize the un-modularizable" [24]. Since then, aspect-oriented languages have been providing new abstraction and composition mechanisms to deal with concerns that could not be modularized because of the limited abstractions of the underlying programming language. This paper is a continuation of our earlier work [32] and further investigates AO software with regard to coupling and cohesion. We compare two versions (Java and AspectJ) of ten applications to review AOP within the context of software modularity. It turns out that the claim that "the software built in AOP is more modular than the software built in OOP" is a myth.

- by
- •
- AOP, AspectJ, AspectJ Language, AOSD/AOP Metrics as per ISO/IEC 9126 stabdard
- by Adão Gonçalves
- •
- Aspect-Oriented Programming, Java Programming, AspectJ, AspectJ Language

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.

- by Adam Przybylek
- •
- Software Maintenance, Software Evolution, AOP, AspectJ

Implementing crosscutting concerns for transactions is difficult, even using Aspect-Oriented
Programming Languages (AOPLs) such as AspectJ. Many of these challenges arise because the context of a
transaction-related crosscutting concern consists of loosely-coupled abstractions like dynamically-generated
identifiers, timestamps, and tentative value sets of distributed resources. Current AOPLs do not provide
joinpoints and pointcuts for weaving advice into high-level abstractions or contexts, like transaction contexts.
Other challenges stem from the essential complexity in the nature of the data, operations on the data, or the
volume of data, and accidental complexity comes from the way that the problem is being solved, even using
common transaction frameworks. This dissertation describes an extension to AspectJ, called TransJ, with
which developers can implement transaction-related crosscutting concerns in cohesive and loosely-coupled
aspects. It also presents a preliminary experiment that provides evidence of improvement in reusability
without sacrificing the performance of applications requiring essential transactions. This empirical study is
conducted using the extended-quality model for transactional application to define measurements on the
transaction software systems. This quality model defines three goals: the first relates to code quality (in terms
of its reusability); the second to software performance; and the third concerns software development
efficiency. Results from this study show that TransJ can improve the reusability while maintaining
performance of TransJ applications requiring transaction for all eight areas addressed by the hypotheses:
better encapsulation and separation of concern; loose Coupling, higher-cohesion and less tangling; improving
obliviousness; preserving the software efficiency; improving extensibility; and hasten the development
process.

- by Anas Alsobeh and +1
- •
- Software Engineering, Object Oriented Programming, Quality Management, Transactional Analysis

Abstract: Implementing crosscutting concerns for transactions is difficult, even using aspect-oriented programming languages such
as AspectJ. Many of these challenges arise because the context of a transaction-related crosscutting concern consists of
loosely-coupled abstractions like dynamically-generated identifiers, timestamps, and tentative value sets of distributed resources.
Current aspect-oriented programming languages do not provide joinpoints and pointcuts for weaving advice into high-level
abstractions or contexts, like transaction contexts. To address these problems, we propose an extension to AspectJ framework, called
TransJ, that allows developers to define pointcuts in terms of transaction abstractions and that automatically keeps track of context
information for transactions. This paper describes TransJ as an abstract independent framework for weaving crosscutting concerns
into high-level runtime abstractions, with which developers can implement transaction-related crosscutting concerns in modular,
cohesive and loosely coupled transaction-aware aspects. Finally, this paper presents eight different ways in which TransJ can
improve the reuse with preserving the performance of applications requiring transactions. Informally, these hypotheses are that
TransJ yields (1) better encapsulation and separation of concern; (2) looser coupling and less scattering; (3) higher cohesion and less
tangling; (4) reduces complexity; (5) improves obliviousness; (6) preserves efficiency; (7) improves extensibility; and (8) hastens the
productivity. A brief discussion of experiment to test the hypotheses is provided, but the details of the experiment are left for another
paper.

- by Anas Alsobeh and +1
- •
- Software Engineering, Object Oriented Programming, Transactional Analysis, Software Development

Over a decade ago, aspect-oriented programming (AOP) was proposed to “modularize the un-modularizable”. 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. However, every new paradigm makes claims that managers want to hear. The aim of this PhD dissertation is to find out how much of what has been written about AOP is true and how much is hype.

- by Adam Przybylek
- •
- Software Evolution, AOP, AspectJ, AspectJ Language

Aspect-oriented programming (AOP) emerged as a paradigm to modularize the concerns that lead to interwoven code if implemented using traditional programming techniques. Unfortunately, the new constructs introduced by aspect-oriented (AO) languages result in both: (1) obstacles in modular reasoning; and (2) high coupling between aspects and the augmented modules. There have been numerous attempts to tackle these issues, but none have succeeded without sacrificing obliviousness or losing the power of AOP. In this paper, we propose a new approach to AOP inspired by the classification of aspects by Clifton & Leavens. Our approach reduces coupling in AO programs and restores modular reasoning in case when the aspects are spectators.

- by Adam Przybylek
- •
- Modular Systems (Architecture), AOP, AspectJ, AspectJ Language

Abstract—A 2013 ICSEA paper introduced CommJ as an
extension to AspectJ for encapsulating communication-related
crosscutting concerns in modular, conversation-aware aspects.
This paper now presents preliminary, but encouraging results
from a subsequent study that shows six different ways in which
CommJ can improve the reusability and maintainability of
applications requiring network communications. We begin by
defining a reuse and maintenance quality model as an
extension to an existing quality model. We then identify six
hypotheses that can be measured using metrics from the
quality model. Finally, to test the hypotheses, we compare
implementations of different sample applications across two
study groups: one for CommJ and another for AspectJ. Results
from the study show improvement in the CommJ for all six
areas addressed by the hypotheses.

- by Jorge Edison Lascano and +1
- •
- Software Maintenance, Software Reuse, Aspect Oriented Software Development, Software Metrics

A 2013 ICSEA paper introduced CommJ as an
extension to AspectJ for encapsulating communication-related
crosscutting concerns in modular, conversation-aware aspects.
This paper now presents preliminary, but encouraging results
from a subsequent study that shows six different ways in which
CommJ can improve the reusability and maintainability of
applications requiring network communications. We begin by
defining a reuse and maintenance quality model as an
extension to an existing quality model. We then identify six
hypotheses that can be measured using metrics from the
quality model. Finally, to test the hypotheses, we compare
implementations of different sample applications across two
study groups: one for CommJ and another for AspectJ. Results
from the study show improvement.

- by Edison Lascano and +1
- •
- Programming Languages, Maintainability, Java Programming, AspectJ Language

A 2013 ICSEA paper introduced CommJ as an extension to AspectJ for encapsulating communication-related crosscutting concerns in modular, conversation-aware aspects. This paper now presents preliminary, but encouraging results from a subsequent study that shows six different ways in which CommJ can improve the reusability and maintainability of applications requiring network communications. We begin by defining a reuse and maintenance quality model as an extension to an existing quality model. We then identify six hypotheses that can be measured using metrics from the quality model. Finally, to test the hypotheses, we compare implementations of different sample applications across two study groups: one for CommJ and another for AspectJ. Results from the study show improvement.

- by Edison Lascano
- •
- Programming Languages, Software Maintenance, Maintainability, Software Reuse