Detecting broken pointcuts using structural commonality and degree of interest

Pointcut fragility is a well-documented problem in Aspect-Oriented Programming; changes to the base-code can lead to join points incorrectly falling in or out of the scope of pointcuts. Deciding which pointcuts have broken due to base-code changes is a daunting venture, especially in large and complex systems. We present an automated approach that recommends pointcuts that are likely to require modification due to a particular base-code change, as well as ones that do not. Our hypothesis is that join points selected by a pointcut exhibit common structural characteristics. Patterns describing such commonality are used to recommend pointcuts that have potentially broken with a degree of confidence as the developer is typing. The approach is implemented as an extension to the popular Mylyn Eclipse IDE plug-in, which maintains focused contexts of entities relevant to the task at hand using a Degree of Interest (DOI) model. We show that it is accurate in revealing broken pointcuts by applying it to multiple versions of several open source projects and evaluating the quality of the recommendations produced against actual modifications. We found that our tool made broken pointcuts 2.14 times more interesting in the DOI model than unbroken ones, with a p-value under 0.1, indicating a significant difference in final DOI value between the two kinds of pointcuts (i.e., broken and unbroken)

Detecting Broken Pointcuts using Structural Commonality and Degree of Interest

Pointcut fragility is a well-documented problem in Aspect-Oriented Programming; changes to the base code can lead to join points incorrectly falling in or out of the scope of pointcuts. Deciding which pointcuts have broken due to base-code changes is daunting, especially in large and complex systems. We present an automated approach that recommends pointcuts that are likely to require modification due to a certain base-code change and ones that do not. Our hypothesis is that join points selected by a pointcut exhibit common structural characteristics. Patterns describing such commonalities recommend pointcuts that have potentially broken to the developer. The approach is implemented as an extension to the popular Mylyn Eclipse IDE plug-in, which maintains focused contexts of entities relevant to the task at hand using a Degree of Interest (DOI) model

Fraglight:shedding light on broken pointcuts in evolving aspect-oriented software

Pointcut fragility is a well-documented problem in Aspect-Oriented Programming; changes to the base-code can lead to join points incorrectly falling in or out of the scope of pointcuts. Deciding which pointcuts have broken due to base-code changes is a daunting venture, especially in large and complex systems. We demonstrate an automated tool called FRAGLIGHT that recommends a set of pointcuts that are likely to require modification due to a particular base-code change. The underlying approach is rooted in harnessing unique and arbitrarily deep structural commonality between program elements corresponding to join points selected by a pointcut in a particular software version. Patterns describing such commonality are used to recommend pointcuts that have potentially broken with a degree of confidence as the developer is typing. Our tool is implemented as an extension to the Mylyn Eclipse IDE plug-in, which maintains focused contexts of entities relevant to a task

Fraglight: Shedding Light on Broken Pointcuts in Evolving Aspect-oriented Software

Pointcut fragility is a well-documented problem in Aspect-Oriented Programming; changes to the base code can lead to join points incorrectly falling in or out of the scope of pointcuts. Deciding which pointcuts have broken due to base-code changes is daunting, especially in large and complex systems. We demonstrate an automated tool called FRAGLIGHT that recommends a set of pointcuts that are likely to require modification due to a certain base-code change. The underlying approach is rooted in harnessing unique and arbitrarily deep structural commonality between program elements corresponding to join points selected by a pointcut in a particular software version. Patterns describing such commonality are used to recommend pointcuts that have potentially broken with a degree of confidence as the developer is typing. Our tool is implemented as an extension to the Mylyn Eclipse IDE plug-in, which maintains focused contexts of entities relevant to a task

Early aspects: aspect-oriented requirements engineering and architecture design

This paper reports on the third Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design Workshop, which has been held in Lancaster, UK, on March 21, 2004. The workshop included a presentation session and working sessions in which the particular topics on early aspects were discussed. The primary goal of the workshop was to focus on challenges to defining methodical software development processes for aspects from early on in the software life cycle and explore the potential of proposed methods and techniques to scale up to industrial applications

Refactorings to evolve object-oriented systems with aspect-oriented concepts

