Software Product Line Engineering Andrew Burmester SE 4110 Section 2 4/14/11.

Software Product Software Product Line EngineeringLine Engineering

Andrew BurmesterAndrew Burmester

SE 4110 Section 2SE 4110 Section 2

4/14/114/14/11

IntroductionIntroduction

Product LinesProduct LinesAuto IndustryAuto Industry

Need a way to produce a large variety of Need a way to produce a large variety of vehicles within a short time period.vehicles within a short time period.

Answer: Create a standard family and Answer: Create a standard family and modify this basis to meet customers modify this basis to meet customers needs.needs.

Can we apply these techniques to Can we apply these techniques to Software Engineering?Software Engineering?

Software Product LinesSoftware Product Lines

Before defining the Software Before defining the Software Product Line, a few concepts need to Product Line, a few concepts need to be addressed.be addressed. Mass Customization – Large-scale Mass Customization – Large-scale

production of goods tailored to production of goods tailored to individual customers’ needsindividual customers’ needs

Platform – Any base of technologies on Platform – Any base of technologies on which other technologies or processes which other technologies or processes are built.are built.

Software Product LinesSoftware Product Lines

Definition of Software Product Line Definition of Software Product Line Engineering:Engineering: ““Software product line engineering is a Software product line engineering is a

paradigm to develop software paradigm to develop software applications (software intensive systems applications (software intensive systems and software products) using platforms and software products) using platforms and mass customization.”and mass customization.”

Software Product LinesSoftware Product Lines

Two main parts of a software product Two main parts of a software product line:line:Domain PlatformDomain Platform

““A software platform is a set of subsystems A software platform is a set of subsystems and interfaces that form a common structure and interfaces that form a common structure from which a set of derivative products can from which a set of derivative products can be efficiently developed and produced”be efficiently developed and produced”

Derivative ApplicationsDerivative ApplicationsDistinct products that were realized by using Distinct products that were realized by using

the platform.the platform.

Software Product LinesSoftware Product Lines

Motivations to use software product Motivations to use software product lineslinesReduction of development costsReduction of development costs

Enhanced qualityEnhanced quality• Platform heavily testedPlatform heavily tested• A lot of reuseA lot of reuse

Reduction of time to marketReduction of time to market

Software Product LinesSoftware Product Lines

LimitationsLimitations

First few projects take much greater First few projects take much greater timetimeTeam issuesTeam issues

Inexperience with the domainInexperience with the domain

Poor platform designPoor platform design

Engineering the Product Engineering the Product LineLine

Broken into two distinct processes: Broken into two distinct processes: domain engineering and application domain engineering and application engineeringengineering

Reusability is keyReusability is key Strong emphasis on documenting Strong emphasis on documenting

variabilityvariability

Engineering the Product Engineering the Product LineLine

Variability in the Product Variability in the Product LineLine

Managed variabilityManaged variabilitySupport activities concerned with Support activities concerned with

defining variabilitydefining variability

Managing variable artifactsManaging variable artifacts

Support activities concerned with Support activities concerned with resolving variabilityresolving variability

Storing information to fulfill these tasksStoring information to fulfill these tasks

Variability in the Product Variability in the Product LineLine

TypesTypes Variability in TimeVariability in Time Variability in SpaceVariability in Space

Where can Variability Come from?Where can Variability Come from? External External

Variability needed to meet customer Variability needed to meet customer satisfactionsatisfaction

InternalInternal Variability caused by introducing external Variability caused by introducing external

variationvariation

Variability in the Product Variability in the Product LineLine

How to Document How to Document VariabilityVariability

What needs to be documented?What needs to be documented?What varies?What varies?

Why does it vary?Why does it vary?

How does it vary?How does it vary?

For whom is it documented?For whom is it documented?

How to document How to document VariabilityVariability

It is necessary to document It is necessary to document Can hold variation information Can hold variation information

directly in UML diagramsdirectly in UML diagrams Feature DiagramsFeature Diagrams Orthogonal Variation Model (OVM)Orthogonal Variation Model (OVM)

Feature DiagramFeature Diagram

Problems With These Problems With These Methods Methods

Documenting Variability in UMLDocumenting Variability in UML Difficult to show to customerDifficult to show to customer Hard to find where all variation points areHard to find where all variation points are

Documenting Variability in Feature ModelsDocumenting Variability in Feature Models Difficult to integrate into commonly used Difficult to integrate into commonly used

diagramsdiagrams The Orthogonal Variability Model captures The Orthogonal Variability Model captures

all the information of variability while all the information of variability while presenting it in a straight forward syntax presenting it in a straight forward syntax and allowing the variation to be included and allowing the variation to be included in standard diagramsin standard diagrams

Orthogonal Variability Orthogonal Variability Model (OVM)Model (OVM)

