Principles of software product lines

Chapter 1 Principles of Software Product Lines Edson OliveiraJr and David Benavides Abstract Software product lines (SPL) has been consolidated in the last decades as a de facto and non-opportunistic way of mass customization and reuse of software artifacts to produce specific products. Over the years, SPLs and their construction processes have evolved based on several seminal works and technologies. In this chapter, we characterize an SPL, present its terminology, chronologically present its first construction methodologies and second-generation ones, and describe SPL development approaches. We conclude the chapter with final remarks and considerations for the next chapters. 1.1 Characterizing Software Product Lines The first Industrial Revolution began in Great Britain in the mid-eighteenth century (1760 to 1820–1840), which was a transition from handmade products manufacturing to a machine-based production. At that time, new inventions were made possible due to increasing iron and chemical processes, such as water and steam power. Therefore, textile industry led employment and mass production [21,38]. Due to these advancements in production, Henry Ford defined the first assembly line manufacturing process in which semi-built parts are assembled together moving from one workstation to another. Thus, an assembled product is built faster than usual hand-based single product production [47]. Then, in 1913, Ford launched the assembly line of a car, named Ford Model T (Fig. 1.1). Since then, Ford assembly lines concept has impacted the overall industry in the manufacturing process by mass production, which might be defined as the E. OliveiraJr () State University of Maringá, Informatics Department, Maringá, Paraná, Brazil e-mail: [email protected].br D. Benavides University of Seville, Escuela Tecnica Superior de Ingeniería Informática, Dpto. de Lenguajes y Sistemas Informáticos, Sevilla, Spain e-mail: [email protected] E. OliveiraJr (ed), UML-Based Software Product Line Engineering with SMarty, https://doi.org/10.1007/978-3-031-18556-4_1 3 4 E. OliveiraJr and D. Benavides Fig. 1.1 Ford assembly line [47] production of a large amount of standardized products using standardized processes that allow producing a big amount of the same product in a reduced time to market. However, mass production was starting to be not enough in a highly competitive and segmented market [31], and mass customization became a must for market success. Therefore, mass customization can be defined as “producing goods and services to meet individual customer’s needs with near mass production efficiency” [31]. Mass customization drastically reduced costs and increasing production. Nowadays, this concept has been successfully applied to the software manufacture industry under the concept of a software product line (SPL) [11,36,41]. One of widely adopted definition for software product line is “a set of softwareintensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way”[ 11]. Such definition is in accordance with the IEEE software engineering definition, which is “the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is, the application of engineering to software” [23]. The concept of SPL takes into account consolidated software engineering practices as domain engineering [15,37]. Domain engineering aims at engineering an understanding the applications domain using development principles, techniques, and tools for static and dynamic attributes, support technology, management and organization, rules and regulations, and human behavior [8]. Figure 1.2 depicts main activities of domain engineering and application engineering. 1 Principles of Software Product Lines 5 Domain Design Domain Implementation System Family Architec− ture Domain Model Domain Knowledge Domain−specific languages Components Generators New Requirements Domain Analysis Customer Needs Integra− tion and Test Custom Develop− ment Product Configuration Custom Design New Require− ments Product Configuration Analysis Requirements Application Engineering Domain Engineering Features Product Fig. 1.2 Domain and application engineering [14] Domain engineering begins with the domain analysis phase, in which knowledge of the domain form the basis for the abstraction of the domain model. Then, domain design is performed taking as input the domain model, which guides the implementation of an infrastructure to support the system family architecture. Based on such architecture, the application engineering produces single products by its first phase: requirement analysis. New requirements and features might be added, and then a single product is configured for a custom designing. Once designed, a product is integrated and tested under the customer requirements. These two cycles mainly compose the foundations of modern SPLs. They provide capability for an SPL to derive several different specific products based on a common architecture and similar/variable features. For further comprehension, Chap. 2 exploits the concept of features and variability in software product lines, whereas Chap. 3 provides basics on product line architectures (PLA). SPL provides several benefits, such as [11,36,44–46]: •Lower time to market by accelerating the production of similar products with non-opportunistic reuse techniques. •Enhance product quality as reusable core assets are previously verified and validated. •Increase productivity as a set of core assets is previously built based on common domain characteristics. •Decrease production costs by reusing de facto self and COTS components. 6 E. OliveiraJr and D. Benavides •Mitigate product risks as domain engineering risk management can be applied. •Support market agility by not developing each product at a time. •Enhance customer satisfaction as most requirements can be reused for specific products of the same domain. •Support mass customization by mainly using the concept of software variability. • Increase predictability as estimation effort can be mitigated based on pre-built components. On the other hand, SPL development might experience some difficulties as SPL training as technical management activities, a considerable amount of investment (financial, time, and people) to obtain return on investment, and SPL architecture integration and testing issues, especially when transiting from single-product development to SPL-based development. 1.2 SPL Terminology The following non-exhaustive terminology has been built over the years. They are more related to the contents of this book [24]. Core asset: is any output of the domain engineering process. It can be reused at producing products during application engineering. They include, for instance, features, models, requirements specifications, domain architecture, domain components, and test cases. SPL architecture (PLA): is the architecture, which includes structure and texture (e.g., common rules and constraints), that constrains all member products within an SPL. It usually provides variability represented in its components. Variability: represents characteristics that may differ among products (members) of an SPL. Such differences are captured from multiple viewpoints such as functionality, quality attributes, and environments. Variation point: representation corresponding to given variable characteristics of products, core asset, and application assets in the context of an SPL. Variation points show what of the SPL varies. Each variation point should have at least one variant. Variant: is an alternative to realize a particular variation point. Selection and binding of variants for a specific product delimit the characteristics of the particular variability for the product. Very often, a variant refers to a concrete configuration of an SPL. Binding: it represents the time when variants are bound to resolve a variation point or an specific variability. Commonality: it refers to functional and nonfunctional characteristics shared to all members in an SPL. Feature: is a high-level characteristics of a system functionality that can be communicable with customers and relevant stakeholders. 1 Principles of Software Product Lines 7 Variability management: it consists of tasks for overseeing variability in the level of the entire SPL, creating and maintaining variability models, ensuring consistencies between variability models, managing all variability and constraint dependencies across the SPL, and managing the traceability links between a variability model and associated domain and application assets (e.g., requirements models, design models). SPL configuration: refers to resolving all variabilities enabling the derivation of a specific SPL product. 1.3 SPL Engineering Methodologies and Reference Model In this section we present consolidated SPL methodologies and reference models. They are used to design, implement, and derive specific SPL products in a systematic and prescriptive way. 1.3.1 First-Generation Methodologies SPL research and practice are nowadays divided into first- and second-generation methodologies. The first ones are those which aided SPL research and practice to deal with several issues, such as variability modeling, feature composition and modeling, resolution of variabilities and derivation of specific SPL products, and maintenance of SPLs. 1.3.1.1 FODA: Feature-Oriented Domain Analysis (1990) Feature-oriented domain analysis (FODA) [28] is a method for performing domain analysis. FODA emphasizes the identification of features the user commonly expects in an application of a given domain. Figure 1.3 depicts the processes and products of FODA, which are: context analysis to produce a structure diagram and a context diagram; domain modeling to produce an E-R model, a feature model, a functional model, and a domain terminology dictionary; and architecture modeling to produce a Process interaction model and a module structure chart. Figure 1.4 depicts products of domain analysis and roles involved to tailoring anew system development. The tailoring process starts with products from the domain analysis. The domain analyst and the requirements analyst add, modify, or delete features from the context and scope domain to form a new system context with the participation of the user. The same occurs for the domain model to tailor a new system software specification. To the domain architecture, the domain analyst, the requirements analyst, and 8 E. OliveiraJr and D. Benavides Fig. 1.3 Feature-oriented domain analysis process and products [28] Fig. 1.4 Feature-oriented domain analysis tailoring products [28] the software engineer work on the domain architecture to produce a new system software architecture. These three tailored artifacts are then verified by the domain expert and the domain analyst to produce a new product. 1 Principles of Software Product Lines 9 1.3.1.2 RSEB: Reuse-Driven Software Engineering Business (1997) The Reuse-Driven Software Engineering Business (RSEB) [25] is a use case-driven systematic reuse process. It was created in 1997 as a single-system develop and reuse process. In 1998, Griss et al. [19] integrated the feature modeling technique from FODA to RSEB to provide a high-level view of the domain architecture and reusable assets. Therefore, users are provided with a more concise and expressive picture of the way to build systems in the application family (SPL). Different sources are used to build a feature model, such as system exemplars, early domain models, and requirements. These sources aid at establishing domain scoping and context modeling, and the expected feature model. 1.3.1.3 FORM: Feature-Oriented Reuse Method for Product Line Software Engineering (1998) The Feature-Oriented Reuse Method (FORM) [29] is a systematic method focused on identifying commonalities and differences of several applications from a given domain in terms of features to develop domain architectures and components. Commonalities and differences are identified in a “feature model” to support both engineering of reusable domain artifacts and development of applications using the domain artifacts. As a domain is described in terms of common and different units of computation, they are used to build different configurations of reusable architectures. Figure 1.5 depicts the FORM engineering processes [29]. FORM is composed of two engineering processes: domain engineering and application engineering. Domain engineering consists of activities for analyzing systems and creating architectures and reusable components. The architectures and reusable accommodate the differences and commonalities of the systems in the domain. Application engineering consists of activities for developing applications using the artifacts. For typical applications in a given domain, such process should be trivial compared to the traditional application development approach as it provides built pieces implemented and tested, ready to be reused. As one can see, FORM is based on the principles of the FODA method to deliver software stakeholders an organized set of processes to develop and reuse domain analysis artifacts into a single-software tailored by means of the application engineering process. 1.3.1.4 FAST: Family-Oriented Abstraction, Specification, and Translation (1999) Family-Oriented Abstraction, Specification, and Translation (FAST) [48]isa development process for producing software in a family-oriented flavor. It separates 10 E. OliveiraJr and D. Benavides Fig. 1.5 FORM engineering processes [29] software product line engineering process into one step to provide the core and another one to produce different software products from such a family. FAST adopts software product line architecture principles into a software engineering process. A common platform is specified to a family of software products. Such a platform is established with similarities between several products as a basis. Variabilities among product family members are implemented with different variation techniques such as parameterization or conditional compilation. The domain engineering step creates abstractions in the family-oriented perspective, which are used to create the design of the family to define standard libraries for prospective implementations. The abstractions are the basis for modeling specific applications, which are materialized by the composition of common implementations from the domain engineering and tailored components to such specific family members. 1.3.1.5 PuLSE: Fraunhofer Product Line Software Engineering (1999) The Product Line Software Engineering (PuLSE) [7] methodology aims at conceiving and deploying software product lines in a large variety of enterprise contexts, which is allowed via a straightforward product-centric focus throughout the phases of PuLSE. Such phase aims at customization of components, incremental capability, and maturity scaling for evolution. 1 Principles of Software Product Lines 11 The deployment phases describe the activities performed to set up and use a given product line, which are [7] initialization, baselines, and customized PuLSE as a result; infrastructure construction to scope, model, and architect the product line infrastructure; infrastructure usage to create product line members; and evolution and management to evolve the infrastructure over time. The technical components are [7]: customizing to perform the initialization phase, scoping to effectively scope the infrastructure to define products, modeling to specify the product characteristics, architecting to develop the reference architecture and maintain the traceability to the model, instantiating to perform the usage phase, and evolving and managing to deal with configuration management issues as products accrue over time. The support components are [7] project entry points to customized PuLSE to major project types, maturity scale to provide integration and evolution to enterprises using PuLSE, and organization issues to provide guidelines to set up and maintain the right organization structure for developing and managing product lines. 1.3.1.6 KobrA: Komponenten basierte Anwendungsentwicklung (2000) The KobrA method [4,5] gathers up different software engineering processes, including software product line development, component-based software development, frameworks, architecture-centric inspections, quality modeling, and process modeling. Thus, KobrA’s goal is to provide a systematic approach to the development of high-quality, component-based application frameworks in a prescriptive way mainly based on UML. In the perspective of product lines, KobrA is an object-oriented customization of the PuLSE method by taking advantages of the UML notation. The infrastructure construction phase of PuLSE corresponds to KobrA’s framework engineering activity, the infrastructure usage phase of PuLSE corresponds to KobrA’s application engineering activity, and the product line evolution phase of PuLSE corresponds to the maintenance of the frameworks and applications. Figure 1.6 depicts the overall KobrA activities 1.3.1.7 SEI Framework for Software Product Line Practice (2002) The framework for software product line practice (PLP) [46] was created by the Software Engineering Institute (SEI) in 20021to describe essential activities and practices (technical and organizational) to benefit from fielding a product line of software or software-intensive systems. 1First version of the framework https://resources.sei.cmu.edu/library/asset-view.cfm?assetid= 495357. 18 E. OliveiraJr and D. Benavides process, such as the SEI PLP’s (Sect. 1.3.1.7): Organizational Management and Technical Management. Käkölä [26] provides several points in favor of such ISO/IEC for de facto standards to be adopted in industry especially because of the need for high levels of abstraction, the need to cope with high levels of complexity, the fragmented body of knowledge, and the lack of tools. Käkölä [27] lists several benefits from the ISO/IEC SPL engineering series, such as they enable its users to holistically understand, adopt, and enact the domain and application engineering life cycles; enable its users to evaluate and select relevant methods and tools based on business and user-related criteria; help development teams specify, verify, and validate engineering and management practices for existing or envisioned product lines based on the product line practices described in the standard; provide a reference model for software product line engineering and management, that is, an abstract representation of the domain and application engineering life cycles and enabling core asset management, organizational management, and technical management processes that will be detailed in the other software product line standards; and help tool vendors develop interoperable tool suites and features supporting the domain and application engineering life cycles and their phases and communicate about their tools to the markets. 1.4 SPL Development Approaches The development of SPLs from a set of systems point of view takes important steps mainly toward domain and application engineering activities. Such activities must be well established, managed, and controlled as they will provide all support for gathering, for instance, SPL requirements, production plan, core asset development and reuse, estimation, and evolution. From this perspective, SPL stakeholders must provide a way to perform all these activities, with minimal costs and time to market, as well as maximum production and mass customization of products, justifying return on investment. The following main approaches play an essential role at SPL development. 1.4.1 The Proactive Approach When SPL stakeholders firstly conventionally analyze, architect, design, and implement all potential specific products on the foreseeable horizon up front, they are developing SPL in a proactive manner [10]. Such approach might be useful and valuable for companies which best known their products requirements and afford a waterfall-like SPL development life cycle. 1 Principles of Software Product Lines 19 Product 1 Product 2 Product 3 Automaton GEARS Production Line Declarations Definitions Actuator Domain Analysis Architecture Design Proactive Implementation Fig. 1.12 Proactive development of GEARS SPL [32] Krüeger [32] claims the proactive approach, illustrated in Fig. 1.12, is similar to the waterfall approach for single systems. The proactive approach requires considerably more effort up front, but this drops sharply once the SPL is complete. To perform tasks of the proactive approach, one must [32,36,45]: •Perform domain analysis and scoping to identify the variation to be supported in the SPL. •Model the SPL architecture to support all products. •Design the common and variant parts of the system. •Implement the common and variant parts of the system. 20 E. OliveiraJr and D. Benavides Once the SPL is developed, one must create the specific products (instances). If more products are needed, they are developed from the existing scope. Therefore, maintenance and evolution are performed directly on the single production line. The literature provides several successful examples on adopting the proactive approach [6,16,17,22,42]. 1.4.2 The Extractive Approach Krüger [32] explains the extractive approach reuses one or more existing software products as the SPL’s initial baseline. To be an effective choice, the extractive approach requires lightweight SPL technology and techniques that can reuse existing software without much reengineering. This approach is very effective for an organization that wants to quickly transition from conventional to software product line engineering. The extractive approach to software mass customization, illustrated in Fig. 1.13, is appropriate when an existing collection of customized systems can be reused. It is not necessary to perform the extraction from all of the preexisting systems at once. Product 1 Product 2 Product 3 Product 1 Product 2 Product 3 Extract Automaton GEARS Production Line Declarations Definitions Actuator Fig. 1.13 Extractive development of GEARS SPL [32] 1 Principles of Software Product Lines 21 To perform the extractive approach tasks, one must [32,36,45]: •Identify commonality and variation in the existing systems. •Create a single copy of the common software. •Create feature declarations that model the scope of variation among the existing systems. •Encapsulate variation points into automata. •Program the automata logic to map declaration parameter values to variant selections in the automata. •Create the product definitions for the desired product instances by selecting values for each of the feature definition parameters. After the SPL has been populated, product instances are created. Software mass customization now becomes the mode of operation as focus shifts to maintaining and enhancing the single production line. Literature examples of this approach are [3,33,35,40,49] 1.4.3 The Reactive Approach The reactive approach is similar to the spiral or extreme programming approach to single-software solutions. One must analyze, architect, design, and implement one or several product variations on each development spiral [32]. This approach works in situations where one cannot predict the requirements for product variations. Figure 1.14 depicts an example of the reactive approach. It is incremental and appropriate when the requirements for new products in the SPL are unpredictable. The reactive approach allows for rapid adoption of mass customization since a minimum number of products must be incorporated in advance. To perform the reactive approach tasks, one must [32,36,45]: •Characterize the requirements for the new product relative to what is currently supported in the SPL. •Analyze whether the new product is currently within the scope of the current SPL. If not, perform the “delta engineering” to the SPL on any or all of the declarations, automata, common software, and definitions. •Create the product definition for the new product by selecting values for each of the feature declaration parameters. Literature has also several examples on the reactive approach adoption as [9,12, 20,39]. 22 E. OliveiraJr and D. Benavides Product 1 Product 2 Product 3 React Automaton GEARS Production Line Declarations Definitions Actuator Product 1 Product 2 Product 3 Automaton GEARS Production Line Declarations Definitions Actuator Requirements for a new product instance, Product 4 + Product 4 Iterate Fig. 1.14 Reactive development of GEARS SPL [32] 1.4.4 Feature-Oriented SPL Development Feature-oriented software development (FOSD) aims at constructing, customizing, and synthesizing large-scale and variable software systems, taking into account their structures, reuse, and variations [1,30]. The basic goal of FOSD is decomposing a software system in terms of its features. According Kang et al. [28], feature is “a prominent or distinctive uservisible aspect, quality, or characteristic of a software system or systems.” In the perspective of SPLs, a feature is defined by Apel and Kastner [2]as“a characteristic or end-user-visible behavior of a software system,” and they are used 1 Principles of Software Product Lines 23 Fig. 1.15 Apel and Kastner’s feature-oriented engineering process for SPLs [2] in “SPLs to specify and communicate commonalities and differences of the products between stakeholders, and to guide structure, reuse, and variation across all phases of the software life cycle.” Figure 1.15 depicts Apel and Kastner’s feature-oriented engineering process for SPLs. This approach is composed of two main processes, as well as traditional methodologies, such as domain engineering and application engineering. The main difference from this approach to the other ones is that all SPL development process is oriented to features, in the problem space, which are mapped to models, source codes, and other artifacts in the solution space of the domain engineering process. Once variabilities are represented in features and other artifacts, requirement analysis and product derivation are performed to configure (selection of features) and derive a specific SPL product in the application engineering process. 1.5 Final Remarks In this chapter we presented concepts on software product lines which are essential to provide the reader a background to understand the rest of this book. As SPL is an extensive subject, which encompasses other methodologies and approaches, in this book we focus our discussion on UML-based SPLs, which are perfectly understandable with the presented concepts. Potential related concepts are presented in respective chapters to avoid overlapping the ones already discussed, such as SPL variability and SPL architectures (PLA). 24 E. OliveiraJr and D. Benavides Acknowledgments Prof. David would like to thank the Project (RTI2018-101204-B-C22, OPHELIA), funded by FEDER/Ministry of Science and Innovation – State Research Agency; and the Junta de Andalucia COPERNICA (P20_01224) and METAMORFOSIS (FEDER_US-1381375) projects. References 1. Apel, S., Kästner, C.: An overview of feature-oriented software development. J. Object Technol. 8(5), 49–84 (2009) 2. Apel, S., Batory, D., Kstner, C., Saake, G.: Feature-Oriented Software Product Lines: Concepts and Implementation. Springer Publishing Company, New York (2013) 3. Assunção, W.K., Lopez-Herrejon, R.E., Linsbauer, L., Vergilio, S.R., Egyed, A.: Reengineering legacy applications into software product lines: a systematic mapping. Empir. Softw. Eng. 22(6), 2972–3016 (2017). https://doi.org/10.1007/s10664-017-9499-z 4. Atkinson, C., Bayer, J., Muthig, D.: Component-based product line development: the kobra approach. In: Proceedings of the First Software Product Lines Conference SPLC, pp. 289– 309. Springer, New York (2000) 5. Atkinson, C., Bayer, J., Bunse, C., Kamsties, E., Laitenberger, O., Laqua, R., Muthig, D., Paech, B., Wüst, J., Zettel, J.: Component-Based Product Line Engineering with UML. Addison-Wesley Longman Publishing Co. Inc., Boston (2002) 6. Ayala, I., Papadopoulos, A.V., Amor, M., Fuentes, L.: Prodspl: Proactive self-adaptation based on dynamic software product lines. J. Syst. Softw. 175, 110,909 (2021). https://doi.org/10. 1016/j.jss.2021.110909 7. Bayer, J., Flege, O., Knauber, P., Laqua, R., Muthig, D., Schmid, K., Widen, T., DeBaud, J.M.: Pulse: a methodology to develop software product lines. In: Proceedings of the 1999 Symposium on Software Reusability, SSR ’99, pp. 122–131. ACM, New York (1999). https:// doi.org/10.1145/303008.303063 8. Bjørner, D.: Domain engineering: a software engineering discipline in need of research. In: Hlavᡠc, V., Jeffery, K.G., Wiedermann, J. (eds.) SOFSEM 2000: Theory and Practice of Informatics, pp. 1–17. Springer, Berlin (2000) 9. Buhrdorf, R., Churchett, D., Krüeger, C.: Salion’s experience with a reactive software product line approach. In: 5th International Workshop on Software Product-Family Engineering (PFE), pp. 317–322 (2003) 10. Clements, P.: Being proactive pays off. IEEE Softw. 19(4), 28 (2002). https://doi.org/10.1109/ MS.2002.1020283 11. Clements, P., Northrop, L.M.: Software Product Lines: Practices and Patterns. SEI Series in Software Engineering. Addison-Wesley, Boston (2002) 12. Clements, P.C., Jones, L.G., Northrop, L.M., McGregor, J.D.: Project management in a software product line organization. IEEE Softw. 22(5), 54–62 (2005). https://doi.org/10.1109/ MS.2005.133 13. Clements, P., Gregg, S., Krüeger, C., Lanman, J., Rivera, J., Scharadin, R., Shepherd, J., Winkler, A.: Second generation product line engineering takes hold in the dod. Crosstalk J. Def. Softw. Eng., 12–18 (2014) 14. Czarnecki, K.: Generative programming: Methods, techniques, and applications tutorial abstract. In: Gacek, C. (ed.) Software Reuse: Methods, Techniques, and Tools, pp. 351–352. Springer, Berlin (2002) 15. Dabhade, M., Suryawanshi, S., Manjula, R.: A systematic review of software reuse using domain engineering paradigms. In: 2016 Online International Conference on Green Engineering and Technologies (IC-GET), pp. 1–6 (2016). https://doi.org/10.1109/GET.2016.7916646 16. FalvoJr, V., Filho, N.F.D., OliveiraJr, E., Barbosa, E.F.: A contribution to the adoption of software product lines in the development of mobile learning applications. In: Proceedings 1 Principles of Software Product Lines 25 of the 2014 IEEE Frontiers in Education Conference (FIE), pp. 1–8 (2014). https://doi.org/10. 1109/FIE.2014.7044091 17. FalvoJr, V., Filho, N.F.D., OliveiraJr, E., Barbosa, E.F.: Towards the establishment of a software product line for mobile learning applications. In: International Conference on Software Engineering and Knowledge Engineering, pp. 678–683 (2014) 18. Gomaa, H.: Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures. Addison Wesley Longman Publishing Co. Inc., (2004) 19. Griss, M.L., Favaro, J., Alessandro, M.d.: Integrating feature modeling with the RSEB. In: Proceedings of the 5th International Conference on Software Reuse, ICSR ’98, p. 76. IEEE Computer Society, Washington (1998) 20. Heider, W., Grünbacher, P., Rabiser, R.: Negotiation constellations in reactive product line evolution. In: 2010 Fourth International Workshop on Software Product Management, pp. 63– 66 (2010). https://doi.org/10.1109/IWSPM.2010.5623862 21. Hobsbawm, E.: The Age of Revolution: Europe 1789–1848, 1 edn. Weidenfeld & Nicolson Ltd., London (1996) 22. Horcas, J.M., Pinto, M., Fuentes, L.: Software product line engineering: a practical experience. In: Proceedings of the 23rd International Systems and Software Product Line Conference, SPLC ’19, vol. A, pp. 164–176. Association for Computing Machinery, New York (2019). https://doi.org/10.1145/3336294.3336304 23. ISO/IEC: ISO/IEC/IEEE 24765:2010 – Systems and software engineering: vocabulary. https:// www.iso.org/standard/50518.html 24. ISO/IEC: ISO/IEC 26550:2015 – Software and systems engineering: reference model for product line engineering and management. https://www.iso.org/standard/69529.html 25. Jacobson, I., Griss, M., Jonsson, P.: Software Reuse: Architecture, Process and Organization for Business Success. ACM Press/Addison-Wesley Publishing Co., New York (1997) 26. Käkölä, T.K.: Standards initiatives for software product line engineering and management within the international organization for standardization. In: Hawaii International Conference on System Sciences, pp. 1–10 (2010). https://doi.org/10.1109/HICSS.2010.348 27. Käkölä, T.K.: ISO initiatives on software product line engineering: vision and current status invited talk for variability. In: De Troyer, O., Bauzer Medeiros, C., Billen, R., Hallot, P., Simitsis, A., Van Mingroot, H. (eds.) Advances in Conceptual Modeling. Recent Developments and New Directions, pp. 119–119. Springer, Berlin (2011) 28. Kang, K., Cohen, S., Hess, J., Novak, W., Peterson, A.: Feature-oriented domain analysis (FODA) feasibility study. Technical Report. CMU/SEI-90-TR-021, Software Engineering Institute, Carnegie Mellon University, Pittsburgh (1990). http://resources.sei.cmu.edu/library/ asset-view.cfm?AssetID=11231 29. Kang, K.C., Kim, S., Lee, J., Kim, K., Shin, E., Huh, M.: Form: a feature-oriented reuse method with domain-specific reference architectures. Ann. Softw. Eng. 5(1), 143 (1998). https://doi. org/10.1023/A:1018980625587 30. Kästner, C., Apel, S., Ostermann, K.: The road to feature modularity? In: International Workshop on Feature-Oriented Software Development (FOSD), pp. 1–8. ACM Press, New York (2011). https://doi.org/10.1145/2019136.2019142 31. Kotha, S.: From mass production to mass customization: the case of the national industrial bicycle company of Japan. Eur. Manag. J. 14(5), 442–450 (1996). https://doi.org/10.1016/ 0263-2373(96)00037-0 32. Krüeger, C.W.: Easing the transition to software mass customization. In: van der Linden, F. (ed.) Software Product-Family Engineering, pp. 282–293. Springer, Berlin (2002) 33. Krüger, J., Berger, T.: An empirical analysis of the costs of clone- and platform-oriented software reuse. In: Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE 2020, pp. 432–444. Association for Computing Machinery, New York (2020). https://doi.org/10. 1145/3368089.3409684 26 E. OliveiraJr and D. Benavides 34. Krüeger, C.W., Clements, P.C.: Second generation systems and software product line engineering. In: Proceedings of the 19th International Conference on Software Product Line, SPLC ’15, pp. 388–389. Association for Computing Machinery, New York (2015). https://doi.org/10. 1145/2791060.2798047 35. Krüger, J., Mahmood, W., Berger, T.: Promote-pl: a round-trip engineering process model for adopting and evolving product lines. In: Proceedings of the 24th ACM Conference on Systems and Software Product Line, SPLC ’20, vol. A. Association for Computing Machinery, New York (2020). https://doi.org/10.1145/3382025.3414970 36. Linden, F.J.v.d., Schmid, K., Rommes, E.: Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering. Springer, Berlin (2007) 37. Lisboa, L.B., Garcia, V.C., Lucrédio, D., de Almeida, E.S., de Lemos Meira, S.R., de Mattos Fortes, R.P.: A systematic review of domain analysis tools. Inf. Softw. Technol. 52(1), 1–13 (2010). https://doi.org/10.1016/j.infsof.2009.05.001 38. Lucas Robert E., J.: Lectures on Economic Growth, 1 edn. Harvard University Press, Cambridge (2002) 39. Neves, G.S., Vilain, P.: Reactive variability realization with test driven development and refactoring. In: The 26th International Conference on Software Engineering and Knowledge Engineering, pp. 100–105 (2014) 40. Niu, N., Easterbrook, S.: Extracting and modeling product line functional requirements. In: 2008 16th IEEE International Requirements Engineering Conference, pp. 155–164 (2008). https://doi.org/10.1109/RE.2008.49 41. Northrop, L.M.: Sei’s software product line tenets. IEEE Softw. 19(4), 32–40 (2002). https:// doi.org/10.1109/MS.2002.1020285 42. Oizumi, W.N., Contieri Junior, A.C., Correia, G.G., Colanzi, T.E., Ferrari, S., Gimenes, I.M.S., OliveiraJr, E., Garcia, A.F., Masiero, P.C.: On the proactive design of product-line architectures with aspects: an exploratory study. In: 2012 IEEE 36th Annual Computer Software and Applications Conference, pp. 273–278 (2012). https://doi.org/10.1109/COMPSAC.2012.38 43. OliveiraJr, E., Gimenes, I.M.S., Huzita, E.H.M., Maldonado, J.C.: A variability management process for software product lines. In: Proceedings of the 2005 Conference of the Centre for Advanced Studies on Collaborative Research, CASCON ’05, pp. 225–241. IBM Press, Indianapolis (2005) 44. OliveiraJr, E., Gimenes, I.M.S., Maldonado, J.C.: Systematic management of variability in UML-based software product lines. J. Univ. Comput. Sci. 16(17), 2374–2393 (2010) 45. Pohl, K., Böckle, G., Linden, F.J.v.d.: Software Product Line Engineering: Foundations, Principles and Techniques. Springer, Berlin (2005) 46. SEI: Software Engineering Institute – Framework for Software Product Line Practice, Version 5.0. https://resources.sei.cmu.edu/asset_files/WhitePaper/2012_019_001_495381.pdf 47. WebArchive: Ford’s assembly line turns 100: how it changed manufacturing and society. https://web.archive.org/web/20131130021237/http://www.nydailynews.com/autos/fordassembly-line-turns-100-changed-society-article-1.1478331 48. Weiss, D.M., Lai, C.T.R.: Software Product-Line Engineering: A Family-Based Software Development Process. Addison-Wesley Longman Publishing Co. Inc., Boston (1999) 49. Wille, D., Runge, T., Seidl, C., Schulze, S.: Extractive software product line engineering using model-based delta module generation. In: Proceedings of the Eleventh International Workshop on Variability Modelling of Software-Intensive Systems, VAMOS ’17, pp. 36–43. ACM, New York (2017). https://doi.org/10.1145/3023956.3023957