Mining Coding Patterns to Detect Crosscutting Concerns in Java Programs

Reverse Engineering, 2008. WCRE '08. 15th Working Conference onDate of Conference:15-18 Oct. 2008Conference Location :Antwer

AspectJ bajo la lupa

La dependencia y acoplamiento existente entre aspectos y clases generan un alto impacto cuando se modifica el dominio de una aplicación. Esta situación es propia de aplicaciones que usan aspectos implementados en lenguajes del estilo AspectJ. En estos casos el desarrollador se enfrenta a nuevos dilemas puesto que el comportamiento introducido por los aspectos se ejecuta o deja de ejecutarse sin haber modificado dichos aspectos. La mejor manera de resolver un problema es anticiparse, se convierte en un principio y estrategia que acuñamos para encontrar una posible solución al problema planteado. En este camino, este trabajo propone una solución empírica basada en la herramienta BaLaLu, cuya finalidad es anticipar las consecuencias que un cambio podrá tener en una aplicación que usa aspectos.Eje: Workshop Ingeniería de software (WIS)Red de Universidades con Carreras en Informática (RedUNCI

A Test-Driven Approach to Developing Pointcut Descriptors in AspectJ

International audienceAspect-oriented programming (AOP) languages introduce new constructs that can lead to new types of faults, which must be targeted by testing techniques. In particular, AOP languages such as AspectJ use a pointcut descriptor (PCD) that provides a convenient way to declaratively specify a set of joinpoints in the program where the aspect should be woven. However, a major difficulty when testing that the PCD matches the intended set of joinpoints is the lack of precise specification for this set other than the PCD itself. In this paper, we propose a test-driven approach for the development and validation of the PCD. We developed a tool, AdviceTracer, which enriches the JUnit API with new types of assertions that can be used to specify the expected joinpoints. In order to validate our approach, we also developed a mutation tool that systematically injects faults into PCDs. Using these two tools, we perform experiments to validate that our approach can be applied for specifying expected joinpoints and for detecting faults in the PCD

Specifying design rules in aspect-oriented systems

Programação Orientada a Aspectos é conhecida como uma técnica para modularização de interesses transversais. Entretanto, construções que visam apoiar a modularidade transversal podem quebrar a modularidade de classe. Como consequência, os desenvolvedores de classes enfrentam problemas de modificabilidade, desenvolvimento em paralelo e entendimento, porque precisam estar conscientes da implementação dos aspectos sempre que forem desenvolver ou dar manutenção em uma classe. Ao mesmo tempo, aspectos são vulneráveis a mudanças nas classes, já que não existe um contrato especificando os pontos de interação entre estes elementos. Estes problemas podem ser mitigados através de Regras de Projeto entre classes e aspectos. Nós apresentamos uma linguagem para especificação de Regras de Projeto (LSD) e exploramos seus benefícios desde as fases iniciais do processo de desenvolvimento, especialmente com o objetivo de dar apoio ao desenvolvimento modular de classes e aspectos. Nós discutimos como nossa linguagem melhora a modularidade transversal sem quebrar a modularidade de classe. Além disso, especificamos a semântica da linguagem em Alloy. A linguagem é implementada através de uma extensão do abc (AspectBench Compiler), tornando mais fácil expressar e checar muitas das Regras de Projeto encontradas em sistemas Orientados a Aspectos. Nós avaliamos LSD usando o sistema Health Watcher como estudo de caso e comparamos com abordagens existentes._________________________________________________________________________________________ ABSTRACT: Aspect-Oriented Programming is known as a technique for modularizing crosscutting concerns. However, constructs aimed to support crosscutting modularity might actually break class modularity. As a consequence, class developers face changeability, parallel development and comprehensibility problems, because they must be aware of aspects whenever they develop or maintain a class. At the same time, aspects are vulnerable to changes in classes, since there is no contract specifying the points of interaction amongst these elements. These problems can be mitigated by using adequate Design Rules between classes and aspects. We present a Design Rule specification language (LSD) and explore its benefits since the initial phases of the development process, specially with the aim of supporting modular development of classes and aspects. We discuss how our language improves crosscutting modularity without breaking class modularity. Besides, we specify the language semantics in Alloy. The language is implemented through an extension of abc (AspectBench Compiler), making it easy to express and check most of the Design Rules found in Aspect-Oriented systems. We evaluate the language using the Health Watcher system as case study and compare it with existent approaches

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)

Formal specification-based monitoring, regression testing and aspects

Ph.DDOCTOR OF PHILOSOPH