![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-spl2019-190228065653/85/Software-variability-management-2019-32-320.jpg)
![• Cross-tree constraints are expressed as boolean expressions
over the features.
Feature model
• The semantics of a feature model corresponds to all the valid
products allowed by the feature model.
P
C1 C2 C3
(C1 ∧ C2) C3
Valid products:
{P, C1} {P, C2} {P, C3}
{P, C1, C2} {P, C2, C3} {P, C1, C3}
{P, C1, C2, C3}
{{P, C1} {P, C2} {P, C3}
{P, C1, C2} {P, C2, C3} {P, C1, C3}
{P, C1, C2, C3}}
P
C1 C2 C3
[| |]=](https://image.slidesharecdn.com/tudelft-architecture-spl2019-190228065653/85/Software-variability-management-2019-36-320.jpg)
Software variability management - 2019
- 1. Software variability management Xavier Devroey <x.d.m.devroey@tudelft.nl> Office 4.W.740 (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 (Variability 101)
- 12. •Fast •Cheap (at first) •Limited •Manage (large number of) copies •Maintenance cost at each evolution •Inconsistent evolution of copies
- 13. Software Product Line (Variability level over 9000!)
- 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
- 22. Example: Enterprise resource planning systems (ERPs) Database Core Customer- relationship management (CRM) API Sales Accounting HR … • Integrated management of business processes • Spread during the 1990s
- 23. Pohl, K., et al. (2005) Software product line engineering: foundations, principles, and techniques. Springer. Building the ERP platform Configuring, customising and deploying an ERP instance Example: Enterprise resource planning systems (ERPs)
- 24. Example: Enterprise resource planning systems (ERPs) Identification of business processes Configuration Customisation and extension Data migration Redefinition of business processes
- 25. Hall of Fame Software Product Line Conference (SPLC) http://splc.net/hall-of-fame/ • Boeing • Bosch Group • CelsiusTech Systems AB • Cummins, Inc. • Danfoss • Ericsson AXE • FISCAN • General Motors Powertrain (GMPT) • Hewlett Packard • HomeAway • Lockheed Martin • LSI Logic • Lucent • Market Maker • Nokia • Philips (Medical Systems) • Philips (Software for Television Sets) • Philips (Telecommunication Switching System) • Salion, Inc. • Siemens (syngo.via) • Toshiba • U.S. Army Live Traning Transformation • U.S. Naval Research Laboratory
- 32. 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.
- 33. A feature model documents the features of a product line and their relationships. Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer.
- 34. • Tree-like structure (directed acyclic graph). • A feature is decomposed in sub- features Feature model • And decomposition: if the parent is selected then all sub-features must be selected too • Or decomposition: if the parent is selected then at least one sub- features must be selected too P C1 C2 C3 Valid product: {P, C1, C2, C3} P C1 C2 C3 Valid products: {P, C1} {P, C2} {P, C3} {P, C1, C2} {P, C2, C3} {P, C1, C3} {P, C1, C2, C3}
- 35. • Tree-like structure (directed acyclic graph). • A feature is decomposed in sub- features Feature model • Xor decomposition: if the parent is selected then exactly one sub- features must be selected too P C1 C2 C3 Valid products: {P, C1} {P, C2} {P, C3} • Mandatory feature: if the parent is selected then the feature must be selected • Optional feature: if the parent is selected then the feature must be selected P C P C Valid product: {P, C} Valid products: {P} {P, C}
- 36. • Cross-tree constraints are expressed as boolean expressions over the features. Feature model • The semantics of a feature model corresponds to all the valid products allowed by the feature model. P C1 C2 C3 (C1 ∧ C2) C3 Valid products: {P, C1} {P, C2} {P, C3} {P, C1, C2} {P, C2, C3} {P, C1, C3} {P, C1, C2, C3} {{P, C1} {P, C2} {P, C3} {P, C1, C2} {P, C2, C3} {P, C1, C3} {P, C1, C2, C3}} P C1 C2 C3 [| |]=
- 37. Halin, A., et al. 2018. Test them all, is it worth it? Assessing configuration sampling on the JHipster Web development stack. EMSE.
- 38. 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 •…
- 41. 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.
- 42. Design-time binding • Clone and own
- 43. 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
- 44. Conditional compiling • Implements variability with preprocessors • Using annotated code (here, templates)
- 45. Conditional compiling Yeoman Configuration Annotated code Source code without annotations
- 46. Load-time Binding Apel, S. et al. (2013) Feature-Oriented Software Product Lines. Springer. • Decided after compilation when the program is started • More flexibility for reconfiguration • … but 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
- 47. 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
- 48. 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
- 49. 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
- 50. 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
- 51. 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
- 52. 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
- 53. Identifying Variability (Feature = Option) (Product = Configuration = Variant)
- 54. • Does your application have variability? • Yes, most probably
- 55. • Does your application have variability? • Hardware • Plattorm • Features • Bundels • Plugins • Command line options • …
- 56. • How is it managed (if it is managed)? • For users • Documentation only? • Configurator (e.g., JHipster)?
- 57. • How is it managed (if it is managed)? • For developers • Documentation only? • Model (e.g., feature model)? • Planned in the development lifecycle?
- 58. Variability Management section outline • Examples of variability in your system, and their manifestation in architectural discussions • Variability management • Current variability implementation mechanism of your system • Conditional compiling • Conditional statements (if-then-else) • Design patterns • Variability binding time • Design-time • Compile-time • Load-time • Run-time • (Partial) feature model
- 59. Take-away
- 60. • 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