1

Software Product Lines (SPL)

Dr. Indika Kumara

2

Outline• Quest for Systematic Software Reuse: Motivating SPL• Software Product Lines (SPL): Concepts and Examples• Software Variability Management: Foundation of SPL• Domain Engineering: Developing Core Assets and Product

Lines Architecture• Application Engineering: Deriving Products• Organization Aspects: Adopting SPL Approach for

Organizations• Dynamic Software Product Lines: SPL Approach for

Dynamic Domains

3

Quest for Systematic Software Reuse: Motivating SPL

4

Software Products/Projects: Some Observations

• Generally, a lifetime of a software product / project can be very long.

WSO2 ESB (Enterprise Service Bus)

• Nearly 10 years (Since 2006)• Several major code rewriting/changes and personnel

changes• No major changes to the expected functional requirements • Some changes to the performance requirements

(throughput and resource usage)• Size (80 MB => 230 MB) from 2.0 version to 4.8 version

5

Software Projects: Some Observations …

• A software product / project may reuse a lot of in-house or third party libraries or components or services to improve productivity. (Successfully???)

Reuse of HTTPCore Library in WSO2 ESBHTTPCore: Non-blocking I/O => May suitable for high latency and throughput scenarios, e.g., chat applications, streaming updates.Main use case within ESB : binary relay (high throughput => key attraction for some customers)Some main issues: • Most of the customer issues/bugs were relevant the usage of the

HTTP core (some issues took a few months to identify and fix)• No real gain when supporting key ESB scenarios (transformation,

security, content-based routing, etc.,…)Currently replacing HTTPCore with Netty library (a major change)

6

Why Is Reuse So Hard?

• Appropriate reusable parts are not available• Can not locate even the appropriate reusable

parts are available• Mismatch issues - parts do not fit together well

– Low-level interoperability issues (SOA?)– Architectural mismatch [D. Garlan et al.]

• Incompatible assumptions that each part makes about its operating environment (including the structure of the composite application)

7

Architectural Mismatches: Illustrations

Asynchronous Reactor Transformer

Socket Input Stream

Buffered Input Stream

Support CenterGarage (with Spare Parts)

Motorist Tow Truck

Garage (no Parts)

Spare Parts Provider

8

Dealing with architectural mismatch …• Preventing mismatch

– Architecture Specialization

• Detecting and resolving mismatches – Wrappers, adapters, mediators, … – in many cases, impossible to avoiding mismatches

9

More Architectural Mismatch Challenges (In Turn, Software Reuse Challenges)

• Dynamic software system– avoid, detect, and repair mismatch dynamically

• Software evolution (architectural) – Can introduce architectural mismatch issues

• Architecture lock-In– Become too expensive to change architecture

without introducing mismatches – Hinder innovation

10

Software Reuse: Recap• Benefits (if successful)

– Greatly reduce time to market and cost– Greatly improve productivity, quality, and business

agility – …

• But software reuse is really hard

But can we still achieve planned, systematic reuse? Software Product Lines

Preventing architectural mismatches, controlled architecture evolution, systematically developing dynamic systems, …

11

Running Example: Roadside Assistance Product Line

12

Software Product Lines: Concepts

13

Software Product Lines(SPL): Concepts

• What is a software product line (SPL)?– Includes a set of related products developed from

a shared, managed core asset base– Targets a specific business domain (the business

case is defined)

Shared and ManagedCore Assets

Products with (Many) Common and (Some) Variable Features

Production Process : Selecting, configuring, and assembling core assets in a prescribed way

14

Software Product Lines: Concepts …

• What are core assets (reusable assets)?– Build to support multiple products of the same

family (the reuse is not accidental)– Contain variations points to allow creating

variants of the assets quickly and systematically – Include software architecture, software elements

(components, services, modules, etc.), designs, documentations, test cases, product schedules, performance models, tools, etc.

15

B

A

Software Product Lines: Concepts …• Product line architecture

– Represent the architectures of multiple related products simultaneously

– Satisfy the functional, quality, and business goals for all products in the product line

Common Design

Decisions

A

Common Design

DecisionsB

Common Design

Decisions

Product Line Architecture

Product A’s Architecture

Product B’s Architecture

