This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/. http://www.ivanomalavolta.com

1. Modern development paradigms
Ivano Malavolta

2. Roadmap
Software product-lines
Service-oriented architecture

3. Software product-lines

4. An Example
You are constructing software that supports a bank loan
office
There are 20 products in your product line
An existing module calculates customer interest payment
– Perfectly adequate for 19 of the products
– Needs 240 lines modification for Delaware

5. How to Manage the Modifications?
One strategy is to make another copy of the affected module
and insert the necessary changes
– Called “clone and own”
– Fast and easy
– Does not scale!
• Suppose each of the 20 products has 1000 modules
• Potentially huge number of distinct versions of the product to maintain
A better strategy is to introduce a “variation point” in the
module and manage the variation point with, e.g., a
configuration parameter
– Setting configuration parameter to “normal” will generate the 18
products as before
– Setting the configuration parameter to “Delaware” will generate the
new version specifically for Delaware

6. Product lines
A set of related products that have substantial commonality
– In general, the commonality exists at the architecture level
One potential ‘silver bullet’ of software engineering
– Power through reuse of
• Engineering knowledge
• Existing product architectures, styles, patterns
• Pre-existing software components and connectors
6

7. Business motivation for product lines
Traditional Software
Engineering
7

8. Business motivation for product lines
Traditional Software
Engineering
8

9. Business motivation for product lines
Product-line-based
engineering

10. The ROI of SPL
David M. Weiss and Chi Tau Robert Lai. 1999. Software Product-Line
Engineering: A Family-Based Software Development Process.
Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

11. SPL engineering

12. Conceptual framework of PLs
Image © Paolo Ciancarini

13. Assets
DEF: artifacts that are representable with software and either
compose a product or support the engineering process to
create a product
Reuse in general needs to be planned for being
– Reusable:
• is fully documented
• is verified independently with high confidence
– Usable:
• is adaptable and that is usable in a variety of situations
Design for reuse/use involves
– analysis to identify explicitly variations to anticipate adaptations
– design for adaptability, engineered a
priori to create assets for future developments

14. Examples of assets
• requirements
• design specifications
• design models
• source code
• build files
• test plans and test cases
• user documentation
• repair manuals and installation guides
• project budgets, schedules, and work plans
• product calibration and configuration files
• data models and parts lists
• …

15. Capturing product line architectures
B
A
B
Common
A
Common
A
Common
B
(a) (b) (c)
• Common: features common to all products
• A: features specific to product A
• B: features specific to product B
• Product A = Common + A
• Product B = Common + B 15
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.

16. A product-line architecture
Definition
A product-line architecture captures the architectures of
many related products simultaneously
Generally employs explicit variation points in the architecture
indicating where design decisions may diverge from product
to product
16

17. A lunar lander product line
“Lite” “Demo” “Pro”

18. Product component table
Helps us decide
whether creating
a product line is
viable or feasible
Data Store
Data Store Connector
Game Logic
Game Logic Connector
Text-based UI
UI Plug-ins Connector
Graphical UI
System Clock
System Clock Connector
Demo Reminder
Lite X X X X X X
Demo X X X X X X X X X X
Pro X X X X X X

19. Group components into features
Not a mechanical
process
Attempt to identify
(mostly) orthogonal
features, or features
that would be
beneficial in different
products
Data Store
Data Store Connector
Game Logic
Game Logic Connector
Text-based UI
UI Plug-ins Connector
Graphical UI
System Clock
System Clock Connector
Demo Reminder
Lite X X X X X X
Demo X X X X X X X X X X
Pro X X X X X X

20. Reconstitute products from features
Use technical and business
knowledge to identify which
combinations form feasible
or marketable products
that will be constructed
Core Elements
Text UI
Graphical UI
Time Limited
Lunar Lander Lite X X
Lunar Lander Demo X X X
Lunar Lander Pro X X

21. How to represent variability?
1. Integrated variability modeling
– variability concepts are introduced into existing modelling
languages or document templates
2. Orthogonal variability modeling
– Ad-hoc models for variability representation
• called feature models
• separated from architectural models
• reusable independently from the used ALs
• understandable by non-technical stakeholders
21

22. 1 - Integrated variability modeling
Architectural models need to be diversified with information
about variation points and features
Not all ALs have good support for this
– Exceptions include
• Koala
• xADL 2.0
– These ALs have explicit support for capturing variation points

23. 23

