Adapting to the rapid changes in our increasingly. Building Dynamic Software Product Lines

Transcription

1 Guest Editors Introduction Building Dynamic Software Product Lines Mike Hinchey, Lero the Irish Software Engineering Research Centre, University of Limerick, Ireland Sooyong Park, Sogang University, South Korea Klaus Schmid, University of Hildesheim, Germany Dynamic software product lines extend existing product line engineering approaches by moving their capabilities to runtime, helping to ensure that system adaptations lead to desirable properties. Adapting to the rapid changes in our increasingly complex world presents challenges for software as well as for people. Systems must have the ability to run continuously under adverse conditions such as harsh environments, partial subsystem failures, and changing user needs. Often, they must run unattended without interruption. Telecommunication systems and space systems are only rather extreme examples of this trend. More mundane applications such as smartphones also need to adapt their overall system behavior to energy levels and varying quality in network connection. The need to cope with these challenges has led to the development of many different approaches for adapting to changing needs, including self-adapting, agent-based, autonomous, emergent, and bio-inspired systems. While these approaches share a fundamental theme flexible adaptation of software to changing needs they also exhibit significant differences in terms of the range of adaptations they support, as well as the guarantees that can be expected for the various adapted systems. A more recent addition to these approaches is dynamic software product lines. 1 DSPLs extend existing product line engineering approaches by moving their capabilities to runtime. Due to their product line heritage, DSPLs have solid (and practicably) proven engineering foundations, which have been tested in numerous applications. This is significant from an engineering perspective because it underlines the need to ensure that system adaptations lead to desirable properties. So far, DSPLs have been used in a wide range of application areas, including household robotics, information systems, surveillance systems, and industrial automation ( DSPL OR NOT? A DSPL is best characterized by how it differs from the product line concept. Product line engineering, a well-known and widely used technology in industry ( is fundamentally a reuse-oriented approach that aims to develop assets that can be reused successfully across a range of products, the software product line (SPL). 2,3 A fundamental step is to change the perspective from viewing one product at a time to viewing the product line as a whole. This requires a set of innovations, including the following: Variability modeling. A core principle is variability modeling, which explicitly describes the differences among the systems in a product line. This description includes basic incompatibilities certain system characteristics cannot be present simultaneously. Typical approaches for variability modeling are feature models or decision models. 4 Reference architecture. A reference architecture is more than a standard software architecture because it provides explicit customizations that cover 22 computer Published by the IEEE Computer Society /12/$ IEEE

2 Table 1. Relationship between SPLs and DSPLs. Classic software product lines Variability management describes different possible systems. Dynamic software product lines Variability management describes different adaptations of the system. Reference architecture provides a common framework for a set of individual product architectures. DSPL architecture is a single system architecture, which provides a basis for all possible adaptations of the system. Business scoping identifies the common market for the set of products. Adaptability scoping identifies the range of adaptation the DSPL supports. Two-life-cycle approach describes two engineering life cycles, one for domain engineering and one for application engineering. Two life cycles: the DSPL engineering life cycle aims at systematic development of the adaptive system, and the usage life cycle exploits adaptability in use. the entire product line, it supports the variations described by the variability model. Business scoping. Product line design requires understanding that the architecture addresses an entire domain or business field, not just a single customer or project. Two life cycles. A conceptual distinction is made between the development of capabilities for reuse, which must be generic and easily composable to several different systems, and development with reuse, which aims to create products from the assets created in the for-reuse life cycle. Today s successful industrial product lines invariably apply most, if not all, of these principles in practice. These principles cover a broad range of typical engineering activities, including modeling, technology, process development, and planning. The key idea of product line engineering is to use the common reference architecture to develop a welldesigned set of assets that fit together as described by the variability model. Thus, in domain engineering, the variability model takes a leading role by describing the potential range of variations; in application engineering, it provides a basis for selecting the intended product s specific characteristics. The reference architecture ensures that all selectable combinations actually correspond to correctly working products. This also provides the mechanisms for adequately composing the various parts at different times during development, distribution, and use of the systems the so-called binding time. While this information explains what an SPL is, it does not describe what a DSPL is. Is a DSPL just a specific form of an SPL? Not quite. A key observation is that in an SPL, the binding time typically is before runtime. During compile time, link time, or perhaps even load time, different modules tailored to specific needs are loaded to compose the system. Runtime variability The key question is whether we can use the same kinds of concepts and just move the binding time to runtime. Can we perhaps even bind and rebind variability at runtime? These ideas lead directly to the DSPL concept. In this case, we are not necessarily dealing with an entire product line in the traditional sense, but we might perceive the DSPL to be a single system, adapting its behavior when variability is rebound during operation. 5 This simple transition from a product line resulting in many different systems where variability is bound at development time to a system that adapts by binding variability at runtime has several repercussions. Variability is suddenly not simply an engineering artifact that is no longer present at runtime. Because the variability model is the core artifact for guiding system adaptation, the DSPL must be able to consult in one form or another the runtime variability model to identify adaptations. A reference architecture is a common framework in an SPL, but the software architecture only supports some parts of it the selected variability. In a DSPL, this becomes the architecture, which essentially is a system architecture that provides explicit and deterministic support for the entire range of adaptation. What is called business scoping in an SPL also has a correspondence in a DSPL, although it is more indirect: we need to identify the DSPL s range of potential adaptations, referred to as adaptability scoping. This typically means identifying potential contexts and triggers for adaptation as well as the set of potential reactions the system will support. Even for the two-life-cycle approach, we can identify a correspondence: the domain engineering life cycle, where the focus on all possible variations corresponds to system construction in a DSPL, while the application engineering is no longer a typical engineering life cycle, but rather corresponds to system use. So, in part, the system itself performs the configuration. Table 1 summarizes this relationship. OCTOBER

3 Guest Editors Introduction Core DSPL principles Is a DSPL also an SPL? The answer depends. Of course, a DSPL can also be built as an SPL. Some approaches support the combination of variabilities with different runtime and development binding time within a single infrastructure. Other approaches even support different binding times for the same variability. 6 Thus, the border between a DSPL and a traditional SPL can range from narrow to nonexistent. However, there is no need for a DSPL to lead to multiple identifiable, distinct systems at development time. What are the core DSPL principles? As in any maturing field, there is not yet a final agreement, but it seems the following principles are currently widely accepted. A DSPL A DSPL s strength is the systematic engineering foundations that it can bring to adaptive and self-adaptive systems, thus leading to higher reliability and predictability for these systems. contains an explicit representation of the configuration space and constraints that describe permissible runtime reconfigurations on the level of intended capabilities of the system (as opposed to a technical level). This is a variability model in the sense that discrete options are identified (as opposed to continuous models). This differentiates a DSPL clearly from several other adaptation approaches. can perform the necessary system reconfiguration autonomously. Thus, once the intended configuration is known, the derivation of different system instances must be autonomous. Environmental monitoring and subsequent identification of a desired configuration are not explicitly necessary to qualify as a DSPL. is developed based on an engineering process that explicitly takes the variability scope into account. Thus, DSPL engineers can exploit classic SPL engineering principles and approaches. What is not required for a system to qualify as a DSPL? It need not be built as part of an SPL. This may seem puzzling at first, but it simply means the entire variability can be managed at runtime. Its variability model at least implicitly predefines its adaptation space. Because variability models are discrete models, any problem requiring some form of analogous or continuous modeling is not appropriate for them. A purely parameterized adaptation is not considered a DSPL; rather, a modification of the actually executing system implementation is required. Ideally, the architectural components are reconfigured. It does not need to be self-adapting. It is completely valid for a human to make a decision on the abstract level to perform a reconfiguration. However, the DSPL must manage all aspects of realizing this reconfiguration at runtime, without human intervention. While autonomous behavior is not required for a DSPL, most DSPLs actually aim at closing the control loop by also addressing monitoring and decision making. Thus, while developers often use DSPLs as a systematic engineering approach to realize self-adaptive systems, this need not be so. Some DSPLs are not self-adaptive systems, and some self-adaptive systems are not DSPLs. DSPLs AS ADAPTIVE SYSTEMS While not necessarily adaptive systems, DSPLs are often considered to be a systematic engineering approach for realizing adaptive systems. 7 It thus makes sense to compare DSPLs with other approaches for developing adaptive systems. A study comparing several existing DSPL realizations to the MAPE-K cycle showed that some of them successfully realize this model. 8 Consequently, some DSPLs also qualify as being autonomous systems. However, they usually will not qualify as emergent systems, as the basic approach underlying adaptivity in a DSPL is the systematic engineering of adaptation options (variability). Thus, DSPLs operate in a predefined (even though potentially infinite) configuration space. A DSPL s strength is the systematic engineering foundations that it can bring to adaptive and self-adaptive systems, thus leading to higher reliability and predictability for these systems. An important problem is a DSPL s evolution. 9 From the DSPL perspective, of course, evolution at runtime by extensions to the variability model or variability implementations would be ideal. However, approaches that actively extend the DSPL s range of applicability at runtime have seldom been addressed thus far. As a result, DSPLs also share a weakness with more traditionally engineered systems: their evolution capabilities. If a modification beyond the initially provided configuration space is needed, the system implementation itself must be modified. However, using a DSPL approach can make this easier: it is possible to integrate further adaptation capabilities by exploiting the variability model and augmenting it referred to as open variability. RESEARCH ISSUES As an evolving field, DSPL research still faces many open issues, 6 including the following: 24 computer

4 Thus far, little support exists for DSPL evolution. Successful evolution requires approaches that explicitly exploit and leverage DSPL characteristics, which could include automated (learning-based) evolution. Although approaches to the implementation of development-time configuration are well-understood, DSPL approaches for runtime reconfiguration remain an important research area, especially with respect to their relation to the overall system architecture. While the core variability model focuses on modeling the reconfiguration options, ongoing DSPL research attempts to enlarge these approaches to capture context description and decision making. Similar to classic product line engineering, DSPL reconfiguration has focused mainly on functional capabilities, while addressing quality characteristics to only a limited extent. Dealing with overly constrained situations at runtime remains a concern. For example, although several available capabilities might be required simultaneously, the variability model defines them as mutually exclusive. An additional concern is how to best extend variability modeling so that developers can use it as a basis for context interpretation and thus support the fully autonomous case. The articles in this issue already aim at addressing some of these challenges. Future DSPL research will certainly provide solutions for many, if not all, unresolved concerns. IN THIS ISSUE The cover features in this special issue illustrate the topic of DSPLs from a wide range of perspectives. In Dynamic Variability in Software-Intensive Embedded System Families, Jan Bosch and Rafael Capilla discuss current industry trends and needs and explain why they lead to a general demand for more DSPLs in practice. They also provide a categorization of different types of variability that can occur in a DSPL. A View of the Dynamic Software Product Line Landscape by Nelly Bencomo, Svein Hallsteinsen, and Eduardo Santana de Almeida provides a different characterization of DSPLs. The authors offer an overview of the existing DSPL landscape based on a study of the existing literature in this area. In particular, they map this work in terms of types of contributions and their maturity. An important theme is the convergence between DSPL approaches and other approaches targeted to more dynamic systems. Two of the contributions in this special issue focus explicitly on combining work in serviceoriented computing with product line engineering and DSPL research. Service-Oriented Dynamic Software Product Lines by Luciano Baresi, Sam Guinea, and Liliana Pasquale focuses on dynamic adaptations of workflows, for which they define the DyBPEL extension to the Business Process Execution Language. The authors combine this with a variability model based on the Common Variability Language and use it to manage workflow variability in serviceoriented systems at runtime. In Engineering Service-Based Dynamic Software Product Lines, Jaejoon Lee, Gerald Kotonya, and Daniel Robinson provide a closer look at the autonomic computing vision, specifically with regard to performing reconfiguration autonomously based on available services, with a focus on the provided quality of service. Interesting in this case is that services can be added or removed from the context at runtime, and the system dynamically takes this into account. Finally, Using Constraint Programming to Manage Configurations in Self-Adaptive Systems by Pete Sawyer and colleagues suggests taking an unusual route toward the realization of a DSPL. While most work focuses on typical variability models, such as feature models, these authors use a goal model based on KAOS to describe the configuration space. Using a wireless sensor network example to illustrate their approach, they also focus on autonomous reconfiguration, where they use a constraint solver to identify the optimal configuration. While the selected contributions to this special issue provide a broad overview of current work on DSPLs, the picture is by no means complete or exhaustive. As dynamically adaptive systems become increasingly important, the community will focus on using approaches such as DSPL that aim at incorporating an engineering basis into their construction. Acknowledgments This work was supported, in part, by Science Foundation Ireland grant 10/CE/I1855 to Lero the Irish Software Engineering Research Centre ( Sooyong Park s research was partly supported by the Next-Generation Information Computing Development Program through the NRF, funded by MEST 2012M3C4A Klaus Schmid s research was partly supported by the EU-project INDENICA. References 1. S. Hallsteinsen et al., Dynamic Software Product Lines, Computer, Apr. 2008, pp P. Clements and L. Northrop, Software Product Lines, Addison-Wesley, F. van der Linden, K. Schmid, and E. Rommes, Software Product Lines in Action The Best Industrial Practice in Product Line Engineering, Springer, OCTOBER

5 G u e s t Edito rs In t rodu c t io n 4. K. Czarnecki et al., Cool Features and Tough Decisions: A Comparison of Variability Modeling Approaches, Proc. 6th Workshop on Variability Modeling of Software-Intensive Systems (VaMoS 12), ACM, 2012, pp J. Peña et al., Designing and Managing Evolving Systems Using a MAS Product Line Approach, Science of Computer Programming, Apr. 2007, pp K. Schmid and H. Eichelberger. Model-Based Implementation of Meta-Variability Constructs: A Case Study Using Aspects, 2008; research/research_reports/icb_report_22.pdf. 7. A. Classen et al., Modelling Variability in Self-Adaptive Systems: Towards a Research Agenda, 2008; kuleuven.be/bitstream/ /203421/1/mcgple08. pdf. 8. N. Bencomo, J. Lee, and S. Hallsteinsen, How Dynamic Is Your Dynamic Software Product Line? 2010; eprints.lancs.ac.uk/34782/1/dspl-2010.pdf. 9. N. Bencomo, S. Hallsteinsen, and E. Santana de Almeida, A View of the Dynamic Software Product Lines Landscape, Computer, Oct. 2012, pp Mike Hinchey is the director of Lero the Irish Software Engineering Research Centre, and a professor of software engineering at the University of Limerick, Ireland. Contact him at mike.hinchey@lero.ie. Sooyong Park is a professor in the Department of Computer Science at Sogang University, South Korea. Contact him at sypark@sogang.ac.kr. Klaus Schmid is a professor of software engineering at the University of Hildesheim, Germany. Contact him at schmid@sse.uni-hildesheim.de. Selected CS articles and columns are available for free at ANYTIME, ANYWHERE ACCESS Interested? Go to to subscribe and see sample articles. 26 computer SEPTEMBE Easy to Save. Easy to Search. notification. Receive an alert as soon as each digital magazine is available. Two formats. Choose the enhanced PDF version OR the web browser-based version. Quick access. Download the full issue in a flash. Convenience. Read your digital magazine anytime, anywhere on your laptop, ipad, or other mobile device. Digital archives. Subscribers can access the digital issues archive dating back to January put er.org http ://w ww.com Keep up on the latest tech innovations with new digital magazines from the IEEE Computer Society. At more than 65% off regular print prices, there has never been a better time to try one. Our industry experts will keep you informed. Digital magazines are: R 2012 DIGITAL MAGAZINES 65 ection, p. lware det s, p. 72 Mobile Ma phone app for smart ent tools developm 80 s, p. interface ch ou Multit