Download Variability Modeling in the Real - Generative Software Development

group
feature
feature
constraints hierarchy representation kinds
feature
constraints
other
concept
Kconfig
CDL
feature models [10]
Grouping
Individual
menu, menuconfig, choice
config
package, component, interface
option
feature
feature
Composition
Feature type
Switch
Data
None
single value
bool. value w/opt. data value
bool. value w/opt. attribute
bool, tristate
hex, int, string
(menu)
bool, booldata
booldata, data
none
(optional)
integer, string
(mandatory)
Specification
Child-to-parent impl.
Root
syntactic and computed
visibility
synthetic
syntactic and reparenting
configuration & visibility
synthetic
syntactic
configuration
explicit
Mutex [0..1]
Or [1..∗]
Xor [1..1]
Interval [m..n]
optional Boolean choice
mandatory tristate choice
mandatory Boolean choice
N/A
interface
interface
interface
interface
mutex group [4]
or group [4]
xor group
[m..n] group [16]
Configuration
Value restrictions
Derived features
Defaults
Visibility conditions
Expression operators
Binding modes
select
range
non-prompt default
prompt default
prompt condition
&&, ||, !, =, !=
three-value logic
requires, active if
legal values
calculated, interface
default value
active if
also inequality, arithm. and str. ops.
N/A
cross-tree constraint
cross-tree constraint
rare [5]
rare [4]
rare [5]
unspecified
rare [4]
Textual content
Modularization
Build symbols
Code mappings
prompt, help
textual inclusion
one-to-one
no, uses KBuild (m:n)
display, description
dynamic loading/unloading
one-to-many
yes (1:n), and build specifications
description
rare [3]
unspecified
N/A
constraint,
constraint,
constraint,
constraint,
int ≤ 1
int ≥ 1
int = 1
m ≤ int ≤ n
Table 1: Mapping of concepts between Kconfig, CDL and feature modeling
Feature representation. The semantics of a feature model is
a set of configurations. A configuration specifies the presence
or absence of each feature, and a value for the related integer
or string if the feature is present (when applicable).
Kconfig and CDL differ in the ways they represent configurations (see Tbl. 1, row 2). In Kconfig, a configuration
assigns a single value to each feature. If F is the set of all
features in the model, and Val is a set of all possible values,
then a particular configuration σ maps features to values:
σ : F 7→ Val
and if σ(f ) = v then v ∈ type-of(f )
Table 1 lists the possible feature types in three categories:
switch, data, and none. Switch features appear as a checkbox
in the configurator. Data features allow the user to input a
value in a text box. Kconfig’s menus have no type, which
corresponds to features of type none in CDL.
The Kconfig type bool has two values, y and n, internally
represented by 2 and 0; 0 denotes feature absence, while 2
means that the feature’s implementation is compiled statically into the kernel. Tristate resembles bool, except for
the additional m value, represented internally by 1, which denotes that the feature should be compiled as a dynamically
loadable module. For example JFFS2_ZLIB (k-32) has type
bool and JFFS2_FS (k-6) is tristate. Kconfig supports two
integer types: int (decimal) and hex (hexadecimal). Both
types also allow an empty value, which is used to encode the
absence of an integer feature. The type string is ambiguous
in this respect: a string feature with the empty value can
be seen as a present feature with that value or an absent
feature; the two cases are indistinguishable.
In CDL, every feature has two values: an enabled state and
a data value. The enabled state is a Boolean and encodes
the presence or absence of the feature; the data value is
dynamically typed and used to store numbers and strings.
Thus, a configuration maps features to value pairs:
σ : F 7→ {0, 1}×Val
and if σ(f ) = (e, d) then d ∈ type-of(f )
CDL refers to the type of a feature as a flavor. The available
flavors map neatly to FODA features as follows:
none
bool
data
booldata
7→
7
→
7
→
7
→
Mandatory with no attribute
Optional with no attribute
Mandatory with attribute
Optional with attribute
More precisely, features with the flavors none and data can
be made optional by specifying a configuration constraint
(explained later). Still, an optional feature with flavor none
or data differs from its respective bool or booldata counterpart: the latter two are shown as user-selectable checkboxes
in the configurator, whereas the former two have no checkboxes since their presence is controlled via visibility conditions. Figure 3 includes features assuming numeric values
(CYGOPT_FS_JFFS2_DEBUG), Bool values (CYGOPT_JFFS2_NAND), or strings (CYGOPT_FS_JFFS2_COMPRESS_CMODE).
Hierarchy. Typical modeling languages organize features
into hierarchies (Tbl. 1, row 3). We distinguish between syntactic and configuration hierarchy. The former is given by
the syntactic nesting of features, such as the nesting of configs in menus or choices in Kconfig, or options and components in other components and packages in CDL. The configuration hierarchy is shown to the user in a configurator (cf.
Fig. 2). In the notation of Fig. 1, the diagrammatic tree represents both the intended configuration hierarchy and the
syntactic nesting. In Kconfig and CDL the configuration
hierarchy can deviate from the syntactic one.
In Kconfig, syntactic nesting within menuconfigs and choices
will be reflected in the configuration hierarchy; however, configs can also appear as children of other configs, even though