While SPLE aims at systematic and planned reuse, product lines can also be realized using ad-hoc techniques, such as code cloning. In fact, our so far unpublished empirical
study on code cloning practices in industry [DRB+12] confirms that cloning—if performed
under strict governance—is a common development technique, even applied for product
2. Background
lines with up to 20 products. However, for larger variant spaces, configurator-based approaches using variability modeling are inevitable.
Problem Space Solution Space Mapping variability models, manifest files build system, generator code, resources, binaries
Figure 2.3.: Problem and solution space (adapted from [CØV02])
The notion of problem and solution space [CE00] provides a useful abstraction to describe the architecture of configurator-based approaches. Fig. 2.3 shows an illustration,
where the parts focused in this thesis are emphasized in gray. Variability models
belong to the problem space, representing requirements and capabilities of the system. A mapping connects the problem to the solution space, which provides realizations (code, resources) for the abstractions in the former. Variability in the solution space is realized using dedicated variability mechanisms, which classify into compositional and annotative approaches [KAK08]. Examples of the former are plugin mechanisms, generative programming [CE00] or component-oriented techniques, such as OSGi [OSG09]; and of the latter the C/C++ preprocessor [PO97], which is dominantly used in embedded software product lines.
We briefly illustrate the principal architecture of configuration-based product lines by describing the problem space, mapping, and solution space of three configurable open source systems—the eCos operating system, and the kernels of Linux and FreeBSD, which we investigated during our variability studies. We refer to their configuration options as features, given the mapping we will later establish (Table 4.1 in Section 4.3).
Fig. 2.4 summarizes common (solid line) and variable (dashed line) parts among the high-level architectures of the three systems. The problem space in Linux and eCos comprises variability models expressed in the CDL and Kconfig language, with graphical configurators on top (explained and analyzed in Chapter 4). The variability models describe features, their possible values, and dependencies among them. In contrast, FreeBSD has no variability model, but a list of features with textually documented dependencies (such as IPI_PREEMPTION → PREEMPTION), as shown in Fig. 2.5 (left). In- terestingly, all three systems distinguish between features configuring the target hardware architecture, and non-hardware (mostly functional) features.
The mapping between features and solution space (code) is realized within the build system. A mapping declares which files have to be included (compiled) for the final product under a certain configuration. It is explicitly specified within the variability model in eCos (see Section 4.4.6), hidden in imperative build logic in Linux (see Section 4.5.6), and explicitly declared as file presence conditions—logical expressions over features—in a
2.1. Software Product Lines Resour ces Header files Feature Definitions & constraints common features architecture -specific features (Makefile) Generator Configurator Header files #DEFINE #DEFINE ge ne ra te Source file … #IFDEF F1 …
#IF defined(F4 & F6 ) … #ENDIF … ENDIF define symbols select and compile configuration Core Kbuild / Make Scripts Presence Conditions optional source artifact generated artifact
Problem Space Mapping Solution Space
Kernel
Figure 2.4.: Variability-enabled architectures of Linux, eCos, and FreeBSD [BSCW10a]
mapping file in FreeBSD, as shown in Fig. 2.5 (right). In contrast to the imperative build scripts in Linux, both eCos and FreeBSD rely on a Makefile generator, which evaluates the mapping for a specific configuration and creates build specifications for the C/C++ files to compile.
All three systems generate header files that define activated features as preprocessor symbols, to be used with C/C++ #IF and #IFDEF preprocessor directives. These enable fine-grained parametrization of source files. These directives can even cut C/C++ language statements or conditional expressions. In fact, undisciplined annotations are
commonly used [KGR+11]. For an analysis of preprocessor use in open source product
lines, see for example [LAL+10].
Further Reading. The architectures we just described rely on variability mechanisms
known as annotative approaches [KAK08]—a preprocessor cuts out irrelevant parts of the platform during product derivation. From experience, this style represents the architecture of many open source configurable systems, but is also—reportedly—used in
commercial product lines3, such as Hewlett Packard’s printer firmware “Owen” [Ref09].
Compositional approaches, such as our analyzed software ecosystems (see Section 2.4 and Chapter 6), have faced more attention in the research community, due to their cleaner design and separation of concerns, as opposed to the maintenance-intensive C/C++ preprocessor [SC92]—sometimes even called the “IFDEF hell”. However, the work of
3
“I am not surprised that parameterization by preprocessor directives has been a sturdy meme which has spread in legacy code despite of its numerous disadvantages. This could only have happened because parameterization is very useful—it is the key to reuse, one of the great goals of software engineering.” [Sim99]
2. Background
# IPI_PREEMPTION instructs the kernel to preempt threads running on other # CPUS if needed. Relies on the PREEMPTION option
# Mandatory:
Device apic # I/O apic # Optional:
options MPTABLE_FORCE_HTT # Enable HTT CPUs
options IPI_PREEMPTION # Watchdog routines. # options MP_WATCHDOG # Debugging options. #
options COUNT_XINVLTLB_HITS # Counters for TLB events
options COUNT_IPIS # Per-CPU IPI interrupt counters ######################################################### # CPU OPTIONS
# You must specify at least one CPU (the one you intend to run on); # deleting the specification for CPUs you don't need to use may make # parts of the system run faster.
#
cpu I486_CPU
cpu I586_CPU # aka Pentium(tm)
cpu I686_CPU # aka Pentium Pro(tm)
hptmvraid.o optional hptmv\
dependency "$S/dev/hptmv/i386-elf.raid.o.uu”\ compile-with "uudecode < $S/dev/hptmv/i386-elf.raid.o.uu"\ no-implicit-rule
#
hptrr_lib.o optional hptrr\
dependency "$S/dev/hptrr/i386-elf.hptrr_lib.o.uu”\ compile-with "uudecode < $S/dev/hptrr/i386-elf.hptrr_lib.o.uu“\ no-implicit-rule
#
compat/linprocfs/linprocfs.c optional linprocfscompat/linsysfs/linsysfs.c optional linsysfs dev/ipmi/ipmi_pci.c optional ipmi pci dev/ipmi/ipmi_linux.c optional ipmi compat_linux
dev/kbd/kbd.c optional atkbd | sc | ukbd | usb2_input_kbd dev/le/if_le_isa.c optional le isa
dev/mem/memutil.c optional mem dev/mse/mse.c optional mse dev/mse/mse_isa.c optional mse isa dev/nfe/if_nfe.c optional nfe pci
Figure 2.5.: Feature specification without variability model (left) and feature-to-code mapping (right) in FreeBSD
Kästner [Käs10] shows that the advantages of both approaches can be combined by providing proper tool support for preprocessor-based variability.
Further implementation techniques are described by Czarnecki et al. [CE00] (generic programming, C++ template metaprogramming, aspect-oriented programming, and code generators), Pohl et al. [PBVDL05] (component frameworks), Völter et al. [VV11] (DSL-based transformation). Svahnberg et al. [SvGB05] provide a general taxonomy on variability mechanisms, while both van Gurp et al. [vGBS01] and Völter [Völ09] identify common patterns of variability mechanisms. As a realization of the intentional
programming paradigm [Sim95], the IDE Jetbrains MPS4 allows switching on and
off features mapped to nodes in the abstract syntax tree (AST) of the underlying programming language [Völ10, Völ11].
Finally, for further mapping techniques, we refer to Heidenreich et al. [HW07], who
present feature-to-model mappings with their tool FeatureMapper5, and Czarnecki et al.,
who describe the concept of a presence condition [CA05].