Software Product Lines
Re-using Architectural Assets
- continued from CSSE 375 CSSE 477
Software Architecture
Week 7, Day 2, including
Ch 14 in Bass’s book
1
Today –
How’s the Security project going?
Tonight – turn in arch doc changes, sec 3 - 5
How’s the research paper going?
Product Lines: Chapter 14 in SA (Bass et al’s book) 
Coming up –
Thursday
Work on Security project
Friday
Show & tell / turn-in security project
Linda Northrop and Len Bass flank Henk Obbink of Philips Research
Laboratories at a 2002 conference on software product lines.
http://www.sei.cmu.edu/news-at-sei/features/2002/4q02/feature-2-4q02.htm .
2
And, for extra credit…
•
Go to this tonight, email me a paragraph describing what you learned, and it
will replace any missing daily quiz grade for CSSE 477:
Beckman Coulter Software Development Tech Symposium
The Union Heritage Room on Thursday, October 20th
5:00- Welcome and Introductions
5:15- Concurrent Software Development with Bob Burger
Why concurrent software is important, what makes it difficult, what concurrency models make it
easier, and how we have used these models at Beckman Coulter over the past decade to make
robust systems.
6:15- Open Panel Discussion
Refreshments will be served
7:00- Domain-specific Programming Languages for Automation with Mike Ashley
Scientists and medical laboratory pathologists want to automate their routine work and do so with
languages that match how they think. This talk will survey different languages we have developed
to automate tasks and give some detail on how these languages were implemented.
8:00- Closing Comments
3
- from CSSE 375 -
SA Ch 14 – Software Product Lines
Review from CSSE 375 discussion:
What is a software product line? (p. 353)
A set of software-intensive systems sharing a common, managed set of features
that satisfy the specific needs of a particular market segment or mission and
that are developed from a common set of core assets in a prescribed way.
In the product line manager’s view, it should go like this:
Develop product 1
1-Spl
Develop product 2
2-Spl
Develop core
product
CORE
Develop product 3
3-Spl
=4
“load
lines”
that
are
better
than
3!
4
SA Ch 14 – Software Product Lines
From the SEI:
Software product lines are emerging as a viable and important
development paradigm allowing companies to realize order-ofmagnitude improvements in time to market, cost, productivity,
quality, and other business drivers. Software product line
engineering can also enable rapid market entry and flexible
response, and provide a capability for mass customization.
How do you implement processes that make software product lines
a dependable, low-risk high-payoff practice?
Combines business and technical approaches to achieve success.
5
SA Ch 14 – Software Product Lines
From the SEI:
Benefits
Product lines can help organizations overcome the problems
caused by resource shortages. Organizations of all types and
sizes have discovered that a product line strategy, when
skillfully implemented, can produce many benefits—and
ultimately give the organizations a competitive edge. Example
organizational benefits include:
•
•
•
•
•
•
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
6
SA Ch 14 – Software Product Lines
From the SEI:
You can “acquire” a product line capability – like the military does:
7
SA Ch 14 – Software Product Lines
From the SEI:
What’s product line work look like to a developer?
8
SA Ch 14 – Software Product Lines
- from CSSE 375 -
How do you do an architecture for a product line (pp. 360+), cntd?
Supporting variation points –
1. Inclusion or omission of elements
2. Inclusion of a different number of replicated elements
3. Selection of versions of elements that have the same interface but
different behavioral or quality attribute characteristics
Supporting these variations can cause:
a.
b.
c.
d.
e.
In OO systems, specializing or generalizing of classes
Building extension points
Introducing build-time parameters
A need for reflective programs, which analyze their data & situation
Overloading of types (good and bad)
9
SA Ch 14 – Software Product Lines
- from CSSE 375 -
How do you do an architecture for a product line (pp. 360+), cntd?
Evaluating a product line architecture –
What and how to evaluate – focus on variation points
When to evaluate – when you think you need separate products with
architectural variations, or when a new product is proposed which
seems significantly different
So, this product line stuff can be a great efficiency or a real problem!
Which of these belong on the same “production line”?
10
SA Ch 14 – Software Product Lines
What makes software product lines work?
Skill in predicting the future! (Or making it happen.)
The characteristic that distinguishes software product lines from previous
efforts is predictive versus opportunistic software reuse. Rather than put
general software components into a library in hopes that opportunities for
reuse will arise, software product lines only call for software artifacts to be
created when reuse is predicted in one or more products in a well defined
product line.
11
SA Ch 14 – Software Product Lines
- from CSSE 375 -
Commonalities are a key (pp. 355-6)?
Commonalities in:
Requirements
Architectural design
Software elements
Modeling and analysis
Testing
Project planning
Processes, methods and tools
People
Exemplar systems
Defect elimination
“Scoping” determines what systems
are in and out (pp 357-8).
Narrow vs. broad scope…
12
SA Ch 14 – Software Product Lines
Details – Ingredients in making product lines work well:
1. Software asset inputs: a collection of software assets – such as
requirements, source code components, test cases, architecture, and
documentation – that can be configured and composed in different ways to
create all of the products in a product line. Each of the assets has a well
defined role within a common architecture for the product line. To
accommodate variation among the products, some of the assets may be
optional and some of the assets may have internal variation points that can
be configured in different ways to provide different behavior.
13
SA Ch 14 – Software Product Lines
Details - Ingredients in making product lines work well:
2. Decision model and product decisions: The decision model describes
optional and variable features for the products in the product line. Each
product in the product line is uniquely defined by its product decisions choices for each of the optional and variable features in the decision model.
14
SA Ch 14 – Software Product Lines
Details - Ingredients in making product lines work well:
3. Production mechanism and process: the means for composing and
configuring products from the software asset inputs. Product decisions are
used during production to determine which software asset inputs to use and
how to configure the variation points within those assets.
15
SA Ch 14 – Software Product Lines
Details - Ingredients in making product lines work well:
4. Software product outputs: the collection of all products that can be produced
for the product line. The scope of the product line is determined by the set
of software product outputs that can be produced from the software assets
and decision model.
16
SA Ch 14 – Software Product Lines
- from CSSE 375 -
What makes software product lines so difficult (pp. 363+)?
Need a mature organization
Need an architecture definition
Need configuration management
Need a conscious decision to adopt an architecture (See Ch 15)
May need to make use of external sources
May need different use of internal sources (e.g., supplying each other)
Probably need to reorganize, need business units to work together
17
SA Ch 14 – Software Product Lines
A great case history – Celsius Tech
Bass Ch 15
- See separate slide set on the course web site! -
18
SA Ch 14 – Software Product Lines
And a framework of best practices!
See http://www.sei.cmu.edu/productlines/frame_report/index.html.
As a sample follow-up activity,
please read the section
of this document on
configuration management!
19