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

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

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

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)

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)

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…

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

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

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

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

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

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

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

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

Feature Models

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]

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

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

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

Feature Models and URN in jUCMNav

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)

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

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

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)

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

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

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

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

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

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

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

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

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

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

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 email 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 email X take #100 transport Hitch a Ride transport X hitch a ride in car

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

Another Example – Authentication Introduction to Software Product Lines (SPL) Feature Models FM in jUCMNav Another Example – Authentication Demo (IMPORTANT): http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/FeatureModeling

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 http://www.youtube.com/watch?v=KWZ7wLsRFFA and https://www.youtube.com/watch?v=Am9jp2y2Uds :-) 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 2013. Springer, LNCS 8107:604-621. DOI: 10.1007/978-3-642-41533-3_37.

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?