1. Software Product Lines and Feature Models
SEG3101 (Fall 2017)
Software Product Lines and Feature Models
Based on material from Gunter Mussbacher and Mathieu Acher

2. Families of Software Products
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Families of Software Products
« A set of programs is considered to constitute a family, whenever it is worthwhile to study programs from the set by first studying the common properties of the set and then determining the special properties of the individual family members » (1)
Software-intensive systems come in many variants  Software Product Lines
aka Variability
aka Commonality
(1) David L. Parnas: ‘‘On the design and development of program families’’, Transactions on Software Engineering, SE-2(1):1–9, 1976

3. Variability in Time vs in Space
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Variability in Time vs in Space
Variability in Time (releases)
the existence of different versions of an artifact that are valid at different times
Variability in Space (variants)
the existence of an artifact in different shapes at the same time

4. Examples of Software Product Lines (1/3)
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Examples of Software Product Lines (1/3)

5. Examples of Software Product Lines (2/3)
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Examples of Software Product Lines (2/3)

6. Examples of (Software) Product Lines (3/3)
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Examples of (Software) Product Lines (3/3)
Nowadays Software Product Lines are everywhere…

7. Benefits Printer Firmware Improve product reliability
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Benefits
Improve product reliability
Improve usability
Improve consistency across products
Reduce production costs
Reduce certification costs
Shorten time-to-market
Production cost reduced by 75%
Development time reduced by 33%
Reported defects reduced by 96%
Printer Firmware

8. Hall of Fame http://www.splc.net/fame.html
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Hall of Fame

9. Challenges of Scale (1/3)
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Challenges of Scale (1/3)
33 features
optional, independent
a unique variant for every
person on this planet

10. Challenges of Scale (2/3)
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Challenges of Scale (2/3)
320 features
more variants than estimated atoms in the universe
optional, independent

11. Challenges of Scale (3/3)
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Challenges of Scale (3/3)
10000
features
2000 features

12. Domain Engineering and Application Engineering
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Domain Engineering and Application Engineering 
Domain/Variability Model
Configuration
Software Generator
Domain Artefacts
Domain
Engineering
Application
Engineering

13. Promises of Software Product Line Engineering (1/2)
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Promises of Software Product Line Engineering (1/2)
Klaus Pohl, 2005

14. Promises of Software Product Line Engineering (2/2)
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Promises of Software Product Line Engineering (2/2)
Klaus Pohl, 2005

15. Feature Models

16. Domain Requirements Engineering
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Domain Requirements Engineering
Problem Space
Elicit requirements and scope the software product line
Variability modeling: determine commonalities and variabilities usually in terms of features
Observation: « Reuse-in-the-large works best in families of related systems, and thus is domain dependent.» [Glass, 2001]
Feature Models are the de facto standard for variability modeling
4800+ citations on Google Scholar for [Kang et al.: “Feature-oriented domain analysis (FODA) feasibility study”, 1990]

17. Feature Model: Notation (1/2)
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Feature Model: Notation (1/2)

18. Feature Model: Notation (2/2)
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Feature Model: Notation (2/2)

19. Configurations & Potential FM Problems
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Configurations & Potential FM Problems
Configuration = feature selection
Declaratively specify a family member of an SPL by selecting or deselecting features while respecting the constraints imposed by the feature model
Given an FM and a configuration, check that the configuration is valid
Similar to testing
Most common usage
Is the FM itself valid?
Does at least one valid configuration exist?
Invalidity often caused by incompatible constraints
Usually requires a theorem prover to check formally
State explosion problem, but can often be con compositionally
Does the FM contain “dead” features?
Features that can never be part of any valid configuration
Can we minimize an FM? Merge two FMs? Etc.
Interesting: SPLOT - Software Product Line Online Tools

20. Feature Models and URN in jUCMNav

21. FM* UCM GRL Bird’s Eye View of URN features + variability URN Links
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Bird’s Eye View of URN
FM*
features + variability
UCM
responsibilities + causality + components + scenarios
URN Links
GRL
intentional elements + actors + links + indicators + strategies
FM … feature model (not part of the URN standard)

22. Feature Modeling with URN
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Feature Modeling with URN
Combined evaluation of features and goals based on shared analysis infrastructure
Apply goal reasoning techniques to features
Consider
Feature Models as Goal Models
Combined goal and feature model reasoning with the User Requirements Notation and jUCMNav
Features can be used directly as tasks in goal models

