The document discusses modern software development paradigms, focusing on agile development, software product lines, and service-oriented architecture. It outlines the principles of agile methodologies, the benefits of managing software variations via product lines, and the importance of service-driven design in creating reusable components. Key standards and practices for each paradigm are highlighted, including testing strategies and design for reuse.

1. Ivano Malavolta
Modern development paradigms
VRIJE
UNIVERSITEIT
AMSTERDAM

2. Roadmap
Agile development
Software product-lines
Service-oriented architecture

3. Agile

4. Waterfall vs agile: poor visibility

5. Waterfall vs agile: poor quality

6. Waterfall vs agile: too risky

7. Waterfall vs agile: can’t handle
change

8. The agile approach

9. Risks and features
http://www.testingthefuture.net/wp-
content/uploads/2011/12/waterfall_versus_agile_development.png

10. Agile manifesto
We are uncovering better ways of developing software 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 on the right, we value the items
on the left more.
http://www.agilemanifesto.org

11. How does it work in practice?
You make a list You start executing
You estimate You update the plan
“@run-time”
You set priorities

12. Agile iterations

13. 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

14. 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

15. Technical tools: test-driven
development
Write tests first
Refactoring is less risky now

16. Technical tools: continuous
integration
Merging 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/

17. An implementation: SCRUM
AAA

18. An implementation: SCRUM
http://www.flickr.com/photos/magia3e/6233729753/

19. An implementation: SCRUM
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.

20. 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

21. Software product-lines

22. 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

23. 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

24. 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. 25
Traditional Software
Engineering
Business motivation for product lines

26. 26
Traditional Software
Engineering
Business motivation for product lines

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

28. 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.

29. SPL engineering

30. Conceptual framework of PLs
Image © Paolo Ciancarini

31. Assets
DEF: 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

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

33. 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

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

35. Product component table
Helps us decide
whether creating
a product line is
viable or feasible
DataStore
DataStoreConnector
GameLogic
GameLogicConnector
Text-basedUI
UIPlug-insConnector
GraphicalUI
SystemClock
SystemClockConnector
DemoReminder
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

36. Group components into features
Not a mechanical
process
Attempt to identify
(mostly) orthogonal
features, or features
that would be
beneficial in different
products
DataStore
DataStoreConnector
GameLogic
GameLogicConnector
Text-basedUI
UIPlug-insConnector
GraphicalUI
SystemClock
SystemClockConnector
DemoReminder
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

37. Reconstitute products from features
Use technical and business
knowledge to identify which
combinations form feasible
or marketable products
that will be constructed
CoreElements
TextUI
GraphicalUI
TimeLimited
Lunar Lander Lite X X
Lunar Lander Demo X X X
Lunar Lander Pro X X

38. 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

39. 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

40. 40

41. 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

42. 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

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

44. 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

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

46. Uses: product lines for evolution

47. 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

48. 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
3.0 2.1
4.0 2.2
Text-based
Evolution
Graphical
Fork
UI.java
(as versioned in a software
configuration management system)

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

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

51. Service-oriented
architecture

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

53. 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.

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

55. 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

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

57. 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

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

59. 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

60. 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

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

62. 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

63. 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

64. 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

65. 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

66. Summary

67. 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

68. 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

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

70. 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

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

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

73. 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>

74. 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>

75. 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

76. References

77. Suggested readings
1. 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 in
startup companies: A systematic mapping study, Information and
Software Technology, Volume 56, Issue 10, October 2014, Pages
1200-1218, ISSN 0950-5849
3. 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.
4. Alfonso Fuggetta and Elisabetta Di Nitto. 2014. Software process. In
Proceedings of the on Future of Software Engineering (FOSE 2014).
ACM, New York, NY, USA, 1-12.

78. Contact
Ivano Malavolta |
Assistant professor
Vrije Universiteit Amsterdam
iivanoo
i.malavolta@vu.nl
www.ivanomalavolta.com