This paper is presented with assistance from the John Jenkins Memorial Fund of the Reengineering Forum (REF). Abstract — Over a decade ago, aspect-oriented programming (AOP) was proposed in the literature to “modularize the unmodularizable”. 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. AOP, separation of concerns, software modularity I.

Abstract—Aspect-oriented programming (AOP) is rapidly gaining popularity among research and industry as a methodology that complements and extends the object-oriented paradigm.AOP promises to localize the concerns that inherently crosscut the primary structural decomposition of a software system. Localization of concerns is critical to parallel development, maintainability, modular reasoning and program understanding. However, AOP as it stands today is bringing problems in exactly these areas, defeating its purpose. Previous work and experience gleaned from building AOP systems have identified two points of contention that are impeding the adoption of AOP. First, the complication arising from the need to open up systems modules for AOP and the need to protect those modules against possible fault injection by AOP. Second, the need to have base system components stabilized before aspect components can be developed. Clearly, this adversely affects parallel development. This dependency also causes aspect components to be sensitive to changes in the base system, complicating maintainability, already a high-cost element in the software process. In this review paper, we argue that the AOP provides better modularity and here main focus is to assess the solution that affords better modularity to AOP systems.

Aspect-oriented programming (AOP) promises to localize concerns that inherently crosscut the primary structural decomposition of a software system. Localization of concerns is critical to parallel development, maintainability, modular reasoning, and program understanding. However, AOP as it stands today causes problems in exactly these areas, defeating its purpose and impeding its adoption. First, the need to open up systems ’ modules for aspects ’ interaction competes with the need to protect those modules against possible fault injection by aspects. Second, since aspects are written in terms of base code interfaces, base system components must be stable before aspect components can be developed. This dependency hinders parallel development. This work proposes a language-based solution that allows base code classes to regulate aspect invasiveness, and provides loose coupling of aspects and base code.

Strictly enforced encapsulation is a key concept for modular software designs. However, in many situations like unanticipated reuse, productivity can be raised by a more flexible approach to encapsulation. Also the discussion about the role of “obliviousness ” in aspect-oriented programming is one instance of a general conflict between strictness and flexibility. Here, different technologies take different stands and the choice of a particular technology locks a project into prioritizing one side over the other. In this paper we suggest that this choice should not be determined by technology but technology should support the co-existence of encapsulation and its inverse — decapsulation — within a single system. We postulate four principles that define a solution space, called “gradual encapsulation”, in which each project should find the best fitting balance between encapsulation and decapsulation with the option to shift this balance during the life time of a system. We use the programming language ObjectTeams/Java for illustrating how encapsulation and decapsulation can be supported by technology and how the four principles can be implemented on top of such technology. 1