Assessing Idioms for Feature Flexible Binding Time

In Software Product Lines, it is sometimes important to provide flexible binding time for features so that one can choose between static or dynamic feature activation. For example, software products designed for devices with constrained resources may use static binding time to avoid the performance overhead introduced by dynamic binding time activation. However, other devices could exploit binding time flexibility and support products with dynamic binding time for some of their features. To implement this kind of flexibility, researchers have proposed the Edicts idiom, which is based on AspectJ and design patterns. Although, in this article we argue that this idiom may lead to code duplication, scattering, tangling, and size increasing consequently hampering code reuse, maintenance, and understanding. To reduce such issues, this paper proposes three AspectJ-based idioms to implement flexible feature binding. We apply our three idioms plus Edicts to implement flexible binding time for 18 features of four different applications. Thereby, we could assess the resulting implementations by using software metrics covering code quality factors. Our evaluation suggests that our idioms reduce the mentioned problems when implementing flexible feature binding for the selected features.

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

This is the Freemind SPL with flexible binding applied to its two features by means of Layered Aspects

Freemind SPL with Layered Aspects

This is the Freemind SPL with flexible binding applied to its two features by means of Layered Aspects

Freemind SPL with PointcutRedefinition

This is the Freemind SPL with flexible binding applied to its two features by means of PointcutRedefinition

Freemind SPL with Flexible Deployment

This is the Freemind SPL with flexible binding applied to its two features by means of Flexible Deployment

BerkeleyDB SPL with Edicts

This is the BerkeleyDB SPL with flexible binding applied to its ten features by means of Edicts

BerkeleyDB SPL with Layered Aspects

This is the BerkeleyDB SPL with flexible binding applied to its ten features by means of Layered Aspects

BerkeleyDB SPL with PointcutRedefinition

This is the BerkeleyDB SPL with flexible binding applied to its ten features by means of PointcutRedefinition

BerkeleyDB SPL with Flexible Deployment

This is the BerkeleyDB SPL with flexible binding applied to its ten features by means of Flexible Deployment

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

ArgoUML SPL

This is the ArgoUML SPL project with its feature implemented with aspects.

ArgoUML SPL with Edicts

This is the ArgoUML SPL with flexible binding applied to its two features by means of Edicts

ArgoUML SPL with Layered Aspects

This is the ArgoUML SPL with flexible binding applied to its two features by means of Layered Aspects

ArgoUML SPL with Pointcut Redefinition

This is the ArgoUML SPL with flexible binding applied to its two features by means of Pointcut Redefinition

ArgoUML SPL with Flexible Deployment

This is the ArgoUML SPL with flexible binding applied to its two features by means of 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:

Members

CIn-UFPE

Technische Universitšt Darmstadt
MyForm
29 Jan. EMN/ARMINES, ULANC, UMA, FCT/UNL
12 Feb. HOLOS, EMN/ARMINES
26 Feb.

Topic attachments
ISorted ascending Attachment Action Size Date Who Comment
Microsoft Excel Spreadsheetxls SoC.xls manage 475.0 K 2014-07-03 - 01:27 RodrigoAndrade  
Microsoft Excel Spreadsheetxls SoCHenrique.xls manage 468.5 K 2014-07-03 - 01:28 RodrigoAndrade  
Topic revision: r1 - 2014-07-03 - RodrigoAndrade
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback

mersin escort bayan adana escort bayan izmit escort ankara escort bursa escort