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

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. http://www.sei.cmu.edu/news-at-sei/features/2002/4q02/feature-2-4q02.htm .

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

- 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

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. http://www.sei.cmu.edu/productlines/

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 http://www.sei.cmu.edu/productlines/

SA Ch 14 – Software Product Lines From the SEI: You can “acquire” a product line capability – like the military does: From http://www.sei.cmu.edu/reports/10tr014.pdf, p 6.

SA Ch 14 – Software Product Lines From the SEI: What’s product line work look like to a developer? From http://www.sei.cmu.edu/reports/10tr014.pdf, p 7.

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

- 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”?

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 http://www.softwareproductlines.com/introduction/introduction.html. Crystal ball image from http://funingames.net/2011/01/2011-a-look-through-the-crystal-ball/.

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

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 http://www.softwareproductlines.com/introduction/introduction.html.

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 http://www.softwareproductlines.com/introduction/introduction.html.

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 http://www.softwareproductlines.com/introduction/introduction.html.

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 http://www.softwareproductlines.com/introduction/introduction.html.

- 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

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

SA Ch 14 – Software Product Lines And a framework of best practices! See http://www.sei.cmu.edu/productlines/frame_report/index.html. As a sample follow-up activity, please read the section of this document on configuration management!