Upload
thejan-wijesinghe
View
71
Download
0
Embed Size (px)
Citation preview
1
Software Product Lines (SPL)
Dr. Indika Kumara
2
Outline• Quest for Systematic Software Reuse: Motivating SPL• Software Product Lines (SPL): Concepts and Examples• Software Variability Management: Foundation of SPL• Domain Engineering: Developing Core Assets and Product
Lines Architecture• Application Engineering: Deriving Products• Organization Aspects: Adopting SPL Approach for
Organizations• Dynamic Software Product Lines: SPL Approach for
Dynamic Domains
3
Quest for Systematic Software Reuse: Motivating SPL
4
Software Products/Projects: Some Observations
• Generally, a lifetime of a software product / project can be very long.
WSO2 ESB (Enterprise Service Bus)
• Nearly 10 years (Since 2006)• Several major code rewriting/changes and personnel
changes• No major changes to the expected functional requirements • Some changes to the performance requirements
(throughput and resource usage)• Size (80 MB => 230 MB) from 2.0 version to 4.8 version
5
Software Projects: Some Observations …
• A software product / project may reuse a lot of in-house or third party libraries or components or services to improve productivity. (Successfully???)
Reuse of HTTPCore Library in WSO2 ESBHTTPCore: Non-blocking I/O => May suitable for high latency and throughput scenarios, e.g., chat applications, streaming updates.Main use case within ESB : binary relay (high throughput => key attraction for some customers)Some main issues: • Most of the customer issues/bugs were relevant the usage of the
HTTP core (some issues took a few months to identify and fix)• No real gain when supporting key ESB scenarios (transformation,
security, content-based routing, etc.,…)Currently replacing HTTPCore with Netty library (a major change)
6
Why Is Reuse So Hard?
• Appropriate reusable parts are not available• Can not locate even the appropriate reusable
parts are available• Mismatch issues - parts do not fit together well
– Low-level interoperability issues (SOA?)– Architectural mismatch [D. Garlan et al.]
• Incompatible assumptions that each part makes about its operating environment (including the structure of the composite application)
7
Architectural Mismatches: Illustrations
Asynchronous Reactor Transformer
Socket Input Stream
Buffered Input Stream
Support CenterGarage (with Spare Parts)
Motorist Tow Truck
Garage (no Parts)
Spare Parts Provider
8
Dealing with architectural mismatch …• Preventing mismatch
– Architecture Specialization
• Detecting and resolving mismatches – Wrappers, adapters, mediators, … – in many cases, impossible to avoiding mismatches
9
More Architectural Mismatch Challenges (In Turn, Software Reuse Challenges)
• Dynamic software system– avoid, detect, and repair mismatch dynamically
• Software evolution (architectural) – Can introduce architectural mismatch issues
• Architecture lock-In– Become too expensive to change architecture
without introducing mismatches – Hinder innovation
10
Software Reuse: Recap• Benefits (if successful)
– Greatly reduce time to market and cost– Greatly improve productivity, quality, and business
agility – …
• But software reuse is really hard
But can we still achieve planned, systematic reuse? Software Product Lines
Preventing architectural mismatches, controlled architecture evolution, systematically developing dynamic systems, …
11
Running Example: Roadside Assistance Product Line
12
Software Product Lines: Concepts
13
Software Product Lines(SPL): Concepts
• What is a software product line (SPL)?– Includes a set of related products developed from
a shared, managed core asset base– Targets a specific business domain (the business
case is defined)
Shared and ManagedCore Assets
Products with (Many) Common and (Some) Variable Features
Production Process : Selecting, configuring, and assembling core assets in a prescribed way
14
Software Product Lines: Concepts …
• What are core assets (reusable assets)?– Build to support multiple products of the same
family (the reuse is not accidental)– Contain variations points to allow creating
variants of the assets quickly and systematically – Include software architecture, software elements
(components, services, modules, etc.), designs, documentations, test cases, product schedules, performance models, tools, etc.
15
B
A
Software Product Lines: Concepts …• Product line architecture
– Represent the architectures of multiple related products simultaneously
– Satisfy the functional, quality, and business goals for all products in the product line
Common Design
Decisions
A
Common Design
DecisionsB
Common Design
Decisions
Product Line Architecture
Product A’s Architecture
Product B’s Architecture
[R. Taylor et. al]
Design Decisions
Specific To A
16
Software Product Lines: Concepts …• Features
– "A feature is a unit of functionality of a software system that satisfies a requirement, represents a design decision, and provides a potential configuration option. " - S. Apel and C. K¨astner
– Functional and quality features
– Software architecture and the software elements that populate it realize the features of the product line.
Towing RepairingAccommodation
Towing time = 2h and repairing time=5dTowing time = 1h and renting duration =3d
17
Software Product Lines: Concepts …
• Products– Each product provides a subset of the product line
features, and targets a specific customer group– Each product uses a variant of the product line
architecture, and the variants of a subset of other appropriate core assets (including software elements)
18
Software Product Lines: Real Examples
• Boeing: Bold Stroke Avionics Software Family• Nokia: Mobile Phones• GNU compiler suite• Philips Product Line of Software for Television
Sets• U.S. Naval Research Laboratory: A-7E
Operational Flight Program• More at http://splc.net/fame.html
19
Reuse History: From Ad Hoc To Systematic
[Linda Northrop]
Economics Of Software Product Lines
20 [Linda Northrop]
21
Economics of Software Product Lines …• Some examples from SEI website
– 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
22
Software Product Lines Are Not• Clone and own: single-system development with reuse
– Modifying code as necessary for the single system only• Accidental small-grained reuse
– Reuse libraries containing algorithms, modules, objects, or components
• Just component-based or service-based development– Selecting components or services from an in-house library, the
marketplace, or the Web with no architecture focus• Just versions of a single product
– Rather, simultaneous release and support of multiple products• Just a configurable architecture
– A good start, but only part of the reuse potential• Just a set of technical standards
– Constraining choices without an architecture-based reuse strategy
[Linda N
orthrop]
23
Software Variability Management: Foundation of SPL
24
Software Variability Management• What is the software variability?
Software variability is the ability of a software system or artifact to be changed, customized or configured for use in a particular context. A high degree of variability allows the use of software in a broader range of contexts, i.e. the software is more reusable” [Bosch 2004]
• What is the software variability management?– Identification, modeling, realization, resolution, validation,
verification, and evolution of the variability in software artifacts– In a product line, must consider all relevant core assets– Must consider the dependences between the variability in different
core assets
Software Variability : Concepts• Variation Points and Variants
– Variation points : where the variations occur– Variants : options/choices at variation points – Cardinality : maximum and minimum numbers of
variants to be selected for a given variation point
25
-maxCardinality : int-minCardinality : int
VariationPoint-maxCardinality : int-minCardinality : int
VariationPointVariantVariant
0...*
variant
Towing
Heavy Light
TowingResTime
1h 2h 3h
Towing
TowingByTomTow
TowingBySwiftTow
Functional and Performance Requirements Design/Implementation
Serv
ice
Colla
bora
tions
26
Sender Push
Reader Pull
Interactive Solo Shared
PrivateLogin
Controlled Public
Wiki = {Reader pull, Public, Shared}Twitter ={Sender push, Public, Solo}Email = {Sender push, Private, Solo}Facebook status= {Reader pull, Private, Solo}
@ Mary Shaw, "The Role of Design Spaces"
Sharing Web Information
Privacy AuthorshipActivation
Design Variability : Illustration
27
Software Variability : Concepts• Common Types of Variation Points and Variants
– Mandatory (single) – must be included in a product• E.g., the repairing option
– Optional (single)• E.g., the accommodation option
– Alternatives (multiple) – only one can be included • E.g., among rental vehicle option and taxi hire option
– Or (multiple) – one or more can be included• E.g., among light towing and heavy towing
– And (multiple) – all must be included• E.g., both direct debit option and credit option for online
payement
28
Software Variability : Concepts• Common Types of Variability Dependencies
– Exclude dependency• Inclusion of one or more options must exclude one or more
other options• E.g., Accommodation exclude AlternativeTransport• E.g., ExternalParts exclude (MajorRepair.ResponseTime = 2d)
– Include dependency• Inclusion of one or more options must include one or more
other options• E.g., Major(Repair) include Tow• E.g., (MajorRepair.ResponseTime = 2d) include InternalParts
29
Software Variability : Concepts
• Variability in Time /Evolution– "The existence of different versions of an artifact that
are valid at different times." [K. Pohl et al.]– E.g., train ticket booking by phone option will be
replaced by train ticket booking by web when the website is available.
• Variability in Space– “The existence of an artifact in different shapes at the
same time."[K. Pohl et al.]– E.g., three payment options are available at the same
time: cash, direct debit, and credit card
30
Software Variability : Concepts• External Variability
• Internal Variability
• Visible to customers • Customers need to make
choices• E.g., selection between
heavy tow and light tow
• Hidden from customers• Developers, operational, etc. need
to make choices• Realization and deployment issues• E.g., selection between
TowingBySwiftTow, TowingByTomTow, …
[K. Pohl et al.]
[K. Pohl et al.]
31
Software Variability : Concepts• The Variability Pyramid
[K. Pohl et al.]
32
Variability Modeling• Explicitly documenting variability in artifacts
– Need to consider the previously mentioned variability concepts
• Why– Rational decision making– Variability communication (including customization)– Traceability of variability across artifacts (time/space)
• Types of variability modeling approaches– Feature modeling – Orthogonal variability modelling – Many custom modeling approaches
33
Feature ModelFeatures
Feature Groups
Feature Constraints (e.g., Include and exclude)
Non-functional features can be represented as feature attributes.
34
Variability Realization
• How to support variation points and variants in core assets (architecture, software elements, models, etc.)– Including enforcing variability dependencies and
supporting variability resolution– Design time and runtime artifacts
• Two main approaches– Annotative Approach– Compositional Approach
35
Annotative Approach• Use some form of annotations to implement variability
If (Accommodation) { code fragment X;} else if (Tow) { code fragment Y;} else if (…){ …} …
Variation Points
Variants
Product Line Implementation
• Can introduce variations at arbitrary granularity levels
But• Obfuscate codes• Tangle business logic and variability
logic • Difficult to introduce modular
abstractionsE.g., Java annotation, If-then-else, C/C++ style preprocessors, variation points and variants in extended UML profiles, etc.
36
Compositional Approach
• Realizes product line features as modular units and creates products by composing these units.
Modular Units Products
Composition Specification per Product
• Merging units• Coordinating units
Modular units may represent total decomposition (e.g., module per feature) or partial decomposition (common base + differences) (e.g., Delta Modules, Aspects, and Plugins)
What about traditional services/components? Architectural mismatch issues + Features crosscut services/components => Need high-level abstractions or variability-aware components and services, etc.
37
Variability Resolution or Product Generation
• Variability Resolution – Selection of a subset of the variation points in an artifact,
and a subset of the variants for each selected variation point, and generate an artifact instance/variant
Variability at Requirements
Variability at Realization
Mapping Models
Variability Resolution
Variability Resolution
Automated (model-to-model transformation)
or Manual
38
Variability Resolution Example in Feature Model: Creating Feature Configurations
39
Software Product Line Engineering
40
Software Product Line Engineering
• Domain engineering– build the product line platform (core asset base)
that supports the derivation of products effectively
• Application Engineering– build products to support different customers
41
Domain Engineering
[K. Pohl et al.]
Compared with a single system, support Variability
42
Application Engineering
Ideally, automated via model-to-model/code transformation techniques
[K. Pohl et al.]
43
Domain Eng. And Application Eng.
[K. Pohl et al.]
44
Organization Aspects: Adopting SPL Approach for Organizations
45
Product Line Scope
Products within the scope of the product line
All possible products - but not for this product line
Products that can be added to the product line (with some effort)
46
SPL Adoption Strategies
• There are three main adoption strategies– proactive, reactive, and extractive
• Proactive Strategy– Follow the domain engineering to develop the
complete product line platform / core asset base – Higher upfront cost but easy to create products– Suited if the requirements are stable, and their
evolution is predictable
47
SPL Adoption Strategies …• Reactive Strategy
• Start with a minimum number of products• Grows the product line as demand arises for new products
or new requirements on existing products• Suited if the requirements are unpredictable.
• Extractive Strategy• Create the product line assets by extracting software
elements from the currently available software systems at the organization
• The selected systems need to have higher commonality (functional and architectural)
48
Dynamic Software Product Lines: SPL Approach for Dynamic Domains
49
Dynamic Software Product Lines (DSPL)• DSPL employs the product line capabilities and
the variability management at runtime. • Products are derived and adapted at runtime,
potentially multiple times.
Product 1
Product 2
Product n
Deployed Product Line (Runtime model)
Adapt
Adaptation Space for a Product
50
DSPL: Use cases
• Multi-tenant applications– A tenant uses a product in an DSPL – Tenants share feature implementations at runtime
• Dynamically adaptive applications/context-aware applications– A product is one application adaptation or for a
context variant – E.g., Smart * (homes, cities, healthcare, industry),
Web servers, Enterprise Applications, Windows OS?,
Conceptually, DSPL provide a systematic approach to build, manage, and evolve these types of applications.
51
Topic Covered
• Challenges of Systematic Reuse• Software Product Lines (SPLs)• Software Variability Management• SPL Engineering
– Domain engineering– Application engineering
• Dynamic SPL
52
Q/A
53
References• http://wso2.com/library/articles/2014/02/esb-performance-round-7.5/• http://www.sei.cmu.edu/productlines/• http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=21564• David Garlan, Robert Allen, and John Ockerbloom. 1995. Architectural Mismatch: Why
Reuse Is So Hard. IEEE Softw. 12, 6 (November 1995), 17-26• Garlan, David, Robert Allen, and John Ockerbloom. "Architectural mismatch: Why reuse is
still so hard." IEEE software 26.4 (2009): 66.• Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2
ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.• Klaus Pohl, Günter Böckle, and Frank J. van der Linden. 2005. Software Product Line
Engineering: Foundations, Principles and Techniques. Springer-Verlag New York, Inc., Secaucus, NJ, USA.
• Taylor, Richard N., Nenad Medvidovic, and Eric M. Dashofy. Software architecture: foundations, theory, and practice. Wiley Publishing, 2009.
• Van Gurp, Jilles, Jan Bosch, and Mikael Svahnberg. "On the notion of variability in software product lines." Software Architecture, 2001. Proceedings. Working IEEE/IFIP Conference on. IEEE, 2001.
• Apel, Sven, and Christian Kästner. "An Overview of Feature-Oriented Software Development." Journal of Object Technology 8.5 (2009): 49-84.
• Shaw, Mary. "The role of design spaces." IEEE software 29.1 (2012): 46-50.
54
References …• Christian Kästner, Sven Apel, and Martin Kuhlemann. 2008. Granularity in software
product lines. In Proceedings of the 30th international conference on Software engineering (ICSE '08). ACM, New York, NY, USA, 311-320.
• Krueger, CharlesW. "Easing the transition to software mass customization." International Workshop on Software Product-Family Engineering. Springer Berlin Heidelberg, 2001.
• Hallsteinsen, Svein, et al. "Dynamic software product lines." Computer 41.4 (2008): 93-95.
• Hinchey, Mike, Sooyong Park, and Klaus Schmid. "Building dynamic software product lines." Computer 45.10 (2012): 22-26.
• Kang, Kyo C., Jaejoon Lee, and Patrick Donohoe. "Feature-oriented product line engineering." IEEE software 19.4 (2002): 58.
• Ina Schaefer, Lorenzo Bettini, Ferruccio Damiani, and Nico Tanzarella. 2010. Delta-oriented programming of software product lines. In Proceedings of the 14th international conference on Software product lines: going beyond (SPLC'10), Jan Bosch and Jaejoon Lee (Eds.). Springer-Verlag, Berlin, Heidelberg, 77-91.
• Klaus Pohl and Andreas Metzger. 2006. Software product line testing. Commun. ACM 49, 12 (December 2006), 78-81. DOI=http://dx.doi.org/10.1145/1183236.1183271
• McGregor, John. "Testing a software product line." (2001).• http://wwwiti.cs.uni-magdeburg.de/iti_db/research/featureide/