Eduardo Figueiredo

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.

Modularizing design patterns with aspects: a quantitative study

Design patterns offer flexible solutions to common problems in software development. Recent studies have shown that several design patterns involve crosscutting concerns. Unfortunately, object-oriented (OO) abstractions are often not able to modularize those crosscutting concerns, which in turn decrease the system reusability and maintainability. Hence, it is important verifying whether aspect-oriented approaches support improved modularization of crosscutting concerns relative to design patterns. Ideally, quantitative studies should be performed to compare OO and aspect-oriented implementations of classical patterns with respect to important software engineering attributes, such as coupling and cohesion. This paper presents a quantitative study that compares aspect-based and OO solutions for the 23 Gang-of-Four patterns. We have used stringent software engineering attributes as the assessment criteria. We have found that most aspect-oriented solutions improve separation of pattern-related concerns, although only 4 aspect-oriented implementations have exhibited significant reuse.

On the impact of aspectual decompositions on design stability: an empirical study

Although one of the main promises of aspect-oriented (AO) programming techniques is to promote better software changeability than objectoriented (OO) techniques, there is no empirical evidence on their efficacy to prolong design stability in realistic development scenarios. For instance, no investigation has been performed on the effectiveness of AO decompositions to sustain overall system modularity and minimize manifestation of ripple-effects in the presence of heterogeneous changes. This paper reports a quantitative case study that evolves a real-life application to assess various facets of design stability of OO and AO implementations. Our evaluation focused upon a number of system changes that are typically performed during software maintenance tasks. They ranged from successive re-factorings to more broadly-scoped software increments relative to both crosscutting and non-crosscutting concerns. The study included an analysis of the application in terms of modularity, change propagation, concern interaction, identification of ripple-effects and adherence to well-known design principles.

Exceptions and aspects: the devil is in the details

It is usually assumed that the implementation of exception handling can be better modularized by the use of aspect-oriented programming (AOP). However, the trade-offs involved in using AOP with this goal are not well-understood. This paper presents an in-depth study of the adequacy of the AspectJ language for modularizing exception handling code. The study consisted in refactoring existing applications so that the code responsible for implementing heterogeneous error handling strategies was moved to separate aspects. We have performed quantitative assessments of four systems - three object-oriented and one aspect-oriented - based on four quality attributes, namely separation of concerns, coupling, cohesion, and conciseness. Our investigation also included a multi-perspective analysis of the refactored systems, including (i) the reusability of the aspectized error handling code, (ii) the beneficial and harmful aspectization scenarios, and (iii) the scalability of AOP to aspectize exception handling in the presence of other crosscutting concerns.

Composing design patterns: a scalability study of aspect-oriented programming

Pattern composition has been shown as a challenge to applying design patterns in real software systems. One of the main problems is that multiple design patterns in a system are not limited to affect only the application concerns. They also crosscut each other in multiple heterogeneous ways so that their separation and composition are far from being trivial. In this context, it is of paramount importance to systematically verify whether aspect-oriented programming (AOP) supports improved composability of design patterns. This paper presents a systematic investigation on how AOP scales up to deal with modularization of pattern-specific concerns in the presence of pattern interactions. We have made both qualitative and quantitative assessments of 62 pairwise compositions taken from 3 medium-sized systems implemented in Java and AspectJ programming languages. Our analysis has also included the evaluation of compositions involving more than two patterns. The assessment was based on four fundamental software attributes, namely separation of concerns, coupling, cohesion, and conciseness.

On the Maintainability of Aspect-Oriented Software: A Concern-Oriented Measurement Framework

Aspect-oriented design needs to be systematically assessed with respect to modularity flaws caused by the realization of driving system concerns, such as tangling, scattering, and excessive concern dependencies. As a result, innovative concern metrics have been defined to support quantitative analyses of concerns properties. However, the vast majority of these measures have not yet being theoretically validated and managed to get accepted in the academic or industrial settings. The core reason for this problem is the fact that they have not been built by using a clearly-defined terminology and criteria. This paper defines a concern-oriented framework that supports the instantiation and comparison of concern measures. The framework subsumes the definition of a core terminology and criteria in order to lay down a rigorous process to foster the definition of meaningful and well-founded concern measures. In order to evaluate the framework generality, we demonstrate the framework instantiation and extension to a number of concern measures suites previously used in empirical studies of aspect-oriented software maintenance.

On the modularity of software architectures: a concern-driven measurement framework

Much of the complexity of software architecture design is derived from the inadequate modularization of key broadly-scoped concerns, such as exception handling, distribution, and persistence. However, conventional architecture metrics are not sensitive to the driving architectural concerns, thereby leading a number of false positives and false negatives in the design assessment process. Therefore, there is a need for assessment techniques that support a more effective identification of early design modularity anomalies relative to crosscutting concerns. In this context, this paper proposes a concern-driven measurement framework for assessing architecture modularity. It encompasses a mechanism for documenting architectural concerns, and a suite of concern-oriented architecture metrics. We evaluated the usefulness of the proposed framework while comparing the modularity of architecture design alternatives in three different case studies.

Extracting Software Product Lines: A Case Study Using Conditional Compilation

Software Product Line (SPL) is a development paradigm that targets the creation of variable software systems. Despite the increasing interest in product lines, research in the area usually relies on small systems implemented in the laboratories of the authors involved in the investigative work. This characteristic hampers broader conclusions about industry-strength product lines. Therefore, in order to address the unavailability of public and realistic product lines, this paper describes an experiment involving the extraction of a SPL for ArgoUML, an open source tool widely used for designing systems in UML. Using conditional compilation we have extracted eight complex and relevant features from ArgoUML, resulting in a product line called ArgoUML-SPL. By making the extracted SPL publicly available, we hope it can be used to evaluate the various flavors of techniques, tools, and languages that have been proposed to implement product lines. Moreover, we have characterized the implementation of the features considered in our experiment relying on a set of product-line specific metrics. Using the results of this characterization, it was possible to shed light on the major challenges involved in extracting features from real-world systems.

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.

Identifying Code Smells with Multiple Concern Views

Code smells are anomalies often caused by the way concerns are realized in the source code. Their identification might depend on properties governing the structure of individual concerns and their inter-dependencies in the system implementation. Although code visualization tools are increasingly applied to support anomaly detection, they are mostly limited to represent modular structures, such as methods, classes and packages. This paper presents a multiple views approach that enriches four categories of code views with concern properties, namely: (i) concern’s package-class method structure, (ii) concern’s inheritance-wise structure, (iii)concern dependency, and (iv) concern dependency weight. An exploratory study was conducted to assess the extent to which visual views support code smell detection. Developers identified a set of well-known code smells on five versions of an open source system. Two important results came out of this study. First, the concern-driven views provided useful support to identify God Class and Divergent Change smells. Second, strategies for smell detection supported by the multiple concern views were uncovered.