Product Line Engineering
CS 415, Software Engineering II
Mark Ardis, Rose-Hulman Institute
March 11, 2003
Acknowledgements
•
•
•
•
•
David Weiss
Lloyd Nakatani
Janel Green
Bob Olsen
Paul Pontrelli
2
Outline
1. What is product line engineering?
2. How did we use product line
engineering at Lucent?
3. Why did product line engineering work
(at Lucent)?
3
Airbus Beats Boeing in Huge
Jetliner Deal with USAir (11/6/96 NY Times)
• USAir, which had never bought a plane from
Airbus, will purchase 120 Airbus A319s,
A320s, and A321s...
• USAir’s current fleet is a hodgepodge of nine
types of aircraft
• A simplified domestic fleet would allow USAir
to lower costs.
• Importance of Commonality
– USAir will reduce costs by using one aircraft type
– Airbus is reducing its production costs by reusing
one aircraft type
4
Airbus Wins $4 Billion Order From
Iberia, Beating Boeing (2/4/98 NY Times)
• Iberia ordered 76 planes:
– 9 A319’s, each with capacity
for 124 passengers
– 36 A320’s, each with capacity
for 150 passengers
– 31 A321’s, each with capacity
for 185 passengers
5
Airbus Wins $4 Billion Order...
• “Iberia president said single-aisle Airbus
models... though differing in passenger
capacity, had identical cockpits and
mechanical specifications that offered
savings in crew training and
maintenance.”
6
Product Line Approach
• Reorganize the software development
process
– Evolve a family rather than build single
systems
– Invest in family infrastructure: Capitalize
• Develop systematic approach to
building flexible application generators
7
FAST: Family-oriented Abstraction,
Specification, Translation
Domain Engineering
Feedback
Application Environment
Application Engineering
Applications
8
Domain Engineering
Domain Analysis
Domain Model
Analysis Document,
Application Modeling
Language
Domain Implementation
Application Environment
Tools,
Process
9
Application Engineering
Application
Requirements
Application Environment
Application Engineering
Application
10
Economics of Families
Current
Practice
Cumulative
Cost
Domain
Engineering
Number of Family Members
11
Defining a Family:
Commonality Analysis
• Dictionary: Technical vocabulary of the
domain
• Commonalities: Assertions about every
member of the family
• Variabilities: Assertions about variation across
the family
• Consensus process
– All domain experts invited to participate
– Led by a trained moderator
– Real-time editing of the document
12
Application Engineering
Environment
• A language for specifying family
members
• Translators from specification to code
• Libraries of common code
• Supporting tools
– Simulator
– Test case generator
– Verifier
13
FAST Benefits
•
•
•
•
•
Improved Understanding
Shorter Intervals
Lower Costs (Domain Dependent)
Process Innovation
Improved Technology
14
Cartoon of the Day
15
How Did We Use Product
Line Engineering at Lucent?
16
Eli Whitney
• Born December 8, 1765
• Raised on a farm in
rural Massachusetts
• Attended Yale College
1789-1792
• What did Whitney do in
1793?
17
The Cotton Gin
• Whitney invented the
cotton gin in 1793
• Southern planters
refused to pay royalties
on patent
– The gin was easy to
manufacture
– Southern legislatures
conspired against
Whitney
18
Eli Whitney
• Whitney’s company was
out of business by 1797
• What did Whitney do in
1798?
19
Flintlock Components
20
Whitney’s Gamble on
Automation
• Whitney offered to make 10,000 muskets
in 2 years
• No other manufacturer had ever made
more than a few hundred muskets
• Automation was needed to improve the
efficiency of the locksmiths
• Whitney invented milling machines to
produce interchangeable parts
• Demonstrated for Congress in 1802
21
Putnam Machine Company, 1875
22
Configuration Control
• Software that enables changes in switch
configuration while the switch is operating
– Ensures that requested configurations are valid
and safe
– Reconfigures
– Example: Remove a Protocol Handler (PH) from
service and replace it with a spare
• New switching technology requires new
configuration controllers
– New unit types for new functionality of lower cost
23
Maintenance Domain Structure
Human Machine
Interface
Routine
Maintenance
Initialization
Control
Diagnostics
Maintenance
Administrator
Fault Detection
and Analysis
Configuration
Control
Hardware Software
Interface
24
Commonality Analysis of
Configuration Control
• 1 staff-year effort over 6 months by 6
experts
• Produced a Commonality Analysis
– Definitions: rational vocabulary
– Commonalities: reusable algorithms
– Variabilities: relationships between devices
– Parameters of Variation: enumerated types
• Reviewed by organization
25
Building Technology for
Configuration Control
• 2 staff-years effort over 12 months by 3
experts
• Languages -- capture generic
algorithms and parameters
• Translators -- translate to executable
code
• Interface to legacy system
• Graphical editor
26
Configuration Control
Architecture
RAD
SMALL-D
Application
Engineering
Environment
SMALL-V SMALL-R
C Data
VFSM
Domain
Engineering
Environment
Application
27
Configuration Control
Development Environment
Application
Data
RAD
Reusable
Assets
Knowledge
Base
C Code
Application
Engineer
Application
Environment
Interface
Domain
Engineer
Application Specific
Configuration Control
28
RAD Tool
29
Reusable Assets
• Validations -- generic algorithms for every unit
type
• Realizations -- generic algorithms for every
unit type
• Relationships
– data that is used to drive the generic algorithms
– design information shared across development
30
Applications
• Project 1 (1994)
– re-engineering project to demonstrate feasibility
– replaced existing code and demonstrated in lab
• Project 2 (1996)
– shadow project to demonstrate performance
– duplicated work of another team and compared
results
• Project 3 (1997-1998)
– first real application
– reworked domain analysis as work progressed
• Project 4 (1999)
– production use
31
Interval Reduction on 5ESS
Projects
100
80
60
40
20
0
CAL
HSI
DECC
PS
AD
AIM
TLP
TRPT
AC
32
Measuring Benefits
• Siy and Mockus studied the effect of
domain engineering on the AIM project:
– Studied 22,804 MRs involved in 1351
distinct software features over a 7 year
period
– Found that domain engineered MRs took
1/4 of the time of other MRs
– Total savings was $6M - $9M for 1999.
33
Where is Domain Engineering
Being Used in Lucent?
• Switching
– Naperville, IL
– Boulder, CO
– Hilversum, Netherlands
– Malmesbury, England
– Poland
• Wireless
– Software development processes
34
Why Did Product Line
Engineering Work
(at Lucent)?
35
Diffusion of Innovations
• Classic work by Everett M. Rogers (ISBN 002-926671-8)
• Discovered keys to technology transfer:
– Relative advantage
• How much better is it?
– Compatibility
• Is it consistent with values, experiences, and needs?
– Complexity
• How difficult is it to understand and use?
– Trialability
• How easily may it be tried experimentally?
– Observability
• How visible are the results of use?
36
Technology Transfer at Lucent
• Estimates are that we only use about 10% of
the good ideas developed within Bell Labs
Research
• What’s wrong with the other 90%?
–
–
–
–
–
Relative advantage?
Compatibility?
Complexity?
Trialability?
Observability?
37
Oral Culture of 5ESS
38
Problems of Oral Culture
• No History (Goody and Watt)
– Story changes with each telling
– Evolution breeds decay
• No abstraction (Luria)
– Insistence on reasoning in terms of ground
elements
– Refusal to extend arguments to
abstractions
39
From Orality to Literacy
•
•
•
•
Write it down
Identify abstractions
Construct languages
Create in the new languages
40
Power of Written Language
• Generic algorithms of Configuration Control
– Translated to flowcharts and English for review
– Executed in simulator for further review
– Translated to VFSM for execution
• Commonality Analysis of Configuration
Control
– Starting point for DECC implementation
– Starting point for 4 other designs
41
Diffusion of Domain
Engineering
• Relative advantage:
– Solution to the right problem
• Compatibility:
– by the right people
• Complexity:
– using the right tools and methods
• Trialability:
– so that anyone can try it
• Observability:
– and see the results
42
Conclusion
• Domain engineering reduces interval
and cost of software development
• Resulting products are more consistent
and easier to maintain
• Capturing domain knowledge in written
form was the key
43
References
Siy and Mockus, "Measuring domain engineering
effects on software coding cost", 6th International
Symposium on Software Metrics, 304-311, November
4-6, 1999.
Ardis, Dudak, Dor, Leu, Nakatani, Olsen, Pontrelli,
"Domain engineered configuration control", Software
Product Line Conference, August 28-31, 2000.
Ardis and Green, "Successful introduction of domain
engineering into software development", Bell Labs
Technical Journal 3(3), July-September 1998.
44