Definition:Definition:– ““An orthogonal variability model is An orthogonal variability model is

a model that defines the variability a model that defines the variability of a software product line. It relates of a software product line. It relates the variability defined to other the variability defined to other software product line. It relates the software product line. It relates the variability defined to other software variability defined to other software development models such as development models such as feature models, use case models, feature models, use case models, design models, component models, design models, component models, test models.”test models.”

Orthogonal Variability Orthogonal Variability Model (OVM)Model (OVM)

Sample OVM DiagramSample OVM Diagram

Domain EngineeringDomain Engineering

Definition - “Process of software Definition - “Process of software product line engineering in which product line engineering in which the commonality and the variability the commonality and the variability of the product line are defined and of the product line are defined and realized.”realized.”

Goal of developing a stable, flexible, Goal of developing a stable, flexible, maintainable platformmaintainable platform

Domain SpecificationDomain Specification

Commonality analysis:Commonality analysis:– Find requirements that are common Find requirements that are common

to all applicationsto all applications Variability analysis:Variability analysis:

– Find requirements that are variableFind requirements that are variable Modeling VariabilityModeling Variability

– Finding variation points and Finding variation points and variantsvariants

– Generating the OVMGenerating the OVM

Use Case Diagram with Use Case Diagram with OVMOVM

Domain DesignDomain Design

Support OVM variation points, mass Support OVM variation points, mass customizationcustomization

Use architectural patterns where Use architectural patterns where necessarynecessary Command Pattern, MVC, Flyweight...Command Pattern, MVC, Flyweight...

Time to start looking for commercial Time to start looking for commercial off the shelf softwareoff the shelf software

Domain DesignDomain Design

Reference ArchitectureReference ArchitectureDefinition - “Core architecture that Definition - “Core architecture that

captures the high level design for the captures the high level design for the applications of the software product applications of the software product line.”line.”

Includes OVM Variation Points and Includes OVM Variation Points and VariantsVariants

Provides limits on applicationsProvides limits on applications

Determines what subsystems are reusableDetermines what subsystems are reusable

Class Diagram and OVMClass Diagram and OVM

Package Diagram and Package Diagram and OVMOVM

Domain ImplementationDomain Implementation

Generate common subsystemsGenerate common subsystems Create Interfaces that will be used Create Interfaces that will be used

by applicationsby applications Purely abstract, no executablesPurely abstract, no executables

Application EngineeringApplication Engineering

Definition - “Process of software Definition - “Process of software product line engineering in which product line engineering in which the applications of the product line the applications of the product line are built by reusing domain artifacts are built by reusing domain artifacts and exploiting the product line and exploiting the product line variability.”variability.”

High reuse of domain artifactsHigh reuse of domain artifacts Exploit commonality and variability Exploit commonality and variability

of the software product lineof the software product line

Application SpecificationApplication Specification

Most requirements are derived from Most requirements are derived from domain requirementsdomain requirements

Additional requirements need to be Additional requirements need to be analyzed and estimated to ensure analyzed and estimated to ensure that they can be met by the product that they can be met by the product lineline

Application Design & Application Design & ImplementationImplementation

Design:Design:

Modify reference architecture to meet Modify reference architecture to meet application requirementsapplication requirements

Implementation:Implementation:

Setting up InterfacesSetting up Interfaces

Both:Both:

Add additional components where Add additional components where necessarynecessary

Find objects to add into platformFind objects to add into platform

Testing the Product LineTesting the Product Line

Domain testingDomain testing Couple Options:Couple Options:

Create simple applicationsCreate simple applications Quicker validationQuicker validation Similar to single system testingSimilar to single system testing Better Option:Better Option:

Create test artifactsCreate test artifacts Used to vary test applicationsUsed to vary test applications

Testing the Product LineTesting the Product Line

Application TestingApplication TestingTests are usually derived from domain Tests are usually derived from domain

test artifactstest artifacts

Additional tests are necessary to ensure Additional tests are necessary to ensure that variability is correctthat variability is correct

Test Coverage needs to take into account Test Coverage needs to take into account common and variable parts of the common and variable parts of the systemsystem

Testing the Product LineTesting the Product Line

Guide Lines for dealing with Guide Lines for dealing with Variability in the Product LineVariability in the Product Line Structure the set of testing processes to Structure the set of testing processes to

test each artifact as early as possibletest each artifact as early as possible Structure test artifacts to accommodate Structure test artifacts to accommodate

the product line variationthe product line variation Maintain test artifactsMaintain test artifacts Structure testing software for traceabilityStructure testing software for traceability Automate regression testingAutomate regression testing

Organization StructureOrganization Structure

Company may need restructuring to Company may need restructuring to deal with software product linesdeal with software product lines

