Download - [2015/2016] Modern development paradigms
![Page 1: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/1.jpg)
Ivano Malavolta
Modern development paradigms
![Page 2: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/2.jpg)
Roadmap
Software product-lines
Service-oriented architecture
![Page 3: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/3.jpg)
Software product-lines
![Page 4: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/4.jpg)
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
![Page 5: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/5.jpg)
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
![Page 6: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/6.jpg)
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)
![Page 7: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/7.jpg)
7
Traditional Software Engineering
Business motivation for product lines
![Page 8: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/8.jpg)
8
Traditional Software Engineering
Business motivation for product lines
![Page 9: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/9.jpg)
Product-line-basedengineering
Business motivation for product lines
![Page 10: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/10.jpg)
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.
![Page 11: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/11.jpg)
SPL engineering
![Page 12: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/12.jpg)
Conceptual framework of PLs
Image © Paolo Ciancarini
![Page 13: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/13.jpg)
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
![Page 14: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/14.jpg)
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• …
![Page 15: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/15.jpg)
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
![Page 16: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/16.jpg)
“Lite” “Demo” “Pro”
A lunar lander product line
![Page 17: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/17.jpg)
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
![Page 18: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/18.jpg)
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
![Page 19: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/19.jpg)
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
![Page 20: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/20.jpg)
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
![Page 21: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/21.jpg)
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
![Page 22: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/22.jpg)
22
![Page 23: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/23.jpg)
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
![Page 24: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/24.jpg)
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
![Page 25: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/25.jpg)
Feature model in the automotive domain
Exemplar of Automotive Architecture with Variability. Kacper Bak , Marko Novakovic , Leonardo Passos. Technical report.
![Page 26: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/26.jpg)
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
![Page 27: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/27.jpg)
Products in a product line don’t have to exclusively capture alternatives
– They can also capture variation over time
Uses: product lines for evolution
![Page 28: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/28.jpg)
Uses: product lines for evolution
![Page 29: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/29.jpg)
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
![Page 30: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/30.jpg)
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)
![Page 31: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/31.jpg)
Example: SPL for robotics
L. Gherardi, “Variability modeling and resolution in component-based robotics systems,” PhD Thesis, 2013.
![Page 32: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/32.jpg)
Example: SPL for robotics
L. Gherardi, “Variability modeling and resolution in component-based robotics systems,” PhD Thesis, 2013.
![Page 33: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/33.jpg)
Service-oriented
architecture
![Page 34: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/34.jpg)
Introduction to service orientation
Three individuals, each capable of providing a distinct service
![Page 35: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/35.jpg)
Introduction to service orientation
A company that employs these three people can compose their capabilities to carry out its business
![Page 36: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/36.jpg)
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)
![Page 37: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/37.jpg)
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
![Page 38: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/38.jpg)
Services inventory
Establishes a pool of services, many of which will be deliberately designed to be reused within multiple service compositions
![Page 39: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/39.jpg)
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
![Page 40: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/40.jpg)
1 - Standardized service contract
Services within the same service inventory are in compliance with the same contract design standards
“contract first” approach
![Page 41: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/41.jpg)
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
![Page 42: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/42.jpg)
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
![Page 43: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/43.jpg)
4 - Service reusability
Services contain and express agnostic logic
Services can be positioned as reusable enterprise resources
![Page 44: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/44.jpg)
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
![Page 45: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/45.jpg)
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
![Page 46: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/46.jpg)
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
![Page 47: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/47.jpg)
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
![Page 48: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/48.jpg)
Summary
![Page 49: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/49.jpg)
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
![Page 50: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/50.jpg)
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
![Page 51: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/51.jpg)
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, ....)
![Page 52: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/52.jpg)
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
![Page 53: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/53.jpg)
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)
![Page 54: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/54.jpg)
Organization of a WSDL specification
Intro
Abstract interface
Concreteimplementation
WSDL service definition
XML namespace declarations
Type declarationsInterface declarationsMessage declarations
Binding declarationsEndpoint declarations
![Page 55: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/55.jpg)
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>
![Page 56: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/56.jpg)
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>
![Page 57: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/57.jpg)
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
![Page 58: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/58.jpg)
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.
![Page 59: [2015/2016] Modern development paradigms](https://reader034.vdocument.in/reader034/viewer/2022042908/58f2babb1a28abd4408b4585/html5/thumbnails/59.jpg)
ContactIvano Malavolta |
Post-doc researcherGran Sasso Science Institute
iivanoo
www.ivanomalavolta.com