This document discusses software product lines and product line architectures. It defines a software product line as a set of software systems that share a common set of features addressing a particular market segment. Product lines are developed from a common set of core assets in a prescribed way to reduce costs and increase reuse. A product line architecture is a common framework that standardizes components and maximizes reuse potential. It specifies common functionality and identifies variation points across related products. Variability management is important for providing flexibility without compromising commonality.

1. Software Product Lines
Paolo Ciancarini

2. Agenda
• Design for reuse
• Software product lines
• Organizational strategies

3. Motivation
Complexity, size, and number of software-
intensive systems a major problem for
software companies
• routine functionality is custom-written repeatedly
from scratch, over and over
• a quagmire of data formats and applications
• ambiguities and interoperability conflicts not only
across different companies but even among
groups within the same company

4. Family of systems
There is a need to
• reduce the development effort
• increase productivity
moving from designing single products to producing
engineering families of products
• identifying generic solutions to common problems
• building related products by assembling components
• providing universal platforms
• synthesizing systems automatically

5. Product Line Architecture (PLA)
Product Line Architecture:
a common design framework that
• standardizes & maximizes reuse potential of all
software artifacts generated during development
- these artifacts include requirements, designs and
patterns, and, of course, actual code components
• specifies common functionality across systems
• clearly identifies variation points

6. Capturing PLA
• Common core: features common to all products
• FA: features specific to product A
• FB: features specific to product B
• Product A = Common core + FA
• Product B = Common core + FB
Common FA Common FB
core core
Product A Product B

7. Lessons from other industries
• Any customer can have Any customer can
a car painted any have a car painted
colour that he wants so any colour that he
long as it is black” - wants so long as it is
Henry Ford black”
Henry Ford

8. Architecture and standard components
Architecture was
simple and flexible
Built from standard parts

9. Standards and diversity
What varied?
Use features to satisfy diversity of needs
Why it worked?
Standard architecture and common parts
What resulted?
Product and assembly lines

10. The role of architecture in sw

11. Component based development
Software factories exploit component-based
development (CBD)
• They engineer applications by composing
prefabricated components in the hope that this
will increase software reuse
• Strategy: building software systematically and
opportunistically exploting reference
architectures about a domain and competitive
knowledge for systems in that domain

12. Domain
What is a domain?
• Area of expertise with specialized particular tasks
• Populated by products with reusable structures
Example: software for a car
• Console
• Engine
• Brakes
• …

13. Domains vs product lines
Domains are in the problem space, product
lines are in the solution space
• Domain • Product line
• Consumer electronics • Philips Digital TVs
• Avionics • Boeing 747 Family
• Compilers • GNU compiler suite
• Videogames • Games using the
same engine

14. Multimedia Product Line
VCR Features:"
• Play Tape"
Answering machine Features:"
• Rewind Tape"
• Play Announcement"
• Forward Tape"
• Record Announcement"
• Button Control"
• Rewind Announcement"
• Signal Handling"
• Play Message"
• Record Message"
• Rewind Message"
• Forward Message"
Audio Player Features " • Display Messages"
• Play Tape" • Button Control"
• Record Tape" • Signal Handling"
• Rewind Tape"
• Forward Tape"
• Button Control"
• Signal Handling"

15. Product lines
• Product line technology builds families of products
exploiting some common core assets and
managing their variability
• Ex.: Boeing 757 e 767 share 60% of components
• Ex.: Mercedes Benz class E models share 70%
• Scale economies and efficiency
• Integrating rather than creating

16. Software reuse
Why is software reuse critical?
• provides predictable behavior (better testing)
• enables shorter delivery timeframes
• reduces repeated building from scratch of
common functionality
History of the concept dated back to 1950 s
• subroutine libraries
• standardized class libraries

17. Old ways to reusing software
Old definitions of sw reuse include:
• Re-use is considered as a means to support the
construction of new programs using in a
systematical way existing designs, design
fragments, program texts, documentation, or
other forms of program representation.
• Reusability is the extent to which a software
component can be used (with or without
adaptation) in multiple problem solutions.

18. Reusable assets
Reference Design
Architecture Pattern
Legacy Architectural
Application Mechanism
Pattern Packaged
Language Application
Development Reference
Method Model
Architectural Programming
Decision Pattern
Pattern Component
Library
Component Architectural
Pattern
Architectural Application
Style Framework