Traditional team organization may Traditional team organization may not be adequatenot be adequate Redundant roles across multiple Redundant roles across multiple

projectsprojects Difficult to incorporate new membersDifficult to incorporate new members

Need to deal with domain developmentNeed to deal with domain development

Organization StructureOrganization Structure

Ways to deal with platform developmentWays to deal with platform developmentDistribute domain engineers across all teamsDistribute domain engineers across all teams

• More difficult to decide common artifactsMore difficult to decide common artifacts• Decisions are decided more on a product to Decisions are decided more on a product to

product basisproduct basis• No specific place to bring platform ideas toNo specific place to bring platform ideas to

Create a dedicated team to develop the platformCreate a dedicated team to develop the platform• Platform covers all productsPlatform covers all products• Place to bring new ideas to the platformPlace to bring new ideas to the platform

Organization StructureOrganization Structure

Matrix OrganizationsMatrix OrganizationsTeams are organized by project and Teams are organized by project and

functionfunction

ReferencesReferences

[1] Bockle, G., Pohl, K., & van der Linden, F. (2010).Software product line [1] Bockle, G., Pohl, K., & van der Linden, F. (2010).Software product line engineering. Germany: Springer.engineering. Germany: Springer.

[2] Casteleyn, S., Daniel, F., Dolog, P., & Matera, M. (2009). Engineering web [2] Casteleyn, S., Daniel, F., Dolog, P., & Matera, M. (2009). Engineering web applications [pp. 205-207]. Retrieved from applications [pp. 205-207]. Retrieved from http://www.scribd.com/doc/49704889/111/Software-Product-Line-Engineering doi: http://www.scribd.com/doc/49704889/111/Software-Product-Line-Engineering doi: 10.1007/978-3-540-92201-8 10.1007/978-3-540-92201-8

[3] Schaefer, I., & Hahnle, R. (2011). Formal methods in software product line [3] Schaefer, I., & Hahnle, R. (2011). Formal methods in software product line engineering. Computer, 44(2), Retrieved from engineering. Computer, 44(2), Retrieved from http://ieeexplore.ieee.org.ezproxy.uwplatt.edu/stamp/stamp.jsp?http://ieeexplore.ieee.org.ezproxy.uwplatt.edu/stamp/stamp.jsp?tp=&arnumber=5713307tp=&arnumber=5713307

[4] Metzger, A., & Pohl, K. (2007). Variability management in software product line [4] Metzger, A., & Pohl, K. (2007). Variability management in software product line engineering.Proceedings of the 29th International Conference on Software engineering.Proceedings of the 29th International Conference on Software Engineering, http://ieeexplore.ieee.org.ezproxy.uwplatt.edu/stamp/stamp.jsp?Engineering, http://ieeexplore.ieee.org.ezproxy.uwplatt.edu/stamp/stamp.jsp?tp=&arnumber=4222738 10.1109/ICSECOMPANION.2007.83 . tp=&arnumber=4222738 10.1109/ICSECOMPANION.2007.83 .

[5] [5] Li, D., & Chang, C.K. (2009). Initiating and institutionalizing software product line Li, D., & Chang, C.K. (2009). Initiating and institutionalizing software product line engineering: from bottom-up approach to top-down practice . Proceedings of the engineering: from bottom-up approach to top-down practice . Proceedings of the Computer Software and Applications Conference, Computer Software and Applications Conference, http://ieeexplore.ieee.org.ezproxy.uwplatt.edu/stamp/stamp.jsp?http://ieeexplore.ieee.org.ezproxy.uwplatt.edu/stamp/stamp.jsp?tp=&arnumber=5254280 10.1109/COMPSAC.2009.17 .tp=&arnumber=5254280 10.1109/COMPSAC.2009.17 .

[6] Jaring, M., Krikhaar, R.L., & Bosch, J. (2008). Modeling variability and testability [6] Jaring, M., Krikhaar, R.L., & Bosch, J. (2008). Modeling variability and testability interaction in software product line engineering mode.Proceedings of the interaction in software product line engineering mode.Proceedings of the Composition-Based Software Systems, Composition-Based Software Systems, http://ieeexplore.ieee.org.ezproxy.uwplatt.edu/stamp/stamp.jsp?http://ieeexplore.ieee.org.ezproxy.uwplatt.edu/stamp/stamp.jsp?tp=&arnumber=4464016 10.1109/ICCBSS.2008.9 . tp=&arnumber=4464016 10.1109/ICCBSS.2008.9 .

[7][7] A framework for software product line practice, version 5.0. (2009). Retrieved A framework for software product line practice, version 5.0. (2009). Retrieved from http://www.sei.cmu.edu/productlines/frame_report/testing.htmfrom http://www.sei.cmu.edu/productlines/frame_report/testing.htm