Fabiano Cutigi Ferrari

Evolving software product lines with aspects: an empirical study on design stability

Software product lines (SPLs) enable modular, large-scale reuse through a software architecture addressing multiple core and varying features. To reap the benefits of SPLs, their designs need to be stable. Design stability encompasses the sustenance of the product lines modularity properties in the presence of changes to both the core and varying features. It is usually assumed that aspect-oriented programming promotes better modularity and changeability of product lines than conventional variability mechanisms, such as conditional compilation. However, there is no empirical evidence on its efficacy to prolong design stability of SPLs through realistic development scenarios. This paper reports a quantitative study that evolves two SPLs to assess various design stability facets of their aspect-oriented implementations. Our investigation focused upon a multi-perspective analysis of the evolving product lines in terms of modularity, change propagation, and feature dependency. We have identified a number of scenarios which positively or negatively affect the architecture stability of aspectual SPLs.

Mutation Testing for Aspect-Oriented Programs

Mutation testing has been shown to be one of the strongest testing criteria for the evaluation of both programs and test suites. Comprehensive sets of mutants require strong test sets to achieve acceptable testing coverage. Moreover, mutation operators are valuable for the evaluation of other testing approaches. Although its importance has been highlighted for aspect-oriented (AO) programs, there is still a need for a suitable set of mutation operators for AO languages. The quality of the mutation testing itself relies on the quality of such operators. This paper presents the design of a set of mutation operators for AspectJ-based programs. These operators model instances of fault types identified in an extensive survey. The fault types and respective operators are grouped according to the related language features. We also discuss the generalisation of the fault types to AO approaches other than AspectJ and the coverage that may be achieved with the application of the proposed operators. In addition, a cost analysis based on two case studies involving real-world applications has provided us feedback on the most expensive operators, which will support the definition of further testing strategies.

An exploratory study of fault-proneness in evolving aspect-oriented programs

This paper presents the results of an exploratory study on the fault-proneness of aspect-oriented programs. We analysed the faults collected from three evolving aspect-oriented systems, all from different application domains. The analysis develops from two different angles. Firstly, we measured the impact of the obliviousness property on the fault-proneness of the evaluated systems. The results show that 40% of reported faults were due to the lack of awareness among base code and aspects. The second analysis regarded the fault-proneness of the main aspect-oriented programming (AOP) mechanisms, namely pointcuts, advices and intertype declarations. The results indicate that these mechanisms present similar fault-proneness when we consider both the overall system and concern-specific implementations. Our findings are reinforced by means of statistical tests. In general, this result contradicts the common intuition stating that the use of pointcut languages is the main source of faults in AOP.

Testing aspect-oriented programming Pointcut Descriptors

Pointcut Descriptors (PCDs) are used to specify sets of program join points with a common property where additional behavior should be applied. If PCDs are wrongly formulated, faults are injected into the program, because additional behavior will be applied to unintended join points or will fail to be applied to intended join points. In this paper we classify the types of faults that can occur in PCDs -- in terms of selected join points -- and present a two-step strategy to: 1) help the tester identifying extra join points selected by PCDs; and 2) help the tester identifying neglected join points that should be selected by PCDs in the first place. We focus on the first step but provide motivating examples and directions for both.

An empirical evaluation of coupling metrics on aspect-oriented programs

Coupling metrics received increased recognition by object-oriented (OO) software developers when they were found to be indicators of important quality attributes, such as fault-proneness. However, there is no consensus on which coupling metrics are effective quality indicators for emerging development paradigms, such as Aspect-Oriented Programming (AOP). AOP aims to improve software quality by providing significantly different decomposition mechanisms, such as pointcut, advice and intertype declarations. Therefore, it is not obvious if quality indicators for AOP can be derived from direct extensions of classical OO metrics. However, empirical studies of AOP do often rely on classical coupling metrics. Despite the recent adoption of AOP in industrial projects, coupling metrics have been rarely evaluated as useful indicators of fault-proneness in this context. This paper analyses the effectiveness of coupling metrics as indicators of fault-proneness in aspect-oriented (AO) systems. We collected faults from several releases of a real-world AO system. We applied and compared existing metrics for coupling and other internal attributes. We have also considered a novel metric that quantifies specific dependencies in AO software not captured by existing metrics. The results show that coupling metrics, which are not directives of object-oriented metrics, tended to be superior indicators of fault-proneness.

