, Lero—the Irish Software Engineering Research Centre, University of Limerick, Ireland
, Sogang University, South Korea
, University of Hildesheim, Germany
Pages: pp. 22-26
Abstract—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 ( http://dspl.lero.ie).
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 ( http://splc.net/fame.html), 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:
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 well-designed 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.
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.
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
What is not required for a system to qualify as a DSPL?
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.
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.
As an evolving field, DSPL research still faces many open issues, 6 including the following:
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.
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 service-oriented 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 service-oriented 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.
This work was supported, in part, by Science Foundation Ireland grant 10/CE/I1855 to Lero—the Irish Software Engineering Research Centre ( www.lero.ie). Sooyong Park's research was partly supported by the Next-Generation Information Computing Development Program through the NRF, funded by MEST 2012M3C4A7033348. Klaus Schmid's research was partly supported by the EU-project INDENICA.