Guest editors’ introduction
heritage, DSPLs have solid (and practicably) proven engineering foundations, which have been tested in numerous applications. This is significant from an en-gineering perspective because it underlines the need to ensure that system adaptations lead to desirable prop-erties. So far, DSPLs have been used in a wide range of application areas, including household robotics, infor-mation systems, surveillance systems, and industrial automation (http://dspl.lero.ie).
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 (http://splc.net/fame.html), is funda-mentally 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 descrip-tion includes basic incompatibilities—certain system characteristics cannot be present simultaneously. Typical approaches for variability modeling are fea-ture models or decision models.4
• Reference architecture. A reference architecture
is more than a standard software architecture— because it provides explicit customizations that cover
A
dapting 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 con-ditions 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 ad-aptation of software to changing needs—they also exhibit significant differences in terms of the range of adapta-tions 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 exist-ing product line engineerexist-ing approaches by movexist-ing their capabilities to runtime. Due to their product line
Dynamic software product lines extend
ex-isting product line engineering approaches
by moving their capabilities to runtime,
helping to ensure that system adaptations
lead to desirable properties.
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
Building Dynamic
Software Product
Lines
the entire product line, it supports the variations de-scribed by the variability model.
• Business scoping. Product line design requires
under-standing 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
be-tween the development of capabilities for reuse, which must be generic and easily composable to several dif-ferent 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 activi-ties, 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 corre-spond 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 com-pile 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 devel-opment time to a system that adapts by binding variability at runtime has several repercussions. Variability is sud-denly 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 reac-tions 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 en-gineering is no longer a typical enen-gineering life cycle, but rather corresponds to system use. So, in part, the system itself performs the configuration. Table 1 summarizes this relationship.
Classic software product lines Dynamic software product lines
Variability management describes different possible systems. Variability management describes different adaptations of the system. Reference architecture provides a common framework for a set of
indi-vidual 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.
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
• contains an explicit representation of the
configura-tion space and constraints that describe permissible runtime reconfigurations on the level of intended capabilities of the system (as opposed to a
techni-cal level). This is a variability model in the sense that discrete options are identified (as opposed to continu-ous 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
ex-plicitly 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 vari-ability can be managed at runtime.
• Its variability model at least implicitly predefines its
adaptation space. Because variability models are dis-crete 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 execut-ing 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 reconfigura-tion at runtime, without human intervenreconfigura-tion. 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 com-pare 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 engi-neering of adaptation options (variability). Thus, DSPLs operate in a predefined (even though potentially infinite) configuration space.
A DSPL’s strength is the systematic engineering foun-dations that it can bring to adaptive and self-adaptive systems, thus leading to higher reliability and predict-ability for these systems. An important problem is a DSPL’s evolution.9 From the DSPL perspective, of course, evolu-tion at runtime by extensions to the variability model or variability implementations would be ideal. However, approaches that actively extend the DSPL’s range of appli-cability at runtime have seldom been addressed thus far. As a result, DSPLs also share a weakness with more tra-ditionally engineered systems: their evolution capabilities. If a modification beyond the initially provided configura-tion space is needed, the system implementaconfigura-tion itself must be modified. However, using a DSPL approach can make this easier: it is possible to integrate further adapta-tion 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:
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.
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 con-text 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 simultane-ously, the variability model defines them as mutually exclusive.
• An additional concern is how to best extend
variabil-ity 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 cer-tainly 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 Embed-ded 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 variabil-ity that can occur in a DSPL.
“A View of the Dynamic Software Product Line Land-scape” 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 dy-namic 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.
cuses on dynamic adaptations of workflows, for which they define the DyBPEL extension to the Business Process Execution Language. The authors combine this with a vari-ability model based on the Common Varivari-ability 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 com-puting 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 Con-figurations 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 configu-ration space. Using a wireless sensor network example to illustrate their approach, they also focus on autonomous reconfiguration, where they use a constraint solver to iden-tify the optimal configuration.
W
hile 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 Ire-land 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 Comput-ing Development Program through the NRF, funded by MEST 2012M3C4A7033348. Klaus Schmid’s research was partly sup-ported by the EU-project INDENICA.
References
1. S. Hallsteinsen et al., “Dynamic Software Product Lines,” Computer, Apr. 2008, pp. 93-95.
2. P. Clements and L. Northrop, Software Product Lines, Addison-Wesley, 2002.
3. F. van der Linden, K. Schmid, and E. Rommes, Software Product Lines in Action—The Best Industrial Practice in Product Line Engineering, Springer, 2007.
Mobile Malware detection, p. 65
developMent tools f
or sMartphone apps, p. 72
Multitouch interfaces, p. 80
S E P T E M B E R 2 0 12 ht tp :/ /w w w .c om pu te r. or g
ANYTIME, ANYWHERE ACCESS
DIGITAL MAGAZINES
Keep up on the latest tech innovations with new digital maga-zines 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:
• Easy to Save. Easy to Search.
• Email notifi cation. Receive an alert as soon as each digi-tal magazine is available.
• Two formats. Choose the enhanced PDF version OR the web browser-based version.
• Quick access. Download the full issue in a fl ash. • Convenience. Read your digital magazine anytime,
any-where—on your laptop, iPad, or other mobile device. • Digital archives. Subscribers can access the digital issues
archive dating back to January 2007.
Interested? Go to www.computer.org/digitalmagazines to subscribe and see sample articles.
Guest editors’ introduction
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. 173-182.
5. J. Peña et al., “Designing and Managing Evolving Systems Using a MAS Product Line Approach,” Science of Computer Programming, Apr. 2007, pp. 71-86.
6. K. Schmid and H. Eichelberger. “Model-Based Imple-mentation of Meta-Variability Constructs: A Case Study Using Aspects,” 2008; www.icb.uni-due.de/fileadmin/ICB/ research/research_reports/icb_report_22.pdf.
7. A. Classen et al., “Modelling Variability in Self-Adaptive Systems: Towards a Research Agenda,” 2008; http://lirias. kuleuven.be/bitstream/123456789/203421/1/McGPLE08. pdf.
8. N. Bencomo, J. Lee, and S. Hallsteinsen, “How Dynamic Is Your Dynamic Software Product Line?” 2010; http:// 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 Land-scape,” Computer, Oct. 2012, pp. 36-41.
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 [email protected].
Sooyong Park is a professor in the Department of
Com-puter Science at Sogang University, South Korea. Contact him at [email protected].
Klaus Schmid is a professor of software engineering at
the University of Hildesheim, Germany. Contact him at [email protected].
Selected CS articles and columns are available for free at http://ComputingNow.computer.org.