19. Reuse
Reuse aspects
• It is not an end in itself but a means to increase
productivity and improve quality
• Reusable components are not limited to code
• Software components may need adaptation
- Adaptive design Community & Enterprise Information Portals
- Variant design
Health ••• other vertical
• Horizontal and Care
Financial Insurance
domains
vertical reuse E-Business facilities ••• other
(Appl. dev., Intelligence, Integration, …) facilities
Metamodel Interoperability •••
Distributed Run-time Middleware

20. Benefits
By planning ahead in support of families of
multiple systems, an organization
• reduces the development time and cost of new
products
• reduces risk and improves quality
• manages its legacy assets more efficiently
• evolves a common marketing strategy
• makes decisions based on the (value of) the
asset base and the strategic goals

21. Software product lines (SPL)
Definition by Clemens and Northrop (SEI, 2002):
• A set of software-intensive systems that share a
common, managed set of features satisfying the
specific needs of a particular market segment
• They are developed from a common set of core
assets in a prescribed way
• Example: software for TV sets (Philips)

22. SPL metamodel
Product lines
- Exploit commonality
- Bound variability

23. Why SPL work?
Product lines amortize the investment in these core assets:
• requirements (and requirements analysis)
• domain models
• software architecture (and design)
• performance engineering
• documentation
• test plans, test cases, and test data
• people: their knowledge and skills
• processes, methods, and tools
• budgets, schedules, and work plans
• components and services

24. A few success stories
• Celsius tech: family of naval command and control systems
• Ericsson AXE: family of telecommunications switches
• Lucent Technologies: 5ESS telecom switch
• US Naval Undersea Warfare Center: A-7°
• SALION: Acquisition Management Systems
• Toshiba: Electric Power Generation Plant
• BOEING: Bold Stroke Avionics SW Family
• BOSCH: Gasoline Systems
• CUMMINS Inc.: Diesel SPL
• LSI: RAID controller firmware SPL
• GM: General Motors Powertrain (GMPT)
• PHILIPS: Medical Systems
• Nokia: mobile phones

25. SPL issues
• ROI: when are they convenient?
• Organization of work
• Domain engineering and scoping
• Design for reuse of commonality
• Control of variability

26. ROI of SPL
ROI

27. ROI of SPL

29. Convenience of Product Lines
29

30. Key concepts

31. Organization by product lines
(from Krueger 2009)

33. Single system perspective
(from Krueger 2009)

37. Product Line Engineering
PL Engineering uses domain-driven, model-
based methodology for building software
• Two complementary processes
- Modeling (domain engineering)
- Development (applications engineering)

38. Product Line Engineering
Domain Engineering Experts
"
Technology"
Domain Experts &
1. Modeling (Domain Engineering,
Domain a.k.a Design-for-Reuse)"
knowledge" Refers to original design, i.e.,
the use of first principles"
"
Solution
models"
Domain Experts &
IT technicians
New Domain Expert
requirements"Development (Application Engineering,
2.
a.k.a design-with-Reuse)" Product"
refers to routine practice, i.e.,
the use of known solutions"

40. Reusable assets
Reuse in general needs to be planned for
• create a reusable asset, i.e. one that is fully
documented, has good code and robust scripts;
is verified independently with high confidence
• create a usable asset, i.e. one that is adaptable
and that is usable in a variety of simulators
Design for reuse/use involves
• analysis to identify explicitly variations to
anticipate adaptations, and
• design for adaptability, engineered a priori to
create assets for future developments

41. Problems
Design for commonality
• standardizing assets by encapsulating common
features
Analysis of variation
• must explicitly identify variations that anticipate
adaptations
Control of variability
• provide assets flexibility without compromising
commonality

42. Levels of reuse
• Domain-independent components
- Designed for reuse to fit any product (e.g., general
purpose class libraries)
• Domain-specific components
- Designed for reuse to fit several different products in a
given market (e.g., multi-media, jpeg encoders, data
communications, digital signal processing, ...)
• Product-specific components
- Designed for reuse within a specific application (to
generate various instances or products)

43. SPL: main issues
There are several issues to consider
• Scoping the SPL (i.e. identify domain and
assets)
• Define a reference architecture
• Define a PLA
• Identification of reusable components at the
appropriate level of abstraction
• Variability management
• Architectural compliance
• SPL maintenance

44. What is SPL scoping?
• the initial phase of a SPL, aims to identify
products, features, potential of the market
domain and reusable assets
• determines the viability of the SPL
• maximizes the economical value of the SPL
• Essential factors in SPL:
- Investment
- Management
- Planning
- Business strategy
} scoping

45. Traditional Engineering Model
Domains!
Individual !
applications!
Individual !
domains!
Systems!
Individual
implementations!
Assets!