Automating the mutation testing of aspect-oriented Java programs

Aspect-Oriented Programming has introduced new types of software faults that may be systematically tackled with mutation testing. However, such testing approach requires adequate tooling support in order to be properly performed. This paper addresses this issue, introducing a novel tool named Proteum/AJ. Proteum/AJ realises a set of requirements for mutation-based testing tools and overcomes some limitations identified in previous tools for aspect-oriented programs. Through an example, we show how Proteum/AJ was designed to support the main steps of mutation testing. This preliminary use of the tool in a full test cycle provided evidences of the feasibility of using it in real software development processes and helped us to reason about the current functionalities and to identify future needs.

An aspect-oriented reference architecture for Software Engineering Environments

Abstract: Reusable and evolvable Software Engineering Environments (SEEs) are essential to software production and have increasingly become a need. In another perspective, software architectures and reference architectures have played a significant role in determining the success of software systems. In this paper we present a reference architecture for SEEs, named RefASSET, which is based on concepts coming from the aspect-oriented approach. This architecture is specialized to the software testing domain and the development of tools for that domain is discussed. This and other case studies have pointed out that the use of aspects in RefASSET provides a better Separation of Concerns, resulting in reusable and evolvable SEEs.

The Impact of Coupling on the Fault-Proneness of Aspect-Oriented Programs: An Empirical Study

Coupling in software applications is often used as an indicator of external quality attributes such as fault-proneness. In fact, the correlation of coupling metrics and faults in object oriented programs has been widely studied. However, there is very limited knowledge about which coupling properties in aspect-oriented programming (AOP) are effective indicators of faults in modules. Existing coupling metrics do not take into account the specificities of AOP mechanisms. As a result, these metrics are unlikely to provide optimal predictions of pivotal quality attributes such as fault-proneness. This impacts further by restraining the assessments of AOP empirical studies. To address these issues, this paper presents an empirical study to evaluate the impact of coupling sourced from AOP-specific mechanisms. We utilise a novel set of coupling metrics to predict fault occurrences in aspect-oriented programs. We also compare these new metrics against previously proposed metrics for AOP. More specifically, we analyse faults from several releases of three AspectJ applications and perform statistical analyses to reveal the effectiveness of these metrics when predicting faults. Our study shows that a particular set of fine-grained directed coupling metrics have the potential to help create better fault prediction models for AO programs.

Development of auxiliary functions: should you be agile? an empirical assessment of pair programming and test-first programming

A considerable part of software systems is comprised of functions that support the main modules, such as array or string manipulation and basic math computation. These auxiliary functions are usually considered less complex, and thus tend to receive less attention from developers. However, failures in these functions might propagate to more critical modules, thereby affecting the systems overall reliability. Given the complementary role of auxiliary functions, a question that arises is whether agile practices, such as pair programming and test-first programming, can improve their correctness without affecting time-to-market. This paper presents an empirical assessment comparing the application of these agile practices with more traditional approaches. Our study comprises independent experiments of pair versus solo programming, and test-first versus test-last programming. The first study involved 85 novice programmers who applied both traditional and agile approaches in the development of six auxiliary functions within three different domains. Our results suggest that the agile practices might bring benefits in this context. In particular, pair programmers delivered correct implementations much more often, and test-first programming encouraged the production of larger and higher coverage test sets. On the downside, the main experiment showed that both practices significantly increase total development time. A replication of the test-first experiment with professional developers shows similar results.

Characterising Faults in Aspect-Oriented Programs: Towards Filling the Gap Between Theory and Practice

Since the proposal of Aspect-Oriented Programming, several candidate fault taxonomies for aspect-oriented (AO) software have been proposed. Such taxonomies, however, generally rely on language features, hence still requiring practical evaluation based on realistic implementation scenarios. The current lack of available AO systems for evaluation as well as historical data are the two major obstacles for this kind of study. This paper quantifies, documents and classifies faults uncovered in several releases of three AO systems, all from different application domains. Our empirical analysis naturally led us to revisit and refine a previously defined fault taxonomy. We identified particular fault types that stood out amongst the categories defined in the taxonomy. Besides this, we illustrate recurring faulty scenarios extracted from the analysed systems. We believe such scenarios should be considered for the establishment of testing strategies along the software development process.