=Paper=
{{Paper
|id=None
|storemode=property
|title=A Dynamic Software Product-Line Approach using Aspect Models at Runtime.
|pdfUrl=https://ceur-ws.org/Vol-564/compositionvariability2010_submission_4.pdf
|volume=Vol-564
}}
==A Dynamic Software Product-Line Approach using Aspect Models at Runtime.==
https://ceur-ws.org/Vol-564/compositionvariability2010_submission_4.pdf
A Dynamic Software Product Line Approach using
Aspect Models at Runtime
Tom Dinkelaker1 Ralf Mitschke1 Karin Fetzer2 Mira Mezini1
1 2
Technische Universität Darmstadt, Germany SAP Research Dresden, Germany
{dinkelaker,ralf.mitschke,mezini}@cs.tu-darmstadt.de karin.fetzer@sap.com
ABSTRACT implementation. However, lacking appropriate methodolo-
Dynamic software product lines (DSPLs) are software prod- gies for building such software systems, the rising complexity
uct lines, which support late variability that is built into (i.e., number of configurations, complex re-configuration re-
the system to address requirements that change at runtime. lationships) can limit the number of dynamic re-configuration
But it is difficult to ensure at runtime that all possible adap- points to a few well-defined ones (e.g., all points at which
tations lead to a correct configuration. In this paper, we variability must be supported must be known at design time,
propose a novel approach for DSPLs that uses a dynamic and the corresponding if-statements and all possible varia-
feature model to describe the variability in the DSPLs and tions must be provided).
that uses a domain-specific language for declaratively im- Dynamic software product lines (DSPLs) [11, 13] are an
plementing variations and their constraints. The approach emerging field that can systemize the configuration space in
combines several trends in aspect-oriented programming for dynamically adaptable software system. Thus, DSPLs break
DSPLs, namely dynamic aspects, runtime models of aspects, down the complexity of managing dynamic re-configuration
as well as detection and resolution of aspect interactions. points by modeling them explicitly in a product line ap-
The advantage is, that reconfigurations must not be speci- proach as late variability [22]. Central to software product
fied for every feature combination, but only for interacting lines (SPLs) are features, where a feature is a distinct prop-
features. We have validated the approach in an example dy- erty of the software product. The late variability can be
namic software product line from industry and preliminarily represented through dynamic features, i.e., features that can
evaluated the approach. be (de-)activated in a running software system.
A research challenge for DSPLs is to find suitable variabil-
ity mechanisms to support dynamic features in the underly-
Keywords ing architecture and implementation. The mechanism must
Dynamic Software Product Line Engineering, Dynamic Fea- not constrain the range of existing techniques used to build
ture Models, Domain-Specific Languages product lines, i.e., it should peacefully co-exist with model-
driven and generative techniques. Further, the mechanism
should be able to cope with dynamic features that affect sev-
1. INTRODUCTION eral modules and require modification of several classes or
Large scale information technology infrastructures are the components in the product line. It should also detect and
backbone of many enterprise processes. Yet these systems resolve interactions between features, in particular feature
are driven to continuous adaptation, due to changing re- interactions that are not statically detectable but arise for a
quirements [10]. However, the evolutionary transitions for set of dynamic contexts of the configuration.
crucial enterprise information systems must be smooth and An interesting research question for aspect-oriented pro-
not hamper current running business processes [18]. Hence, gramming (AOP) [16] is how far dynamic AOP [2, 20, 19, 5,
methods and mechanisms for dynamic adaptation of the 7] is capable as a variability mechanism for dynamic SPLs.
software system are required. For example, dynamic aspects [4] have been used to im-
The challenge of building dynamically adaptable software plement business rules. Although dynamic AOP solutions
systems is how to define suitable methods and mechanisms provide a flexible variability mechanism, they do not pro-
for the dynamism. An ad-hoc approach is to use exist- vide appropriate support for declaring, detecting, and re-
ing variability mechanisms (e.g., if -statements, method dis- solving dynamic interactions. Most dynamic AO solutions
patch) directly in the architecture, and/or the underlying only provide support for defining the precedence of aspects
[2], i.e., defining the execution order of their advice. But
these precedence relations are inappropriate for expressing
Permission to make digital or hard copies of all or part of this work for exclusions, i.e., one cannot declare that one aspect does not
personal or classroom use is granted without fee provided that copies are allow another aspect to be present. Furthermore, dynamic
not made or distributed for profit or commercial advantage and that copies dependency relations between the features implemented by
bear this notice and the full citation on the first page. To copy otherwise, to aspects cannot declare that one aspect needs another aspect
republish, to post on servers or to redistribute to lists, requires prior specific to work correctly. The works in [20, 5] support static decla-
permission and/or a fee.
First Workshop on Composition and Variability’10 Rennes, France colo-
ration of exclusions and dependencies between aspects, but
cated with AOSD’2010 do not address dynamic interactions.
Copyright 2010 ACM ...$10.00.
In DSPLs the dynamicity in the exclusion of features is of order
Static
receive order vp
great interest. The problem with static exclusions and de- management receive pack ship
pendencies is that they must be declared permanently (e.g., process model
aspect A always excludes aspect B) and are enforced inde-
pendent of the fact that aspects A and B may not actually manual approve ... receive manual approve ...
(after receive)
conflict because the aspects are never applied at the same
Dynamic
auto approve ... ...
points at runtime. This is too conservative and disallows (after receive)
receive auto approve
meaningful compositions of dynamic features. man./auto approve ...
receive ? ? ...
For example, a workflow requires an approval step, which (after receive)
can be automatic manual. Modularizing the variability in
the approval step entails interaction between the automatic Figure 1: Late variation point for approval step in
and the manual variants, because the goal of immediate au- the order management business process
tomated approval is violated by waiting for a manual ap-
proval. The repetitive manual approval following an auto-
mated appoval would be a waste of human resources. late variability and give an overview of the methodology.
However, using more powerful declaration mechanism, we In Sec. 4, we describe how dynamic aspects can be used to
can declare that both dynamic features be selected at once realize dynamic SPLs. Sec. 5 presents the case study. Sec. 6
and affect different parts of the DSPL, with the exception of evaluates the approach. Sec. 7 discusses related work. Sec. 8
cases in which conflict occurs. For example, when the auto- concludes the paper and outlines future work.
matic approval is only applied to orders that have a certain
state (e.g., exceeds a certain amount), a conflict occurs only 2. LATE VARIABILITY IN AN SPL
for those particular orders and must be resolved only when
Our example SPL is the Sales Scenario, which is a soft-
this runtime condition is satisfied. The other orders are only
ware system for the management of business data, including
affected by the manual approval without any conflicts.
central storage and user-centric information inquiry. The
In this paper, we propose mechanisms to detect and re-
main focus of the Sales Scenario is on stock sales processes,
solve such context-dependent interactions between features
where the core processes are customer order management,
in a DSPL. The contribution of this paper is twofold. On
payment, account management, stock management and com-
the one hand, we adopt DSPLs as a systematic framework
munication. The main goal of the Sales Scenario is to inte-
in which complex dynamic software systems can be planned
grate all processes and corresponding data of an organization
and managed by modeling late variability. On the other
into one system. The system addresses sales processes for
hand, we provide support for detecting and resolving context-
both mid-sized and large enterprises. The business processes
dependent interactions by validating an aspect-oriented (AO)
themselves are customizable, often in multiple independent
model at runtime.
variations. For example the order management process can
First, we extend existing DSPL approaches by a novel no-
include a quotation management (i.e., placing strategic of-
tation termed dynamic feature model that allows us to model
fers to customers) or sales order processing (i.e., tracking of
late variability. Feature models are a widely used nota-
individual orders).
tion, that models the configuration space of software product
The customer needs for these features vary depending on
lines, yet they lack explicit support to model late variabil-
the business size of the customer, thus making it advanta-
ity. Our notation extends feature models to capture dynamic
geous for the software provider to implement the system as
features, i.e., features that may be (de-)activated at runtime,
a SPL. The products resulting from the SPL might be as
and to model their runtime constraints. Thus we provide an
small as a simple way to keep track of executed orders, or
explicit representation of dynamic re-configuration points in
as large as a complete sales management system, in which
an adaptable software system.
everything from the first idea of a sales opportunity to the
Second, we propose a novel approach for DSPLs on top of
delivery and payment of the sold product can be managed.
a dynamic AO runtime environment with a meta-aspect pro-
The processes in the Sales Scenario are modeled using
tocol [7] that is used as a dynamic feature manager. We map
model-driven techniques. Thus, we can identify variation
dynamic feature models to aspect-oriented models that are
in the processes on the model level. For example, Fig. 1
available as first-class entities in running products. DSPLs
depicts a short version of the order management process,
are delivered with the AO runtime environment, through
which consists of at least three steps: “receive” (order is
which (de-)activation of dynamic features is enabled, which
received from a customer), “pack” (order items are prepared
updates dynamic feature model representation, takes care
for delivery), and “ship” (order is sent to the customer). The
of the composition of dynamic features, as well as it detects
lower part of Fig. 1 models an example of late variability in
and resolves dynamic feature constraints.
the order management process. The modeling elements with
We have validated the approach by evolving a static soft-
solid lines describe the static part of the process. The receive
ware product-line from industry into a DSPL in a case study.
step is subject to a dynamic variation that is described using
Furthermore, we have evaluated the performance overhead
modeling elements with dashed lines.
of dynamic aspects in the context of SPLs. The results in-
As an example for late variability, we model an additional
dicate that the approach copes well with performance re-
approval step after an order is received. We have identified
quirements, also in the presence of the special scalability
two subcategories of approval, namely a manual approval,
requirements of SPLs.
which requires human interaction with the system, or an
The remainder of this paper is structured as follows. Sec. 2
automated approval, e.g., a check if the order is issued by
illustrates the example SPL and motivates late variability.
credit-worthy customers. To provide flexibility we allow cus-
In Sec. 3, we present dynamic feature models for modeling
tomers of the product line to adapt their software system
from one process model to another without the need to re- depicted with dashed border lines. Likewise dynamic con-
deploy the whole system. Therefore, these two variants of straints are modeled using dashed arrows.
approval processes are modeled as dynamic features. We impose some limitations in the usage of our constraints.
A conceptual problem arises when multiple dynamic fea- First of all, the conjunction of implies and excludes is for-
tures are composed, e.g., when a customer activates both bidden, as this combination is not satisfiable by the DSPL.
of the above features at once, as indicated in the last row For multiple features with multiple precedes constraints we
of Fig. 1. When composing the features, it is necessary to disallow cycles, thereby all involved precedence constraints
take into account their semantics. One solution would be must form a chain. Furthermore, the combination of pre-
that the automated approval manages all orders and that cedes and excludes ii) + iii) is allowed and states that the
we require human intervention only in cases where the au- feature with the highest precedence is the only one taken
tomation does not approve of an order. However, we cannot into account at points where these features interact.
describe such compositions with the current technology. Static constraints may also be formulated between dy-
Existing approaches support a form of linear composition namic and static features. For example, a dynmic feature
for features, by controlling their order through precedences requires the presence of a static feature. The static con-
[1, 19, 5]. But, declaring that the automated approval step straints must be enforced with the same semantics as having
precedes the manual approval step is not enough, since we static constraints between static features.
want to declare that the automated approval must be exe-
cuted and that the manual approval must be skipped. The 4. DSPLS USING DYNAMIC AOP
above approaches also provide composition strategies to de-
Our approach realizes a DSPL by mapping dynamic fea-
clare and enforce a static exclusion constraint between fea-
tures and their interactions to an aspect-oriented model at
tures. For example, the manual approval feature always ex-
runtime. The AO model consists of first-class entities, such
cludes the automatic approval feature in all configurations.
as dynamic aspects and their pointcuts-and-advice, primitive
The problem is that static precedences and exclusions are
pointcut designators that match join points, and rule base
too conservative. If the constraint between features only
with declared constraints on aspect interactions. Dynamic
occurs in a certain (runtime-) context, such strategies are
features are mapped to dynamic aspects, which adapt late
inappropriate. A correct strategy must take into account
variation points in the DSPL. To enforce the modeled con-
the application context. For example, a manual approval is
straints, feature interactions are mapped to constraints on
selected only for a certain group of orders, e.g., orders with
dynamic aspects. The aspect model is used as a first-class
a high quantity, while the rest is approved automatically.
runtime representation of the dynamic feature model. The
Without knowledge of the domain and application seman-
AO model is validated to ensure consistency when features
tics, we cannot express such a composition scenario at the
are dynamically activated and deactivated at runtime.
level of feature modeling.
To express dynamic features in terms of dynamic aspects,
SPL developers define a DSL. This language, also denoted
3. MODELING DYNAMIC SPLS as dynamic feature language (DFL), incorporates the neces-
Dynamic feature models are an extension of existing ’static’ sary abstractions for the specification of dynamic features in
feature model notations, such as [6], and provide a special- terms of domain concepts. In addition, the DFL provides the
ized notation to specify the product lines dynamism and run- required aspect-oriented machinery to declare constraints on
time constraints. The dynamic constraints allow expressing dynamic features, as well as semantics for the composition of
i) that the activation of one dynamic feature requires that dynamic features. The DFL enables a safe feature composi-
another dynamic feature be active as well. This constraint tion, because dynamic feature interactions are automatically
is termed implies in dynamic feature models and allows SPL detected.
designers to model requirements on the reconfiguration logic As the underlying language technology for implementing
of the DSPL. Furthermore, we model ii) that two features the DFL, we use Popart [7], which is a dynamic aspect-
must not be simultaneously active, by constraining them oriented language that provides generic AO mechanisms and
with excludes. This constraint allows restricting the run- that is extensible for new domain-specific syntax and se-
ning system from activating both features, if an SPL de- mantics. Domain extensions are integrated into Popart to
signer deems their combination harmful due to possible in- create a complete SPL-specific aspect language.
teractions. The iii) precedes constraint declares that an in- The process of defining a DFL consists of the steps: 1) late
teraction of features is allowed and states a resolution strat- variation points are identified and modeled as a domain-
egy, which grants one feature precedence over another. The specific join point model (DS-JPM) [8], 2) late VPs are
precedence is not exclusive, thus all features are active but at made available for the DFL using a domain-specific pointcut
interacting points, the precedence defines an order in which language DS-PCL [8] that quantifies over the DS-JPM, 3)
the features are taken into account. the results are integrated with a generic declarative aspect-
oriented language, that provides commonly used AO con-
<>
cepts (e.g., before/after/around advice). The resulting dy-
Dynamic <> Dynamic i) implies
Feature A Feature B
namic feature language is thus summarized as: DFL = DS-
ii) excludes
iii) precedes
JPM + DS-PCL + Generic AO Concepts.
4.1 Modeling Late VPs (DS-JPM)
Figure 2: Notation of dynamic features The first step of the SPL developer is to analyze the design
of the SPL for possible late variation points and model them
Fig. 2 depicts the visual representation of dynamic feature in a dynamic DS-JPM. For each late variation point, the
models and the possible constraints. Dynamic features are developer defines the context for this VP, i.e., a properties
map that defines identifiers referring to relevant values, e.g., 1 class SalesScenarioDFL extends PointcutDSL {
the identifier “customerOrder” refers to the business object 2 ...
in the dynamic context of the running application. 3 Pointcut receive order (long quantity ) {
4 return new ReceiveOrderPredicate(quantity );
Late VPs can be defined at various levels of abstraction 5 } }
in the SPL and thus identify different artifacts, e.g., model 6
elements or source code points. At the model level, late VPs 7 class ReceiveOrderPredicate extends PrimitivePCD {
8 ReceiveOrderPredicate(long quantity ) {...}
are modeled as annotations on modeling elements. For ex- 9 ...
ample, in a UML activity diagram, one activity is annotated 10 boolean match(ReceiveOrderJP jp) {
to be dynamically variable. These annotated modeling ele- 11 long orderOuantity = computeQuantity(jp.context.get(”order ”));
12 if ( orderOuantity < quantity ) return true ;
ments are treated in a special way by code generators. Late 13 return false ;
VPs require a facility for dynamic de-/activation, thus, the 14 } }
respective source code elements for the model elements are
generated, e.g., classes or methods, and the de-/activation
is provided by generating domain-specific aspects for these Figure 3: Excerpt of the Sales Scenario DFL imple-
source code elements. At the code level, the late VPs refer mentation for selecting an example late VP
to code elements, such as a class, an attribute, a method,
or an expression in the body of a method, e.g., when an ac- The AO instrumentation of the SPL binds context values at
tivity is implemented in a method, the late VP casts on the late variation points to instances of these join point types.
call to this method. The full technical details of the definition of a DS-JPM are
An excerpt of late VPs that we have identified in the Sales elaborated in [8].
Scenario inside the order management workflow is presented
in the following: 4.2 Quantification over Late Variation Points
1) Payment type selection: The customer chooses a (DS-PCL)
specific payment type, e.g., credit card or cash-on-delivery. To allow the dynamic features to quantify over late vari-
This step presents various payment types to the customer. ation points, the SPL developer declares predicates on the
Variation at this point can restructure the choice of payment late variations points. In principle, a dynamic feature can
types, e.g., filtering to a more specific list. The context select every one of the defined late variation points. All late
made available at this late variation point are the choice variation points are made available by a set of predicates,
of payment types presented to the customer as well as the which can be combined using logical expressions (and, or,
customer’s concrete choice. not). For each late variation point, a predicate is defined
2) Price calculation: The price of an order or a quota- that selects this point. For the above late variation points,
tion is calculated as the sum of the prices of the contained the following predicates are defined: 1) payment_type, 2)
order items. This is a late variation point, that allows to in- price_calculation, and 3) receive_order.
troduce new pricing strategies and override existing strate- Further, the predicates can be parameterized, e.g., to con-
gies, e.g., to define a discount and allowances on the price. strain late variation points depending on runtime values of
The context is the order for which the price is calculated. the application context. For example, receive_order(quantity)
From the domain model this implies the exposure of the in- defines a parameterized predicate that filters late variation
dividual items in the order, since they are accessible via the points, where the quantity of the order is less than a certain
order. threshold, e.g., receive_order(1000) selects the late vari-
3) Receive order: The first step in the order manage- ation points of all orders with a quantity of less than 1000
ment is the reception of new orders. In the Sales Scenario units. Fig. 3 depicts the implementation of the receive_or-
orders enter the workflow with all information on the cus- der(quantity) predicate, which constitutes a domain-specific
tomers and the payment modalities. This step is a late vari- keyword in the Sales Scenario DFL. Using the POPART
ation point such that we can insert an approval step before framework, the receive_order(long) method becomes a
packing and shipping the order. Such an additional step keyword in the aspect runtime that can be used to declare
then approves whether the customer is trustable before an where a dynamic feature is active. The concrete matching
unpaid cash-on-delivery order is shipped. The available con- happens in the ReceiveOrderPredicate, where the match
text is the customer, the order, and the selected payment method of the framework is adopted to match at join points
method. (ReceiveOrderJP) that have an order in their runtime con-
From the identified late variation points the SPL devel- text, that contains a quantity lower than the threshold. For
oper builds the DFL for a particular dynamic software prod- every predicate, the domain-specific pointcut language (DS-
uct line. To allow the dynamic aspects to intercept the late PCL) defines a domain-specific keyword that selects the join
variation points of the DSPL, the SPL developer declares points of the corresponding late variation point. Each DS-
an instrumentation 1 of the SPL implementation, that rei- PCL keyword creates a primitive pointcut designator as a
fies SPL concepts. Using this instrumentation we define a sub-class of Pointcut in the AO model used to filter Join-
domain-specific join point model. In this DS-JPM, each late Point objects. More details about implementing a DS-PCL
variation point is represented through a SPL-specific join are elaborated in [8].
point type as a sub-class of JoinPoint and its context is a
properties map. For the above late variation points, the SPL 4.3 Generic AO Concepts
developer defines join point types: 1) PaymentTypeSelec-
To define dynamic features as aspects the following general-
tionJP, 2) PriceCalculationJP, and 3) ReceiveOrderJP.
purpose AO concepts are provided by Popart and reused in
1 the DFL. The aspect keyword defines a new dynamic aspect
In the case-study AspectJ aspects are used to reify runtime
information. module, parameters define its name and initial activation
status (deployed), i.e., active (true) or inactive (false). 5. CASE STUDY
Popart allows to define where to insert actions at a late To validate our concept, we have implemented the Sales
variation point using before/after advice, which execute Scenario as an example dynamic SPL, parts of which were
before or after reaching the late variation point. In addi- introduced in Sec. 2. While static variability is modeled and
tion, around advice replaces the actions of a late variation implemented using existing technologies, the late variability
point and proceed invokes the replaced actions in an around is modeled and implemented using the technology that is
advice. To define constraints from the feature model the presented in this paper and that helps to manage late vari-
following mechanics are used: i) assert validates a boolean ability. The late variability technology seamlessly integrates
expression when loading the aspect and is used to model with the above technologies in the Eclipse-based workbench.
dependencies to static features. ii) declare_dependency, In the remainder of this section, we first summarize the static
declare_exclusion, and declare_precedence are used to part of the Sales Scenario, then we elaborate how the dy-
declare aspect interaction constraints that are detected and namic features are implemented using the feature DSL.
resolved at runtime by Popart. For the implementation of the static part of the SPLs, we
used the Eclipse based facilities for developing SPLs, pro-
vided by the feasiPLe research project [9]. The static vari-
4.4 DSPL specific AO language (DFL) ability is modeled and implemented using extension of ex-
To instantiate the DFL, the SPL developer mixes the ex- isting methodology, adapted by feasiPLe to better support
isting generic AO language with the specific parts for the model-driven and aspect-oriented software development of
SPL. Popart take care that all common and specific parts SPLs.
of the AO syntax are integrated together into a SPL-specific To give a short overview of the methodology: 1) we de-
aspect language signed domain-specific languages (DSLs) for the different ap-
Using the DFL, each dynamic feature is mapped to a dy- plication domains (e.g., process, business objects, graphical
namic aspect. The aspect is declared with a unique name, view, etc.) as Ecore2 metamodels, and instantiated them
that maps to the corresponding feature and the aspect is into variant independent models (VIMs). 2) The model el-
either active or not depending on the (default) choice of the ements in these models were then mapped to features us-
user. For each specific variation at a late variation point, ing the FeatureMapper [15], and 3) using this mapping the
the aspect defines a pointcut-and-advice. Its pointcut uses VIMs were transformed into variant specific models (VSMs)
the DS-PCL to quantify over join points (i.e., it intercepts using pure::variants3 For each DSL, we also implemented
the execution of a late variation point) and its advice de- 4) one code generator in Xpand4 , and generated Java and
fines how to adapt selected variation points by inserting or AspectJ [1] code based on these VSMs using the code gener-
replacing certain actions at the join point (i.e., it adapts a ators. In summary, the Sales Scenario has 27 static features
late variation point). We will discuss concrete examples of and six dynamic features. The implementation consists of
dynamic aspects in the next section. 4,000 Java hand-written lines of code (LOC), 17.000 LOC
Each constraint on dynamic features is implemented as generated Java, 10.000 LOC related to oAW artifacts, 6,000
an aspect interaction in one of the aspects. A dynamic con- LOC AspectJ, and 130 LOC Groovy/Popart.
straint is defined using one of the declare-keywords. For In Fig. 4 the dynamic feature model of the Sales Scenario
implies, an aspect declares declare_dependency between is presented, of which we will discuss first the dynamic ap-
the two aspects with the corresponding feature names. For proval feature, and then the dynamic pricing strategy fea-
excludes, the aspect uses declare_exclusion; and for prece- ture. The purpose of the dynamic approval feature is to
dence, the aspect uses declare_precedence instead. Note validate customer creditability to reduce risk for large quan-
that for symmetric constraints such as excludes it does not tity orders. An implementation of the dynamic approval
matter which aspect actually declares the interaction. Re- feature from the Sales Scenario is shown in Fig. 5. In lines 1–
call that dynamic feature models are an extension to ’static’ 8, the class OrderManager (realizing the Customer Order
feature models. A static constraint on features can also be Mgmnt feature) is shown that is part of the static part of
defined using the assert keyword. the SPL. It implements one method for each step in the
Using our AO model at runtime for the composition of order management use case, i.e. receive, pack, and ship.
features and the detection and resolution of constraints has The execution of the method receive (lines 3–5) constitutes
several advantages. First, there is no need to consider all a late VP as modeled in the previous section. In Fig. 3, the
combinations of feature selections. When dynamic features class ReceiveOrderJP represents executions of the receive
are selected or deselected at runtime, the DSPL is automat- method and is used to declare the receive_order predicate.
ically adapted by Popart as aspects are composed at join This predicate is used in lines 10 and 15 (parameter quan-
points in the runtime model of the application. Second, the tity is optional), to specify where the different approval
dynamic AO mechanisms allow the declaration of runtime steps are inserted.
context-dependent feature interactions in conjunction with For the dynamic features, the three aspects in the ex-
a continuous enforcement of these constraints by validating ample are deployed to the running system. The Manual-
possible aspect interaction as specified in the rule base of Approval aspect defines a pointcut that selects the late VP
the AO model. Thus the DFL allows the safe specification of the receive step by using the corresponding predicate re-
of features that interact with each other, because advice are ceive_order defined in Sec. 4. The advice extends the SPL
ordered, conflicting advice are never executed at the same at the selected variation point by opening a dialog (line 11)
time, and dependencies are enforced. We will see example
2
resolutions in the next section. http://www.eclipse.org/modeling/emf/
3
http://www.pure-systems.com/
4
http://www.openarchitectureware.org/
Sales
Scenario
Account
Mgmnt
Customer Customer
Ratings Groups Commu- Payment
nication
Consumer Enterprise Cash On
Email Letter Fax Invoicing Credit Card
Delivery
Competitor Prospect Customer
Order Mgmnt
Sales
Product Returns
Processing
Mgmnt
Availability Credit
Check Check
Approval
Stock Quotation
Process
Mgmnt
Single Multiple AutomaticApprove ManualApprove
Stock Stock
Pricing
Strategy
implies implies excludes, precedes
Enterprise Quantity
Discount VATPricing
Discount
mandatory static feature
optional
dynamic feature
exclusive or implies excludes, precedes precedes
or constraint
precedes
Figure 4: Dynamic feature model of the Sales Scenario; extending notation from [6] with dynamic features
1 class OrderManager { the SPL dynamicity, the AutomaticApproval aspect is not
2 ... deployed (i.e. inactive) during startup. At a later point,
3 void receive (Order order) { i.e. when the company exceeds a certain amount of placed
4 // receive the order from customer ( is a dynamic VP)
5 } orders, the automated approval is deployed.
6 void pack(Order order) {...} The feature interaction between the two approval features
7 void send(Order order) {...} is mapped to an aspect constraint, which is delcared in a sep-
8 }
9 aspect(name:”ManualApproval”, deployed:true) { arate aspect (ApprovalInteraction). Line 18 declares the
10 after ( receive order () ) { aspects ManualApproval and AutomaticApproval to be mu-
11 boolean trustable = UI.openApprovalDlg(order).isCustomerTrustable (); tually exclusive, i.e., they may not affect variation points at
12 if (! trustable ) // clarify customers creditibility
13 } } the same time. The following line declares the precedence
14 aspect(name:”AutomaticApproval”, deployed: false ) { constraint between the two features. We choose to declare
15 after ( receive order (100) ) { ... } } the interaction in a separate aspect, because this has the
16 aspect(name:”CreditCheck”) {...}
17 aspect(name:”ApprovalInteraction ”, deployed : true) {
advantage that the implementation of the two aspects is in-
18 declare exclusion ”ManualApproval”, ”AutomaticApproval”; dependent from each other. When the AutomaticApproval
19 declare precedence ”AutomaticApproval”, ”ManualApproval”; aspect is deployed, the interaction at the late VP is detected
20 declare dependency ”AutomaticApproval”, ”CreditCheck ”;
21 }
and resolved according to the constraints. Because of the dy-
namic exclusion constraint in line 18, a conflict is detected
that is resolved by taking into account the dynamic prece-
Figure 5: Dynamic feature: order approval dence constraint in line 19. As the AutomaticApproval has a
higher precedence, its advice will be executed and the advice
of ManualApproval are skipped. Because of the dynamic
dependency constraint in line 20, the advice of Automatic-
for the manual approval in a user interface. If the user is not Approval requires the CreditCheck feature to be deployed.
trustable, a sub-workflow is invoked (line 12) to clarify the For the Sales Scenario, we have implemented a flexible
status of the customer, e.g., the customer presents further pricing strategy feature using our late variability support,
credentials, pays the order before shipment, or the process is to introduce new pricing strategies as dynamic features into
aborted. The aspect AutomaticApproval (line 15) is imple- a running product line. The static part of our SPL comes
mented similarly to the manual approval feature, but only with a simple pricing strategy that calculates the price of an
executes at late VPs where the quantity of the received order order by calculating the sum of the price of its order items.
is smaller than 100. As an automation, customer creditabil- However, in the context of discounts, allowances and taxes,
ity is checked via the corresponding credit card. To illustrate the actual price of an order depends on various requirements
1 aspect(name:”VATPricing”) { 6. EVALUATION
2 final float VAT FACTOR = 1.19; //Currently the German VAT is 19% There are certain limitations in the current implementa-
3 around ( pricing ()) {
4 return proceed() ∗ VAT FACTOR; tion that prevent our technology to be used in production.
5 } } 1) In a real-world business scenario, new business rules
6 aspect(name:”EnterpriseDiscount ”) { would need to be defined and loaded to the Sales Scenario
7 assert Class .forName(”EnterpriseCustomer”) != null ;
8 ... during its lifetime. In the case study, we provide support
9 } only for de-/activation of features via a management con-
10 aspect(name:”QuantityDiscount”) {...} sole. For convenient runtime evolution a special manage-
11 aspect(name:” PricingInteraction ”) {
12 declare precedence ”QuantityDiscount”, ”VATPricing”; ment console is required, through which new dynamic fea-
13 declare precedence ”EnterpriseDiscount ”, ”VATPricing”; ture can be uploaded into a running system. Popart comes
14 declare exclusion ”EnterpriseDiscount ”, ”QuantityDiscount”; with the necessary support, since it allows to deploy aspect
15 declare precedence ”EnterpriseDiscount ”, ”QuantityDiscount”;
16 }
definitions provided as a String, due to its roots in Groovy.
2) Our approach does detect feature interactions if the in-
teracting aspects affect the same join point, but omits cer-
Figure 6: Dynamic feature: pricing strategy tain indirect interactions, e.g., two aspect accessing shared
state. Such interactions are also possible using our approach,
i.e. through the contexts available to aspects. Using these
interactions in a structured way can prove advantageous.
from the business domain, e.g., there are business rules that For example in the Sales Scenario this allows us to define
add the value added tax (VAT) to the order price, depending a manual approval, that checks in the context of the join
on the customers country or rules that give various discounts point, that the order was not automatically approved and
to certain customers. In the context of discounts, the inter- only in this case asks the user with a feedback. However,
action of features is again of high interest. Depending on the such interactions are currently not detected by Popart and
actual context, two discounts are applicable to one order at are not modeled at the level of the feature model. How to
the same time, or only one discount is allowed to be applied. capture such feature interactions in a structured way at the
A late VP has been inserted into the price calculation of modeling level is an interesting research question.
orders that exposes the necessary context, such as the order, 3) When deploying new dynamic features at runtime, the
its items, and the customer. We use 3 aspects shown in integrity of internal state of adapted use cases is not ensured
Fig. 6 for realizing the dynamic pricing features: 1) VATPric- by Popart. Adapting a running use case that has an inter-
ing: calculating the VAT, 2) EnterpriseDiscount: giving nal state is difficult, as for example previously started stack-
a discount to enterprise customers5 , and 3) QuantityDis- frames may be omitted from the aspects execution leading
count: a special discount is applied when the order contains to erroneous internal state. In our case study, we did not ex-
a large quantity of items. Note that all aspects advise the perience such problems because deploying aspects was only
same late variation point through the pricing predicate. allowed after all running instances of a business process, e.g.
In this scenario the dynamic feature interactions between the order management use case, were completed.
the pricing strategies must be handled by appropriate aspect To evaluate our approach w.r.t. performance scalability,
constraints (Fig. 6), as declared in the PricingInteraction we have determined the relative instrumentation overhead
aspect. The tax calculation is performed after all other cal- incurred by the AO runtime. We executed our Sales Sce-
culations have been applied, consequently the VATPrice as- nario case study with and without our AO runtime, i.e., in
pect is declared to have the lowest precedence, using the Popart and in Java. To measure the bare instrumentation
aspect precedences in lines 12 and 13. The Enterprise- overhead, we do not apply any dynamic aspects at the de-
Discount feature requires that the static feature Enterprise clared late VPs. Thus the basic AO instrumentation is in
has been selected for the product. To check the presence, place and delegates to our matching algorithm, which does
an assertion is used to check whether the class Enterprise- almost nothing, i.e. iterating over an empty list of poten-
Customer, corresponding to the Enterprise feature, is avail- tial dynamic aspects. We measured the relative overhead
able in the product. This static assertion is checked during incurred by the instrumentation for repeating execution of
startup of the application. the variation point and found the approach to scale well with
The EnterpriseDiscount and the QuantityDiscount ex- the number of late VPs. When the VP is executed only once
clude each other (line 14), since for these particular discounts there is a large overhead of 97%, but when the late VPs is
in the product line we choose to disallow double discounts. visited more often, the overhead is reduced to a value as
Such a situation arises only if an order contains a significant low as 0.8% (1000 executions). This is due to a dynamic
quantity of items and is ordered by an EnterpriseCustomer. adaptive optimization applied by the Java virtual machine,
Because of the exclusion constraint in line 14, the interaction which identifies frequently called methods at runtime and
of QuantityDiscount and EnterpriseDiscount is detected performs more advanced optimizations such as inlining.
as a conflict. Because in line 15 the EnterpriseDiscount
is declared to have a higher precedence than Quantity-
Discount, Popart can resolve this conflict by not excluding 7. RELATED WORK
the effects of the dynamic feature with a lower precedence,
Most AOP tools only support aspect precedences similar
i.e. QuantityDiscount, in the composition.
to AspectJ [1]. Several AOP tools allow expressing aspect
5
The order business object (BO) refers to the corresponding dependencies (such as [19, 7]) but there is little work on
customer BO, which is typed as a representative of a com- context-dependent interactions [14, 17, 7].
pany or a private customer. We use the type to decide if the Context-oriented programming [5] supports modularizing
discount should be applied. features into layers of functionality that can be activated
and deactivated at runtime. This work supports only static [4] A. Charfi and M. Mezini. Hybrid Web Service
dependencies between interacting features. Composition: Business Processes meet Business Rules.
Research on dynamic product-lines [12] [13] is particularly In International Conference on Service Oriented
relevant. In [11], DSPLs are specified as a set of components Computing, pages 30–38, 2004.
that can be exchanged at runtime. The components follows [5] P. Costanza and T. D’Hondt. Feature Descriptions for
the design of software reconfiguration patterns and have a Context-oriented Programming. In Workshop on
set of state charts that define all valid reconfiguration cases. Dynamic Software Product Lines [12], 2008.
In contrast to our approach, components have to implement [6] K. Czarnecki and A. Wasowski. Feature diagrams and
patterns and interfaces, features with a crosscutting char- logics: There and back again. In SPLC ’07:
acter are not modularized, and runtime evolution is disal- Proceedings of the 11th International Software Product
lowed because all possible reconfigurations must be known Line Conference (SPLC 2007), pages 23–34,
and enumerated into the state chart models at design time. Washington, DC, USA, 2007. IEEE Computer Society.
Cetina et al. [3] discuss possible architectures of dynamic [7] T. Dinkelaker, M. Mezini, and C. Bockisch. The Art of
software product-lines and distinguish connected and dis- the Meta-Aspect Protocol. In AOSD, 2009.
connected architectures for DSPLs, depending on whether [8] T. Dinkelaker, M. Monperrus, and M. Mezini.
the DSPL or the product is responsible for reconfiguration. Untangling crosscutting concerns in domain-specific
They propose to follow a hybrid approach that combines the languages with domain-specific join points. In
best of both, our approach can be used to implement such Workshop on Domain-specific Aspect languages (at
a hybrid approach, because every product is delivered with AOSD), 2009.
a runtime model of the DSPL. Our approach complements
[9] The feasiPLe Homepage. http://feasiple.de/.
their discussion by prosing a concrete realization.
Trinidad et al. [21] propose the realization of DSPLs [10] Y. Gil, E. Deelman, M. Ellisman, T. Fahringer,
through a mapping of features onto components in a com- G. Fox, D. Gannon, C. Goble, M. Livny, L. Moreau,
ponent model. Their component architecture introduces the and J. Myers. Examining the challenges of scientific
specialized concepts of feature component that can be de- workflows. Computer, pages 24–32, 2007.
/activated and feature relationship that can be un-/linked. [11] H. Gomaa and M. Hussein. Dynamic software
However, the approach does not consider crosscutting fea- reconfiguration in software product families. LNCS,
tures, it enforces only static constraints on features, and it pages 435–444, 2004.
does not allow to consider runtime context. [12] S. Hallsteinsen and et al. International Workshop on
Dynamic Software Product Lines (DSPL). In
8. CONCLUSION International Software Product Line Conference,
2007-2009.
We have proposed a novel approach for dynamic software
[13] S. Hallsteinsen, M. Hinchey, S. Park, and K. Schmid.
product-lines that uses a dynamic feature model to describe
Dynamic software product lines. Computer,
the variability in the DSPLs. The approach combines several
41(4):93–95, 2008.
trends in aspect-oriented programming for DSPLs, namely
dynamic aspects, runtime models of aspects, as well as de- [14] J. Hannemann, R. Chitchyan, and A. Rashid. Analysis
tection and resolution of aspect interactions. We have imple- of aspect-oriented software. LNCS, 2004.
mented and validated the approach and preliminarily eval- [15] F. Heidenreich, J. Kopcsek, and C. Wende.
uation results show its scalability. Featuremapper: Mapping features to models. In ICSE,
Although, current support for managing aspect interac- 2008.
tions is weak in existing dynamic AOP tools, we strongly [16] G. Kiczales, J. Lamping, A. Menhdhekar, C. Maeda,
believe that dynamic AOP solutions in general can be used C. Lopes, J. Loingtier, and J. Irwin. Aspect-Oriented
for dynamic product-lines. The biggest challenges for dy- Programming. In ECOOP, 1997.
namic AOP for DSPLs are a) addressing the limitations [17] G. Kniesel. Detection and Resolution of Weaving
found when building (static) SPLs that are also present in Interactions. Transactions on Aspect-Oriented
dynamic AOP, b) improving the support to handle aspect in- Software Development V, page 186, 2009.
teractions in particular context-dependent interactions, and [18] M. Papazoglou, P. Traverso, S. Dustdar, F. Leymann,
c) scalability requirements, such as performance in case of and B. Krämer. Service-oriented computing: A
large DSPLs. research roadmap. International Journal of
Future work will address the current limitations. In par- Cooperative Information Systems, 17(2):223–255, 2008.
ticular, we would like to provide better means to scope [19] É. Tanter. Aspects of composition in the Reflex AOP
feature constraints and wildcards in constraint expressions, kernel. LNCS, 4089:98–113, 2006.
e.g., to specify that a constraint must be enforced a global [20] E. Tanter and J. Noye. A Versatile Kernel for
application scope, for all sub-features of a certain feature, Multi-language AOP. In GPCE, 2005.
and for all features that names starts with a certain prefix. [21] P. Trinidad, A. Ruiz-Cortés, J. Pena, and
D. Benavides. Mapping Feature Models onto
9. REFERENCES Component Models to Build Dynamic Software
[1] AspectJ Home Page. Product Lines. In DSPL [12], 2007.
http://www.eclipse.org/aspectj/.
[22] J. van Gurp. Variability in software systems: the key
[2] CaesarJ Homepage. http://caesarj.org/. to software reuse. PhD thesis, Dept. of Software
[3] C. Cetina, V. Pelechano, P. Trinidad, and A. Cortes. Engineering & Computer Science, Blekinge Institute
An Architectural Discussion on DSPL. In Software of Technology, 2000.
Product Line Conference, pages 59–68, 2008.