24. 2 – Orthogonal variability modeling
The variability of the product line is treated as a first class product
line artifact à the feature model
Note that commonalities
are not represented here

25. Concepts
Variation point
– a variable item and thus defines “what can vary” (without saying
how it can vary)
Variant
– a concrete variation
– is related to a variation point
Variability constraints
– restrictions about the variability
– e.g.
• to define permissible combinations of variants in an application
• to define that the selection of one variant requires or
excludes the selection of another variant

26. Feature model in the automotive
domain
Exemplar of Automotive Architecture with Variability. Kacper Bak ,
Marko Novakovic , Leonardo Passos. Technical report.

27. Uses: product lines for feature selection
Product-line selection is the process of extracting a single
product architecture (or smaller product line) from an
architectural model that contains explicit points of variation
ALs such as Koala and xADL 2.0 can do selection
automatically with tools

28. Uses: product lines for evolution
Products in a product line don’t have to exclusively capture
alternatives
– They can also capture variation over time

29. Uses: product lines for evolution

30. Uses: product lines for ‘what-if’ analysis
In addition to alternative products and different versions of
the same product, product lines can capture different
potential products
– Selection can be used to quickly generate product architectures
for potential products
– These can be checked for certain properties or subjected to more
rigorous analysis for feasibility or quality
– Can also be used to generate new product ideas
30

31. Implementation issues
Important to partition implementations along variation-point
boundaries
File1.java
Common
File2.java
File3.java
File4.java
A
B
File1.java
Common
File2.java
File3.java
File4.java
A
B
Ba(ad) G(bo) od

32. Implementation issues 2
Keeping evolving architectures and version-controlled
source repositories (e.g., Git, SVN) in sync
Text-Based UI
Component
Graphical UI
Component
1.0
2.0
Text-based
Evolution
Graphical
3.0 2.1
4.0 2.2
Fork
UI.java
(as versioned in a software
configuration management system)

33. Unifying products with different
heritage
Often, the idea to create a product line emerges after several products
have been implemented and commonality is noticed
Strategies include
– No product line
• It may be more expensive to create a product line or there may
not be enough commonality
– One master product
• One product architecture becomes the basis for the product
line
– Hybrid
• A new product line architecture emerges out of many products
• Seems ideal but can be hard in practice
33

34. Product lines in their context
Architectural Styles
– Can be general or domain-specific
– Provides general guidelines for diverse kinds of applications
– Focus on –ility development
Domain-specific software architectures
– Domain specific
– Includes elaborate domain model and specific reference
architecture
Product lines
– Explicit set of related products with common aspects
Style DSSA / Ref Arch Product Line

35. Example: lunar lander in Koala
• No product line features yet
interface IDataStore{
void setAltitude(int altitudeInMeters);
int getAltitude();
void setBurnRate(int newBurnRate);
int getBurnRate();
...
}

36. Example: lunar lander PL in Koala
• Switch construct routes
calls to one of two
potential data stores
• ‘Diversity interface’ lets
game logic component
select callee from
external config
component
• Same IDataStore
interface ensures call
compatibility

37. Example 2: SPL for robotics
L. Gherardi, “Variability modeling and resolution in component-based
robotics systems,” PhD Thesis, 2013.

38. Example 2: SPL for robotics
L. Gherardi, “Variability modeling and resolution in component-based
robotics systems,” PhD Thesis, 2013.

39. Open research challenges in
variability modeling and analysis
• Variability modelling
– Understanding tradeoffs between expressiveness and analyzability
– Interrelating variability with base models
– Handling large-scale variability models
• Variability analysis
– Metrics for performance of solvers prediction
– Large-scale, realistic variability models for empirical studies
• Product management
– Scope optimization
– Artifact-interrelations in multi-level product lines

40. Open research challenges in domain
engineering
• Domain requirements engineering
– Interrelation between scoping and requirements engineering
– Interrelation between requirements engineering and other
development activities
– Impact of requirements changes
• Domain design
– Building resilient service-oriented product lines
– Delayed design decision and variability
– SPLE and cloud computing
– Variability in quality attributes
• Domain realization
– Mapping of product line variability and software
variability

41. Open research challenges in domain
engineering 2
• Quality assurance
– Causes for failures
– Inter-model verification
– Empirical evidence
– Empowering additional quality assurance techniques during
domain engineering

42. Open research challenges in
application engineering
• Application requirements engineering
– ︎Eliciting application-specific requirements
– Handling application-specific deviations
• Application design
– ︎Documentation of application design alternatives
– Impact of application-specific extensions
• Application realization
– Framing application-specific programming
– Extended configuration mechanism
– Product line development environments

