1. Enhancing the scope of CSCI577ab with Software Product Line Engineering
Kevin Ha
April 27, 2011

2. Outline Introduction Motivation
Software Product Line Engineering (SPLE)
Framework
Challenges
Solutions
Knowledge and Skills to adopt SPLE
Additional artifacts
Summary
References

3. Introduction Industry 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

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

5. 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)

6. Key to SPLE Is to determine the Commonality Variability
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
Determine:
what is common between the products
what are the differences between the products

7. 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).
Domain artifacts
- Constitutes the product line PLATFORM
Application Engineering
- Exploits the variability of the domain artifacts by resolving variability according to the requirements defined for the particular application (product).
- Integrates product’s core assets
- instantiate variation points
- implement product specific functionality
Having separate processes provide separation of concerns
robust product line platform
establish individual, customer or market specific products

8. Modeling Variability Two approaches
Integrate variability information into existing models
Dedicated variability model
Orthogonal Variability Model (OVM)
OVM, only the variability of the product line is documented (independent of its realization in the various product line artifacts).
Will not get into these approaches due to time constraint. Instead I will talk about the challenges that

9. Change Control Problems
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.

10. Simple, not too bad to manageWF
WelcomeFaith = WF
Simple, not too bad to manage

11. 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”
Core assets
1. implement most product functionality
2. support variable functionality
Core assets must support different products, so it must support different stakeholders. Sometimes it must satisfy conflicting needs of different stakeholders.
Custom assets
1. integrate product’s core assets
2. instantiate variation points (interfaces)
3. implement functionality unique to the product

12. Common Assets
USA
Core Assets (Common)
GERMANY …
Variation Points (Interfaces)
US Air Defense System Product = Common (including variation Points) + USA
NATO Air Defense System Product = Common (including variation points) + Germany
Variation points are most likely related for the different products.
Example:

13. 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
Different product release constraints
Schedule
Quality
Product Line Decay
New similar functionality implemented in custom assets
Erosion of SPLE benefits

14. Root Cause
Shared core assets must satisfy the sometimes conflicting needs of different stakeholders (US and NATO)

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

16. Diagram showing specific branched version of a core asset
US product is still using the latest version of Common
Germ 2
Germ 1
Canadian ADS
Common 6
Common 5
Common 4
Common 3
Common 2
Common 1
Artifact XYZ
Diagram showing specific branched version of a core asset
As you can see in this example, having a Germ branch voids the benefit of reusability in SPLE. With these two branches, only the US benefits from changes to the common version of artifact XYZ and vice versa, only Germany benefits from changes to the Germ history.
Germ history (branch) has only the functionality specific to the Germany product.
If you start a new product, you can look at all of the common versions of artifact XYZ and pick up the version most suitable for that product.

17. 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
If it is product specific, then branching from the history might be required.
Fake core changes.
- Implement core changes in the custom asset.
- This solve the problem of different product release constraints.
- This should ONLY be used sparingly because it leads to decay of SPLE.
Folding back fake core changes
- fake core changes due to conflicting stakeholder needs, then negotiate out the conflict in order to fold the core changes back

18. Solutions (Cont’d) Higher Quality Core Assets
High quality core assets are essential
Smaller core assets changes = smaller number of change control problems
Extra effort needed to ensure very high quality core assets

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

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

21. 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?)
Orthogonal Variability Model

22. Summary Introduced SPLE SPLE lectures coming to future CS577ab??
Framework
SPLE challenges and solutions
Knowledge and skills needed to adopt SPLE
Additional SPLE artifacts
SPLE lectures coming to future CS577ab??

23. 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 , 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 , 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 , ACM Press, Los Angeles, USA,
[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 , 2002.
[6] P. Clements, “Successful Product Line Engineering Requires More Than Reuse” 8th Workshop on Institutionalizing Software Reuse, pp , Ohio (USA), 1997.
[7] P. Clements, “On the Importance of Product Line Scope”, Software Product-Family Engineering, LNCS vol 2290, Springer-Verlag, pp , 2002.
 [8] J. M. DeBaud and P. Knauber, “Applying PuLSE for Software Product Line Development” 2nd European Reuse Workshop, pp , 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 , 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.

24. References (Cont’d)
[12] D. L. Parnas. “Software aging”. In Proceedings of the 16th International Conference on Software Engineering (ICSE’94), Sorento, Italy, IEEE Computer Society Press. [13] A. Metzger, and K. Pohl, “Variability Management in Software Product Line Engineering” 29th International Software Engineering Conference, pp , [14] O. Kobayashi, “What Should Software Practitioners Know for Adopting Product Line Software Engineering?”, 11th Asia-Pacific Software Engineering Conference, pp , [15] M. Jiang, J. Zhang, H. Zhao, and Y. Zhou, “Maintaining Software Product Lines – an Industrial Practice”, IEEE International Conference on Software Maintenance, pp , [16] M. Staples, “Change Control for Product Line Software Engineering”, 11th Asia-Pacific Software Engineering Conference, pp , [17] C. Krueger, “Software Product Line Reuse in Practice”, 3rd IEEE symposium on Application-Specific Systems and Software Engineering Technology, pp , [18] A. Fuggetta and E. Nitto, “Product lines: what are the issues?”, 10th International Software Process Workshop, pp , 1996.

25. Thank You!