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
4
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???)
5
Reuse of HTTPCore Library in WSO2 ESB
HTTPCore: 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)
6
8. Dealing with architectural mismatch …
• Preventing mismatch
– Architecture Specialization
• Detecting and resolving mismatches
– Wrappers, adapters, mediators, …
– in many cases, impossible to avoiding mismatches 8
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
9
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
10
But can we still achieve planned, systematic reuse?
Software Product Lines
Preventing architectural mismatches, controlled architecture
evolution, systematically developing dynamic systems, …
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)
13
Shared and
Managed
Core 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.
14
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
15
Common
Design
Decisions
A
Common
Design
Decisions
B
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.
16
Towing
Repairing
Accommodation
Towing time = 2h and repairing time=5d
Towing 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)
17
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
18
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
21
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 22
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
24
25. 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
VariationPoint
VariantVariant
0...*
variant
Towing
Heavy Light
Towing
ResTime
1h 2h 3h
Towing
TowingBy
TomTow
TowingBy
SwiftTow
Functional and Performance Requirements Design/Implementation
Service
Collaborations
26. 26
Sender
Push
Reader
Pull
Interactive Solo Shared
Private
Login
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
27
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
28
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
29
30. Software Variability : Concepts
• External Variability
• Internal Variability
30
• 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.]
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
34
35. Annotative Approach
• Use some form of annotations to implement variability
35
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
abstractions
E.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.
36
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
37
Variability at Requirements
Variability at Realization
Mapping Models
Variability Resolution
Variability Resolution
Automated (model-to-
model transformation)
or Manual
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
40
45. Product Line Scope
45
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
46
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)
47
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.
49
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?,
50
Conceptually, DSPL provide a systematic approach to
build, manage, and evolve these types of applications.
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. 53
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/
54
