Modern development paradigms 
Ivano Malavolta
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 
A...
How to Manage the Modifications? 
One strategy is to make another copy of the affected module 
and insert the necessary ch...
Product lines 
A set of related products that have substantial commonality 
– In general, the commonality exists at the ar...
Business motivation for product lines 
Traditional Software 
Engineering 
7
Business motivation for product lines 
Traditional Software 
Engineering 
8
Business motivation for product lines 
Product-line-based 
engineering
The ROI of SPL 
David M. Weiss and Chi Tau Robert Lai. 1999. Software Product-Line 
Engineering: A Family-Based Software D...
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 proce...
Examples of assets 
• requirements 
• design specifications 
• design models 
• source code 
• build files 
• test plans a...
Capturing product line architectures 
B 
A 
B 
Common 
A 
Common 
A 
Common 
B 
(a) (b) (c) 
• Common: features common to ...
A product-line architecture 
Definition 
A product-line architecture captures the architectures of 
many related products ...
A lunar lander product line 
“Lite” “Demo” “Pro”
Product component table 
Helps us decide 
whether creating 
a product line is 
viable or feasible 
Data Store 
Data Store ...
Group components into features 
Not a mechanical 
process 
Attempt to identify 
(mostly) orthogonal 
features, or features...
Reconstitute products from features 
Use technical and business 
knowledge to identify which 
combinations form feasible 
...
How to represent variability? 
1. Integrated variability modeling 
– variability concepts are introduced into existing mod...
1 - Integrated variability modeling 
Architectural models need to be diversified with information 
about variation points ...
23
2 – Orthogonal variability modeling 
The variability of the product line is treated as a first class product 
line artifac...
Concepts 
Variation point 
– a variable item and thus defines “what can vary” (without saying 
how it can vary) 
Variant 
...
Feature model in the automotive 
domain 
Exemplar of Automotive Architecture with Variability. Kacper Bak , 
Marko Novakov...
Uses: product lines for feature selection 
Product-line selection is the process of extracting a single 
product architect...
Uses: product lines for evolution 
Products in a product line don’t have to exclusively capture 
alternatives 
– They can ...
Uses: product lines for evolution
Uses: product lines for ‘what-if’ analysis 
In addition to alternative products and different versions of 
the same produc...
Implementation issues 
Important to partition implementations along variation-point 
boundaries 
File1.java 
Common 
File2...
Implementation issues 2 
Keeping evolving architectures and version-controlled 
source repositories (e.g., Git, SVN) in sy...
Unifying products with different 
heritage 
Often, the idea to create a product line emerges after several products 
have ...
Product lines in their context 
Architectural Styles 
– Can be general or domain-specific 
– Provides general guidelines f...
Example: lunar lander in Koala 
• No product line features yet 
interface IDataStore{ 
void setAltitude(int altitudeInMete...
Example: lunar lander PL in Koala 
• Switch construct routes 
calls to one of two 
potential data stores 
• ‘Diversity int...
Example 2: SPL for robotics 
L. Gherardi, “Variability modeling and resolution in component-based 
robotics systems,” PhD ...
Example 2: SPL for robotics 
L. Gherardi, “Variability modeling and resolution in component-based 
robotics systems,” PhD ...
Open research challenges in 
variability modeling and analysis 
• Variability modelling 
– Understanding tradeoffs between...
Open research challenges in domain 
engineering 
• Domain requirements engineering 
– Interrelation between scoping and re...
Open research challenges in domain 
engineering 2 
• Quality assurance 
– Causes for failures 
– Inter-model verification ...
Open research challenges in 
application engineering 
• Application requirements engineering 
– ︎Eliciting application-spe...
Open research challenges in 
application engineering 
• Application quality assurance 
– Minimizing test redundancy 
– Cor...
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 ou...
Services are collections of capabilities 
Much like a human, an automated service can provide 
multiple capabilities 
Publ...
Service composition 
A service composition is a coordinated aggregate of services 
The functional context of each service ...
Basic example of service composition 
MASHUP 
When data and information from various sources integrated in order to 
provi...
Basic example of service composition
Services inventory 
Establishes a pool of services, many of which will be 
deliberately designed to be reused within multi...
SOA principles 
1. Standardized service contract 
2. Service loose coupling 
3. Service abstraction 
4. Service reusabilit...
1 - Standardized service contract 
Services within the same service inventory are in compliance with the 
same contract de...
2 - Service loose coupling 
Service contracts are decoupled from their surrounding environment 
The service contract be th...
3 - Service abstraction 
Service contracts contain only essential information 
Information about services is limited to wh...
4 - Service reusability 
Services contain and express agnostic logic 
Services can be positioned as reusable enterprise re...
5 - Service autonomy 
Services exercise a high level of control over their underlying runtime 
execution environment 
Redu...
6 - Service statelessness 
Services minimize resource consumption by deferring the management 
of state information when n...
7 - Service discoverability 
Services are supplemented 
with communicative metadata 
by which they can be effectively 
dis...
8 - Service composability 
Services can be repurposed to solve multiple problems 
à services must address agnostic or cro...
Summary
Service-oriented architecture 
A means of developing distributed systems where the 
components are stand-alone services 
S...
Service-oriented architecture 
Service 
registry 
Service 
requestor 
Service 
provider 
Service 
Find Publish 
Bind (SOAP...
Benefits of SOA 
• Services can be provided locally or outsourced to external 
providers 
• Services are language-independ...
Key standards 
• SOAP 
– A message exchange standard that supports service 
communication 
• WSDL (Web Service Definition ...
Web service standards 
XML technologies (XML, XSD, XSLT, ....) 
Support (WS-Security, WS-Addressing, ...) 
Process (WS-BPE...
RESTful web services 
Current web services standards have been criticized as 
‘heavyweight’ standards that are over-genera...
Example: in-car information system 
1. Provides drivers with information on weather, road traffic conditions, 
local infor...
Example: in-car information system 
User interface 
Locator 
Discovers car 
position 
Weather 
info 
Receives request 
fro...
Advantage of SOA for this application 
It is not necessary to decide when the system is 
programmed or deployed what servi...
Services as reusable components 
• A service can be defined as: 
– A loosely-coupled, reusable software component that 
en...
WSDL: Web Service Description 
Language 
The service interface can be defined in a service description 
expressed in WSDL ...
Organization of a WSDL specification 
WSDL service definition 
Intro 
Abstract interface 
Concrete 
implementation 
XML na...
Part of a WSDL description for a web 
service 
Define some of the types used. Assume that the namespace prefixes ‘ws’ 
ref...
Part of a WSDL description for a web 
service 
Now define the interface and its operations. In this case, there is only a ...
What this lecture means to you? 
• Software product lines exploit the commonalities of a family of 
systems and systematic...
References 
Andreas Metzger and Klaus Pohl. 2014. Software 
product line engineering and variability 
management: achievem...
Contact Ivano Malavolta | 
Post-doc researcher 
Gran Sasso Science Institute 
iivanoo 
ivano.malavolta@gssi.infn.it 
www.i...
Prochain SlideShare
Chargement dans…5
×

Modern development paradigms

1 063 vues

Publié le

This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.

http://www.ivanomalavolta.com

Publié dans : Technologie
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 063
Sur SlideShare
0
Issues des intégrations
0
Intégrations
42
Actions
Partages
0
Téléchargements
31
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Modern development paradigms

  1. 1. Modern development paradigms Ivano Malavolta
  2. 2. Roadmap Software product-lines Service-oriented architecture
  3. 3. Software product-lines
  4. 4. 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
  5. 5. 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
  6. 6. 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. 7. Business motivation for product lines Traditional Software Engineering 7
  8. 8. Business motivation for product lines Traditional Software Engineering 8
  9. 9. Business motivation for product lines Product-line-based engineering
  10. 10. 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.
  11. 11. SPL engineering
  12. 12. Conceptual framework of PLs Image © Paolo Ciancarini
  13. 13. 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
  14. 14. 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 • …
  15. 15. Capturing product line architectures B A B Common A Common A Common B (a) (b) (c) • 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 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.
  16. 16. 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
  17. 17. A lunar lander product line “Lite” “Demo” “Pro”
  18. 18. Product component table Helps us decide whether creating a product line is viable or feasible Data Store Data Store Connector Game Logic Game Logic Connector Text-based UI UI Plug-ins Connector Graphical UI System Clock System Clock Connector Demo Reminder 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
  19. 19. Group components into features Not a mechanical process Attempt to identify (mostly) orthogonal features, or features that would be beneficial in different products Data Store Data Store Connector Game Logic Game Logic Connector Text-based UI UI Plug-ins Connector Graphical UI System Clock System Clock Connector Demo Reminder 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
  20. 20. Reconstitute products from features Use technical and business knowledge to identify which combinations form feasible or marketable products that will be constructed Core Elements Text UI Graphical UI Time Limited Lunar Lander Lite X X Lunar Lander Demo X X X Lunar Lander Pro X X
  21. 21. 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
  22. 22. 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. 23. 23
  24. 24. 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
  25. 25. 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
  26. 26. Feature model in the automotive domain Exemplar of Automotive Architecture with Variability. Kacper Bak , Marko Novakovic , Leonardo Passos. Technical report.
  27. 27. Uses: product lines for feature selection 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
  28. 28. Uses: product lines for evolution Products in a product line don’t have to exclusively capture alternatives – They can also capture variation over time
  29. 29. Uses: product lines for evolution
  30. 30. 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
  31. 31. Implementation issues Important to partition implementations along variation-point boundaries File1.java Common File2.java File3.java File4.java A B File1.java Common File2.java File3.java File4.java A B Ba(ad) G(bo) od
  32. 32. 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 Text-based Evolution Graphical 3.0 2.1 4.0 2.2 Fork UI.java (as versioned in a software configuration management system)
  33. 33. 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
  34. 34. 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
  35. 35. Example: lunar lander in Koala • No product line features yet interface IDataStore{ void setAltitude(int altitudeInMeters); int getAltitude(); void setBurnRate(int newBurnRate); int getBurnRate(); ... }
  36. 36. 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
  37. 37. Example 2: SPL for robotics L. Gherardi, “Variability modeling and resolution in component-based robotics systems,” PhD Thesis, 2013.
  38. 38. Example 2: SPL for robotics L. Gherardi, “Variability modeling and resolution in component-based robotics systems,” PhD Thesis, 2013.
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. 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
  43. 43. 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
  44. 44. Service-oriented architecture
  45. 45. Introduction to service orientation Three individuals, each capable of providing a distinct service
  46. 46. Introduction to service orientation A company that employs these three people can compose their capabilities to carry out its business
  47. 47. 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)
  48. 48. 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
  49. 49. Basic example of service composition 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 Mashup APIs application Single graphical interface
  50. 50. Basic example of service composition
  51. 51. Services inventory Establishes a pool of services, many of which will be deliberately designed to be reused within multiple service compositions
  52. 52. 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
  53. 53. 1 - Standardized service contract Services within the same service inventory are in compliance with the same contract design standards “contract first” approach
  54. 54. 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
  55. 55. 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
  56. 56. 4 - Service reusability Services contain and express agnostic logic Services can be positioned as reusable enterprise resources
  57. 57. 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
  58. 58. 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
  59. 59. 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
  60. 60. 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
  61. 61. Summary
  62. 62. 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
  63. 63. Service-oriented architecture Service registry Service requestor Service provider Service Find Publish Bind (SOAP) (WSDL)
  64. 64. 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
  65. 65. 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
  66. 66. Web service standards XML technologies (XML, XSD, XSLT, ....) Support (WS-Security, WS-Addressing, ...) Process (WS-BPEL) Service definition (UDDI, WSDL) Messaging (SOAP) Transport (HTTP, HTTPS, SMTP, ...)
  67. 67. 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
  68. 68. 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
  69. 69. Example: in-car information system User interface Locator Discovers car position Weather info Receives request from user Receiver Receives information stream from services Transmitter Facilities info Sends position and information request to services Radio Translates digital info stream to radio signal In-car software system Mobile Info Service Translator Road locator Traffic info Collates information Road traffic info command gps coord gps gps coord coord gps coord Language Info info stream Service discovery Finds available services
  70. 70. 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
  71. 71. 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 SOA VS component-based systems Services are independent – Services do not have a ‘requires’ interface – Services rely on message-based communication with messages expressed in XML
  72. 72. 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)
  73. 73. Organization of a WSDL specification WSDL service definition Intro Abstract interface Concrete implementation XML namespace declarations Type declarations Interface declarations Message declarations Binding declarations Endpoint declarations
  74. 74. 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>
  75. 75. 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>
  76. 76. 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
  77. 77. References 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.
  78. 78. Contact Ivano Malavolta | Post-doc researcher Gran Sasso Science Institute iivanoo ivano.malavolta@gssi.infn.it www.ivanomalavolta.com

×