Tese de doutoramento em Informática.Software engineering tools should support complete separation of concerns, by enabling the deployment of each different concern in its own unit of modularity. Unfortunately, current tools and languages – including those supporting the object-oriented programming paradigm – fail to provide a complete and effective support for the separation of all concerns. Undesirable phenomena such as code scattering and code tangling ensue. Aspect-Oriented Programming is a new programming paradigm capable of modularising crosscutting concerns. Aspect-oriented programming complements existing programming paradigms, including object-oriented programming, with constructs that provide a fuller separation of concerns. Refactoring is a technique to restructure program source code in order to improve its underlying design and style while preserving the externally observable behaviour. “Code smells” help to detect inadequate structures and designs, which are then gradually removed through refactoring processes. There is a prospect of aspect-oriented programming becoming a mainstream technology in the near future. This begs the question of how to deal with a large base of object-oriented legacy code when aspect-orientation becomes standard practice. AspectJ's backward compatibility with Java opens the way for refactoring existing Java applications to leverage the concepts and mechanisms of aspects. This requires a prior idea of good style for aspect-oriented source code, something yet to be developed and matured. This thesis contributes to the definition of a new style appropriate to aspect orientation. To this effect, this thesis documents a collection of novel refactorings enabling the extraction of crosscutting concerns from object-oriented legacy source code and the subsequent restructuring of the aspects thus obtained. In addition, this thesis presents a review of traditional object-oriented code smells so they can be used as indicators of latent aspects in object-oriented source code. Finally, this thesis proposes several novel aspect-oriented code smells. We validate the refactorings through an illustrative refactoring process.Idealmente, as ferramentas de engenharia de programas suportariam uma estrita separação de facetas, possibilitando a colocação de cada faceta na sua própria unidade modular. Infelizmente, as actuais ferramentas e linguagens – incluindo as que suportam o paradigma da orientação ao objecto – não conseguem obter uma completa e efectiva separação de todas as facetas. Daí resultam fenómenos indesejáveis tais como a dispersão e emaranhado de texto fonte. A programação orientada ao aspecto é um novo paradigma da programação capaz de modularizar facetas transversais. A orientação ao aspecto complementa os paradigmas existentes, incluindo a orientação ao objecto, com mecanismos que providenciam uma separação de facetas mais completa. A refabricação de programas é uma técnica para reestruturar o texto fonte de um programa no sentido de melhorar a concepção e estilo subjacentes, mantendo o seu comportamento externamente observável. “Maus cheiros” no texto fonte ajudam a detectar estruturas e concepções inadequadas, que são então gradualmente removidos através de processos de refabricação. Existe a perspectiva da orientação ao aspecto ter uma aceitação generalizada no futuro próximo. Coloca-se a questão de como lidar com uma grande base instalada de texto fonte orientado ao objecto legado quando tal acontecer. A compatibilidade retroactiva de AspectJ em relação a Java possibilita a refabricação das aplicações Java existentes de modo a tomarem partido dos conceitos e mecanismos dos aspectos. Porém, isto tem como pressuposto uma ideia clara de bom estilo para o texto fonte orientado ao aspecto, algo que actualmente não existe duma maneira desenvolvida e matura. Esta tese contribui para a caracterização de um novo estilo, apropriado à orientação ao aspecto. Para esse efeito, esta tese documenta uma colecção de refabricações originais através das quais facetas transversais existentes em texto legado orientado ao objecto são extraídas para aspectos, e a posterior reestruturação dos aspectos assim obtidos pode ser realizada. Esta tese apresenta também uma reapreciação dos maus cheiros orientados ao objecto tradicionais no sentido de poderem ser usados na detecção de aspectos latentes no texto fonte orientado ao objecto. Por fim, esta tese propõe diversos maus cheiros originais, orientados ao aspecto. As refabricações são validadas por meio de um processo de refabricação ilustrativo.Programa de Desenvolvimento Educativo para Portugal III (PRODEP III) - (Medida 5 - Acção 5.3 - Eixo 3 - Formação Avançada de Docentes do Ensino Superior).Portable Parallel Computing based on Virtual Machines (PPC-VM) - (PO-SI/CHS/47158/2002).Fundação Luso Americana para o Desenvolvimento (FLAD)

