| dc.description | Companies are adopting the Software Product Line (SPL) development paradigm to
obtain significant improvements in time to market, maintenance cost, productivity, and
quality of products. SPL encompasses a family of software-intensive systems developed
from reusable assets. By reusing such assets, it is possible to construct a large number of
different products applying various compositions. There is a variety of widely used techniques
to develop SPLs, such as aspect-oriented programming (AOP), feature-oriented
programming (FOP), and conditional compilation. These techniques differ in the type of
composition to create a product within the SPL static or dynamically.
In this context, it is important to define when certain features should be activated
in the product due to specific client requirements and different application scenarios.
Thereby, the binding time of a feature is the time that one decides to activate or deactivate
the feature from a product. In general, static and dynamic binding times are considered.
For example, products for devices with constrained resources may use static binding time
instead of dynamic due to the performance overhead introduced by the latter. For devices
without constrained resources, the binding time can be flexible, features can be activated
or deactivated statically or users may do it on demand (dynamically).
To provide flexible binding time for features, researchers proposed an AOP idiom
based on AspectJ and design patterns named Edicts. The idea consists of supporting
binding time flexibility of features in a modular and convenient way. However, we
observe modularity problems in the Edicts idiom. Although we usually use aspects to
tackle crosscutting concerns common in classes, such a problem now appears within the
own aspects. Indeed, several studies indicate that these concerns hurt software modularity.
This way, we observe that Edicts clones, scatters, and tangles code throughout its implementation,
which may lead to time consuming tasks, such as maintaining duplicated
code.
This way, we develop three idioms and implement them to provide flexible binding
time for features of four different applications. In addition, we evaluate Edicts and the
three idioms quantitatively by means of metrics with respect to code tangling, scattering,
cloning, size, and also try to guarantee that our idioms do not change feature code
behavior among the different implementations. | |
