=Paper=
{{Paper
|id=Vol-557/paper-8
|storemode=property
|title=Aspect-Oriented Patterns for the Realization of Flexible Feature Binding
|pdfUrl=https://ceur-ws.org/Vol-557/paper8.pdf
|volume=Vol-557
|dblpUrl=https://dblp.org/rec/conf/splc/Lee09
}}
==Aspect-Oriented Patterns for the Realization of Flexible Feature Binding==
https://ceur-ws.org/Vol-557/paper8.pdf
Aspect-Oriented Patterns for the Realization of
Flexible Feature Binding
Kwanwoo Lee
Department of Information Systems Engineering
Hansung University
Seoul, Korea
kwlee@hansung.ac.kr
Abstract—Feature selection is the process of determining ular components. Since the code for multiple feature binding
features that should be included in a product to satisfy the times may affect multiple feature implementation components,
requirements for the various stakeholders. Feature binding time this paper uses AOP mechanisms to achieve flexible feature
refers to the time at which variable features are selected for a
product and their implementations are bound into the product. binding time. That is. The approach makes it possible to
A feature may have different binding times for different prod- choose among compile-time, load-time and run-time binding
ucts. In this paper, we present an aspect-oriented approach to for selected features.
supporting flexible feature binding time. For better understanding of this paper, the next section
Index Terms—component; formatting; style; styling;
presents the concept of feature binding. Based on this un-
derstanding, aspect-oriented patterns for supporting flexible
I. I NTRODUCTION
feature binding time are presented in section 3. Section 4
In software product line engineering, a product is derived discusses areas requiring further research and concludes this
by selecting some of product line features that satisfies the paper.
product requirements. Feature selection is the process of
determining features that should be included in a product to II. F EATURE B INDING
satisfy the requirements for the various stakeholders.
The time at which features are selected for a product may A feature has to be bound into a product to provide its
vary depending on marketing strategies. For instance, one capability to users. As shown in Fig. 1, an unbound feature
marketing strategy may be to deliver products to customers must be first included into a product to provide its capability.
by prepackaging product specific features, as customer needs However, it is considered that a feature is not bound into a
in this market rarely change. In this case, product specific product, if it is not available to users although included in
features may be selected for a product during product build the product. Therefore, feature binding means that a feature
time. On the other hand, another marketing strategy may be is included into a product and become available to users. It is
to allow customers to start with a product with core features important to note that available features that are bound into a
and then grow to a bigger one by adding new features at load product can provide their capabilities to users only when they
time or run time. In this case, product specific features may are active.
be selected for products at product load time or run time.
Included in a product
Feature binding time refers to the time at which variable
features are selected for a product and their implementations Available to users
are bound into the product. Feature binding time has signif- made available activated
icant influences on the way a feature is implemented. There selected
are many variability mechanisms for realizing feature binding Unbound Unavailable Inactive Active
times. Some of those include conditional compilation, macro deselected
processing, virtual dispatch tables, reflection, dynamic class deactivated
made unavailable
loading, etc.
These mechanisms, however, are strongly tied to a particular
choice of binding time [1]. The problem may occur when a
feature may have different binding times for different products. Fig. 1. Feature Binding Context.
That is, the variability of feature binding time affects the way
a feature is implemented. To support multiple feature binding For feature binding to occur, the inclusion and availability of
times effectively, code for feature binding times needs to be a feature may be decided simultaneously at compile time, load
separated from feature implementations. time, or run time. Or, the inclusion of a feature is decided at
Aspect-oriented programming (AOP) provides effective compile time, but its availability may be postponed until load
mechanisms for separating crosscutting concerns from mod- time or run time.
Feature binding at compile time: In this case, the code The pointcut variationPoint defines the join points in
related to the selected features is included into a product and CFModule at which VFModule is bound into a product.
becomes available to customers at compile time, while the The advice body in CompileTimeBinding defines actual
code for deselected features is excluded from the product. This binding between CFModule and VFModule. If VFModule
results in different packaging of the product. and CompileTimeBinding are given to a AspectJ compiler
Feature binding at load time: There are two cases for load at compile time, the compiler produce a weaved product.
time feature binding to occur. The first case is that features
are included into a product at compile time and become <> <>
available at load time. The second case is that the inclusion
CFModule VFModule
and availability of features are decided at load time. The main
difference between the compile feature binding and the load method1() method2()
time feature binding is that the software derived from the
advices
compile time feature binding must be compiled, whereas that
from the load time feature binding needs not. <>
Feature binding at run time: Feature binding in this class is CompileTimeBinding
similar to the load time feature binding. That is, features are
included into a product at compile time and become available VFModule featureModule =
new VFModule();
at run time or included at product load time and available at
run time. Alternatively, both the inclusion and availability of pointcut variationPoint()
features are decided at run time. advice(): variationPoint() {
Depending on the inclusion and availability decisions of a featureModule.method2();
}
feature, it may have to be implemented in different ways. In
the next section, we present an aspect-oriented approach to
supporting flexible feature binding times. Fig. 2. Compile-Time Inclusion Pattern.
III. A SPECT-O RIENTED D ESIGN PATTERNS
Note that AspectJ provides explicit support for load
The current AspectJ weaver provides explicit support for time weaving. Therefore, we can integrate VFModule and
compile-time and load time weaving. This implies that if we CompileTimeBinding with an existing product at load
implement variable features with aspects, we do not need to time, simply by including them before program execution.
change the aspects to support for either compile-time or load-
time feature binding. However, when we want to implement a
<> <>
load-time binding feature that has to be included at compile-
time and becomes available at load-time, we have to change CFModule VFModule
the feature implementation to support the required feature method1() method2()
binding decisions. Moreover, if we consider run-time feature
binding, we may have to change the feature implementation
as well. This implies a feature with multiple binding times <>
may have to be implemented differently depending on which
advices RunTimeBinding
binding time decisions are decided for a product.
In this section, we present aspect-oriented design patterns VFModule featureModule;
for supporting flexible feature binding times.
pointcut variationPoint()
A. Variable Inclusion Decisions advice(): variationPoint() {
if (featureModule!= null)
For feature binding to occur, the code implementing a featureModule.method2();
feature must be included in a product and integrated with the }
other code for the product. Since the time at which a feature
is included in a product may vary for different products in a void include(VFModule a) {
featureModule = a;
product line, the variable inclusion times may require variable
}
feature implementations. void exclude(VFModule a) {..}
To support flexible binding times effectively, the code
implementing the decision on feature inclusion needs to be
separated from the code implementing the core functionality Fig. 3. Run-Time Inclusion Pattern.
of a feature. As shown in Fig. 2, CompileTimeBinding
is an aspectual implementation for integrating the module Although AspectJ does not provide support for run time
(VFModule) implementing a variable feature with the module weaving, we can implement the run time feature binding which
(CFModule) in the scope of a product at compile time. includes the implementation of a variable feature in a product
at run-time. As shown in Fig. 3, RunTimeBinding allow configuring a product after compilation. On the other hand,
VFModule implementing a variable feature to be included in RunTimeAvailability sets the variable isAvailable
a product scope and integrated with CFModule, which is an to true using the method setAvailable. But the decision
implementation module in the product scope. is made by an external configurator at run-time.
RunTimeBinding is similar to CompileTime- With these patterns, we can clearly separate binding time
Binding in that it specifies the join points used to integrate decisions from the code implementing the core functionality
CFModule and VFModule using pointcut definitions. of a feature. This enables us to select different choices among
However, their integration is deferred until the actual instance multiple feature binding implementations when a feature has
of VFModule is included in the product at run-time. A multiple feature binding times.
external configurator has the responsibility for including the
instance using the include method based on the user’s IV. R ELATED W ORK
decision at run-time. The concept of feature binding time was first introduced by
Kang et al. [3]. Gurp et al. [5] elaborated it more precisely
B. Deferring Availability Decisions
and provided a classification of many variability realization
Although AspectJ weaver does not provide explicit support techniques. A broad range of mechanisms exist to implement
for run-time weaving, we can support runtime feature binding different binding times, including the use of compiler direc-
using AOP, in case inclusion is determined at compile-time tives, dynamic linking and loading, load tables, reflection,
but availability is decided at load-time or run-time. That is, plug-ins, configuration files, etc. However these solutions are
availability of included aspects is decided by enabling or limited in that each supports only a specific binding time. They
disabling advices in the aspects. cannot be used effectiely in a situation where the binding
time of a feature may vary depending on different product
<> <> requirements.
CFModule VFModule Dolstra et al. [2] introduced the notion on the variability of
method1() method2() feature binding time as timeline variability. However, they do
not provide concrete mechanisms for realizing flexible feature
<> binding time. They only suggested some future directions for
advices
the solutions.
CompileTimeInclusion
There have been several attempts to realize flexible feature
VFModule featureModule = new VFModule();
boolean isAvailable = false
binding time. Hoek [6] proposed architecture-based approach
to support any-time variability. The Koala component model
pointcut variationPoint()
advice(): variationPoint() && if(isAvailable){
[7] allows connection between components to be established
featureModule.method2(); either at compile time or at run time through a switch.
}
Depending on the setting of a switch, the Koala compiler
generates C code for connecting components either at compile
time or at run time. Both of these approaches specify product
<> <>
line variabilities at design time, but resove them at any time
LoadTimeAvailablity RunTimeAvailablity
thereafter. On the other hand, the approach presented in this
LoadTimeAvailability() { void setAvailable(boolean on} { paper uses aspect-oriented design patterns using AOP.
isAvailable = isAvailable = on;
Configurator.isSelected(“vFeature”); } Similar to our approach, Edicts [1] uses AOP for flexible
} feature binding. However, it only supports run time feature
biding which includes a feature at compile time and makes it
available at run time. But our approach can add more flexibility
Fig. 4. Variable Availability Pattern.
of feature binding time from different choices of inclusion and
avaiability decisions.
Fig. 4 shows how to support the load-time or run-
time binding of a variable feature, which is included V. R ESEARCH I SSUES AND C ONCLUSIONS
at compile time but becomes available during load-time
or run-time. CompileTimeInclusionNotAvailable In this paper, aspect-oriented patterns are introduced to
is similar to CompileTimeBinding shown in Fig. 2 support flexible feature binding times. There are many issues
except that the boolean type variable isAvailable that have to be addressed before this approach becomes useful.
is used to allow the availability decision to be de- Some of these issues are summarized below:
cided in its child aspects (LoadTimeAvailability and • Method: We need methods for analyzing feature binding
RunTimeAvailability). time, developing a software product line applying the
LoadTimeAvailability determines the value of patterns presented above, deriving a product based on a
isAvailable when the aspect is created by consulting feature configuration, which can be determined at either
with an external configuration, which has responsibility for compile-time, load-time, or run-time.
• Feature model extension: Although there have been many
attempts to extend the original feature model [3], there
has been no attempt to model the variability of feature
binding time. Since the inclusion and availability deci-
sions for feature binding are affected by resources avail-
able during run time or development environments such
as programming languages or operating environments,
when we model variabilities of feature binding time, we
may take into account constraints or dependencies from
various sources (e.g., available resources). Also we may
have to consider finer classification of feature binding
times.
• Implementation mechanism: In this paper, we illustrated
the patterns using AspectJ. However, more advanced
mechanisms such as Prose [4], which supports run-time
weaving, can be used to support flexible feature binding
time. Which one among current available technologies or
mechanisms can be best utilized for achieving this goal?
We need to analyze pros and cons for each technology
or mechanism.
In this section, we have examined some of research issues
that have to be addressed. Although we are at an early stage
of research, most of research topics discussed above are being
addressed.
ACKNOWLEDGMENT
This work was supported by the Korea SW Industry Pro-
motion Agency (KIPA)
R EFERENCES
[1] V. Chakravarthy, J. Regehr, E. Eide, Edits: Implementing Features with
Flexible Binding Times, AOSD’08, 2008.
[2] E. Dolstra, G. Florijin, E. Visser, Timeline Variability: The Variability
of Binding Time of Variation Points, Proceedings of the Workshop on
Software Variability Management, 2003, pp. 119-122.
[3] K. Kang, S. Cohen, J. Hess, W. Novak, A. Peterson, Feature-Oriented
Domain Analysis (FODA) feasibility study, Software Engineering Institute
Technical Report CMU/SEI-90TR-21, Software Engineering Institute,
Carnegie Mellon University, Pittsburgh, PA, 1990.
[4] A. Popovici, T. Gross, G Alonso, Dynamic Weaving for Aspect-Oriented
Programming, Proceedings of the 1st international conference on Aspect-
oriented software development, Enschede, The Netherlands, 2002, pp.
141-147
[5] M. Svahnberg, J. van Gurp, and J. Bosch. A taxonomy of variability
realization techniques, Software-Practice & Experience, 35(8), pp. 705-
754, 2005.
[6] A. van der Hoek, Design-Time Product Line Architecture for Any-
Time Variability, Science of Computer Programming, Vol. 53, Issue 3,
December 2004, pp. 285-304
[7] R. van Ommering, Building Product Populations with Software Compo-
nents, ICSE’02, May 19-25, 2002, pp.255-264