[Paper Review] Comparative Study of Variability Management in Software Product Lines and Runtime Adaptable Systems

Vander Alves, Daniel Schneider, Martin Becker

Fraunhofer IESE

Nelly Bencomo, Paul Grace

Lancaster University

In Third International Workshop on Variability Modeling of Software-intensive Systems (VaMoS 09),

pp. 9-17, Sevilla, Spain, January 2009. 

<Eliot> This paper presented how to combine Software Product Lines (SPL) and Runtime Adaptation (RTA) and make a synergy. This paper is presenting the motivation of my research – Applying SPL to Autonomic Management (AM) – RTA (or Dynamic Reconfiguration (DR)) is a key of AM. In this article, I summarize the paper and present how we can apply the results to our research. My comment starts with <Eliot>.

 

Abstract

SPL and RTA have traditionally been distinct research areas addressing different problems and with different communities. Despite the differences, there are also underlying commonalities with synergies that are worth investigating in both domains, potentially leading to more systematic variability support in both domains. Accordingly, this paper analyses commonality and differences of variability management between SPL and RTA and presents an initial discussion on the feasibility of integrating variability management in both areas.

SPL deals with strategic reuse of software artifacts in a specific domain so that shorter time-to-market, lower costs, and higher quality are achieved. In contrast to that, RTA aims for optimized service provisioning, guaranteed properties, and failure compensation in dynamic environments. To this end, RTA deals mostly with dynamic flexibility so that structure and behavior is changed in order to dynamically adapt to changing conditions at runtime.

In SPL, a product consists of product artifacts in a given context. A product artifact is an instance of SPL artifacts and comprises Variants, which in turn are instances of variation points after these have been resolved by the decision model when the application engineer configures this model into the product model.

Binding time refers to the time at which the decisions for a variation point are bound. Examples of binding time are pre-compilation, compilation, linking, load, or runtime.

Traditionally, SPL has been used mostly without the latter binding time. Variation points and decision models then do not persist in the generated product.

Another artifact that does not persist in the generated product is context. “Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and the application themselves”. For example, context can be language or regulations. Although context is considered during domain analysis and is used by the decision model, it is not explicitly integrated into the instantiated product.

An adaptable system is a system that can be changed at runtime to better meet users’ needs.

An adaptive system is a system that changes by itself at runtime.

A Reference Architecture addresses specific solution Domains, such as routing algorithms, networking technologies, and service discovery. The Reference Architecture is specified by the Domain Engineer. Different component configurations can result in different connection topologies (compositions) as well as in different “internal” behavior (parameters). Dynamic adaptation is achieved via transitions between Component Configuration variations over time; for example, components being added, removed and replaced, as the system adapts based upon environmental context changes.

A transition starts in a previous system variant and ends in a next variant. Transitions occur due to Triggers. Triggers are specified by the Application Engineer in terms of conditions of environment and context.

-          Rule-based approaches usually have the “Event-Condition-Action” (ECA) form and hence distinctly specify when to adapt and which variant to choose. Such approaches are widely spread in the domains of sensor computing, embedded systems, and mobile computing because such systems need to rely on light-weight approaches due to the inherent scarcity of resources and must be deterministic. The rule sets are usually to be specified at design time. However, rules can also be added during execution.

-          Goal-based approaches equip the system with goal evaluation functions in order to determine the best system variant under current circumstances. Goal-based adaptation can be more flexible than rule-based adaptation and it is more likely that optimal configurations can be identified, albeit at a higher resource usage.

<Eliot> We can use a hybrid approach of Rule-based and Goal-based approaches. A DFM specifies a state machine which consists of states, events, conditions, and actions. Transition conditions can be determined by utility function (goal-based approach). (e.g., optimal network selection problem).

 

Dynamic reconfiguration can be performed via the dynamic composition of components at run-time.

 

In RTA, systems may need to adapt to the prevailing situation on their own. There needs to be runtime models defining when and how to adapt. There needs to be a notion of context, as acceptable configurations strongly depend upon the prevailing situation. This paper considers the following aspects as typical drivers for runtime adaption: changes in required functionality and Quality of Service (QoS), including dependability, changes in the availability of services and resources, and occurrence of failures.

 

Comparison of Variability Management between SPL and RTA

Comparison Criteria

-          Goal: addresses the goals(s) of variability

-          Binding time: time when the variability decisions are revolved, e.g., pre-compilation, compilation, linking, load, or runtime.

-          Mechanism: a software development technique that is used to implement a variation point, e.g., parametric polymorphism, subtype polymorphism, design patterns, aspects, features, conditional compilation, reflection, selection of one among alternative implementations, frames

-          Who: defines who resolves the variability decisions. It can be the domain engineer, the application engineer, the user, or the application itself