[R. Taylor et. al]

Design Decisions

Specific To A

16

Software Product Lines: Concepts …• Features

– "A feature is a unit of functionality of a software system that satisfies a requirement, represents a design decision, and provides a potential configuration option. " - S. Apel and C. K¨astner

– Functional and quality features

– Software architecture and the software elements that populate it realize the features of the product line.

Towing RepairingAccommodation

Towing time = 2h and repairing time=5dTowing time = 1h and renting duration =3d

17

Software Product Lines: Concepts …

• Products– Each product provides a subset of the product line

features, and targets a specific customer group– Each product uses a variant of the product line

architecture, and the variants of a subset of other appropriate core assets (including software elements)

18

Software Product Lines: Real Examples

• Boeing: Bold Stroke Avionics Software Family• Nokia: Mobile Phones• GNU compiler suite• Philips Product Line of Software for Television

Sets• U.S. Naval Research Laboratory: A-7E

Operational Flight Program• More at http://splc.net/fame.html

19

Reuse History: From Ad Hoc To Systematic

[Linda Northrop]

Economics Of Software Product Lines

20 [Linda Northrop]

21

Economics of Software Product Lines …• Some examples from SEI website

– Improved productivity by as much as 10x– Increased quality by as much as 10x– Decreased cost by as much as 60%– Decreased labor needs by as much as 87%– Decreased time to market (to field, to launch) by

as much as 98%– Ability to move into new markets in months, not

years

22

Software Product Lines Are Not• Clone and own: single-system development with reuse

– Modifying code as necessary for the single system only• Accidental small-grained reuse

– Reuse libraries containing algorithms, modules, objects, or components

• Just component-based or service-based development– Selecting components or services from an in-house library, the

marketplace, or the Web with no architecture focus• Just versions of a single product

– Rather, simultaneous release and support of multiple products• Just a configurable architecture

– A good start, but only part of the reuse potential• Just a set of technical standards

– Constraining choices without an architecture-based reuse strategy

[Linda N

orthrop]

23

Software Variability Management: Foundation of SPL

24

Software Variability Management• What is the software variability?

Software variability is the ability of a software system or artifact to be changed, customized or configured for use in a particular context. A high degree of variability allows the use of software in a broader range of contexts, i.e. the software is more reusable” [Bosch 2004]

• What is the software variability management?– Identification, modeling, realization, resolution, validation,

verification, and evolution of the variability in software artifacts– In a product line, must consider all relevant core assets– Must consider the dependences between the variability in different

core assets

Software Variability : Concepts• Variation Points and Variants

– Variation points : where the variations occur– Variants : options/choices at variation points – Cardinality : maximum and minimum numbers of

variants to be selected for a given variation point

25

-maxCardinality : int-minCardinality : int

VariationPoint-maxCardinality : int-minCardinality : int

VariationPointVariantVariant

0...*

variant

Towing

Heavy Light

TowingResTime

1h 2h 3h

Towing

TowingByTomTow

TowingBySwiftTow

Functional and Performance Requirements Design/Implementation

Serv

ice

Colla

bora

tions

26

Sender Push

Reader Pull

Interactive Solo Shared

PrivateLogin

Controlled Public

Wiki = {Reader pull, Public, Shared}Twitter ={Sender push, Public, Solo}Email = {Sender push, Private, Solo}Facebook status= {Reader pull, Private, Solo}

@ Mary Shaw, "The Role of Design Spaces"

Sharing Web Information

Privacy AuthorshipActivation

Design Variability : Illustration

27

Software Variability : Concepts• Common Types of Variation Points and Variants

– Mandatory (single) – must be included in a product• E.g., the repairing option

– Optional (single)• E.g., the accommodation option

– Alternatives (multiple) – only one can be included • E.g., among rental vehicle option and taxi hire option

– Or (multiple) – one or more can be included• E.g., among light towing and heavy towing

– And (multiple) – all must be included• E.g., both direct debit option and credit option for online

payement

28

Software Variability : Concepts• Common Types of Variability Dependencies

– Exclude dependency• Inclusion of one or more options must exclude one or more

other options• E.g., Accommodation exclude AlternativeTransport• E.g., ExternalParts exclude (MajorRepair.ResponseTime = 2d)

