07 modern development

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 18 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

6

7

Traditional Software Engineering

Business motivation for product lines

8

Traditional Software Engineering

Business motivation for product lines

Product-line-based engineering

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

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

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

Capturing product line architectures

•  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

B

A

B

Common

A

Common

A

Common

B

(a) (b) (c)

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.

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

“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 which combinations form feasible or marketable products that 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

21

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

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

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

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)

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

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

Example: lunar lander in Koala

•  No product line features yet

interface IDataStore{ void setAltitude(int altitudeInMeters); int getAltitude(); void setBurnRate(int newBurnRate); int getBurnRate(); ... }

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

Example 2: SPL for robotics

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

Example 2: SPL for robotics

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

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

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

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

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

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

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

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 APIs Mashup

application

Single graphical interface

Basic example of service composition

Basic example of service composition

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 coupling 3.  Service abstraction 4.  Service reusability 5.  Service autonomy 6.  Service statelessness 7.  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 are concurrently 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

Service-oriented architecture

Serviceregistry

Servicerequestor

Serviceprovider

Service

Find Publish

Bind (SOAP)(WSDL)

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

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, ....)

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

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

Example: in-car information system

User interface

Locator

Discovers carposition

Weatherinfo

Receives requestfrom user

Receiver

Receivesinformation stream

from services

Transmitter

Sends position andinformation request

to services

Radio

Translates digitalinfo stream toradio signal

In-car software system

Mobile Info Service

Facilitiesinfo

Translator

Roadlocator

Trafficinfo

Collates information

Road traffic info

commandgps coord

gpscoord gps coordgps coord

LanguageinfoInfo

stream

Service discovery

Finds availableservices

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

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 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)

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. Software product l ine engineering and variabil ity management: achievements and challenges. In Proceedings of the on Future of Software Engineering (FOSE 2014). ACM, New York, NY, USA, 70-84.

Contact Ivano Malavolta |

Post-doc researcher Gran Sasso Science Institute

iivanoo

ivano.malavolta@gssi.infn.it

www.ivanomalavolta.com