-          Variability models: define the models that have variation points or that control adaptation, e.g., decision model, feature model, reference architecture, PLArtifact, reconfiguration policies

<Eliot> We can use this criteria to define our extended feature model.

 

Comparison Results

Criteria	SPL	RTA
Goal	Focus on functional requirements	Focus on improving QoS while maintaining functional requirements
Binding time	Mostly Pre-process/Compile/Linking	Load time/Runtime
Mechanism	e.g., conditional compilation, polymorphism, AOP, FOP, Frames, parameterization	e.g., MOP, dynamic aspect weaving, wrappers, proxies
Who	Application Engineer	Expert/User, Application itself
Variability Models	Decision Model, PLArtifact	Reference architecture, System variant, Variability rules

Table 1. Comparison of Variability Management between SPL and RTA

 

-          Goal – SPL has focused more on providing fulfillment of functional requirements than RTA. RTA has focused more on improving QoS than SPL. Recently there has been a trend for SPL research to address QoS more closely (Benavides's work), which still remains an open issue and thus an explicit submission topic in key venues.

-          Binding time in SPL has traditionally been at pre-compile, compile, and link time, whereas in RTA variability has been achieved at load time when the system (or component configuration) is first deployed and loaded into memory, and more commonly at runtime after the system has begun executing

-          Mechanism: mechanisms of SPL are conditional compilation, polymorphism, AOP, FOP, Frames, parameterization (introduction times, open for adding variant, collection of variants, binding times, functionality for binding. Those of RTA are a level of indirection for intercepting and redirecting interactions among program entities. Key technologies are computational reflection, AOP, and component-based design, Meta-Object Protocols (MOP) dynamic aspect weaving, wrappers, proxies, and architectural patterns (such as the Decentralized Control reconfiguration pattern). RTA mechanisms can be described according to the taxonomy by McKinley et al., which highlights how, when, and where to compose adaptation. Key technologies and techniques for RTA variability can also be used for SPL variability.

-          Who: In SPL it is the application engineer who is responsible for resolving and implementing variability decisions. The responsibility entity in RTA depends on the actual binding time. It is an expert/user at load time and the system itself at runtime. The system requires means to perform the role of the application engineer during runtime (and partially so at load time), when, due to context changes, reconfiguration is necessary so that a new variant is generated. The application engineer in RTA only specifies the triggers, but does not actually perform the adaptation. Instead, triggers themselves play this role.

-          Variability Model: SPL involves using mechanisms to adapt PLArtifacts according to the decision model, whereas RTA mechanisms adapt System Variants according to the configuration models and the reconfiguration policies. These variants are then an instance of the Reference Architecture. RTA variability models are inherently available at runtime, thus requiring an explicit and computationally tangible representation of all such artifacts, whereas variability SPL artifacts in general do not have a runtime representation and are often expressed informally.

 

<Eliot> In our approach, we define two feature models (SFM and DFM). SFM is for SPL and DFM is for RTA. We need to define outputs of each model clearly.

 

Analysis and Potential Synergy

-          Goal: SPL could benefit from well-established techniques for guaranteeing QoS at runtime that have been used in RTA. Open reflective system and MOP (Fitzpatrick et al.), Hybrid feature model (Benavides et al.), RTA can use models for describing variability, such as enhanced version of feature models (Lee and Kang). There is still the challenge of addressing QoS issues

-          Runtime binding time is on the focus of current research in SPL and could leverage corresponding mechanisms in RTA. Automatic runtime adaptation and reconfiguration are achieved by using the knowledge documented in variability models (Wolfinger et al.). In addition to the focus on runtime binding time in SPL, the transition itself towards runtime binding has also led to interest in binding time flexibility, whereby a variation point can be bound at different times.

-          Binding time flexibility has increased the importance of models in RTA and SPL (e.g., DSPLs). In SPL, decision about binding time is achieved informally and implicitly by the domain engineer. Conversely, in RTA, at later binding times, the decision models and context are still needed to decide on adaptation. There remains the challenge of improving reasoning over this model at runtime. Conversely, the development of Reference Architecture in RTA could benefit from well established Domain Engineering approaches in SPL.

-          The commonality among some models between SPL and RTA, the flexibility of binding time, and the blurredness of goals suggest that a holistic development process, exploring the synergies between SPL and RTA, would be beneficial to both domains.

A holistic model-based engineering approach would naturally also benefit from the whole range of typical gains brought by model-driven engineering (MDE) approaches (i.e., validation, verification, reuse, automation). The combination of SPL and RTA approaches could bear a significant step in this direction. Further, the benefits of the combination would also include more consistent handling of variability across the binding timeline and leverage of modeling and analysis techniques across both domains.

 

<Eliot> Feature oriented software development has focused on automation of producing programs using feature model for SPL. I introduce a new feature model for RTA (or AM) called a DFM and integrate previous approach.