Supporting Architectural Variabiality in Software Product Lines
4 likes755 views
This document discusses supporting architectural variability in software product lines. It begins with an overview of software product lines and product line architectures. It then discusses implementing variability at the architectural level using tactics and design patterns. Tactics aim to achieve certain quality attributes, and there are theories linking concerns to tactics and designs. Feature models can be used to represent relationships between tactics and design alternatives. Tactics can also be implemented using configuration options like in cloud computing platforms. Relating tactics to configuration options allows automatically deriving architectural designs based on quality attribute requirements.
![Product Line Architecture
26
Social
Network
Twitter
V
Facebook
V
[0..2]
VP
Shopping
Cart
Shopping Cart
V
VP](https://image.slidesharecdn.com/supportingarchitecturalvaribialityinspls-160329210359/85/Supporting-Architectural-Variabiality-in-Software-Product-Lines-26-320.jpg)
Supporting Architectural Variabiality in Software Product Lines
- 1. Supporting Architectural Variability in Software Product Lines Jaime Chavarriaga, ja.chavarriaga908@uniandes.edu.co
- 2. What is the subject of this talk? Architectural Variability in SPLs â Software Product Lines â Architecting a single product and an SPL â Product Line Architecture â Implementing Variability in Architecture âą Using tactics and design patterns âą Using tactics and deployment options 2
- 3. Software Product Lines: a short review
- 4. e.g. Software Product Lines MS Office 4
- 5. e.g. Software Product Lines MS Office 5
- 6. Feature Models / Configuration âą C1 = { Word, Excel, Powerpoint, OneNote} âą C2 = { Word, Excel, Powerpoint, OneNote , Access} âą C3 = { Word, Excel, Powerpoint, OneNote , Access, Publisher} âą C4 = { Word, Excel, Powerpoint, OneNote, Outlook} âą C5 = { Word, Excel, Powerpoint, OneNote , Access, Outlook} âą C6 = { Word, Excel, Powerpoint, OneNote , Access, Publisher, Outlook} 6
- 7. Feature Models / Configuration âą C1 = { Word, Excel, Powerpoint, OneNote} âą C2 = { Word, Excel, Powerpoint, OneNote , Access} âą C3 = { Word, Excel, Powerpoint, OneNote , Access, Publisher} âą C4 = { Word, Excel, Powerpoint, OneNote, Outlook} âą C5 = { Word, Excel, Powerpoint, OneNote , Access, Outlook} âą C6 = { Word, Excel, Powerpoint, OneNote , Access, Publisher, Outlook} 7 Commonalities Variabilities
- 8. e.g. Software Product Lines Song Stores 8
- 9. e.g. Software Product Lines Song Stores 9 Search Functionality
- 10. e.g. Software Product Lines Song Stores 10 Catalog
- 11. e.g. Software Product Lines Song Stores 11 Social Networks
- 12. e.g. Software Product Lines Song Stores 12 Shopping Cart
- 13. e.g. Software Product Lines Song Stores 13 Videos and News
- 14. Software Product Lines Song Stores 14
- 15. SPL Engineering: a short review
- 16. Problem Statement âą How to build all the products in the product line in a cost-effective way ? â Reducing development effort / Reusing assets â Reducing the cost of creating a new product 16
- 17. Each product is derived based on a configuration of features Software Product Lines 17
- 18. Each product is derived based on a configuration of features Software Product Lines 18
- 19. Each product is derived based on a configuration of features Software Product Lines 19 Product Derivation Process
- 20. Software Product Lines Each product is derived using shared assets Assets Product Derivation Process
- 25. Product Line Architecture (PLA) âą A shared PLA for all the products â PLA = architectural design for all the products + orthogonal variability 25
- 26. Product Line Architecture 26 Social Network Twitter V Facebook V [0..2] VP Shopping Cart Shopping Cart V VP
- 27. Product Line Architecture 27 Shopping Cart Public Cart V For Members V VP
- 28. Quality Attributes and Architectural Tactics
- 29. Architectural Tactics âą e.g. For Performance (Bass et al.)
- 30. Architectural Tactics How to achieve a quality attribute ? 30
- 31. Architectural Tactics there is a theory for each quality attribute Bass et al. Software Architecture in Practice Addison-Wesley 2014 31
- 32. Architectural Tactics there is a theory for each quality attribute Bass et al. Software Architecture in Practice Addison-Wesley 2014 32
- 33. Architectural Tactics there is a theory for each quality attribute Bass et al. Software Architecture in Practice Addison-Wesley 2014 33
- 34. Architectural Tactics there are concerns for each quality attribute Bass et al. Software Architecture in Practice Addison-Wesley 2014 34 To Increase the number or capacity of nodes To Control the arrival rate of events or the queue
- 35. Architectural Tactics there are tactics for each concern Bass et al. Software Architecture in Practice Addison-Wesley 2014 35
- 36. Architectural Tactics there are designs to implement these tactics Bass et al. Software Architecture in Practice Addison-Wesley 2014 36
- 37. Architectural Tactics ⊠using code or deployment options. Bass et al. Software Architecture in Practice Addison-Wesley 2014 37
- 38. Implementing Architectural Tactics using Design Patterns
- 39. Variants of Architectural Design 39 As a foundation, we can use Three layers: Presentation, Domain Logic and Presentation
- 40. Variants of Architectural Design 40 For Performance, caching elements to maintain copies of data
- 41. Variants of Architectural Design 41 As a foundation, we can use Three tiers: Client, Web and Database Tier
- 42. Variants of Architectural Design 42 For Performance, application servers allow us to introduce concurrency
- 43. Variants of Architectural Design 43 For Performance, load balanced servers to maintain copies of computation
- 44. A Feature Model for Design Alternatives
- 45. 45 Our Idea A Configuration of Tactics can be used to derive the Architectural Design of a product
- 46. 46 Feature Solution Graph (FS-Graphs) forces prohibits suggests
- 47. 47 Feature Solution Graph (FS-Graphs) forces prohibits suggests
- 48. 48 Feature Solution Graph (FS-Graphs) forces prohibits suggests
- 50. FM for Architectural Tactics 6 Quality Attributes 79 Architectural Tactics Bass et al. Software Architecture in Practice Addison-Wesley 2013 50
- 51. FM for Architectural Tactics Bass et al. Software Architecture in Practice Addison-Wesley 2013 51
- 52. (again) A Feature Model for Design Alternatives
- 53. Configure architecture based on QA-Tactics âą Suggests relationships 53 suggests forces
- 54. Configure architecture based on QA-Tactics âą Forces relationships 54 suggests forces
- 55. Configure architecture based on QA-Tactics âą Forces relationships 55 forces
- 56. Configure architecture based on QA-Tactics âą Forces relationships 56 forces
- 57. Configure architecture based on QA-Tactics âą Prohibits relationships 57 Prohibits
- 58. Configure architecture based on QA-Tactics âą Prohibits relationships 58 Prohibits
- 59. Implementing Architectural Tactics using Configuration options
- 62. some Tactics in Cloud Computing 62
- 63. some Tactics in Cloud Computing 63
- 64. FM for Jelastic Cloud Computing Quinton et al. Handling Constraints in Cardinality-Based Feature Models INRIA, RR # 8478, 2014 64
- 65. FM for Jelastic Cloud Computing Quinton et al. Handling Constraints in Cardinality-Based Feature Models INRIA, RR # 8478, 2014 65
- 66. Jelastic âŠSession Server App Server Tomcat Glassfish Jetty HA requires Tactics Performance Availability⊠forces TPC LB forces prohibits Passive Redundancy Active Redundancy Reduce Overhead HTTP LB Load Balancer Relating architectural tactics to configuration options 66
- 67. Jelastic âŠSession Server App Server Tomcat Glassfish Jetty HA requires Tactics Performance Availability⊠forces TPC LB forces prohibits Passive Redundancy Active Redundancy Reduce Overhead HTTP LB Load Balancer Relating architectural tactics to configuration options 67
- 68. Jelastic âŠSession Server App Server Tomcat Glassfish Jetty HA requires Tactics Performance Availability⊠forces TPC LB forces prohibits Passive Redundancy Active Redundancy Reduce Overhead HTTP LB Load Balancer Relating architectural tactics to configuration options 68
- 69. Questions ? Jaime Chavarriaga, jchavarr@vub.ac.be Rubby Casallas, rcasalla@uniandes.edu.co
Editor's Notes
- #5: A Software product Line (or a Software product family) represents a set of software products that are made from the same assets, e.g. the same components or the same classes. An example is Microsoft Office.
- #6: A Software product Line (or a Software product family) represents a set of software products that are made from the same assets, e.g. the same components or the same classes. An example is Microsoft Office.
- #7: In an SPL, each product is defined by a configuration. That is that each product is defined by a subset of the features in a feature model. Each configuration must be consistent with the constraints and rules defined in the feature model. In turn, each feature model represents a set of products, i.e. a set of configurations. Each
- #8: In an SPL, each product is defined by a configuration. That is that each product is defined by a subset of the features in a feature model. Each configuration must be consistent with the constraints and rules defined in the feature model. In turn, each feature model represents a set of products, i.e. a set of configurations. Each
- #21: Feature Oriented Programming Component-based SPLs Model-driven SPLs âŠ
- #62: (Options to deploy in cloud computing) For instance, a Java application may be deployed in a Cloud platform such as Jelastic using multiple options. An application can be installed using a single tomcat application server, multiple application servers using an sticky session load balancer or an application server cluster with a non-sticky session load balancer
- #65: Numero de opciones Note they are featuresâŠ
- #66: Numero de opciones Note they are featuresâŠ