Transcript Slide 1

Enhancing the scope of CSCI577ab with Software Product
Line Engineering
Kevin Ha
April 27, 2011
Outline
Introduction
 Motivation
 Software Product Line Engineering (SPLE)

◦
◦
◦
◦
◦
Framework
Challenges
Solutions
Knowledge and Skills to adopt SPLE
Additional artifacts
Summary
 References

Introduction

Software Engineering in CS577ab
◦ Provides students SE foundations
◦ Gives students hands on experience
◦ Materials are tailored for one of a kind system

Industry
◦ “First to Market” mentality
◦ Similar software for cell phone devices, software
applications, automobiles, GPSs, radars, air defense
systems, etc.
◦ Favors product line approach
Motivation

Bridging the gap between skills taught in 577ab
and skills required in industry
◦ Suggest Ideas to enhance scope of CS577ab to better
prepare students for an immediate contribution to
the SE industry.
What is SPLE?

Paradigm for developing a diversity of similar
software intensive systems (similar products)
◦ At low costs (benefit from reuse)
◦ In short time (improve time-to-market)
◦ With high quality (benefit of reuse)
Key to SPLE

Is to determine the
◦ Commonality
 Artifacts and properties shared by all products
 Core assets (implement most product functionality)
◦ Variability
 Artifacts and properties that make the products different
 Support the variable functionality to make the products
different
Framework for SPLE
Process to define the
commonality (core asset) and
variability of the products.
Process to derive applications
from the domain artifacts
(custom assets).
Having separate processes provide separation of concerns
• robust product line platform
• establish individual, customer or market specific products
Modeling Variability

Two approaches
1. Integrate variability information into existing
models
2. Dedicated variability model

Orthogonal Variability Model (OVM)
Change Control Problems
1.
Complicated configuration Identification
◦ Configuration Management of single system
 Collection of 1 history (version) of versioned objects
 Example: WelcomFaith has 1 history of say WF and it has a collection of
objects (artifacts, code files, etc.) with different version for each object.
WF


WelcomeFaith = WF
Simple, not too bad to manage
Complicated Configuration
Identification (Cont’d)

Configuration Management in SPLE
◦ Each core asset and custom asset combination is a
different configuration
 Example: Command and Control (C2) air defense system is a
product line supporting two products.
 Product 1 configuration combines the core asset with
history of “common” and the custom asset with history of
say “USA”
 Product 2 configuration combines the same core asset
“common” and the custom asset with history of say
“Germany”
Common Assets
USA
GERM
ANY
Core Assets
(Common)
…


Variation Points
(Interfaces)
US Air Defense System Product = Common (including variation
Points) + USA
NATO Air Defense System Product = Common (including variation
points) + Germany
Change Control Problems (Cont’d)
Change in variation point (core asset
interface) can force changes in all products
using the new version of the core assets
3. Different product release constraints
2.
◦
◦
Schedule
Quality
Product Line Decay
4.
◦
◦
New similar functionality implemented in custom
assets
Erosion of SPLE benefits
Root Cause

Shared core assets must satisfy the sometimes
conflicting needs of different stakeholders (US and
NATO)
Change Control Solutions

Do not have to use latest version of Core asset
◦ Solves change in variation point
◦ Solves different product release constraints
◦ Product specific branch version of core asset
 Too much can void the benefit of SPLE
US product is still using
the latest version of
Common
Canadian ADS
Germ 2
Germ 1
Common 6
Common 5
Common 4
Common 3
Common 2
Common 1
Artifact XYZ
Diagram showing specific branched version of a core asset
Solutions (Cont’d)

Core Change Control Board (CCB)
◦ Consists of Subject Matter Experts (SME)
◦ Negotiate with different stakeholders
◦ Carefully review potential changes
 Is it product specific changes?
◦ Determine whether fake core changes are
appropriate?
◦ Constant work to reduce/eliminate decay
 Folding back core changes
Solutions (Cont’d)

Higher Quality Core Assets
◦ High quality core assets are essential
◦ Smaller core assets changes = smaller number of
change control problems
Knowledge/skills for SPLE?

What do we need to know for adopting
PLSE?
◦ Software Architecture
 Need to consider commonalities and variation points of
product lines
◦ Programming Techniques
 Knowing pros and cons and associated costs
◦ Cost Estimation
 Need to consider costs to maintain the core assets.
 Might be expensive
 Who will pay for it?