– Include dependency• Inclusion of one or more options must include one or more

other options• E.g., Major(Repair) include Tow• E.g., (MajorRepair.ResponseTime = 2d) include InternalParts

29

Software Variability : Concepts

• Variability in Time /Evolution– "The existence of different versions of an artifact that

are valid at different times." [K. Pohl et al.]– E.g., train ticket booking by phone option will be

replaced by train ticket booking by web when the website is available.

• Variability in Space– “The existence of an artifact in different shapes at the

same time."[K. Pohl et al.]– E.g., three payment options are available at the same

time: cash, direct debit, and credit card

30

Software Variability : Concepts• External Variability

• Internal Variability

• Visible to customers • Customers need to make

choices• E.g., selection between

heavy tow and light tow

• Hidden from customers• Developers, operational, etc. need

to make choices• Realization and deployment issues• E.g., selection between

TowingBySwiftTow, TowingByTomTow, …

[K. Pohl et al.]

[K. Pohl et al.]

31

Software Variability : Concepts• The Variability Pyramid

[K. Pohl et al.]

32

Variability Modeling• Explicitly documenting variability in artifacts

– Need to consider the previously mentioned variability concepts

• Why– Rational decision making– Variability communication (including customization)– Traceability of variability across artifacts (time/space)

• Types of variability modeling approaches– Feature modeling – Orthogonal variability modelling – Many custom modeling approaches

33

Feature ModelFeatures

Feature Groups

Feature Constraints (e.g., Include and exclude)

Non-functional features can be represented as feature attributes.

34

Variability Realization

• How to support variation points and variants in core assets (architecture, software elements, models, etc.)– Including enforcing variability dependencies and

supporting variability resolution– Design time and runtime artifacts

• Two main approaches– Annotative Approach– Compositional Approach

35

Annotative Approach• Use some form of annotations to implement variability

If (Accommodation) { code fragment X;} else if (Tow) { code fragment Y;} else if (…){ …} …

Variation Points

Variants

Product Line Implementation

• Can introduce variations at arbitrary granularity levels

But• Obfuscate codes• Tangle business logic and variability

logic • Difficult to introduce modular

abstractionsE.g., Java annotation, If-then-else, C/C++ style preprocessors, variation points and variants in extended UML profiles, etc.

36

Compositional Approach

• Realizes product line features as modular units and creates products by composing these units.

Modular Units Products

Composition Specification per Product

• Merging units• Coordinating units

Modular units may represent total decomposition (e.g., module per feature) or partial decomposition (common base + differences) (e.g., Delta Modules, Aspects, and Plugins)

What about traditional services/components? Architectural mismatch issues + Features crosscut services/components => Need high-level abstractions or variability-aware components and services, etc.

37

Variability Resolution or Product Generation

• Variability Resolution – Selection of a subset of the variation points in an artifact,

and a subset of the variants for each selected variation point, and generate an artifact instance/variant

Variability at Requirements

Variability at Realization

Mapping Models

Variability Resolution

Variability Resolution

Automated (model-to-model transformation)

or Manual

38

Variability Resolution Example in Feature Model: Creating Feature Configurations

39

Software Product Line Engineering

40

Software Product Line Engineering

• Domain engineering– build the product line platform (core asset base)

that supports the derivation of products effectively

• Application Engineering– build products to support different customers

41

Domain Engineering

[K. Pohl et al.]

Compared with a single system, support Variability

42

Application Engineering

Ideally, automated via model-to-model/code transformation techniques

[K. Pohl et al.]

43

Domain Eng. And Application Eng.

[K. Pohl et al.]

44

Organization Aspects: Adopting SPL Approach for Organizations

45

Product Line Scope

Products within the scope of the product line

All possible products - but not for this product line

Products that can be added to the product line (with some effort)

46

SPL Adoption Strategies

• There are three main adoption strategies– proactive, reactive, and extractive

• Proactive Strategy– Follow the domain engineering to develop the

complete product line platform / core asset base – Higher upfront cost but easy to create products– Suited if the requirements are stable, and their

evolution is predictable

47

SPL Adoption Strategies …• Reactive Strategy

