1. CSSE 477 Software Architecture
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

2. How’s the Security project going?
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. .

3. And, for extra credit…
Go to this tonight, 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

4. - 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
= 4
“load
lines”
that
are
better
than
3 !
Develop product 2
2-Spl
CORE
Develop core
product
Develop product 3
3-Spl

5. 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-of-magnitude 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.

6. 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

7. SA Ch 14 – Software Product Lines
From the SEI:
You can “acquire” a product line capability – like the military does:
From p 6.

8. SA Ch 14 – Software Product Lines
From the SEI:
What’s product line work look like to a developer?
From p 7.

9. - from CSSE 375 -
SA Ch 14 – Software Product Lines
How do you do an architecture for a product line (pp. 360+), cntd?
Supporting variation points –
Inclusion or omission of elements
Inclusion of a different number of replicated elements
Selection of versions of elements that have the same interface but different behavioral or quality attribute characteristics
Supporting these variations can cause:
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)

10. - from CSSE 375 -
SA Ch 14 – Software Product Lines
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”?

11. 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.
Discussion from Crystal ball image from

12. - from CSSE 375 -
SA Ch 14 – Software Product Lines
Commonalities are a key (pp )?
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…

13. SA Ch 14 – Software Product Lines
Details – Ingredients in making product lines work well:
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.
Discussion from

14. 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.
Discussion from

15. 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.
Discussion from

16. 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.
Discussion from

17. - from CSSE 375 -
SA Ch 14 – Software Product Lines
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

18. SA Ch 14 – Software Product Lines
A great case history – Celsius Tech
Bass Ch 15
- See separate slide set on the course web site! -

19. SA Ch 14 – Software Product Lines
And a framework of best practices!
See
As a sample follow-up activity,
please read the section
of this document on
configuration management!