![What about constraints?
Which type of application would you like to create?
You can either use:
• Monolithic application […]
• Microservice application […]
• Microservice gateway […]
http://www.jhipster.tech/creating-an-app/
Which type of database would you like to use?
You can choose between:
• No database (only available when using a microservice application)
• An SQL database (H2, MySQL, MariaDB, PostgreSQL, MSSQL, Oracle),
which you will access with Spring Data JPA
• MongoDB
• Cassandra
• Couchbase
Social login (Google, Facebook, Twitter)
This option is only available if you selected an SQL, MongoDB, or
Couchbase database.](https://image.slidesharecdn.com/tudelft-architecture-spl2018-181126133750/85/Software-variability-management-2017-29-320.jpg)
Software variability management - 2017
- 1. Software variability management Xavier Devroey <x.d.m.devroey@tudelft.nl> Office 4.W.540 (4th floor, West side, new EWI building)
- 2. Introduction
- 3. software variability is the ability of a software system or artefact to be efficiently extended, changed, customised or configured for use in a particular context. Svahnberg, M., et al. (2005) ‘A taxonomy of variability realization techniques’, Software - Practice and Experience, 35(8), pp. 705–754.
- 4. iOS 10.0.x iOS 10.1.x iOS 11.0.x … … 7.0.x 7.1.x 8.0.x … … { { Hardware • Processor • RAM • Screen size • … Platform • OS • Version • Navigator • …
- 6. 33 Options 0 A unique product for every person on this planet
- 7. 33 320 Options 0 More products than the estimated atoms in the universe
- 10. Clone and Own
- 12. •Fast •Cheap (at first) •Limited •Manage (large number of) copies •Maintenance cost at each evolution •Inconsistent evolution of copies
- 14. Henry Ford 1901
- 17. •Tailor-made • For individual customers •Reduced costs • Reusable parts can be combined in different ways •Improved quality • Parts can be standardized and checked in isolation and reused and tested in multiple products. •Time to market • building on top of existing parts is much faster than developing it entirely from scratch
- 18. A product is built by systematically combining commonalities, common to all products, and variabilities, specific to some products. Features
- 19. A feature is a characteristic or end-user-visible behaviour of a software system. Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer.
- 20. Pohl, K., et al. (2005) Software product line engineering: foundations, principles, and techniques. Springer. The software product line engineering framework
- 21. Pohl, K., et al. (2005) Software product line engineering: foundations, principles, and techniques. Springer. The software product line engineering framework Commonalities and variabilities definition and realisation Product derivation
- 29. What about constraints? Which type of application would you like to create? You can either use: • Monolithic application […] • Microservice application […] • Microservice gateway […] http://www.jhipster.tech/creating-an-app/ Which type of database would you like to use? You can choose between: • No database (only available when using a microservice application) • An SQL database (H2, MySQL, MariaDB, PostgreSQL, MSSQL, Oracle), which you will access with Spring Data JPA • MongoDB • Cassandra • Couchbase Social login (Google, Facebook, Twitter) This option is only available if you selected an SQL, MongoDB, or Couchbase database.
- 30. A feature model documents the features of a product line and their relationships. Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer.
- 32. • Tree-like structure (directed acyclic graph). • A feature is decomposed in sub- features using and, or, or xor. • Cross-tree constraints are expressed as boolean expressions over the features. • The semantics of a feature model corresponds to all the valid products allowed by the feature model. • A boolean feature model may be translated to a Conjunctive Normal Form (CNF) formula
- 33. JHipster-App ∧ (Building ∨ ¬Maven) ∧ (Building ∨ ¬Gradle) ∧ (Maven ∨ Gradle ∨ ¬Building) ∧ (¬Maven ∨ ¬Gradle) ∧ (Server ∨ ¬Database) ∧ (Server ∨ ¬HibernateCache) ∧ (Server ∨ ¬Building) ∧ (Building ∨ ¬Server) ∧ (JHipster-App ∨ ¬Type) ∧ (JHipster-App ∨ ¬Client) ∧ (JHipster-App ∨ ¬Server) ∧ (Type ∨ ¬JHipster-App) ∧ (Server ∨ ¬JHipster-App) ∧ (Type ∨ ¬Monolithic) ∧ (Type ∨ ¬Microservice) ∧ (Type ∨ ¬Gateway) ∧ (Monolithic ∨ Microservice ∨ Gateway ∨ ¬Type) ∧ (¬Monolithic ∨ ¬Microservice) ∧ (¬Monolithic ∨ ¬Gateway) ∧ (¬Microservice ∨ ¬Gateway) ∧ (Database ∨ ¬MongoDB) ∧ (Database ∨ ¬SQL) ∧ (Database ∨ ¬Cassandra) ∧ (MongoDB ∨ SQL ∨ Cassandra ∨ ¬Database) ∧ (¬MongoDB ∨ ¬SQL) ∧ (¬MongoDB ∨ ¬Cassandra) ∧ (¬SQL ∨ ¬Cassandra) ∧ (¬HibernateCache ∨ SQL) ∧ (¬Client ∨ Monolithic) ∧ (Client ∨ Microservice ∨ Gateway) ∧ True ∧ ¬False Conjunctive Normal Form (CNF) •SAT •Consistency •Valid configurations •Dead features •…
- 34. • Does your application have variability? • Hardware • Plattorm • Features • Bundels • Plugins • Command line options • … • How is it managed (if it is managed)? • For developers • Documentation only? • Model (e.g., feature model)? • Planned in the development lifecycle? • For users • Documentation only? • Configurator (e.g., JHipster)? • Validation mechanism?
- 35. Binding Time
- 36. Variability offers choices. When we derive a product, we make decisions; we decide which features will be included in the product or not. We also say that we bind a decision. Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer.
- 37. Design-time binding • Clone and own
- 38. Compile-time Binding Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer. • Decided before or at compile time • Allows optimisations • Removes unnecessary code from the product • Once the product has been generated and deployed, it is not variable any more
- 39. Conditional compiling • Implements variability with preprocessors • Using annotated code (here, templates)
- 40. Conditional compiling Yeoman Configuration Annotated code Source code without annotations
- 41. Load-time Binding Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer. • Decided after compilation when the program is started • More flexible to reconfigure • Requires a reboot • Memory and performance overhead • All variations are compiled into a single binary • Consistency conditions must be checked at load time • Unnecessary functionality may be considered as potential security threat
- 42. Parameters and Configuration Files Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer. • Implement variability using conditional statements (such as if and switch) • Controlled by configuration parameters • Passed to the method or module, • Set as global variables in a system Gcc
- 43. Run-time Binding Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer. • Decided during program execution and may be changed latter • Used in dynamic adaptive systems (e.g., robots) • Most flexible to reconfigure • Able to react to internal and external stimuli by adapting its behaviour • Memory and performance overhead • All variations are compiled into a single binary • Consistency conditions must be checked at run time • Unnecessary functionality may be considered as potential security threat
- 44. Design Patterns Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer. • Observer pattern (publish/subscribe) to implement distributed event handling • Feature are implemented as observers • Variability is achieved by registering or not registering observers
- 45. Design Patterns Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer. • Template-method pattern • Using an abstract class • Implement feature’s behaviour using inheritance
- 46. Design Patterns Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer. • Strategy pattern • Encodes a callback mechanism • Alternative features where each corresponds to one implementation of the algorithm • Uses polymorphism instead of conditional statements
- 47. Design Patterns Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer. • Decorator pattern • Extends object with additional behaviour at run time • Optional features and feature groups, of which multiple features can be selected, are implemented as decorators
- 48. • Variability binding time? • Design-time • Compile-time • Load-time • Run-time • Variability implementation mechanism? • Conditional compiling • Conditional statements (if-then-else) • Design patterns
- 49. Testing
- 51. •26,256 possible products •4,376 hours (182 days) processor time to execute the tests •8 person/month to setup testing infrastructure How to test a SPL?
- 52. Combinatorial Interaction Testing • Assumption • Most of the faults are due to the undesired feature interactions of a limited number of features • Example • Gradle + MariaDB fails due to a missing dependency in _liquibase.gradle template file • Idea • Extract configurations so that all combinations of options are covered (at least) once: t-wise sampling
- 53. t-wise sampling • All t combinations of features are in at least one product • 2-wise: 26,256 ➠ 41 products • 3-wise: 26,256 ➠ 126 products • 4-wise: 26,256 ➠ 374 products … but, t-wise sampling is NP-complete when there are constraints • Tools • MoSo-Polite (constraint programming) • PACOGEN (constraint programming) • CASA (simulated annealing) • SPLCAT (various algorithms) and Pairwiser (industrial version) … have a hard time to go above 4-wise for large feature models
- 54. •26,256 possible products •4,376 hours (182 days) processor time to execute the tests •8 person/month to setup testing infrastructure How to test a SPL… …when you have a budget of max. 20 products?
- 55. Dissimilarity sampling • Assumption • Dissimilar configurations cover more t-tuples than similar ones Henard, C., et al. (2014) Bypassing the Combinatorial Explosion: Using Similarity to Generate and Prioritize T-Wise Test Configurations for Software Product Lines. TSE. 40, 7 (Jul. 2014), 650–670. • Tool: PLEDGE • Evolutionary algorithm • Fitness function based on distance (i.e., differences in the selected features) • Correlated with t-wise coverage but easier to compute • Testers decide on generation time and number of products
- 56. •26,256 possible products •4,376 hours (182 days) processor time to execute the tests •8 person/month to setup testing infrastructure How to test a SPL… …when you have a budget of max. 20 products? PLEDGE(fm, 20, 1 min.)
- 57. … but What about product dependencies, and how to automate the testing process? Halin, A., et al. (2017) Test them all, is it worth it? A ground truth comparison of configuration sampling strategies. CoRR. abs/1710.0, (Oct. 2017).
- 59. • Variability is unavoidable in software developments • It should be planned and managed •Identify development practices • Clone and own • Software product line • Most probably something intermediate • Binding • Design, compile, load, and/or runtime binding • Variability implementation mechanism(s) (conditional compiling, parameters, design patterns) •Feature modelling helps to manage variability • Analysis on the feature model • Sample products to test
- 60. Software variability management Xavier Devroey <x.d.m.devroey@tudelft.nl> Office 4.W.540 (4th floor, West side, new EWI building)