• Start with a minimum number of products• Grows the product line as demand arises for new products

or new requirements on existing products• Suited if the requirements are unpredictable.

• Extractive Strategy• Create the product line assets by extracting software

elements from the currently available software systems at the organization

• The selected systems need to have higher commonality (functional and architectural)

48

Dynamic Software Product Lines: SPL Approach for Dynamic Domains

49

Dynamic Software Product Lines (DSPL)• DSPL employs the product line capabilities and

the variability management at runtime. • Products are derived and adapted at runtime,

potentially multiple times.

Product 1

Product 2

Product n

Deployed Product Line (Runtime model)

Adapt

Adaptation Space for a Product

50

DSPL: Use cases

• Multi-tenant applications– A tenant uses a product in an DSPL – Tenants share feature implementations at runtime

• Dynamically adaptive applications/context-aware applications– A product is one application adaptation or for a

context variant – E.g., Smart * (homes, cities, healthcare, industry),

Web servers, Enterprise Applications, Windows OS?,

Conceptually, DSPL provide a systematic approach to build, manage, and evolve these types of applications.

51

Topic Covered

• Challenges of Systematic Reuse• Software Product Lines (SPLs)• Software Variability Management• SPL Engineering

– Domain engineering– Application engineering

• Dynamic SPL

52

Q/A

53

References• http://wso2.com/library/articles/2014/02/esb-performance-round-7.5/• http://www.sei.cmu.edu/productlines/• http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=21564• David Garlan, Robert Allen, and John Ockerbloom. 1995. Architectural Mismatch: Why

Reuse Is So Hard. IEEE Softw. 12, 6 (November 1995), 17-26• Garlan, David, Robert Allen, and John Ockerbloom. "Architectural mismatch: Why reuse is

still so hard." IEEE software 26.4 (2009): 66.• Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2

ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.• Klaus Pohl, Günter Böckle, and Frank J. van der Linden. 2005. Software Product Line

Engineering: Foundations, Principles and Techniques. Springer-Verlag New York, Inc., Secaucus, NJ, USA.

• Taylor, Richard N., Nenad Medvidovic, and Eric M. Dashofy. Software architecture: foundations, theory, and practice. Wiley Publishing, 2009.

• Van Gurp, Jilles, Jan Bosch, and Mikael Svahnberg. "On the notion of variability in software product lines." Software Architecture, 2001. Proceedings. Working IEEE/IFIP Conference on. IEEE, 2001.

• Apel, Sven, and Christian Kästner. "An Overview of Feature-Oriented Software Development." Journal of Object Technology 8.5 (2009): 49-84.

• Shaw, Mary. "The role of design spaces." IEEE software 29.1 (2012): 46-50.

54

References …• Christian Kästner, Sven Apel, and Martin Kuhlemann. 2008. Granularity in software

product lines. In Proceedings of the 30th international conference on Software engineering (ICSE '08). ACM, New York, NY, USA, 311-320.

• Krueger, CharlesW. "Easing the transition to software mass customization." International Workshop on Software Product-Family Engineering. Springer Berlin Heidelberg, 2001.

• Hallsteinsen, Svein, et al. "Dynamic software product lines." Computer 41.4 (2008): 93-95.

• Hinchey, Mike, Sooyong Park, and Klaus Schmid. "Building dynamic software product lines." Computer 45.10 (2012): 22-26.

• Kang, Kyo C., Jaejoon Lee, and Patrick Donohoe. "Feature-oriented product line engineering." IEEE software 19.4 (2002): 58.

• Ina Schaefer, Lorenzo Bettini, Ferruccio Damiani, and Nico Tanzarella. 2010. Delta-oriented programming of software product lines. In Proceedings of the 14th international conference on Software product lines: going beyond (SPLC'10), Jan Bosch and Jaejoon Lee (Eds.). Springer-Verlag, Berlin, Heidelberg, 77-91.

• Klaus Pohl and Andreas Metzger. 2006. Software product line testing. Commun. ACM 49, 12 (December 2006), 78-81. DOI=http://dx.doi.org/10.1145/1183236.1183271

• McGregor, John. "Testing a software product line." (2001).• http://wwwiti.cs.uni-magdeburg.de/iti_db/research/featureide/