The document summarizes techniques for managing variability in software product lines, including feature modeling, binding times, implementation mechanisms, and testing approaches. It discusses feature modeling to define commonalities and variabilities, different binding times (design-time, compile-time, load-time, run-time), implementation using conditional compiling, parameters, design patterns, and approaches for testing product lines including combinatorial interaction testing and dissimilarity sampling when the number of possible products is large.

1. Software variability
management
Xavier Devroey <x.d.m.devroey@tudelft.nl>
Office 4.W.540 (4th floor, West side, new EWI building)

2. Introduction

3. software variability is the ability of
a software system or artefact to be efficiently
extended, changed, customised or configured
for use in a particular context.
Svahnberg, M., et al. (2005) ‘A taxonomy of variability realization techniques’,
Software - Practice and Experience, 35(8), pp. 705–754.

4. iOS 10.0.x
iOS 10.1.x
iOS 11.0.x
…
…
7.0.x
7.1.x
8.0.x
…
…
{
{
Hardware
• Processor
• RAM
• Screen size
• …
Platform
• OS
• Version
• Navigator
• …

5. Behaviour
gcc -help

6. 33
Options
0
A unique product for every person on this planet

7. 33 320
Options
0
More products than the
estimated atoms in the universe

8. 33 320 6,888
Options
0

9. How to…
…develop?
…test?
…maintain?
…define requirements?

10. Clone and Own

12. •Fast
•Cheap (at first)
•Limited
•Manage (large number of) copies
•Maintenance cost at each evolution
•Inconsistent evolution of copies

13. Software Product Line

14. Henry Ford 1901

17. •Tailor-made
• For individual customers
•Reduced costs
• Reusable parts can be combined in different ways
•Improved quality
• Parts can be standardized and checked in isolation
and reused and tested in multiple products.
•Time to market
• building on top of existing parts is much faster than
developing it entirely from scratch

18. A product is built by systematically combining
commonalities, common to all products, and
variabilities, specific to some products.
Features

19. A feature is a characteristic
or end-user-visible behaviour
of a software system.
Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer.

20. Pohl, K., et al. (2005) Software product line engineering: foundations, principles,
and techniques. Springer.
The software product line engineering framework

21. Pohl, K., et al. (2005) Software product line engineering: foundations, principles,
and techniques. Springer.
The software product line engineering framework
Commonalities and variabilities
definition and realisation
Product derivation

22. Feature Modelling

23. 33 320 6,888
Options
0

24. https://start.jhipster.tech/

25. 4833 320 5,426
Options
0

28. https://start.jhipster.tech/

29. What about constraints?
Which type of application would you like to create?
You can either use:
• Monolithic application […]
• Microservice application […]
• Microservice gateway […]
http://www.jhipster.tech/creating-an-app/
Which type of database would you like to use?
You can choose between:
• No database (only available when using a microservice application)
• An SQL database (H2, MySQL, MariaDB, PostgreSQL, MSSQL, Oracle),
which you will access with Spring Data JPA
• MongoDB
• Cassandra
• Couchbase
Social login (Google, Facebook, Twitter)
This option is only available if you selected an SQL, MongoDB, or
Couchbase database.

30. A feature model documents
the features of a product line
and their relationships.
Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer.

32. • Tree-like structure (directed acyclic graph).
• A feature is decomposed in sub- features using and, or,
or xor.
• Cross-tree constraints are expressed as boolean
expressions over the features.
• The semantics of a feature model corresponds to all the
valid products allowed by the feature model.
• A boolean feature model may be translated to a
Conjunctive Normal Form (CNF) formula

33. JHipster-App ∧ (Building ∨ ¬Maven) ∧ (Building ∨ ¬Gradle) ∧ (Maven ∨
Gradle ∨ ¬Building) ∧ (¬Maven ∨ ¬Gradle) ∧ (Server ∨ ¬Database) ∧ (Server
∨ ¬HibernateCache) ∧ (Server ∨ ¬Building) ∧ (Building ∨ ¬Server) ∧
(JHipster-App ∨ ¬Type) ∧ (JHipster-App ∨ ¬Client) ∧ (JHipster-App ∨
¬Server) ∧ (Type ∨ ¬JHipster-App) ∧ (Server ∨ ¬JHipster-App) ∧ (Type ∨
¬Monolithic) ∧ (Type ∨ ¬Microservice) ∧ (Type ∨ ¬Gateway) ∧ (Monolithic ∨
Microservice ∨ Gateway ∨ ¬Type) ∧ (¬Monolithic ∨ ¬Microservice) ∧
(¬Monolithic ∨ ¬Gateway) ∧ (¬Microservice ∨ ¬Gateway) ∧ (Database ∨
¬MongoDB) ∧ (Database ∨ ¬SQL) ∧ (Database ∨ ¬Cassandra) ∧ (MongoDB ∨ SQL
∨ Cassandra ∨ ¬Database) ∧ (¬MongoDB ∨ ¬SQL) ∧ (¬MongoDB ∨ ¬Cassandra) ∧
(¬SQL ∨ ¬Cassandra) ∧ (¬HibernateCache ∨ SQL) ∧ (¬Client ∨ Monolithic) ∧
(Client ∨ Microservice ∨ Gateway) ∧ True ∧ ¬False
Conjunctive Normal Form (CNF)
•SAT
•Consistency
•Valid configurations
•Dead features
•…

34. • Does your application have variability?
• Hardware
• Plattorm
• Features
• Bundels
• Plugins
• Command line options
• …
• How is it managed (if it is managed)?
• For developers
• Documentation only?
• Model (e.g., feature model)?
• Planned in the development lifecycle?
• For users
• Documentation only?
• Configurator (e.g., JHipster)?
• Validation mechanism?

35. Binding Time

36. Variability offers choices.
When we derive a product, we make decisions;
we decide which features will be included in the
product or not. We also say that we bind a decision.
Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer.

37. Design-time binding
• Clone and own

38. Compile-time Binding
Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer.
• Decided before or at compile time
• Allows optimisations
• Removes unnecessary code from the product
• Once the product has been generated and deployed, it is not
variable any more

39. Conditional compiling
• Implements variability with preprocessors
• Using annotated code (here, templates)

40. Conditional compiling
Yeoman
Configuration
Annotated code
Source code
without annotations

41. Load-time Binding
Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer.
• Decided after compilation when the program is started
• More flexible to reconfigure
• Requires a reboot
• Memory and performance overhead
• All variations are compiled into a single binary
• Consistency conditions must be checked at load time
• Unnecessary functionality may be considered as potential
security threat

42. Parameters and Configuration Files
Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer.
• Implement variability using conditional statements (such as if
and switch)
• Controlled by configuration parameters
• Passed to the method or module,
• Set as global variables in a system
Gcc

43. Run-time Binding
Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer.
• Decided during program execution and may be changed latter
• Used in dynamic adaptive systems (e.g., robots)
• Most flexible to reconfigure
• Able to react to internal and external stimuli by adapting its behaviour
• Memory and performance overhead
• All variations are compiled into a single binary
• Consistency conditions must be checked at run time
• Unnecessary functionality may be considered as potential
security threat

44. Design Patterns
Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer.
• Observer pattern (publish/subscribe) to implement distributed
event handling
• Feature are implemented as observers
• Variability is achieved by registering or not registering observers

45. Design Patterns
Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer.
• Template-method pattern
• Using an abstract class
• Implement feature’s behaviour using inheritance

46. Design Patterns
Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer.
• Strategy pattern
• Encodes a callback mechanism
• Alternative features where each corresponds to one implementation of
the algorithm
• Uses polymorphism instead of conditional statements

47. Design Patterns
Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer.
• Decorator pattern
• Extends object with additional behaviour at run time
• Optional features and feature groups, of which multiple features can be
selected, are implemented as decorators

48. • Variability binding time?
• Design-time
• Compile-time
• Load-time
• Run-time
• Variability implementation mechanism?
• Conditional compiling
• Conditional statements (if-then-else)
• Design patterns

49. Testing

51. •26,256 possible products
•4,376 hours (182 days) processor time to
execute the tests
•8 person/month to setup testing infrastructure
How to test a SPL?

52. Combinatorial Interaction Testing
• Assumption
• Most of the faults are due to the undesired feature interactions of a
limited number of features
• Example
• Gradle + MariaDB fails due to a missing dependency in _liquibase.gradle
template file
• Idea
• Extract configurations so that all combinations of options are covered
(at least) once: t-wise sampling

53. t-wise sampling
• All t combinations of features are in at least one product
• 2-wise: 26,256 ➠ 41 products
• 3-wise: 26,256 ➠ 126 products
• 4-wise: 26,256 ➠ 374 products
… but, t-wise sampling is NP-complete when there are constraints
• Tools
• MoSo-Polite (constraint programming)
• PACOGEN (constraint programming)
• CASA (simulated annealing)
• SPLCAT (various algorithms) and Pairwiser (industrial version)
… have a hard time to go above 4-wise for large feature models

54. •26,256 possible products
•4,376 hours (182 days) processor time to
execute the tests
•8 person/month to setup testing infrastructure
How to test a SPL…
…when you have a
budget of max. 20
products?

55. Dissimilarity sampling
• Assumption
• Dissimilar configurations cover more t-tuples than similar ones
Henard, C., et al. (2014) Bypassing the Combinatorial Explosion: Using
Similarity to Generate and Prioritize T-Wise Test Configurations for Software
Product Lines. TSE. 40, 7 (Jul. 2014), 650–670.
• Tool: PLEDGE
• Evolutionary algorithm
• Fitness function based on distance (i.e., differences in the
selected features)
• Correlated with t-wise coverage but easier to compute
• Testers decide on generation time and number of products

56. •26,256 possible products
•4,376 hours (182 days) processor time to
execute the tests
•8 person/month to setup testing infrastructure
How to test a SPL…
…when you have a
budget of max. 20
products?
PLEDGE(fm, 20, 1 min.)

57. … but
What about product dependencies, and
how to automate the testing process?
Halin, A., et al. (2017) Test them all, is it worth it? A ground truth
comparison of configuration sampling strategies. CoRR. abs/1710.0,
(Oct. 2017).

58. Take-away message

59. • Variability is unavoidable in software developments
• It should be planned and managed
•Identify development practices
• Clone and own
• Software product line
• Most probably something intermediate
• Binding
• Design, compile, load, and/or runtime binding
• Variability implementation mechanism(s) (conditional compiling,
parameters, design patterns)
•Feature modelling helps to manage variability
• Analysis on the feature model
• Sample products to test

60. Software variability
management
Xavier Devroey <x.d.m.devroey@tudelft.nl>
Office 4.W.540 (4th floor, West side, new EWI building)