Software Product Lines
Adapted from: •Software Product Lines: Reuse That Makes Business Sense by Linda Northrop, 2007 •Software Architecture in Practice, 3rd edition by Bass, Clements and Kazman •Software Product Lines: Practices and Patterns by Clements and Northrop. •Feature Diagrams and Logics: There and Back Again, Czarnecki ,2007 •Managing Variability in Software Architectures, Bachman & Bass,2001
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 1
Strategic and Systematic Reuse
Large scale, strategic, planned reuse
Software Product Lines
Software product lines align software reuse with business strategy to produce predictable results.
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 2
What is a Software Product Line?
What are some product line examples? J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 3
Business Goals
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 4
Failure of Ad Hoc Reuse Reuse libraries that are ….
Not useful Too difficult to use Too small – easier to rewrite Unknown pedigree Quality attributes mismatched or insufficient
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 5
Economics Of Product Lines
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 6
Essential Activities
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 7
Management Challenges Business case – ROI Customer communications Startup – launching and institutionalizing Configuration management Process discipline Product schedule priority conflict resolution Make/buy/reuse/sub-contract decisions Project planning, resourcing, budgeting Testing
Product Line Development Adoption strategies Top down versus bottom up Proactive versus reactive adoption Incremental versus big-bang
Organizational structure Who manages, develops, and supports core assets? Dedicated group? Coordinated across product teams?
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 8
Scope, Commonality, and Variability Analysis (SCV)
Adapted from: •Software Product Lines: Reuse That Makes Business Sense by Linda Northrop, 2007 •Software Architecture in Practice, 3rd edition by Bass, Clements and Kazman •Software Product Lines: Practices and Patterns by Clements and Northrop. •Feature Diagrams and Logics: There and Back Again, Czarnecki ,2007 •Managing Variability in Software Architectures, Bachman & Bass,2001
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 9
Scoping Find commonality and variation points among potential products Product Lines are distinguished in terms of features Software and potentially associated hardware elements
Identify differentiating characteristics among products Feature Matrix Feature Model Scope, variability, commonality (SVC) analysis
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 10
Feature Matrix
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 11
Feature Model
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 12
SVC Architecture Analysis Find architecture variation points to support modifiability Module(s) that needs to be modifiable to achieve a product line variation Based on what will be common, what will vary in the product line
Select a variation mechanism for each variation point Trade-off – cost of over-engineering flexibility versus design refactoring Variability (modifiability)as a quality attribute
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 13
Variation Points
Alternatives for Variant A
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 14
Variation Mechanisms Ways to configure variation points; compile, build, or run time Each mechanism has a cost – development, deployment, side effects
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 15
Architecture Variation Mechanisms Could just copy modules and make changes (“clone and own”) Fast and easy, but scalability? Inclusion or omission of elements Through build procedures
Selection of different versions of elements with the same interface Different behavioral or quality attribute characteristics. Selection can occur at compile, build, or run time.
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 16
Variation Mechanisms Extension points
Identified places in the architecture to safely add functions
Reflection
Programs that can adjust their behavior or state at runtime
Overloading
Reuse named functionality with different parameter types
Inheritance
Specialization or generalization of a class
Component substitution
Swap components at compile time
Add-ons, plug-ins
Runtime substitution of components
Templates
Code templates – add application specific code
Parameters
Parameter values specify variations
Generator
Code generators
Aspects
Separate “cross cutting” concerns
Runtime conditions
Execution decisions directed by conditional values
Configurator
Installation configuration of components
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 17
Android Software Architecture
J. Scott Hawker/R. Kuehl RIT Software Engineering
p. 18