[2016/2017] modern development paradigms

Ivano Malavolta

Modern development paradigms

VRIJEUNIVERSITEITAMSTERDAM

Roadmap

Agile development

Software product-lines

Service-oriented architecture

Waterfall vs agile: poor visibility

Waterfall vs agile: poor quality

Waterfall vs agile: too risky

Waterfall vs agile: can’t handle change

The agile approach

Risks and features

http://www.testingthefuture.net/wp-content/uploads/2011/12/waterfall_versus_agile_development.png

Agile manifesto

We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items onthe right, we value the items on the left more.

http://www.agilemanifesto.org

How does it work in practice?

You make a list You start executing

You estimate You update the plan

“@run-time”

You set priorities

Agile iterations

Agile principles (extract)

Agile methods are iterative development processes with:

• frequent releases of the product

• continuous interaction between dev. team and customer

• reduce product documentation

• continuous and systematic assessment of produced value

and risks

Technical tools: unit tests

Snippet of test code for exercising some functionality of the product à codified requirements

We will have a dedicated core course on testing

Technical tools: test-driven development

Write tests firstRefactoring is less risky now

Technical tools: continuous integrationMerging all the developers’ working copies many times a day à it allows to make sure that all the code integrates, all the unit tests pass, and a warning if anything goes wrong

image from http://newmedialabs.com/

An implementation: SCRUM

AAA


http://www.flickr.com/photos/magia3e/6233729753/


Burndown chart = how much work is left

Scope changes• The engineering team

missed features in the UI mockups when we created the release backlog

• Integrations into other AdWords features were overlooked

• The rate of change in AdWords APIs is very high.

Critical evaluation of the agile method+ Acceptance of change à less risky+ Frequent and short iterations+ Emphasis on working code+ Associating a test with every piece of functionality

+ tests are a key resource within the project

+ Continuous integration (and delivery)+ Planned– Tests as a replacement for specifications– Feature-based development & ignorance of

dependencies– No quality plan– Dismissal of a priori architecture work

– actually, dismissal of everything which is non-shippable

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)

25

Traditional Software Engineering

Business motivation for product lines

26

Traditional Software Engineering


Product-line-basedengineering


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

33

“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

38

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

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.

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

This image cannot currently be displayed.

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?

• Agile software development– focus on shippable features

– test-driven

• Software product lines– exploit the commonalities of a family of systems– systematically handle their variations

• Service-oriented software engineering– programs can be constructed by composing independent services

– services encapsulate reusable functionality– Service interfaces can be defined in WSDL

References

Suggested readings1. Striebeck, M., "Ssh! We are adding a process... [agile practices],"

Agile Conference, 2006 , vol., no., pp.9 pp.,193, 23-28 July 2006

2. Nicolò Paternoster, Carmine Giardino, Michael Unterkalmsteiner,Tony Gorschek, Pekka Abrahamsson, Software development instartup companies: A systematic mapping study, Information andSoftware Technology, Volume 56, Issue 10, October 2014, Pages1200-1218, ISSN 0950-5849

3. Andreas Metzger and Klaus Pohl. 2014. Software product lineengineering and variability management: achievements andchallenges. In Proceedings of the on Future of SoftwareEngineering (FOSE 2014). ACM, New York, NY, USA, 70-84.

4. Alfonso Fuggetta and Elisabetta Di Nitto. 2014. Software process. InProceedings of the on Future of Software Engineering (FOSE 2014).ACM, New York, NY, USA, 1-12.

ContactIvano Malavolta |

Assistant professorVrije Universiteit Amsterdam

iivanoo

[email protected]

www.ivanomalavolta.com