43. Open research challenges in
application engineering
• Application quality assurance
– Minimizing test redundancy
– Correct variability bindings
– Empowering additional quality assurance techniques
– Empirical evidence
• Variability management in non-product-line settings
• Leveraging instantaneous feedback
• Open world assumption
– Exploration of autonomic computing principles
– Reasoning in the presence of variability and uncertainty
– Human-in-the-loop adaptations
– Run-time quality assurance

44. Service-oriented
architecture

45. Introduction to service orientation
Three individuals, each capable of providing a distinct
service

46. Introduction to service orientation
A company that employs these three people can compose
their capabilities to carry out its business

47. Services are collections of capabilities
Much like a human, an automated service can provide
multiple capabilities
Public capabilities are commonly expressed via a published
service contract (much like a traditional API)

48. Service composition
A service composition is a coordinated aggregate of services
The functional context of each service is agnostic to any
business process
à services can participate in multiple service compositions
à reusability + testability

49. Basic example of service composition
MASHUP
When data and information from various sources integrated in order to
provide new features and services on a single graphical interface
Data
Web
services
RSS
feed
Platform
Mashup APIs
application
Single graphical interface

50. Basic example of service composition

51. Services inventory
Establishes a pool of services, many of which will be
deliberately designed to be reused within multiple service
compositions

52. SOA principles
1. Standardized service contract
2. Service loose coupling
3. Service abstraction
4. Service reusability
5. Service autonomy
6. Service statelessness
7. Service discoverability
8. Service composability

53. 1 - Standardized service contract
Services within the same service inventory are in compliance with the
same contract design standards
“contract first” approach

54. 2 - Service loose coupling
Service contracts are decoupled from their surrounding environment
The service contract be the sole means of accessing service logic and
resources

55. 3 - Service abstraction
Service contracts contain only essential information
Information about services is limited to what is published in service contracts
Consumers may be unaware
that a service is composing others

56. 4 - Service reusability
Services contain and express agnostic logic
Services can be positioned as reusable enterprise resources

57. 5 - Service autonomy
Services exercise a high level of control over their underlying runtime
execution environment
Reducing shared access to
service resources and
increasing physical isolation
can raise a service's ability to
function autonomously

58. 6 - Service statelessness
Services minimize resource consumption by deferring the management
of state information when necessary
State data management consumes system resources and can result in a
significant resource burden when multiple instances of services are
concurrently invoked

59. 7 - Service discoverability
Services are supplemented
with communicative metadata
by which they can be effectively
discovered and interpreted
It enables a wide range of
project team members to
effectively carry out the
discovery process and not to
limit it to those with technical
expertise

60. 8 - Service composability
Services can be repurposed to solve multiple problems
à services must address agnostic or cross-cutting concerns
Notice that capabilities
are composed within a
service composition,
not services

61. Summary

62. Service-oriented architecture
A means of developing distributed systems where the
components are stand-alone services
Services may execute on
different computers from
different service providers
Standard protocols have been
developed to support service
communication and
information exchange

63. Service-oriented architecture
Service
registry
Service
requestor
Service
provider
Service
Find Publish
Bind (SOAP)
(WSDL)

64. Benefits of SOA
• Services can be provided locally or outsourced to external
providers
• Services are language-independent
• Investment in legacy systems can be preserved
• Inter-organisational computing is facilitated through
simplified information exchange

65. Key standards
• SOAP
– A message exchange standard that supports service
communication
• WSDL (Web Service Definition Language)
– To define a service interface and its bindings
• WS-BPEL
– A standard for workflow languages used to define service
composition

66. Web service standards
XML technologies (XML, XSD, XSLT, ....)
Support (WS-Security, WS-Addressing, ...)
Process (WS-BPEL)
Service definition (UDDI, WSDL)
Messaging (SOAP)
Transport (HTTP, HTTPS, SMTP, ...)

67. RESTful web services
Current web services standards have been criticized as
‘heavyweight’ standards that are over-general and inefficient
REST (REpresentational State Transfer) is an architectural style
based on transferring representations of resources from a server
to a client
– This style underlies the web as a whole and is simpler than SOAP/WSDL
for implementing web services
– RESTFul services involve a lower overhead
We will have a seminar on
REST in the next weeks

