Staged Configuration Through Specialization and Multi-Level
Configuration of Feature Mo dels
Krzysztof Czarnecki
1
, Simon Helsen
2
, and Ulrich Eisenecker
3
1
University of Waterloo, Canada
2
Interactive Objects Software GmbH, Germany
3
University of Leipzig, Germany
Abstract Feature modeling is a key technique for capturing commonalities and variabilities in sys-
tem families and product lines. In this paper, we propose a cardinality-based notation for feature
modeling, which integrates a number of existing extensions of previous approaches. We then intro-
duce and motivate the novel concept of staged configuration. Staged configuration can be achieved
by the stepwise specialization of feature models or by multi-level configuration, where the configu-
ration choices available in each stage are defined by separate feature models. Staged configuration
is important because in a realistic development process, different groups and different people make
product configuration choices in different stages. Finally, we also discuss how multi-level config-
uration avoids a breakdown between the different abstraction levels of individual features. This
problem, sometimes referred to as “analysis paralysis”, easily occurs in feature modeling because
features can denote entities at arbitrary levels of abstractions within a system family.
Key words: Software product lines, system families, domain analysis, software configuration
1 Introduction
Software product-line engineering (also known as system-family engineering) seeks to exploit the com-
monalities among systems from a given problem domain while managing the variabilities among them
in a systematic way (Clements and Northrop, 2001; Weiss and Lai, 1999; Parnas, 1976). In product-line
engineering, new product variants can be rapidly created based on a common set of reusable assets such
as a common architecture, components, models, development processes, etc.
4
Feature modeling is an important technique for capturing and managing commonalities and variabil-
ities in product lines throughout all stages of product-line engineering. At an early stage of product-line
development, feature modeling is used for product-line scoping, i.e., deciding which features should be
supported by a product line and which should not. Scoping involves recording and assessing information
in feature models such as which features are important to enter a new market or remain in an existing
market, which features incur a technological risk, what is the projected development cost of each feature,
and so forth (DeBaud and Schmid, 1999). In product-line design, the points and ranges of variation
captured in feature models need to be mapped to a common product-line architecture (Czarnecki and
Eisenecker, 2000; Bosch, 2000). In actual product development, feature models can drive requirements
elicitation and analysis, help in estimating development cost and effort, and provide a basis for automated
product configuration.
Feature models also play a key role in generative software development (Czarnecki and Eisenecker,
2000; Greenfield and Short, 2004). Generative software development aims at automating application
engineering based on system families: a system is generated from a specification written in one or more
textual or graphical domain-specific languages (DSLs) (Weiss and Lai, 1999; Czarnecki and Eisenecker,
2000; Cleaveland, 2001; Batory, Johnson, MacDonald and von Heeder, 2002; Greenfield and Short, 2004).
In this context, feature models are used to scope and develop DSLs (Czarnecki and Eisenecker, 2000;
Work done while at the University of Waterloo.
4
System-family engineering is mainly concerned with building systems from common assets, whereas software
product-line engineering additionally considers scoping and managing common product characteristics from the
marketing perspective. In this paper, we use both terms interchangeably.
Deursen and Klint, 2002), which may range from simple parameter lists or feature hierarchies to more
sophisticated DSLs with graph-like structures.
Feature modeling was originally proposed as part of the Feature-Oriented Domain Analysis (FODA)
method (Kang, Cohen, Hess, Nowak and Peterson, 1990), and since then, it has been applied in a range
of domains including telecom systems (Griss, Favaro and d’Alessandro, 1998; Lee, Kang and Lee, 2002),
template libraries (Czarnecki and Eisenecker, 2000), network protocols (Barbeau and Bordeleau, 2002),
and embedded systems (Czarnecki, Bednasch, Unger and Eisenecker, 2002; Lohmann, Schr¨oder-Preikschat
and Spinczyk, 2005). Based on this growing experience, a number of extensions and variants of the original
FODA notation have been put forward (Griss et al., 1998; Czarnecki, 1998; Hein, Schlick and Vinga-
Martins, 2000; van Gurp, Bosch and Svahnberg, 2001; Lee et al., 2002; Riebisch, B¨ollert, Streitferdt and
Philippow, 2002; Czarnecki et al., 2002; Beuche, 2003; Cechticky, Pasetti, Rohlik and Schaufelberger,
2004).
1.1 Contributions and Overview
In this paper, we make the following contributions: we present a cardinality-based notation for feature
models, which integrates and adapts four existing extensions to the FODA notation—namely feature
cardinalities, group cardinalities, feature diagram references, and attributes. We also propose the novel
concept of staged configuration, which can be achieved either by stepwise specialization of feature models
or by multi-level configuration, where the configuration choices available in each stage are defined by
separate feature models. Finally, we discuss how the concept of multi-level configuration helps avoiding
the problem of “analysis paralysis” in feature modeling, which amounts to a breakdown between the
different abstraction levels of individual features.
The remainder of the paper is organized as follows. Section 2 reviews background concepts and related
work on feature modeling. Our cardinality-based notation for feature modeling is presented in Section 3.
Staged configuration is described in Section 4. Section 5 describes how “analysis paralysis” in feature
modeling can be avoided thanks to multi-level configuration. A larger example of multi-level configuration
including some observations is presented in Section 6. Related work on incorporating time in variability
modeling and configuration is discussed in Section 7. Appendix A gives a comparison of three different
notations for feature modeling.
Note: A shorter version of this paper was presented at the Software Product Line Conference (Czarnecki,
Helsen and Eisenecker, 2004). The current paper extends the earlier version with new material on multi-
level configuration (major parts of Section 4), process of feature modeling (Section 5), and electronic
commerce example (Section 6).
2 Background
2.1 Features, Feature Diagrams, and Feature Models
A feature is a system property that is relevant to some stakeholder and is used to capture commonalities
or discriminate among systems in a family (Czarnecki and Eisenecker, 2000). Note that while the original
definition by Kang et al. (Kang et al., 1990) has defined features as “user-visible” properties, we allow
features with respect to any stakeholder, including customers, analysts, architects, developers, system
administrators, etc. Consequently, a feature may denote any functional or non-functional characteristic at
the requirements, architectural, component, platform, or any other level. Features are organized in feature
diagrams. A feature diagram is a tree with the root representing a concept (e.g., a software system) and
its descendant nodes being features. In the FODA feature diagram notation (see the leftmost column of
Table 7 in Appendix A), features can be mandatory, optional,oralternative. Feature models are feature
diagrams plus additional information such as feature descriptions, binding times, priorities, stakeholders,
and so forth.
Feature diagrams offer a simple and intuitive notation to represent variation points in a way that is
independent of implementation mechanisms such as inheritance or aggregation. It is important not to
confuse feature diagrams with part-of hierarchies or decompositions of software modules. Features may
or may not correspond to concrete software modules. In general, we distinguish the following four cases:
2
– Concrete features such as data storage or sorting may be realized as individual components.
– Aspectual features such as synchronization or logging may affect a number of components and can
be modularized using aspect technologies.
– Abstract features such as performance requirements usually map to some configuration of components
and/or aspects.
– Grouping features may represent a variation point and map to a common interface of plug-compatible
components, or they may have a purely organizational purpose with no requirements implied.
2.2 Summary of Existing Extensi ons
Since its initial introduction in the technical report by Kang et al. (1990), several extensions and variants
of the original FODA notation have been proposed. In the following summary, we abstract from variations
in concrete syntax and focus on the conceptual extensions.
– feature cardinalities. Features can be annotated with cardinalities, such as [1..∗] or [3..3]. Mandatory
and optional features can be considered special cases of features with the cardinalities [1..1] and [0..1],
respectively. Feature cardinalities were motivated by a practical application (Czarnecki et al., 2002),
after being initially discouraged (Czarnecki and Eisenecker, 2000, p. 117).
– groups and group cardinalities. Alternative features in the FODA notation can be viewed as a grouping
mechanism. Two further kinds of groups were proposed in Czarnecki’s (1998) thesis: the inclusive-or
group and the inclusive-or group with optional subfeatures (see the middle column of Table 7 in
Appendix A).
5
The concept of groups was further generalized by Riebisch et al. (2002) as a set of
features annotated with a cardinality specifying an interval of how many features can be selected
from that set. The previous kinds of groups become special cases of groups with cardinalities (see the
rightmost column of Table 7 in Appendix A).
– attributes. Attributes were introduced by Czarnecki et al. (2002) as a way to represent a choice of a
value from a large or infinite domain such as integers or strings. An elegant way to model attributes
proposed by Bednasch (2002) is to allow a feature to be associated with a type, such as integer or
string. A collection of attributes can be modeled as a number of subfeatures, where each is associated
with the desired type.
– relationships. Several authors (e.g., Griss et al., 1998; van Gurp et al., 2001; Lee et al., 2002) proposed
to extend feature models with different kinds of relationships such as consists-of or is-generalization-
of.
– feature categories and annotations. FODA distinguishes among context, representation, and oper-
ational features. Griss et al. (1998) propose functional, architectural, and implementation feature
categories. Section 2.1 gives yet another categorization. Additional information on features suggested
in FODA include descriptions, constraints, binding time, and rationale. Other examples are pri-
orities, stakeholders, default selections, open-or-closed-for-extensions attribute, and exemplar sys-
tems (Czarnecki, 1998).
– modularization. A feature diagram may contain one or more special leaf nodes, each representing a
separate feature diagram (Bednasch, 2002). This mechanism allows breaking up large diagrams into
smaller ones and reusing common parts in several places. This is an important mechanism because,
in practice, feature diagrams often become too large to be considered in their entirety.
3 Cardinality-Based Feature Modeling
This section proposes a cardinality-based notation for feature modeling, which is based on modest changes
to the previously introduced concepts of feature cardinalities, group cardinalities, and diagram modular-
ization (see Section 2.2).
In particular, a feature cardinality specification may consist of a sequence of intervals. Furthermore,
our notation does not allow features that are members of a feature group to be qualified with feature
5
Inclusive-or features were introduced independently by Czarnecki (1998) and Griss et al. (1998). However,
inclusive-or features as proposed by the latter authors imply reuse-time binding, whereas inclusive-or features
as proposed by the former author are independent of binding time.
3
environmentVariables
securityProfile
fileIO
unrestricted
restricted
open
close
fileDialog
lowerCase
upperCase
digit
specialChar
chars
passwordPolicy
expiration
inDays (Int)
never
write
read
permission
[0..*]
[0..*]
<2−4>
<0−2>
filepath(String)
permissionSet(String)
Figure 1. Security profile example
cardinalities. This is because a feature cardinality is a property of the relationship between a single
subfeature and its parent. Similarly, a group cardinality is a property of the relationship between a
parent and a set of subfeatures. Next to cardinalities, we have the notion of feature diagram references,
which allow us to reuse or modularize feature models in a similar fashion as described by Bednasch (2002).
In contrast to Bednasch’s (2002) work, feature diagram references allow recursion, which may be either
direct or indirect. Direct recursion occurs when a feature diagram reference refers to the feature diagram
in which it resides, while indirect recursion involves more than one diagram.
The chosen set of conceptual extensions and their adaptations are motivated both by practical ap-
plications and the urge to achieve a balance between simplicity and conceptual completeness. Feature
cardinalities and attributes are common in modeling both embedded software (Czarnecki et al., 2002)
and enterprise software (see our example in Section 3.1). The primary motivation for including group
cardinalities is elegance and completeness. Although our experience so far shows that the vast majority
of groups are either exclusive-or or inclusive-or, other group cardinality values may still be useful in more
exotic situations, as shown by Riebisch et al. (2002) and in Section 3.1. Compared to the more profound
semantic implications of feature cardinalities, the addition of group cardinalities is semantically relatively
straightforward.
In our notation, we do not consider relationships between features such as consists-of or is-generalization-
of because we think that they are better modeled using other notations such as entity-relationship or UML
class diagrams. In general, we believe that a feature modeling notation should focus purely on capturing
commonality and variability. However, if necessary, a tool with an extensible metamodel (Bednasch, 2002;
Bednasch, Endler and Lang, 2002-2004) may allow the user to introduce additional kinds of relationships.
Finally, feature categories and other additional information are domain dependent, and as previously ar-
gued by Czarnecki et al. (2002), we think that they are better handled as user-defined, structured
annotations. Such annotations are also supported through an extensible metamodel (Bednasch, 2002).
3.1 A Security Profiling Example
As a practical example to demonstrate the expressiveness of our feature modeling language, consider a
feature model of an operating system security profile in Figure 1.
The password policy of the security profile has an expiration time and possible requirements on the
kind of characters to be used. Passwords can be set to never expire, or to expire after a given number
of days. The number of days a password remains valid can be set in the integer attribute of the inDays
feature. Generally, whenever a feature has an attribute, we indicate its type within parentheses after the
feature name, e.g., inDays(Int). It is also possible to specify a value of the associated type immediately
4
*
Feature
name
SolitaryFeature
featureCardinality
GroupedFeature
ContainableByF
ContainableByFG
FeatureGroup
groupCardinality
TypedValue
StringValue
value
IntValue
value
type
Attribute
RootFeature
FDReference
1
*
*
*
0..1
0..1
FeatureMode
l
Figure 2. UML metamodel for cardinality-based feature models
with the type, e.g., inDays(30:Int). The constraints on the kind of characters required in a password
are specified by a feature group with cardinality 2– 4. This means that any actual password policy must
specify between two and four (different) requirements on the kind of characters.
In our example, because no cardinality was specified for the group of expiration policies, the cardi-
nality 1– 1 is assumed (i.e., the expiration policies form an exclusive-or group).
The security profile also has zero or more permission sets. This is indicated with the feature cardinality
[0..∗]. If a feature cardinality is [1..1], we draw a little filled circle above the feature. Observe that features
belonging to a group do not have feature cardinalities.
A permission set determines various permissions for executing code. In our simple model, a permission
set has a string attribute to specify its name, and it allows us to specify permissions with respect to file
IO, file dialogs, and environment variables. Other examples would be permissions to access a database,
invoke reflection, access a Web address, etc. According to our model, file IO can be restricted to a list
of file paths, or it is unrestricted. For each file path, we can specify its name and associated read/write
permissions.
Notice that we use a feature diagram reference for the permission model because we want to reuse it
for environment variables. In this paper, we use a dashed line to represent a feature diagram reference,
but it should be noted that, in practice, a different representation may be necessary to avoid a convoluted
diagram. This is especially important if the purpose of the feature diagram reference is to modularize a
large feature model over different diagrams.
Finally, the permission to open a file dialog and to close it can be selected independently. The empty
circle above the features open and closed indicates that those features are optional, i.e., they have the
feature cardinality [0..1].
3.2 A Metamodel
Now that we have seen an example of a cardinality-based feature model, we explain the available concepts
more accurately by means of an abstract syntax model, where we will refer to the example in Figure 1
for clarification.
Consider the Unified Modeling Language (UML) metamodel for cardinality-based feature models in
Figure 2. A feature model consists of any number of root features, which form the root of the different
feature diagrams in the model. In the security profile example, both the features securityProfile and
permission are root features.
A root feature is only one of three different kinds of features. The other two are the grouped feature
and the solitary feature. The former is a feature which can only occur in a feature group. For example,
never is a grouped feature in a feature group, which is contained by the feature expiration. A solitary
feature is a feature which is, by definition, not grouped in a feature group. Many features in a typical
feature model are solitary; for example, the feature passwordPolicy and permissionSet.
Features can have an optional attribute of a certain type, and those attributes can have an optional
value. In this simplified model, we only have integer and string attributes.
5
