Assessing Idioms for Feature Flexible Binding Time

Procedures

To obtain results for the metrics and perform our assessment, we followed the procedure below. We detail it in five steps.

1- Selection of case studies. In order to generalize the results of our study to other contexts, we selected four different applications and 18 different features. The applications we chose represent different sizes, purposes, and architectures. Additionally, the selected features have different granularity and complexity. Moreover, they have different types regarding feature model, such as optional, alternative, OR, and mandatory.

2- Feature code identification and assignment. After choosing the feature, we apply Prune Dependency [43] rules to identify feature code scattered throughout the application. These rules state that "a program element is relevant to a concern if it should be removed, or otherwise altered, when the concern is pruned from the application". By following these rules, two different people can identify the same code related to a given concern. We chose this rule to reduce introducing bias while identifying feature code. We use comments to manually assign the program elements related to each feature. In this way, two different researchers could identify and assign our feature code.

3- Code modularization. For this phase, we extracted the feature code assigned from the classes to aspects, except for BerkeleyDB, which the feature code was extracted before. Thus, we aim at separating the feature and core code. This allows the creation of product lines from the applications. After this phase, the application should be independent from the feature code. For example, the application may compile and execute properly without the optional feature code.

4- Flexible binding time implementation. We then apply the idiom for the selected features that we wish to provide binding time flexibility. We use the chosen idiom to control whether the feature code is executed. In this work, we apply the four idioms for each feature, but only one idiom is necessary to obtain binding time flexibility. The same authors of this work were in charge of feature code extraction and flexible binding time implementation.

5- Evaluate idioms. In this phase, we use the GQM design to drive our evaluation of the four idioms. Our goal is to assess the implementation of the idioms in the case studies. We elaborate four questions with respect to points that we want to investigate about the idioms. Then, we answer the questions by analyzing the measures obtained for the metrics we selected. To collect the required information to compute these metrics, we use the Metrics tool [44], which measures the number of lines of code of components, such as classes and aspects. Additionally, to compute some of the selected metrics, we need to know the number of lines of code of the feature and the driver. To do that, we manually count the corresponding lines. This information and the formulas of the metrics are stored in a sheet, which we used to obtain our results [16]. Moreover, we investigate possible changes concerning the implementations of the idioms behavior. For example, we seek for changes in the behavior of certain feature code with respect to its implementation using Edicts and Layered Aspects.

Tools and source code necessary to replicate our study

Here, we provide all the tools and source code necessary to replicate our study.

Source code - SVN repositories

Freemind SPL with Edicts

Freemind SPL with Layered Aspects

Freemind SPL with PointcutRedefinition

Freemind SPL with Flexible Deployment

BerkeleyDB SPL with Edicts

BerkeleyDB SPL with Layered Aspects

BerkeleyDB SPL with PointcutRedefinition

BerkeleyDB SPL with Flexible Deployment

In order to run the ArgoUML, these three projects must be included in the workspace: tools, model, and infra.

ArgoUML SPL

ArgoUML SPL with Edicts

ArgoUML SPL with Layered Aspects

ArgoUML SPL with Pointcut Redefinition

ArgoUML SPL with Flexible Deployment

Tetris SPL with Edicts

This is the Tetris SPL with flexible binding applied to its feature by means of Edicts

Tetris with Edicts

Tetris SPL with Layered Aspects

This is the Tetris SPL with flexible binding applied to its feature by means of Layered Aspects

Tetris with Layered Aspects

Tetris SPL with PointcutRedefinition

This is the Tetris SPL with flexible binding applied to its feature by means of PointcutRedefinition

Tetris with PointcutRedefinition

Sheets

In both sheets, we provide the formula of all the selected metrics. Additionally, they contain all the data we collected from the source code.

First Sheet

Second Sheet

Tools

The following list contains the tools we used to perform our work:

• CCFinder
• SafeRefactor
• Eclipse Juno

Members

CIn-UFPE

• Rodrigo Andrade
• Márcio Ribeiro
• Henrique Rebêlo
• Paulo Borba

Technische Universität Darmstadt

• Vaidas Gasiunas
• Lucas Satabin