◦ Configuration Management
Additional SPLE Artifacts
Domain artifacts
 Application (product) artifacts
 Variation points artifact

◦ Whether integrated or dedicated (OVM)
Product history (branch) artifact
 Artifact capturing all decisions made by the
CCB

If OVM is Selected

OVM artifacts should cover
◦
◦
◦
◦
Variation points (what vary?)
Variant (How do they vary?)
Variability constraints
Visibility of variability (who is it documented for?
Internal or external variability?)
Summary

Introduced SPLE
◦
◦
◦
◦

Framework
SPLE challenges and solutions
Knowledge and skills needed to adopt SPLE
Additional SPLE artifacts
SPLE lectures coming to future CS577ab??
References
[1] K. Kim, H. Kim, and W. Kim, “Building Software Product Line from the Legacy Systems “Experience in the Digital
Audio & Video Domain” 11th International Software Product Line Conference, pp.171-180, 2007.
[2] R. Capilla and J. Duenas, “Light-weight product-lines for evolution and maintenance of Web sites” 7th European
conference on Software Maintenance and Reengineering, pp. 53-62, IEEEXplorer, 2003.
[3] J. Bayer, O. Flege, P. Knauber, R. Laqua, D. Muthig, K. Schmidt, T. Widen and J. M. DeBaud, “PuLSE: A Methodology to
develop Software Product Lines” 5th Symposium on Software Reusability, pp.122-131, ACM Press, Los Angeles, USA,
1999.
[4] J. Bergey, L. O’Brien and D. Smith. “Mining Existing Assets for Software Product Lines”, CMU/SEI-2000-TN-008,
Technical Report, Software Engineering Institute, Carnegie Mellon University, Pittsburg, PA (USA), 2000.
[5] J. Bosch, G. Florijn, D. Greefhorst, J. Kuusela, H. Obbink and K. Pohl, “Variability Issues in Software Product Lines”,
Software Product-Family Engineering, LNCS vol 2290, Springer-Verlag, pp. 13-21, 2002.
[6] P. Clements, “Successful Product Line Engineering Requires More Than Reuse” 8th Workshop on Institutionalizing
Software Reuse, pp. 63-68, Ohio (USA), 1997.
[7] P. Clements, “On the Importance of Product Line Scope”, Software Product-Family Engineering, LNCS vol 2290,
Springer-Verlag, pp. 70-78, 2002.
[8] J. M. DeBaud and P. Knauber, “Applying PuLSE for Software Product Line Development” 2nd European Reuse
Workshop, pp. 73-94, Madrid, Spain, 1998.
[9] F. Loesch, R. Bosch, and E. Ploedereder, “Optimization of Variability in Software Product Lines” 11th International
Software Product Line Conference, pp. 151-162, 2007.
[10] P. Clements and L. Northrop. Software Product Lines: Practices and Patterns. Addison-Wesley, 2001.
[11] S. Deelstra, M. Sinnema, J. Nijhuis, and J. Bosch. COSVAM: A technique for assessing software variability in
software product families. In Proceedings of the 20th IEEE International Conference on Software Maintenance
(ICSM’04), pages 458–462, September 2004.
References (Cont’d)
[12] D. L. Parnas. “Software aging”. In Proceedings of the 16th International Conference on Software Engineering
(ICSE’94), Sorento, Italy, 1994. IEEE Computer Society Press.
[13] A. Metzger, and K. Pohl, “Variability Management in Software Product Line Engineering” 29th International
Software Engineering Conference, pp. 186-187, 2007.
[14] O. Kobayashi, “What Should Software Practitioners Know for Adopting Product Line Software Engineering?”,
11th Asia-Pacific Software Engineering Conference, pp. 565-566, 2004.
[15] M. Jiang, J. Zhang, H. Zhao, and Y. Zhou, “Maintaining Software Product Lines – an Industrial Practice”, IEEE
International Conference on Software Maintenance, pp. 444-447, 2008.
[16] M. Staples, “Change Control for Product Line Software Engineering”, 11th Asia-Pacific Software Engineering
Conference, pp. 572-573, 2004.
[17] C. Krueger, “Software Product Line Reuse in Practice”, 3rd IEEE symposium on Application-Specific Systems and
Software Engineering Technology, pp. 117-118, 2000.
[18] A. Fuggetta and E. Nitto, “Product lines: what are the issues?”, 10th International Software Process Workshop, pp.
51-53, 1996.
Thank You!