Rodrigo Bonifácio

Modeling scenario variability as crosscutting mechanisms

Variability management is a common challenge for Software Product Line (SPL) adoption, since developers need suitable mechanisms for specifying and implementing variability that occurs at different SPL artifacts (requirements, design, implementation, and test). In this paper, we present a novel approach for use case scenario variability management, enabling a better separation of concerns between languages used to manage variabilities and languages used to specify use case scenarios. The result is that both representations can be understood and evolved in a separate way. We achieve such a goal by modeling variability management as a crosscutting phenomenon, for the reason that artifacts such as feature models, product configurations, and configuration knowledge crosscut each other with respect to each specific SPL member. After applying our approach to different case studies, we achieved a better feature modularity and scenario cohesion.

Managing variability in business processes: an aspect-oriented approach

Business processes specify key activities in an organization, some of which can be automated. It is often the case that replication of activities across such processes occur and failure in identifying such replication results in organizational costs. To minimize this risk and optimize organizational resources, in this paper we characterize variability in business process and propose an approach to manage such a variability. The characterization of variability relies on the study of industrial-strength applications in the Human Resources domain. The management of variability is based on a compositional and parametric approach with Aspect-Orientation. It leverages and extends an existing tool to address variability in such domain

Evaluating scenario-based SPL requirements approaches: the case for modularity, stability and expressiveness

AbstractSoftware product lines (SPL) provide support for productivity gains through systematic reuse. Among the various quality attributes supporting these goals, modularity, stability and expressiveness of feature specifications, their composition and configuration knowledge emerge as strategic values in modern software development paradigms. This paper presents a metric-based evaluation aiming at assessing how well the chosen qualities are supported by scenario-based SPL requirements approaches. The selected approaches for this study span from type of notation (textual or graphical based), style to support variability (annotation or composition based), and specification expressiveness. They are compared using the metrics developed in a set of releases from an exemplar case study. Our major findings indicate that composition-based approaches have greater potential to support modularity and stability, and that quantification mechanisms simplify and increase expressiveness of configuration knowledge and composition specifications.

Comparing Two Black-Box Testing Strategies for Software Product Lines

SPL testing has been considered a challenging task,mainly due to the diversity of products that might be generatedfrom an SPL. To deal with this problem, some techniques for derivingproduct specific functional test cases have been proposed.However, this research area still lacks empirical studies showingthe benefits of using such techniques. This paper presents a studythat empirically compares two different black-box manual testdesign techniques: a generic technique that we have observed inan industrial test execution environment and a product specifictechnique whose functional test cases could be derived using anySPL technique that considers variations in functional tests. Weevaluated their impact from the point of view of the test execution process, achieving results that indicate that executing product specific test cases is faster and generates fewer errors.

Understanding the exception handling strategies of Java libraries: an empirical study

This paper presents an empirical study whose goal was to investigate the exception handling strategies adopted by Java libraries and their potential impact on the client applications. In this study, exception flow analysis was used in combination with manual inspections in order: (i) to characterize the exception handling strategies of existing Java libraries from the perspective of their users; and (ii) to identify exception handling anti-patterns. We extended an existing static analysis tool to reason about exception flows and handler actions of 656 Java libraries selected from 145 categories in the Maven Central Repository. The study findings suggest a current trend of a high number of undocumented API runtime exceptions (i.e., @throws in Javadoc) and Unintended Handler problem. Moreover, we could also identify a considerable number of occurrences of exception handling anti-patterns (e.g. Catch and Ignore). Finally, we have also analyzed 647 bug issues of the 7 most popular libraries and identified that 20.71% of the reports are defects related to the problems of the exception strategies and anti-patterns identified in our study. The results of this study point to the need of tools to better understand and document the exception handling behavior of libraries.

A design rule language for aspect-oriented programming

HighlightsWe present a design rule specification language for aspect-oriented systems.We explore its benefits to supporting the modular development of classes and aspects.We discuss how our language improves crosscutting modularity without breaking class modularity.We present a Compiler for LSD and AspectJ (COLA), a tool to automate design rules checking.We evaluate it using a real case study and compare it with other approaches. 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 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. We evaluate it using a real case study and compare it with other approaches.

