Ivano Malavolta

Modern development paradigms

Roadmap

Software product-lines

Service-oriented architecture

Software product-lines

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

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 19 products as before

– Setting the configuration parameter to “Delaware” will generate the new version specifically for Delaware

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

B

A

B

Common

A

Common

A

Common

B

(a) (b) (c)

7

Traditional Software Engineering

Business motivation for product lines

8

Traditional Software Engineering

Business motivation for product lines

Product-line-basedengineering

Business motivation for product lines

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.

SPL engineering

Conceptual framework of PLs

Image © Paolo Ciancarini

AssetsDEF: artifacts that are representable with software and either compose a product or support the engineering process to create a product

The system needs to be designed 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

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• …

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

15

“Lite” “Demo” “Pro”

A lunar lander product line

Product component table

Helps us decide whether creating a product line is viable or feasible

D

ata

Stor

e

Dat

a St

ore

Con

nect

or

Gam

e Lo

gic

Gam

e Lo

gic

Con

nect

or

Text

-bas

ed U

I

UI P

lug-

ins C

onne

ctor

Gra

phic

al U

I

Syst

em C

lock

Syst

em C

lock

Con

nect

or

Dem

o R

emin

der

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

Group components into features

Not a mechanical process

Attempt to identify (mostly) orthogonal features, or features that would be beneficial in different products

D

ata

Stor

e

Dat

a St

ore

Con

nect

or

Gam

e Lo

gic

Gam

e Lo

gic

Con

nect

or

Text

-bas

ed U

I

UI P

lug-

ins C

onne

ctor

Gra

phic

al U

I

Syst

em C

lock

Syst

em C

lock

Con

nect

or

Dem

o R

emin

der

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

Reconstitute products from features

Use technical and business knowledge to identify whichcombinations form feasibleor marketable productsthat will be constructed

Cor

e El

emen

ts

Text

UI

Gra

phic

al U

I

Tim

e Li

mite

d

Lunar Lander Lite X X Lunar Lander Demo X X X

Lunar Lander Pro X X

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

20

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

22

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

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

Feature model in the automotive domain

Exemplar of Automotive Architecture with Variability. Kacper Bak , Marko Novakovic , Leonardo Passos. Technical report.

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

Uses: product lines for feature selection

Products in a product line don’t have to exclusively capture alternatives

– They can also capture variation over time

Uses: product lines for evolution

Uses: product lines for evolution

Implementation issues

Important to partition implementations along variation-point boundaries

Common

File1.java

File2.java

File3.java

File4.java

A

B

Common

File1.java

File2.java

File3.java

File4.java

A

B

(a) (b)Bad Good

Implementation issues 2

Keeping evolving architectures and version-controlled source repositories (e.g., Git, SVN) in sync

Text-Based UIComponent

Graphical UIComponent

1.0

2.0

3.0 2.1

4.0 2.2

Text-basedEvolution

GraphicalFork

UI.java(as versioned in a software

configuration management system)

Example: SPL for robotics

L. Gherardi, “Variability modeling and resolution in component-based robotics systems,” PhD Thesis, 2013.

Example: SPL for robotics

L. Gherardi, “Variability modeling and resolution in component-based robotics systems,” PhD Thesis, 2013.

Service-oriented

architecture

Introduction to service orientation

Three individuals, each capable of providing a distinct service

Introduction to service orientation

A company that employs these three people can compose their capabilities to carry out its business

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)

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

Services inventory

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

SOA principles

1. Standardized service contract

2. Service loose coupling3. Service abstraction

4. Service reusability5. Service autonomy

6. Service statelessness7. Service discoverability

8. Service composability

1 - Standardized service contract

Services within the same service inventory are in compliance with the same contract design standards

“contract first” approach

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

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

4 - Service reusability

Services contain and express agnostic logic

Services can be positioned as reusable enterprise resources

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

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 areconcurrently invoked

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

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

Summary

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

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

Web service standards

Transport (HTTP, HTTPS, SMTP, ...)

Messaging (SOAP)

Service definition (UDDI, WSDL)

Process (WS-BPEL)

Support (WS-Security, WS-Addressing, ...)

XML technologies (XML, XSD, XSLT, ....)

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

Services are independent– Services do not have a ‘requires’ interface

– Services rely on message-based communication with messages expressed in XML

SOA VS

component-based systems

WSDL: Web Service Description LanguageThe 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)

Organization of a WSDL specification

Intro

Abstract interface

Concreteimplementation

WSDL service definition

XML namespace declarations

Type declarationsInterface declarationsMessage declarations

Binding declarationsEndpoint declarations

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>

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>

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

References

Andreas Metzger and Klaus Pohl. 2014. Softwareproduct line engineering and variabilitymanagement: achievements and challenges. InProceedings of the on Future of SoftwareEngineering (FOSE 2014). ACM, New York, NY,USA, 70-84.

ContactIvano Malavolta |

Post-doc researcherGran Sasso Science Institute

iivanoo

ivano.malavolta@gssi.infn.it

www.ivanomalavolta.com