68. Example: in-car information system
1. Provides drivers with information on weather, road traffic conditions,
local information etc.
2. It is linked to car radio so that information is delivered as a signal on a
specific radio channel
3. The car is equipped with GPS receiver to discover its position and,
based on that position, the system accesses a range of information
services
4. Information may be delivered in the driver’s specified language

69. Example: in-car information system
User interface
Locator
Discovers car
position
Weather
info
Receives request
from user
Receiver
Receives
information stream
from services
Transmitter
Facilities
info
Sends position and
information request
to services
Radio
Translates digital
info stream to
radio signal
In-car software system
Mobile Info Service
Translator
Road
locator
Traffic
info
Collates information
Road traffic info
command
gps coord
gps
gps coord coord gps coord
Language
Info info
stream
Service discovery
Finds available
services

70. Advantage of SOA for this application
It is not necessary to decide when the system is
programmed or deployed what service provider should be
used or what specific services should be accessed
– As the car moves around, the in-car software uses the service
discovery service to find the most appropriate information service
and binds to that
– Because of the use of a translation service, it can move across
borders and therefore make local information available to people
who don’t speak the local language

71. Services as reusable components
• A service can be defined as:
– A loosely-coupled, reusable software component that
encapsulates discrete functionality which may be distributed and
programmatically accessed.
– A web service is a service that is accessed using standard Internet
and XML-based protocols
SOA
VS
component-based systems
Services are independent
– Services do not have a ‘requires’ interface
– Services rely on message-based communication with messages
expressed in XML

72. WSDL: Web Service Description
Language
The service interface can be defined in a service description
expressed in WSDL (Web Service Description Language)
• The WSDL specification defines
– what operations the service supports
– the format of the messages that are sent and received by the
service
– how the service is accessed
• the binding between the abstract interface and the concrete set of
protocols
– where the service is located
• This is usually expressed as a URI (Universal Resource Identifier)

73. Organization of a WSDL specification
WSDL service definition
Intro
Abstract interface
Concrete
implementation
XML namespace declarations
Type declarations
Interface declarations
Message declarations
Binding declarations
Endpoint declarations

74. Part of a WSDL description for a web
service
Define some of the types used. Assume that the namespace prefixes ‘ws’
refers to the namespace URI for XML schemas and the namespace prefix
associated with this definition is weathns.
<types>
<xs: schema targetNameSpace = “http://.../weathns”
xmlns: weathns = “http://…/weathns” >
<xs:element name = “PlaceAndDate” type = “pdrec” />
<xs:element name = “MaxMinTemp” type = “mmtrec” />
<xs: element name = “InDataFault” type = “errmess” />
<xs: complexType name = “pdrec”
<xs: sequence>
<xs:element name = “town” type = “xs:string”/>
<xs:element name = “country” type = “xs:string”/>
<xs:element name = “day” type = “xs:date” />
</xs:complexType>
Definitions of MaxMinType and InDataFault here
</schema>
</types>

75. Part of a WSDL description for a web
service
Now define the interface and its operations. In this case, there is only a single
operation to return maximum and minimum temperatures.
<interface name = “weatherInfo” >
<operation name = “getMaxMinTemps” pattern = “wsdlns: in-out”>
<input messageLabel = “In” element = “weathns: PlaceAndDate” />
<output messageLabel = “Out” element = “weathns:MaxMinTemp” />
<outfault messageLabel = “Out” element = “weathns:InDataFault” />
</operation>
</interface>

76. What this lecture means to you?
• Software product lines exploit the commonalities of a family of
systems and systematically handle their variations
• Commonality is a property shared by all applications of the family
– e.g., all mobile phones allow users to make calls
• Product line applications may differ in terms of features, functional and
quality requirements they fulfill
– e.g., some tablet computers may include mobile broadband connectivity,
others not
• Service-oriented software engineering is based on the notion that
programs can be constructed by composing independent services
which encapsulate reusable functionality
• Service interfaces can be defined in WSDL
– A WSDL specification includes a definition of the interface types and operations, the
binding protocol used by the service and the service location

77. References
Andreas Metzger and Klaus Pohl. 2014. Software
product line engineering and variability
management: achievements and challenges. In
Proceedings of the on Future of Software
Engineering (FOSE 2014). ACM, New York, NY,
USA, 70-84.

78. Contact Ivano Malavolta |
Post-doc researcher
Gran Sasso Science Institute
iivanoo
ivano.malavolta@gssi.infn.it
www.ivanomalavolta.com