23. Feature Modeling: Overview
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Feature Modeling: Overview
A feature model describes the commonalities and variabilities of members in a Software Product Line (SPL)
Defines the product space (which products are possible)
Commonality: each SPL member has this feature
Variability: varies from one SPL member to the next
Domain Engineering: build the infrastructure for the whole product family
Application Engineering: build one particular product
A feature model is essentially an AND/OR-tree with additional links and constraints
A GRL model is an AND/OR-graph  perfect match?
Structure of feature model needs to be mapped to structure of GRL model
Evaluation of feature model needs to match evaluation of GRL model

24. Basic Modeling of Commonality and Variability
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Basic Modeling of Commonality and Variability
Example: Commuting
Mandatory Link
Optional Link
Commuting
XOR / OR Group
Transportation
Alarm System
Office Access
XOR OR
Regular Bus
Regular Bus
Regular Bus
Express Bus
Express Bus
Take own car
Take own car
Hitch a ride
Hitch a ride
Alternative Alarm System
Elevator
Stairs
What (Feature)

25. Cross-Tree Integrity Constraints
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Cross-Tree Integrity Constraints
Typically, requires (includes) and conflicts (excludes) constraints are specified for a pair of features
A requires B (i.e., if feature A is selected, then feature B must also be selected)
A conflicts with B (i.e., if feature A is selected, then feature B must not be selected)
In jUCMNav, implemented with the help of third-party support for OCL constraints
Not just limited to requires and conflicts constraints
Being reimplemented by a McGill team as first-class constructs

26. Goal Model Semantics for Feature Model (1/3)
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Goal Model Semantics for Feature Model (1/3)
Selected feature = satisfaction value 100; 0 if not selected
Feature configuration is valid, if root feature is satisfied (100) and no warnings exist for the feature model
Propagation of XOR / OR groups
The same as propagation for GRL decompositions (a selection of a parent feature is only valid if at most/least one child feature is selected) OR
Child A
Child B
Parent
100*
100 OR
Child A
Child B
Parent
Parent
Child B
Child A 
Parent
Child B
Child A OR OR

27. Goal Model Semantics for Feature Model (2/3)
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Goal Model Semantics for Feature Model (2/3)
Propagation for groups of mandatory and optional links
Interpreted as GRL contributions
Contribution values are determined automatically
Mandatory links only: all links must contribute equally (barring rounding errors) for a parent to be fully satisfied (100) (e.g., [(100x33) + (100x33) + (100x34)] / 100 = 100)
Parent
Child B
Child A
Child C 
Child A
Child B
Child C
Parent 33 34
100* 67

28. Goal Model Semantics for Feature Model (3/3)
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Goal Model Semantics for Feature Model (3/3)
Propagation for groups of mandatory and optional links
Optional links only: any optional link can fully contribute
Mixed mandatory and optional links: only mandatory links count
Parent
Child B
Child A
Child C 
Child A
Child B
Child C
Parent
100
100*
Parent
Child B
Child A
Child C  50
Child A
Child B
Child C
Parent
100* 28

29. Feature Model Analysis (1/5)
Introduction Fundamentals (GRL/UCM) Analysis (GRL/UCM) Features Indicators jUCMNav Tool Profiling
Feature Model Analysis (1/5)
Configuration “Regular Bus”: Regular Bus = 100
mandatory child not selected (possible only when automatic selection of mandatory features is turned off) 50
Commuting
100
Transportation
Alarm System
Office Access
XOR OR
100*
Regular Bus
Regular Bus
Regular Bus
Express Bus
Express Bus
Take own car
Take own car
Hitch a ride
Hitch a ride
Alternative Alarm System
Elevator
Stairs
grey = does not need to be selected for valid configuration
yellow = selection required for valid configuration

30. Feature Model Analysis (2/5)
Introduction Fundamentals (GRL/UCM) Analysis (GRL/UCM) Features Indicators jUCMNav Tool Profiling
Feature Model Analysis (2/5)
Configuration “Regular Bus, Standard Office Access”: Regular Bus = 100; Elevator = 100; Stairs = 100
automatically selected (no choice)
fully satisfied + no warnings  valid configuration
100
Commuting
Commuting
100 (A)
100 (A)
Transportation
Transportation
Alarm System
Alarm System
Office Access
Office Access
XOR OR
100*
100*
100*
Regular Bus
Regular Bus
Regular Bus
Regular Bus
Regular Bus
Express Bus
Express Bus
Express Bus
Express Bus
Take own car
Take own car
Take own car
Take own car
Hitch a ride
Hitch a ride
Hitch a ride
Hitch a ride
Alternative Alarm System
Alternative Alarm System
Elevator
Elevator
Stairs
Stairs