The discipline of preprocessor-based annotations does #ifdef TAG n't #endif matter

The C preprocessor is a simple, effective, and language-independent tool. Developers use the preprocessor in practice to deal with portability and variability issues. Despite the widespread usage, the C preprocessor suffers from severe criticism, such as negative effects on code understandability and maintainability. In particular, these problems may get worse when using undisciplined annotations, i.e., when a preprocessor directive encompasses only parts of C syntactical units. Nevertheless, despite the criticism and guidelines found in systems like Linux to avoid undisciplined annotations, the results of a previous controlled experiment indicated that the discipline of annotations has no influence on program comprehension and maintenance. To better understand whether developers care about the discipline of preprocessor-based annotations and whether they can really influence on maintenance tasks, in this paper we conduct a mixed-method research involving two studies. In the first one, we identify undisciplined annotations in 110 open-source C/C++ systems of different domains, sizes, and popularity GitHub metrics. We then refactor the identified undisciplined annotations to make them disciplined. Right away, we submit pull requests with our code changes. Our results show that almost two thirds of our pull requests have been accepted and are now merged. In the second study, we conduct a controlled experiment. We have several differences with respect to the aforementioned one, such as blocking of cofounding effects and more replicas. We have evidences that maintaining undisciplined annotations is more time consuming and error prone, representing a different result when compared to the previous experiment. Overall, we conclude that undisciplined annotations should not be neglected.

The use of C++ exception handling constructs: A comprehensive study

Exception handling (EH) is a well-known mechanism that aims at improving software reliability in a modular way - allowing a better separation between the code that deals with exceptional conditions and the code that deals with the normal control flow of a program. Although the exception handling mechanism was conceived almost 40 years ago, formulating a reasonable design of exception handling code is still considered a challenge, which might hinder its widespread use. This paper reports the results of an empirical study that use a mixed-method approach to investigate the adoption of the exception handing mechanism in C++. Firstly, we carried out a static analysis investigation to understand how developers employ the exception handling construct of C++, considering 65 open-source systems (which comprise 34 million lines of C++ code overall). Then, to better understand the findings from the static analysis phase, we conducted a survey involving 145 C++ developers who have contributed to the subject systems. Some of the findings consistently detected during this mixed-method study reveal that, for several projects, the use of exception handling constructs is scarce and developers favor the use of other strategies to deal with exceptional conditions. In addition, the survey respondents consider that incompatibility with existing C code and libraries, extra performance costs (in terms of response time and size of the compiled code), and lack of expertise to design an exception handling strategy are among the reasons for avoiding the use of exception handling constructs.

On the benefits of scenario variability as crosscutting

Variability management allows product customization by specifying variation points and composition rules related to feature models and product configurations. This is an interesting kind of crosscutting concern, since a feature might require variation points to be spread into different artifacts of each Software Product Line model (requirements, design, source code, and tests). In order to modularize use case scenario variability management, we proposed a crosscutting approach that weaves scenarios, feature models, product configurations, and configuration knowledge. The result leads to independent specification of behavior and variability concerns. In this work, we report the benefits of such kind of separation of concerns by comparing our approach with other techniques for handling scenario variability management.

Empirical assessment of two approaches for specifying software product line use case scenarios

Modularity benefits, including the independent maintenance and comprehension of individual modules, have been widely advocated. However, empirical assessments to investigate those benefits have mostly focused on source code, and thus, the relevance of modularity to earlier artifacts is still not so clear (such as requirements and design models). In this paper, we use a multimethod technique, including designed experiments, to empirically evaluate the benefits of modularity in the context of two approaches for specifying product line use case scenarios: PLUSS and MSVCM. The first uses an annotative approach for specifying variability, whereas the second relies on aspect-oriented constructs for separating common and variant scenario specifications. After evaluating these approaches through the specifications of several systems, we find out that MSVCM reduces feature scattering and improves scenario cohesion. These results suggest that evolving a product line specification using MSVCM requires only localized changes. On the other hand, the results of six experiments reveal that MSVCM requires more time to derive the product line specifications and, contrasting with the modularity results, reduces the time to evolve a product line specification only when the subjects have been well trained and are used to the task of evolving product line specifications.