Impact-Analyse für AspectJ - Eine kritische Analyse mit werkzeuggestütztem Ansatz

Aspect-Oriented Programming (AOP) has been promoted as a solution for modularization problems known as the tyranny of the dominant decomposition in literature. However, when analyzing AOP languages it can be doubted that uncontrolled AOP is indeed a silver bullet. The contributions of the work presented in this thesis are twofold. First, we critically analyze AOP language constructs and their effects on program semantics to sensitize programmers and researchers to resulting problems. We further demonstrate that AOP—as available in AspectJ and similar languages—can easily result in less understandable, less evolvable, and thus error prone code—quite opposite to its claims. Second, we examine how tools relying on both static and dynamic program analysis can help to detect problematical usage of aspect-oriented constructs. We propose to use change impact analysis techniques to both automatically determine the impact of aspects and to deal with AOP system evolution. We further introduce an analysis technique to detect potential semantical issues related to undefined advice precedence. The thesis concludes with an overview of available open source AspectJ systems and an assessment of aspect-oriented programming considering both fundamentals of software engineering and the contents of this thesis

Automated Evolution of Feature Logging Statement Levels Using Git Histories and Degree of Interest

Logging—used for system events and security breaches to more informational yet essential aspects of software features—is pervasive. Given the high transactionality of today’s software, logging effectiveness can be reduced by information overload. Log levels help alleviate this problem by correlating a priority to logs that can be later filtered. As software evolves, however, levels of logs documenting surrounding feature implementations may also require modification as features once deemed important may have decreased in urgency and vice-versa. We present an automated approach that assists developers in evolving levels of such (feature) logs. The approach, based on mining Git histories and manipulating a degree of interest (DOI) model, transforms source code to revitalize feature log levels based on the “interestingness” of the surrounding code. Built upon JGit and Mylyn, the approach is implemented as an Eclipse IDE plug-in and evaluated on 18 Java projects with ~3 million lines of code and ~4K log statements. Our tool successfully analyzes 99.26% of logging statements, increases log level distributions by ~20%, identifies logs manually modified with a recall of ~80% and a level-direction match rate of ~87%, and increases the focus of logs in bug fix contexts ~83% of the time. Moreover, pull (patch) requests were integrated into large and popular open-source projects. The results indicate that the approach is promising in assisting developers in evolving feature log levels

Co-Evolution of Source Code and the Build System: Impact on the Introduction of AOSD in Legacy Systems

Software is omnipresent in our daily lives. As users demand ever more advanced features, software systems have to keep on evolving. In practice, this means that software developers need to adapt the description of a software application. Such a description not only consists of source code written down in a programming language, as a lot of knowledge is hidden in lesser known software development artifacts, like the build system. As its name suggests, the build system is responsible for building an executable program, ready for use, from the source code. There are various indications that the evolution of source code is strongly related to that of the build system. When the source code changes, the build system has to co-evolve to safeguard the ability to build an executable program. A rigid build system on the other hand limits software developers. This phenomenon especially surfaces when drastic changes in the source code are coupled with an inflexible build system, as is the case for the introduction of AOSD technology in legacy systems. AOSD is a young software development approach which enables developers to structure and compose source code in a better way. Legacy systems are old software systems which are still mission-critical, but of which the source code and the build system are no longer fully understood, and which typically make use of old(-fashioned) technology. This PhD dissertation focuses on finding an explanation for this co-evolution of source code and the build system, and on finding developer support to grasp and manage this phenomenon. We postulate four "roots of co-evolution" which represent four different ways in which source code and the build system interact with each other. Based on these roots, we have developed tool and aspect language support to understand and manage co-evolution. The roots and the tool support have been validated in case studies, both in the context of co-evolution in general and of the introduction of AOSD technology in legacy systems. The dissertation experimentally shows that co-evolution indeed is a real problem, but that specific software development and aspect language support enables developers to deal with it