31. Feature Model Analysis (3/5)
Introduction Fundamentals (GRL/UCM) Analysis (GRL/UCM) Features Indicators jUCMNav Tool Profiling
Feature Model Analysis (3/5)
Configuration “Take own car, Alarm, Stairs only”: Take own car = 100; Alarm System = 100; Stairs = 100
100
Commuting
100 (A)
100*
100 (A)
Transportation
Alarm System
Office Access
XOR OR
100*
100*
Regular Bus
Regular Bus
Regular Bus
Express Bus
Express Bus
Take own car
Take own car
Hitch a ride
Hitch a ride
Alternative Alarm System
Elevator
Stairs

32. Feature Model Analysis (4/5)
Introduction Fundamentals (GRL/UCM) Analysis (GRL/UCM) Features Indicators jUCMNav Tool Profiling
Feature Model Analysis (4/5)
Configuration “Regular and Express Bus, Standard Office Access”: Regular Bus = 100; Express Bus = 100; Elevator = 100; Stairs = 100
exactly one selected child in an XOR group
100
Commuting
100 (A)
100 (A)
Transportation
Alarm System
Office Access
XOR OR
100*
100*
100*
100*
Regular Bus
Regular Bus
Regular Bus
Express Bus
Express Bus
Take own car
Take own car
Hitch a ride
Hitch a ride
Alternative Alarm System
Elevator
Stairs

33. Feature Model Analysis (5/5)
Introduction Fundamentals (GRL/UCM) Analysis (GRL/UCM) Features Indicators jUCMNav Tool Profiling
Feature Model Analysis (5/5)
Configuration “Regular Bus, Standard Office Access”: Regular Bus = 100
at least one selected child in an OR group
100
Commuting
100 (A)
100 (A)
Transportation
Alarm System
Office Access
XOR OR
100*
Regular Bus
Regular Bus
Regular Bus
Express Bus
Express Bus
Take own car
Take own car
Hitch a ride
Hitch a ride
Alternative Alarm System
Elevator
Stairs

34. Goal Models vs. Feature Models + Attributes
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Goal Models vs. Feature Models + Attributes
Quite common to add attributes to feature models that capture non- functional requirements and system qualities, which are otherwise not covered in feature models
E.g., cost = $100 for Feature A, $150 for Feature B; memory usage = 200 KB for Feature A, 125 KB for Feature B;…
Goal models offer a way to capture richer relationships among these attributes (i.e., goals) as well as between attributes and features
Goal models allow various stakeholders to be described and allow reasoning about them
Considering feature models as a subset of goal models increases the expressiveness of non-functional requirements and system qualities in feature models

35. Impact of Feature Orientation on Scenario Model
Introduction Fundamentals (GRL/UCM) Analysis (GRL/UCM) Features Indicators jUCMNav Tool Profiling
Impact of Feature Orientation on Scenario Model
XOR
Regular Bus
Express Bus
Take own car
Hitch a ride
Transportation
Alarm System
Alternative Alarm System OR
Elevator
Stairs
Office Access
Commuting
take
elevator
secure
home
ready to
leave in
cubicle
transport
commute
stay
Secure Home
home X
lock door
arm system in
out2
out1
stay
use alternative
alarm system
Arm System
accept
code
check
armed
[matched]
[not
matched]
not armed
[quit]
Regular Bus
commuter
deal with
work X
take #96
transport
take #97
take #95
Car
transport X
drive car
Take Elevator
elevator
call X
select
floor
take
stairs
arrived
Express Bus
commuter
deal with
work X
take #100
transport
Hitch a Ride
transport X
hitch a ride in car

36. Impact of Feature Orientation on Scenario Model
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Impact of Feature Orientation on Scenario Model

37. Another Example – Authentication
Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Another Example – Authentication
Demo (IMPORTANT):

38. Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Towards the Future
Can we combine goals, scenarios, features, aspects, class diagrams, sequence diagrams, and code?
Concern-Driven Development (CDD)
Reusable, multi-layered aspects with interfaces
jUCMNav + RAM (Reusable Aspect Model)
See demos and :-)
Alam, O., Kienzle, J., and Mussbacher, G. (2013) Concern-Oriented Software Design. ACM/IEEE 16th International Conference on Model Driven Engineering Languages and Systems (MODELS 2013), Miami, Florida, USA, September-October Springer, LNCS 8107: DOI: / _37.

39. Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav
Quiz!
What are the two aspects that characterize a family of products/models?
Are feature models created or used in:
Domain engineering?
Application engineering?
In a feature model, what kinds of links can we have between two features?
What is a configuration?
What is a valid configuration?
How are feature models represented using jUCMNav?
How are configurations expressed using jUCMNav?
If we combine URN with FM, how do we know that a valid configuration is superior to another valid configuration?