46. SPL Model
Domains! Domain
models!
• Variability analysis!
<<includes>>! Start
Startup! compressor!
<<extends>>!
<<extends>>!
Shutdown!
Operator! <<includes>>! Alarm <<includes>>!
Plant!
detected!
Remote! Operate!
Shutdown! <<extends>>!
<<includes>>! <<includes>>!
Local! Remote! <<includes>>!
Local
Shutdown! Stop
compressor!
• Features!
2 2 CapsuleC
CapsuleB CapsuleA
Class Diagram (domain model)
:CapsuleA
Collaboration Diagram
(role model)
:CapsuleB CapsuleC
connection
Reusable
network
:CapsuleB CapsuleC
Component! Systems!
Cn
Cn
Cn
•••" Cn
Cn
Assets! Architectural
Framework!

47. Product Lines and UML
Domain Analysis Problem Analysis Solution Analysis
Specify basic problem Describe implementation
Identify the entities
overall functionality, and of the solution in terms of
and their relations in the
identify and specify system interactions between
applications domain"
features" classes and permitted
(expected) overall system
behavior"
Problem Model
(Activity diagram) Behavioral Model
(traces + constraints)
Domain Model
(class diagram)
Requirements Model Implementation Model
(Use Case diagram) (Collaboration diagram)

50. Variability in requirements
Optional requirements Cross-cutting aspects
Optional scenarios Varying flow of events

51. Eriksson, Börstler,
Borg, Software
product line
modeling made
practical CACM,
Dec. 2006

52. A reference domain for automotive
From Bak, Exemplar of Automotive Architecture with Variability, 2010

53. Software Defined Radios
• Variation points in radio configuration,
board configuration, software
configuration

54. SDRs PL
• By applying product line techniques to
SDRs
• Can manage different configurations of the radio
- Deploying components on alternative hosts
- Deployments with
– No waveforms
– One waveform
– Different combinations of waveforms
• Can show radio in different states as radio starts
up or transitions from one waveform to another

55. SPL according to SEI
(5th framework, 2007)

56. SPL according to SEI

57. SPL according to SEI

58. Two approaches to start a SPL
• Proactive: Develop the core assets first
• Develop the scope first and use it as a “mission” statement.
• Products come to market quickly with minimum code writing.
• Requires upfront investment and predictive knowledge
• Reactive: Start with one or more products
• From them, generate the product line core assets and then the future
products; the scope evolves more dramatically
• Much lower cost of entry
• The architecture and other core assets must be robust, extensible, and
appropriate to future product line needs

59. Summary
Product Line Architectures, rather than
single-product architectures, support
systematic reuse
• represent recurrent requirements and
architectures (i.e., components and interfaces)
suitable for solving typical problems in a domain
• depict structures for design related products and
provide models for integrating optional/
alternative components
• allow engineers to come up with the right
solutions quickly and effectively

60. Architecture-Centric Development Activities
Architecture-specific activities for SPL include:
• creating the business case for the system
• understanding the requirements
• creating and/or selecting the architecture
• documenting and communicating the architecture
• analyzing or evaluating the architecture
• implementing the system based on the architecture
• ensuring that the implementation conforms to the
architecture

61. From SA to PLA
• Of all a product line’s core assets, the product
line architecture is the most important one for
ensuring technical success.
• If an organization already uses disciplined
practices to develop single-product software
under the aegis of a software architecture, it is
well poised to
• define a product line architecture
• Identify the core assets
• Build products from those core assets.

62. Test questions
• What is a software product line?
• What is a product line architecture?
• What is variability management?

63. References
• Clemens & Northrop, Software Product Lines, Addison Wesley, 2002
• Gomaa, Designing SPL with UML, Addison Wesley, 2005
• Pohl & Böckle, SPL Engineering: foundations, principles, and
techniques, Springer 2005
• vanderLinden & Schmid & Rommes, SPL in action, Springer, 2007
• van Gurp & Bosch & Svahnberg, On the notion of variability in SPL,
Conf. on Sw Architecture, 2001
• Eriksson, Bostler, Borg, Software product line modeling made
practical. An example from the Swedish defense industry, CACM 2006
• Krueger & Jackson, Requirements engineering for systems and
software product lines, White paper IBM Rationa,l 2009

64. Conferences
• SPLC 2011, Munich, Germany
• Workshop on Variability in Software Product Line
Architectures
• Wokshop on Product LinE Approaches in Software
Engineering (PLEASE)

65. Sites
• www.sei.cmu.edu/productlines
• www.biglever.com

66. Questions?