Dynamic Software Product Line Engineering: A Reference Framework

Runtime adaptive systems are able to dynamically transform their internal structure, and hence their behavior, in response to internal or external changes. Such transformations provide the basis for new functionalities or improvements of the non-functional properties that match operational requirements and standards. Software Product Line Engineering (SPLE) has introduced several models and mechanisms for variability modeling and management. Dynamic software product lines (DSPL) engineering exploits the knowledge acquired in SPLE to develop systems that can be context-aware, post-deployment recon¯gurable, or runtime adaptive. This paper focuses on DSPL engineering approaches for developing runtime adaptive systems and proposes a framework for classifying and comparing these approaches from two distinct perspectives: adaptation properties and adaptation realization. These two perspectives are linked together by a series of guidelines that help to select a suitable adaptation realization approach based on desired adaptation types.


Introduction
In order to provide better service in many areas, software systems require behavior modi¯cation at runtime particularly in response to users' dynamically varying needs as well as environmental constraints [1].Such changes could be on the features of the system or on how the system caters those features.This is referred to as runtime adaptation, and a system capable of deciding about and performing runtime adaptation is called a runtime adaptive system.Developing runtime adaptive systems has been a signi¯cant concern in many research areas such as mobile computing, autonomic computing, robotics and ubiquitous computing [2].
Runtime adaptation is a complex process and runtime adaptive systems are at times prone to be unstable, ine±cient and unreliable [3].Furthermore, not taking a systematic approach toward adaptation design results in a system which is complex and an adaptation mechanism which is hard to modify [1].Therefore, there have been e®orts for the systematic development of runtime adaptive systems by separating the application logic from adaptation logic [4].Still, many of these approaches su®er from limitations such as being domain speci¯c, having low performance or limited adaptability [3].Therefore, the research community still tries to introduce more e±cient frameworks and processes for the development of runtime adaptive systems [2].
The Software Product Line Engineering (SPLE) paradigm [5] suggests an e®ective way to deal with the variability of similar products especially when satisfying requirements of di®erent operating environments and users.This group of similar products is called a product family which is a group of products sharing common features.In SPLE, the development of a system that ¯ts the user-needs and operating environment relies heavily on the reuse of assets through two development phases: domain engineering and application engineering [5].In the domain engineering phase, those reusable assets needed for developing products are speci¯ed and built.These assets consist of common parts and variation points.In the application engineering phase, the target product for the speci¯c operating environment and user requirements are derived using the reusable assets developed in the domain engineering phase.The binding of these assets into a product is mostly performed at design, compile or link time, after which the system stays the same during its lifetime.SPLE and runtime adaptive systems have much in common [6].The software product line paradigm (SPL) is a solution for managing the variability of products in a product family.In SPLE, the variability of the products is captured at the domain engineering phase, and the best variant for a speci¯c operating environment and user requirements is selected during the application engineering phase.As such, designing a runtime adaptive system may be considered to be a variability management problem, where ¯rst and foremost the variability of the system is captured at design time, and then the best product variant is selected at runtime according to context requirements.The fact that both of these two paradigms are dealing with variability management, one as the problem and one as a solution, has motivated researchers to consider the synergy of these two paradigms in dynamic software product line (DSPL) engineering [7].
DSPL is used for software development in di®erent application areas such as context-aware systems, post-deployment recon¯guration, and runtime adaption.In DSPL engineering for runtime adaptation, SPL models and techniques are used at runtime to manage and decide about the variability of runtime adaptive systems [8].
SPL-inspired models and mechanisms are used at runtime to select the most suitable variant of the system and adapt the system to that variant.In this paper, we focus on DSPL engineering approaches for realizing runtime adaptation by presenting a framework for classifying and comparing adaptation properties and implementation concerns.Additionally, we suggest guidelines for the adoption or design of DSPL engineering approaches using the recommended framework.In order to do so, we ¯rst review key adaptation properties.Subsequently, we identify realization concerns for the development of DSPL.Finally, we link adaptation properties to the iden¯tied realization concerns by providing guidelines for the selection of suitable models and techniques.
The proposed framework is designed by de¯ning a set of dimensions which answer questions about how runtime adaptation could be realized using DSPL engineering approaches.These dimensions are de¯ned such that they can be generally used to characterize a DSPL engineering approach.In the framework, these dimensions are clearly described, the possible values are discussed, and examples from existing DSPL engineering approaches are provided.In order to organize these dimensions, our framework conceptualizes DSPL adaptation management as a MAPE-K loop [9].Using this conceptualization, our framework dimensions are organized in a taxonomy in which the steps of the MAPE-K loop are used to classify di®erent dimensions of adaptation realization.
In the following sections, we de¯ne what we mean by DSPL and then select seven of the prominent approaches from the literature to which we shall apply the proposed framework (Sec.2).Subsequently, we describe what we mean by adaptation through de¯ning its properties and by comparing the selected approaches based on the type of adaptation they o®er (Sec.3).Furthermore, the framework and its dimensions are described, and this time the framework will be used to compare adaptation realization in the selected approaches (Sec.4).After describing the framework, adaptation dimensions and framework dimensions are linked together by a set of guidelines which are used for selecting various values for the dimensions of the proposed framework.The guidelines provide strengths and weaknesses of each possible value according to the adaptation required when either building a new DSPL engineering approach or choosing from already existing approaches (Sec.5).

Dynamic Software Product Lines
Although SPLE models and techniques are utilized for managing variability in DSPL paradigms, SPLE and DSPL engineering paradigms follow di®erent goals, each of which results in products with di®erent nature.Hallsteinsen et al. [10] characterize DSPL engineering with a set of properties that distinguishes it from SPL engineering in terms of the goal and properties of their products.For instance, the goal for selecting a di®erent system variant in SPL is satisfying speci¯c market needs; while, the goal in the DSPL paradigm is satisfying the requirements of di®erent running contexts [7].Hallsteinsen et al. [10] also de¯ne two types of properties for DSPL engineering products that make them distinct from SPLE products: runtime recon¯guration and self-management.Runtime recon¯guration properties represent a product's ability to `con¯gure and bind variability at runtime', `bind changes several times during lifetime', `change in variation points', and `deal with unexpected changes' [10].Selfmanagement properties represent a product's ability to be `context-aware', `selfadaptive', and function as an `automatic decision maker' [10].Runtime recon¯guration properties are considered mandatory for the product, but self-management properties are deemed as optional within the context of DSPL.
Several approaches and frameworks, which may or may not call themselves a DSPL engineering approach, have been proposed that exploit SPL models and techniques in the development of di®erent systems such as service-oriented and context-aware systems.In this study, in order to distinguish DSPL approaches from other engineering approaches, we have adopted the DSPL de¯nition o®ered by Hallsteinsen et al. [10].Hence, we consider an approach DSPL engineering approach if it uses SPL assets in its development and has runtime recon¯guration properties.Considering this de¯nition as a guideline, we used Google Scholar to locate DSPL studies using search terms `DSPL', `Software Product Line Runtime adaptation', and `Software Product Line Self-adaptive' with no restriction set on the date or place of publication.The results, and other studies cited within these publications, were reviewed to determine whether they matched the Hallsteinsen DSPL de¯nition for inclusion in the study pool.The studies documenting di®erent aspects of a speci¯c approach were grouped together.A list of these study groups can be found in Table A.1 in Appendix A.
We have selected seven approaches from these studies, which will be discussed in a comparative scale using our framework.Our criteria for the selection of these seven approaches were as follows: . Select studies which propose a development methodology.The studies were classi¯ed by their focus into four groups: conceptual discussions, development methodologies, models and languages, and other (tools, algorithms,. ..).Using this classi¯cation, only those studies which propose a development methodology are considered for selection. .Select studies with greater impact on the trends in the ¯eld.The sum of citation counts provided by Google Scholar for the study group documenting the approach has been selected as the criterion for measuring the impact of the research on the ¯eld. .Select studies with well-documented adaptation realization procedures.In the case of development methodologies, the studies were reviewed to determine if they have addressed each of the di®erent steps of adaptation realization and relevant knowledge in the MAPE-K loop (i.e.Monitoring & Analysing, Planning, and Execution). .Select studies which propose an original approach.Approaches were reviewed to see if they were original or built as extensions on other approaches.The latter group were excluded.
The above criteria were used to build a table which is used as reference for the selection of the seven reviewed approaches (Appendix A).Table 1 shows the selected approaches, their relation to SPLE and their application domain.A brief overview of these approaches is as follows: Baresi et al.: This DSPL engineering approach utilizes SPL, Common Variability Language (CVL) [28] and aspect-oriented programming for enabling runtime re-con¯guration of business processes represented with Business Process Execution Language (BPEL).BPEL is a language for the formal speci¯cation of business process behavior focusing exclusively on Web services.The approach by Baresi et al. has been built as an implementation of CVL, which is a suggested generic approach for managing variability in domain speci¯c languages.In this CVL-based approach, the variants of the system are chosen by selecting the desired features from the feature model of the system.The selected features in the feature model are mapped to series of substitutions in the base BPEL code.Base BPEL code is a process which is considered as a reference point for de¯ning variability.A substitution is de¯ned as placing a BPEL aspect from the CVL library into placement location in the base code.The target business process is derived using these placements after which it replaces the current business process.Runtime recon¯guration has been enabled in this approach by extending the ActiveBPEL engine [29] using aspect-oriented programming to modify BPEL at runtime by changing the included aspects [30].
Bencomo et al. (Genie): Genie is a model-based approach for developing selfadaptive systems for grid mobile computing and embedded systems.In this approach, two variability dimensions are recognized for a system and linked to each other in the development process: environment or context variability which represents variability in the environment and structural variability which represents variability in the architecture of the running system.The structure of the system can adapt according to changes in the environment by linking these two dimensions.In the Genie approach, the environment is represented by a state transition diagram, where states represent the states of the environment and the transitions represent possible environment state changes which are guarded by conditions over the context of the system.The structural variability of the system is represented with OpenCOM DSL which is a domain speci¯c language that represents system architecture.This approach takes advantage of the OVM [5] for linking those models which represent two dimensions.OVM traditionally is used for tracing variability between models at di®erent levels of abstraction in the software product line.Genie enables runtime recon¯guration using OpenCOM [31] middleware.Cetina et al. (MoRE): MoRE is a recon¯guration engine which incorporates SPLE ideas for developing autonomic pervasive systems such as Smarthomes.This approach uses feature models as a variability space model at runtime.Runtime adaptation takes place in this approach by modifying the current feature model con¯guration of the system using a set of condition/resolution rules, where these rules de¯ne which features are activated/deactivated as context conditions change.
The system managed by MoRE should be built using service-oriented architectures, where services and devices communicate using channels.The actual system adaptation is performed by mappings features of the feature model to the services and channels that realize these speci¯c features.Therefore, a feature model con¯guration is mapped to a con¯guration of the system, where a set of services and channels are active while the others are inactive.This approach also proposes a technology-independent, domain-speci¯c language named PervML [32] representing system architecture.PervML is used for representing services and devices and how they are connected though channels.
Floch et al. (MADAM): MADAM is a utility-based approach for building selfadaptive systems for mobile and distributed environments.This approach extends an SPL engineering concept named con¯gurable product bases [33] to enable runtime adaptation.Con¯gurable product bases is a type of SPLE approach which requires no product speci¯c development during application engineering.The MADAM approach extends con¯gurable product bases by adding a utility-based planner to it and enabling con¯gurable product bases to recon¯gure at runtime.In this utilitybased approach, a utility function is de¯ned over the system properties and its context to represent desirability of the current con¯guration in the current context.Therefore, the goal of adaptation becomes the maximization of the value of this function.The planner functions by taking advantage of property predictor functions, which can predict di®erent properties of the system according to the system con-¯guration and the context.When the utility becomes unacceptable, the planner uses a brute-force technique to ¯nd a con¯guration with the highest predicted utility and adapts to it.

Gomaa et al. (REPFLC):
The Recon¯gurable Evolutionary Product Family Life Cycle (REPFLC) approach proposes a lifecycle for SPLE which covers product execution phase in addition to those related to domain engineering and application engineering.In this lifecycle, recon¯guration patterns are designed at the domain engineering phase, alongside other domain engineering assets, in order to de¯ne reusable patterns for safe runtime recon¯guration of components.These recon¯guration patterns provide state-based and scenario-based behavioral models for an adaptation.The state-based model represents how the system adapts in an adaptation while the scenario-based model represents the requirements of the situation when the adaptation is necessary.These recon¯guration patterns are available in the con¯gured target system.The system uses these recon¯guration patterns to safely recon¯gure at runtime when an adaptation is required.
Morin et al. (DiVA): This approach builds on ideas from SPLE and aspectoriented modeling to develop self-adaptive systems.In this approach, the architecture of the system is built in three layers.The bottom layer contains the application logic; the top layer plans the adaptation; and the middle layer creates the link between the top and the bottom layers.The middle layer creates the bottom to top link by analyzing data from sensors and converting the data into context information useful for reasoning.It also creates the top to bottom link by re°ecting changes in the system architecture model into the running system.The top layer uses feature models at runtime for managing the variability of system at an abstract level.Feature models are used to decide about the best con¯guration for the current context using a reasoner.Planning results in a feature model con¯guration which represents what system features should be available in this context.This feature model con¯guration is then mapped to the architectural model of the system using aspect model weaving.The approach uses a system variant con¯guration checker to ensure consistency of the target architecture model at runtime.Parra et al. (CAPucine): In this approach, software product line and service oriented architecture have been used to create a process to build systems that monitor context changes in order to dynamically incorporate required assets at runtime.The variability of the system is kept modeled using a feature model.The approach gathers context information using a context sensing middleware which has been built based on the COSMOS framework.The changes in the context triggers changes in the feature model based on a set of rules.This approach suggests the use of aspect model weaving [34] for generating the architecture model of the system from feature model con¯guration at runtime.In aspect model weaving, features are mapped to aspect models representing di®erent aspects of a given feature in the system architecture.For a feature model con¯guration, the corresponding aspect models of selected features are woven into the base model of the system to create an integrated model of the architecture of the system.Then the approach uses FraS-CAti [35] which is a Fractal-based Service Component Architecture (SCA) [36] platform with dynamic properties, to recon¯gure the system according to the target architecture model at runtime.
Although systems with the ability to adapt at runtime can be built using any of these approaches, the types of adaptation o®ered by them are di®erent.Therefore, in what follows, we provide a method for characterizing adaptation achieved by each speci¯c approach.Knowing the type of adaptation which is o®ered by systems developed using each approach can help in the selection of a suitable one according to speci¯c adaptation needed for a problem domain.

Characterizing Adaptation Properties in DSPL
Runtime adaptation covers a wide range of runtime changes.In order to arrive at a better understanding of the kind of adaptations which are addressed by existing DSPL engineering approaches, we need to characterize the adaptations that can be performed by each approach.The characteristics of alternative adaptations can be determined by a number of points of di®erence (also called dimensions).These points refer to the properties of an adaptation itself regardless of techniques and tools which are used to realize it.In [37], 20 dimensions have been proposed for characterizing an adaptation in a speci¯c system.Therefore, we use these dimensions for comparing the adaptation properties that the di®erent approaches o®er.Figure 1 shows the dimensions classi¯ed in three categories.Those dimension whose values cannot be determined for a DSPL approach were removed from the ¯gure.The dimensions in each of the goal, cause, and mechanism categories represent characteristics of the goal of an adaptation, source of changes that causes an adaptation, and mechanism used for enabling adaptation, respectively.In Table 2, we have listed these dimensions and their values for di®erent DSPL engineering approaches.Each of these dimensions has been discussed in the following.

Goal type
This dimension is concerned with the intent for adding runtime adaptation.In the de¯nition of autonomic computing [9], Kephart and Chess cite four goal types for self-managing systems: self-con¯guring, self-optimizing, self-healing and selfprotecting.Goals for enabling runtime adaptation can be categorized into these categories.In the following, these goal types have been discussed, except that of the self-protection aspect due to the yet unavailability of a DSPL engineering approach with this goal type.
. Self-con¯guring: The goal here is to enable the system to automatically recon¯gure itself as the context or requirements change such that the system satis¯es the high level policies.This is similar to product con¯guration in SPLE, where a product is con¯gured for di®erent situations such that it satis¯es stakeholders' needs.The goals can be de¯ned as a condition that should be always satis¯ed for the corresponding system; for example, the response time of a speci¯c service of the system should be always lower than a speci¯c duration.In [12], the Genie approach was used to develop a system that runs on sensor nodes in a sensor network for °ood monitoring, where the system needs to be self-con¯guring.In this speci¯c problem domain, the goal of adaptation was to enable the system to switch from the battery preserving con¯guration to the high performance con¯guration so as to be able to communicate faster when °ood was likely to occur. .Self-optimizing: A system supports self-optimizing adaptation when the goal of enabling adaptation is to make the system perform optimally under di®erent environments and contexts.Usually, the optimality of the system is represented with a single utility value which is typically the weighted sum of di®erent quantitative attributes of the system (such as QoS attributes).For example, In [7], MADAM was used to develop a supporting application for service technicians working in geographically dispersed installations.The application adapts itself to changes in the context (such as connectivity, noise, etc.) to optimize user experience represented with a utility value. .Self-healing: In self-healing adaptation, the goal of adaptation is to have a system that adapts itself after a failure in order to reduce the impact of failure on the system.A self-healing system enables search for alternatives when a component of the system fails.For example, the MoRE approach is used for developing selfhealing Smarthomes, where failure of devices is likely to happen [16].In this example, failure of devices is handled by exploiting alternative ways; for example, alarm failure results in the blinking lights of the house.As an another example, Abotsi et al. [38] developed a DSPL engineering approach for developing a Webbased application, where the system is monitored for critical conditions.In case of a critical condition, a suitable variant of the system is identi¯ed and selected to recover from the critical condition.For instance variants that use less resource demanding contents are selected when there is lack or dearth of resources.

Goal evolution
This dimension denotes whether the goal of adaptation can change at runtime or not.The change in the goal is usually required when the system faces an unforeseen situation not supported by the adaptation manager of the system.The ability to evolve the adaptation goal can range from static, where the goal of adaptation does not change to dynamic, where the system itself can modify goals of adaptation during the systems lifetime: . Static: In this type of adaptive systems, the goal of adaptation stays the same during the lifetime of the adaptive systems.These systems usually have a ¯xed adaptation policy and system variants.In the case that new goals are needed, the system should be stopped and modi¯ed to support new goals.However, the veri-¯cation of these systems is usually easier considering their limited °exibility. .Non-static: Here, the system adaptation manager provides a mechanism to introduce new adaptation goals to the system at runtime [23,39,40].This can range from manual change of goals to evolution of the system by itself.The DiVA project [23] has claimed that it has enabled manual change of system goals by providing interfaces for modi¯cation of models both at design time and runtime.Another notable research in enabling runtime goal evolution in DSPL proposes an approach for supporting feature model changes as a result of runtime goal changes [39].In this approach, a meta variability model is de¯ned over the variation points of the system, which provides the information required for anticipating goal updates and explicitly expressing how these goal updates are supported in the feature model.For example, this meta model speci¯es which variation points may have new variants as the systems evolves and what are the requirements of these new variants.

Cause type
The trigger of an adaptation in°uences how monitoring and planning activities operate in a runtime adaptive system.The types of changes which can trigger adaptation may be generally classi¯ed as context changes, system, and user changes.
. Context: Context changes are those changes that take place in the external environment of a system.When the system needs to responds to context changes, it requires the right sensors to measure the properties of interest in real-time.The gathered information is then used in planning for adaptation.Therefore, a mechanism should be provided by the engineering approach for capturing the context information.For example, CAPucine uses the COSMOS framework for monitoring the context.In this framework, a component is developed for each sensor named context node, which represents that sensor as a component. .System: System changes are those changes that take place in a system internally.
Examples of these changes are failure of a component, performance of a component, and exceptions.For capturing these type of changes, sensors should be integrated within the system implementation.For example in [19], sensors are used as part of the architecture, monitoring the performance of components such as component response time and memory usage.These information are then used by the adaptation manager for planning about possible system adaptations. .User: Changes are alterations in user requirements or priorities at runtime, and therefore the trigger for adaptation is an external entity such as a user.User preferences are usually captured using an interface.The change in requirements is expressed in high level terms such as features, and is realized by an adaptation manager.In the Helleboogh et al. approach [39], the user of the system can change the operation mode of an automotive transportation system in a warehouse in response to changes in the operating condition.For example, when a load of goods arrive at the warehouse, the operation mode of the system is changed by the user to e±ciently unload the packages.Another example for adaptation as a result of user preference changes is that proposed by Wol¯nger et al. [41] where the users' preferences are captured by wizard-like dialogues following a decision model.In each dialogue, the user selects from available alternatives in a decision point while the system o®ers the consequence of selecting each alternative.The adaptation target con¯guration for the system is built based on user decisions captured by the wizard.

Mechanism autonomy
This dimension de¯nes if an outside entity (mostly humans) is responsible for planning the adaptation.This can range from completely manual to autonomous.In autonomic computing, the degree of a system's autonomy is demonstrated in ¯ve levels from adaptations which are completely manual (basic level) to adaptations which are completely automatic and where the human agent only speci¯es high level business rules and policies [9].In the following, we only discuss the two extremes of this range: . Manual: In the manual adaptation mechanism, the system cannot complete an adaptation without help from an external entity.In this type of adaptation, an interface is usually provided for the user to specify the required adaptations of the system.An example for manual adaptation in DSPL engineering is an approach proposed by Baresi et al. [11], where a variability designer, in the form of an Eclipse plug-in is used for managing the variability of the system represented by a feature model. .Autonomous: In an autonomous mechanism, the system plans and performs the needed adaptations automatically.The required behavior of the system is usually provided using high-level goals or rules.It is according to these goals or rules that the system makes its adaptation planning.Therefore, the system should be contextaware, which implies that it needs to monitor its internal state as well as the context.

Mechanism type
This dimension de¯nes the type of changes that an adaptation mechanism can make in the structure of a system to perform an adaptation.Gomaa et al. [42] classify adaptations into three classes according to the extent by which they a®ect the architecture of the system: . Code-level adaptation: In this type of adaptation, system behavior changes although its architecture stays the same.This type of adaptation can be implemented by changing runtime entities using parametrization, inheritance, and preprocessor directives in the code [43,44].This type of adaptation is simpler to implement; however, it limits system adaptability since system adaptation is limited to the code of the constituents within the system.Additionally, modi¯cation and extension of the system is harder because, in most cases, adaptation logic is interwoven with system code. .Component adaptation: Here, adaptation is achieved by substituting a component with another of similar interface though with a di®erent behavior.This substitution provides a plug-in mechanism, where plug-ins are replaced with other plug-ins of the same type as the system adapts.However, some components and also the way these component are connected to each other stay the same.An example for this is systems developed with the MADAM engineering approach [19], where a number of ports are de¯ned in the architecture which can be ¯lled with components of the same type.In order for the system to adapt, the system middleware allows components connected to the ports to be replaced at runtime. .Architectural adaptation: In this type of adaptation, the structure or the architecture of the system changes to modify the collaboration between components or the incorporation of new components in to the system.
These dimensions can be used to characterize the type of adaptation which is required for a system.In Table 2, the value of these dimensions for systems developed using the seven DSPL engineering approaches covered in this paper are presented.In the next section, we will focus on the dimensions characterizing the way adaptation is realized in a DSPL engineering approach.

Characterizing Adaptation Realization in DSPL
From the early e®orts made in the area of systematic implementation of runtime adaptive systems, the separation between parts of the system focusing on adaptation logic and application logic has been promoted [45].Adaptation logic is concerned with selecting the best possible variant of the running system based on the current context while the application logic provides the required functionalities of the system.This practical distinction makes the development of a runtime adaptive system easier and results in a more reliable system [3].The separation is usually implemented as a two-layered structure.In this structure, an adaptation management layer is implemented over the application layer.The adaptation management layer accommodates adaptation logic.The application layer enables runtime recon¯guration and also provides the interfaces for monitoring and recon¯guring the system for the adaptation management layer as well as accommodating the application logic.Figure 2 shows the adaptation manager layer and the application layer.
The focus of DSPL engineering approaches is mostly on building adaptation managers for runtime adaptive systems.In order to break down the concerns for building an adaptation manager, we conceptually represent an adaptation manager as a MAPE-K loop model [9] similar to what Bencomo et al. [8] have proposed.In their research, they have proposed a conceptual model for DSPL adaptation management process in which the system adaptation manager can be viewed as a MAPE-K loop.However, they do not provide the details of how this process can be mapped to the MAPE-K loop.Here, we adopt their conceptual model for adaptation management and provide detailed mapping between DSPL adaptation management process and the MAPE-K loop.The MAPE-K loop (Fig. 2) model is used in autonomic computing to represent the main concerns for building an autonomic manager.An autonomic manager is responsible for handling autonomic properties of a system.MAPE consists of the initial characters of the four main steps to be taken by an autonomic manager: Monitor, Analyze, Plan, and Execute.The added K character following the hyphen stands for knowledge which is usually represented by models which are used in the ¯rst four steps.The monitoring step is about capturing those properties which are required for planning the adaptation of the system.The analysis step addresses concerns regarding the examination of the monitored data to get new information by considering a combination of monitored values and taking into account the monitoring history which will be useful for the planning step.The planning step decides if adaptation is essential and selects the best system variant if adaptation is necessary.After planning for the adaptation, the execution step safely executes the adaptation.
We have extracted the dimensions that can be used to distinguish between existing DSPL engineering approaches.In order to design our framework adaptation realization taxonomy tree, we posit that all dimensions that characterize DSPL adaptation manager can be attributed to one of the MAPE-K steps.With this assumption, a one level taxonomy tree was de¯ned with its ¯rst level nodes representing di®erent steps of the MAPE-K loop (i.e.Monitoring, Analysing, Planning, Executing).Subsequently, relevant dimensions for each step are identi¯ed and those dimensions are placed as a child nodes for that step in the taxonomy tree.For a dimension related to the MAPE-K knowledge(K), the dimension was added to the step which mainly works with that knowledge.
Figure 3 shows the resulting taxonomy.In this ¯gure, dimensions related to knowledge are shown with gray boxes while other dimensions are shown with white boxes.In the remainder of this section, these dimensions are described in detail.Each subsection describes one of the steps of the MAPE-K loop.For each dimension, the aspect of DSPL engineering approach that is characterized by that dimension is described and a number of possible values for that dimension is listed.The dashed line between dimensions means values selected for the dimension at the beginning of the arrow directly a®ects possible selectable values for the dimension at the end of the arrow.For each of these values, its description and supporting examples from the literature are provided.

Monitoring and analysis
These two steps of MAPE-K loop are responsible for making adaptation manager context-aware.This is essential where adaptation manager is expected to autonomously respond to context changes.This step captures internal or external context through a context sensing mechanism.The information captured through the context sensing mechanism is represented context model.Since the information captured by context sensing are usually too low level to be directly usable by the planner, they are usually extended by de¯ning more complex context conditions using context reasoning models.Figure 4 shows these dimensions and some of their possible values.In the following, these dimensions are reviewed: (i) Context model: A context model is used to represent the knowledge acquired by the monitoring and analysis steps.This is a minimal representation of the system context that is important for planning.Two types of common context models are presented in the following: . Property-set: In this type of context model, the context of the system is represented by a set of properties crucial for planning.The values of these properties are updated at runtime through monitoring and analysis which may lead to the adaptation of the system.For example in the MUSIC framework  [ 46,47], the information about the environment (e.g.ambient noise) as well as information about internal state of the system (e.g.device memory) and QoS properties (e.g.network quality) are kept and updated as values to a number of context variables.The planner accesses these context variables to decide about system adaptation. .Ontology.In this type of context model, ontology representation languages such as OWL [48] are adopted to relate (together) the important properties of the system using semantic relationships in the ontology.The use of an ontology allows a more structured representation of the context.It also enables reasoning over the context model using existing semantics reasoners and sharing of the context model between di®erent systems.For example in [49], the OWL language is used for expressing the context information in a way that allows for reasoning.In this framework, the properties are organized using classes and their relations are expressed using semantic relations.In another case study [50], the OWL language is used to represent the context model of a smart hotel.As an another example in [51], the global context which is represented with an ontology is mapped to the feature model which represents the variability of the system.Using this mapping, a local context of each variant of system is found based on the features in that con¯guration.This will exclude irrelevant information from reasoning in each speci¯c context which results in more e±cient adaptation.
(ii) Context reasoning: Context reasoning extend information acquired using context sensing by producing more contextual information using existing ones.A context reasoner accepts one or more existing context information and produces new more abstract information.For example, it may take information from ambient noise and motion sensors and specify the value for the home occupancy information.Use of context reasoning allows providing more abstract information for the planner which facilitates the design of reasoning in a planner.Additionally, context reasoning can be used for alleviating the e®ects of noise and uncertainty by working with multiple sources of information.
. Rule-based logic: In this type of reasoning, the new context conditions is de-¯ned by creating simple rules over existing context information (e.g.propositional logic).For example in Genie [13], conditions which result in transition from one state to another state is de¯ned using propositional logic over existing information.Use of rule-based logic provides a simple and performance e±cient way of ¯nding new information over existing ones.However, in the cases, where temporal characteristics as well as quality of information (e.g.certainty) should be considered in context reasoning, simple rule-based methods may not be e±cient. .Query languages: The captured information by context sensing usually provides a stream of observed values (with di®erent timestamps, con¯dence, and etc).Therefore, query languages and their corresponding reasoners are used in 206 M. Bashari, E. Bagheri & W. Du some context managers.These query languages facilitate expression of more complex context condition.For example, the context manager in DiVA project provides a query language named EQL which is a language similar to SQL which works on a sliding window of sensor events.Similarly, MoRE uses an ontology as its context model and SPARQL is used for context reasoning.
(iii) Context sensing: In order to be context-aware, a DSPL engineering approach should provide a way for de¯ning context sensing mechasnism which enables capturing situational information (e.g.internal state, environmental context).This separates activities for capturing information from other adaptation activities and prevents other entities in adaptation management from becoming involved in the internal process for obtaining these information.Context sensing mechanisms are usually implemented by enforcing a standard for designing sensors (e.g.de¯ning standard interfaces for sensor components) which provide a uni¯ed way for capturing contextual information.This enables the use of a central middleware for management of contextual information.Additionally, the middleware provides functionalities such as organizing, storing, or querying context information.For example, in [27], the sensors are realized as components named context nodes which are organized in a hierarchy.Although these components may have di®erent properties such as active or passive, they all provide same interface which allow them to be accessed by the context manager in a similar way.Context sensing middleware also allow reuse of general sensors such as CPU load sensors.For example, context manager library for the DiVA project provides a library of sensors which can be reused in di®erent projects.This context sensing is usually provided in two ways: observation and noti¯cation.
. Observation: The context sensing mechanism which enables observation allows the planner to query contextual information.Therefore, the planner is responsible for getting new context changes (e.g. in a speci¯c interval) in order to get new context information.This is a simple type of monitoring but it may cause overhead as it is needed to query new information regularly in order to have model of the context. .Noti¯cation: Context sensing mechanisms which enable noti¯cation allow the planner to be noti¯ed of changes in certain contextual information as the they take place.Therefore, the planner gets noti¯ed as soon as an interesting situation takes place and reduces the overhead.However, it requires interfaces in the middleware to be called when those changes happen.

Planning
In a typical software product line process, the application engineers develop a suitable variant of the product for a speci¯c user by selecting and instantiating assets developed during domain engineering with the help of variability models.In the context of DSPL engineering, variant selection should be performed at runtime, usually without any external help.Therefore, the system should take the role of the application engineer to select and instantiate new assets to generate a new variant of the system.We refer to this process as planning.Most e®orts in the DSPL community have been in the area of developing planning approaches [8].A planner uses situational information provided in the context model to decide if an adaptation is necessary, and if so, to ¯nd the desired variant for the current situation.The possible variants of the system are represented in a variability space model.The planner uses a planning model to select the next variants of the system from the variability space model.The planning model represents how the system selects the desired variant according to the current context and variant of the system.Variability space models may de¯ne possible variants of the system in terms of their features or architectural structure.Since the planner works by selecting variants from the variability space model, the level used for variability space model speci¯es the planning level.Planning level speci¯es the aspect of the system on which planners reason (i.e.feature or architecture).If feature-level planning is used, the desired variant of the system will be represented by its features which needs to be transformed to architectural structure of the system using a transformation mechanism.This architectural structure is then used in the execution step to recon¯gure the running system to the selected target system.Figure 5 shows these dimensions and some of their possible values which will be reviewed below.
(i) Variability space model: The variability space model represents the alternative variants of the system and their di®erence points.The model can represent variability at di®erent abstraction levels.For example, the variability of a system can be represented by what are the properties of di®erent contexts the system can operate in [51,52] or what components are di®erent between the variants of the system.
. Enumeration: In this type of variability modeling, the possible variants of the system and their properties are enumerated as a set of possible variants [53].
The planner selects the most suitable variant of the system for the current context from the enumerated set and adapts to it.Those systems that model their variability using this type of modeling are generally simpler to design and validate.However, it is likely that the size of the possible variants of the system increases rapidly and becomes unmanageable as the system grows [23].This type of variability modeling is usable when the possible set of variants of the system is possible to de¯ne.For example, in a case study of using DSPL [15], the enumeration model is used to model three possible variants of a network discovery agent.These variants showed what kinds of roles the agent can have in the service discovery process at runtime. .Variation points: In this type of variability space modeling, di®erence points in a base system are speci¯ed and called variation points.A type is de¯ned for each variation point within the system, where di®erent alternatives of the same type can be selected for each variation point.The adaptation in the system takes place by the replacement of alternatives with the same type in the variation points of the system.The current variant of the system can be speci¯ed by knowing the alternatives that have been selected for the variation points.An example for this type of variation management is the MADAM approach [19], where ports are de¯ned in the architecture of the system.Ports are the locations where di®erent components with the same interface can be substituted with one another.Variation points provide a simple and manageable solution for managing variability in a system [7].However, one problem facing this type of variability modeling is that it does not support cross-cutting variations, where the selection of alternatives in one variation point puts constraints such as exclusion or inclusion on other variation points [7]. .Feature modeling: Feature models [54,55] are widely used in SPL engineering for representing the variability of the product family [17,23,27,56,57].A feature model provides a hierarchical structure that represents the organization of the features which are `increments in product functionality' [58].
When decomposing a feature into sub-features, the sub-features may be optional or mandatory, or may form Xor-, Or-, or And-groups.These relations express the possible variability of the system.Feature models also represent cross-cutting variations using integrity constraints.Feature models are commonly used as a variability space model in DSPL engineering approaches because of their power to represent complex variability of a system.variation (e.g.di®erent locations) is de¯ned beside the feature model.This model is linked to feature model in a way that selection of di®erent dimensions of it constrains the feature model variability space [59][60][61][62].This creates an orthogonal link between context and features which facilitates relating di®erent context conditions to an appropriate feature con¯guration by eliminating irrelevant features during feature model con¯guration.For example in [59] another feature model is used as context variability model.This context variability model is linked to the main feature model using feature model integrity constraints.
(ii) Planning model: The adaptation planner of a system is usually implemented using a reasoner which considers the variability model, the context, and the current variant of the system as inputs.It then develops the most suitable variant for the current context according to its planning knowledge [1].The planning knowledge could be hard-coded into the reasoner or expressed explicitly by a model which is available at runtime and used by the reasoner.Using models for representing the planning knowledge eliminates the need for the development of a new reasoner from scratch for every system developed with a DSPL engineering approach.A planning model speci¯es the policy of the system for selecting the suitable variant of the system by having access to the current variant of the system and the current context at runtime [6].The type of planning model is determined by the planning method that is used in the system.Here, we cover the planning models used by the reviewed systems in this study.
. State transition diagrams: In these models, which can only be adopted when enumeration is used for representing the variation space model, the adaptation policy of the system is represented using a state transition diagram.The states are variants of the system and the transitions are the possible adaptations.The guard condition of a transition de¯nes the situation in which that speci¯c adaptation could take place.One problem associated with the state transition diagram is that they are not easy to maintain after they are initially designed because of their relatively complex structure [23].An example of using this approach to de¯ne the adaptation policy is a case study of the Genie framework [12], where a state transition diagram is used to specify when a °ood monitoring agent should change its behavior according to its context and what target variant it should adapt to. .ECA rules: Event-Condition-Action rules represent what actions the system should perform in response to an event when certain conditions hold [23].
Events could be changes in the context (e.g.network tra±c) or system internal state (e.g.processor usage); Conditions are de¯ned over the current environment or the current variant of the system; and ¯nally Actions can be a set of activations and deactivations over the system components or similar changes in system features.Expressed using di®erent languages and models, the ECA rules usually have the advantage of being readable [63].The planning model of the system can also be modi¯ed easily by adding and removing ECA rules.However, a problem with ECA rules is that when the number of rules are large, con°icts are likely to arise between the rules.Detecting such con°icts are di±cult [63].In such a case, it is ambiguous how the system should act, and a con°ict resolution mechanism is essential, for example, giving priorities to some actions.An example for using ECA rules to de¯ne adaptation policy is a case study where the ECA rules are used in a dynamic access control product line to specify the changes in the available functionality of the system as users with di®erent roles use the system [64].In this system, the ECA rules specify access to what functionality should be granted to a user according to his role. .Utility functions: In this type of planning modeling, the planning model consists of a utility function which is usually a heuristic representation of the desirability of adapting to a variant of the system or performing an action in a speci¯c context [63].This utility function is used to select the most desirable variant of the system to adapt or determine the action that should be performed in each context of the system.An example for this is the MADAM approach [19], where a utility function represents the desirability of each system variant which is a weighted sum of the important properties of the system.In another example [65], features in the feature model are annotated with quality attribute and value for a quality attribute of a con¯guration is calculated using aggregated functions.The desirability of a con¯guration is de¯ned by a single value which equals the weighted sum of all quality attributes for that con¯guration.Using these information, an optimization method is used to ¯nd a con¯guration between possible con¯gurations of the partially con¯gured feature model which maximizes this value.One problem associated with the utility function is the di±culty usually encountered in the design of such function that would precisely model the desirability of the system [7].
(iii) Planning level: The planning level dimensions speci¯es if planning is performed over the features of the system or the architectural entities of the system.The planner may see the system as a number of components collaborating with each other and therefore decides which components should be active, their con¯guration and how they should collaborate (e.g.[7,12]).
Similarly, the planner can view a system according to its feature, therefore deciding what features should be active in the system according to its context (e.g.[16,23]).The selection of appropriate planning level removes unnecessary details while preserving the required information for planning.
. Feature: Similar to feature model con¯guration in SPLE, the planner could decide at the feature level which would abstract away realization details.Planning on the features promotes the separation of concerns by dissociating the context requirements from realization details [66].However, using planning on features necessitates the implementation of a transformation mechanism which converts the feature level con¯guration to the architectural con¯guration [23].For example, in a robotic case study [67], the adaptation planner for the robot software selects required features according to the context.The feature model con¯guration is used by a weaver to compose related architectural models to create architectural con¯guration model of the system. .Architecture: Here, planning is performed on architectural entities (such as components).Planning on architectural entities is usually harder than planning on features, because reasoning becomes more complicated when context requirements and implementation constraints are taken into consideration at the same time.For example, in [19], the requirements of the system are de¯ned on the properties of the components and the planner tries to ¯nd the components which satisfy these requirements best.
(iv) Planning type: Planning type represents the kind of planning method are employed for selecting the most suitable variant of the system.Selecting the most suitable variant of the system is usually expressed informally in SPLE [6], but it should be speci¯ed explicitly and formally in DSPL in order to automate the selection process.Generally, planners can be categorized into three groups [68]: . Rule-based: In rule-based planning, adaptation takes place by following a set of rules which specify what actions should be performed in each particular context [8].In this planning type, the planning strategy is usually modeled using ECA rules or state-transition diagrams and the strategies are then enforced by a reasoner.In this type of planning, adaptation rules are usually de¯ned at design time which requires thorough knowledge of the operating environment at design time [8].However, some rule-based planners allow the modi¯cation of the rules at runtime [23].In a case study of MoRE engine used in the context of Smarthomes [16], adaptation rules are organized as a set of condition/resolution rules.The conditions are speci¯ed using propositional logic over context variables.The planner is made of a reasoner which checks if a condition holds for any of the rules and performs the resolution for those rules whose condition holds. .Goal-based: In goal-based planning, the high level goal of the adaptation is de¯ned, and ¯nding how to achieve the goal is left to be ¯gured out by the planner.In goal-based planning, unlike rule-based planning where the actions of the system in di®erent contexts are speci¯ed at design time, the most suitable action to be performed is ¯gured out at runtime by using a planning method.Usually in this planning type, the e®ects of di®erent actions on the adaptation goals are formally de¯ned.Subsequently, the problem of ¯nding the most suitable action is reduced to a satis¯ability problem (SAT) [51,69] or a constraint satisfaction problem (CSP) [70][71][72] which is then solved using a SAT-solver or a CSP-solver.For example, in Parra et al. [70], a CSP solver is used at runtime to ¯nd the most suitable variant of the system which satis¯es the goals of adaptation.The goals of adaptation are expressed through constraints over system quality of service properties. .Utility-based: Goal-based planners categorize the current con¯guration of the system into two possible states: desirable when the goals of the adaptation are satis¯ed and undesirable when the goals are not satis¯ed.However, it is not always possible to satisfy all goals of the adaptation at the same time or exactly specify the goals of adaptation.Therefore, the goal of planning can be changed to keeping the system at the most desirable state.In such cases, a utility which is a quantitative value representing the desirability of the current system variant in the current context is de¯ned for the system [73].This utility is approximated by a utility function over the properties of the system and the system context.Similarly, the best action is usually chosen using a heuristic which approximates the e®ect of each action on the utility of the system.For example, in [46], the planner of an adaptive travel assistant mobile application uses a utility function to approximate the ful¯llment of user preferences in di®erent situations.This prediction function is used to ¯nd the con¯guration of the system which has the highest predicted utility.In another example [74], the problem of feature con¯guration is represented as multiobjective optimization with various criteria and then di®erent multiobjective evolutionary algorithms are used in order to ¯nd the best con¯guration for that feature model.
(v) Transformation: In the DSPL adaptation managers which perform planning on the feature level, the planner speci¯es the target con¯guration of the system in terms of features other than architectural con¯guration which necessitates a linking strategy between feature and architectural con¯guration of the system.This mapping is usually addressed by a transformation mechanism which can create target architectural con¯guration of the system based on the selected features.A similar situation arises in the SPLE product con¯guration, where target product con¯guration is speci¯ed in terms of features.There are some work in SPLE which focus on relating the variability space model of the system to system code [75,76] or its architectural model [77][78][79][80], or its domain speci¯c modeling language in the design of a planner [81].DSPL engineering approaches have been inspired by such SPLE approaches in their development of a transformation mechanism between feature con¯guration and the architectural con¯guration at runtime.Here are three approaches used for this purpose: . Direct link: One simple way of linking models at two levels is to create a direct mapping between the features in the high level model to the architectural model in system implementation [82].Consequently, the architecture model of the system after adaptation can be built by selecting the fragments of the architecture model that are mapped to the selected features of the system.However, this type of linking is not practical in certain cases, because direct mapping between features and the architectural model fragments would not exist [82].In these cases, the linking between the feature model and the architecture model can only be enabled if the feature model is built considering the architecture.However building the feature model by considering the architecture does not provide proper separation of concerns.An example of using direct link for relating these two models is the MoRE approach [16], where the link between features and architecture model of the system is de¯ned by a superimposition operator which takes features as input and returns the components and connectors which should be active. .Aspect model weaving: Model-Driven Development (MDD) techniques allow for the automated generation of detailed architecture models from high level designs.Specially for creating a detailed architecture model from the con-¯gured feature model, aspect model weaving can be used as presented in SMARTADAPTERS [83] and Kompose [84].In these approaches, system architectural commonalities are represented in a base model.To create the ¯nal model of the system, each feature is mapped to a set of aspect models which are then woven into the base model if that feature is selected in the feature model con¯guration of the system.For example in [85], this approach was used to build an adaptive home automation system for dependent people.
In their system, the authors de¯ned a pointcut model representing, where an aspect could be woven into the system and an advice model which represents what can be woven at joint points.When the system adapts, the advices are woven into the pointcut model according to the weaving directives. .Transformation rules: In this linking strategy, in addition to the feature model of the system, an alternative feature model is de¯ned over the variability of the architecture model such that all possible variants of the architecture model could be represented by that feature model con¯gurations.Subsequently, this feature model is linked to the main feature model of the system using a set of transformation rules.The con¯guration for the feature model over the architectural model can be found using these transformation rules whenever a feature model con¯guration is available.For example, in [86], this approach was used to link between features of the system and the architecture model in an adaptive video surveillance system.The system was modeled using two feature models one on the features and another on the components.These two models were linked using a set of rules represented using propositional logic.
When the system adapts, the planner ¯nds a con¯guration for the feature model over components satisfying the rules using a SAT solver.

Execution
In traditional software product lines, the target system is developed and deployed after its con¯guration has been speci¯ed.But adaptation manager in DSPL should recon¯gure a running instance such that current variant gives its place to the target variant while ensuring system consistency.The execution step is responsible for this part of system adaptation.The planner provides the architecture model of the target system to the execution steps.The architecture model speci¯es the con¯guration of architectural entities (e.g.components, services, connectors) and how they are put together.The execution step uses a runtime recon¯guration mechanism to safely introduce, remove, or modify variation entities.The variation entities are those architectural entities by which adaptation is made possible through adding, removing, or modifying them.The selection of architecture model, variation entity, and runtime recon¯guration mechanism is a®ected by the architectural style which has been selected for the system.Figure 5 shows these dimensions and some of their possible values which we review in the remainder of this sub-section.
(i) Architecture model: When an adaptation occurs, the planner should provide the con¯guration of the target variant of the system to be used for the actual recon¯guration.This model is an abstract view of the system with which all possible variability of the system can be represented.In other words, it is detailed enough so that every possible adaptation which the planner can perform can be re°ected in it.This model is used by the recon¯guration mechanism to ¯nd points in the system which should change as a result of adaptation.
. Custom languages: Since this model of the system is available at runtime, it should be abstract to enhance memory and processing e±ciency.Therefore, approach-speci¯c models are de¯ned in some cases [12,16].For example, in MoRe [16], an architecture model named PervML [32] has been proposed and adopted, where only the component and their connections are represented as a graph.Some other approaches [24,27] use the architecture model which is used by the adopted recon¯guration middleware to de¯ne the system Fig. 6.The taxonomy for dimension related execution step.architecture.Fore example, in [12], OpenCOM DSL which is used by the OpenCOM middleware to specify system architecture is used. .Process modeling languages: Business process modeling languages are widely used for de¯ning how services interact in order to ful¯ll the requested functionality of the system.This models is usually abstract enough for representing structure of the system for planning and used in some approaches as architecture model of system.For example, the system adapts dynamically by changing the process that de¯nes the service interaction in [11], which is expressed using the BPEL. .Architecture description languages (ADL) this type of formalism is used for conceptually specifying architecture of the system.This model is used by system architect to design the system in the high level and therefore can be used for representing system architecture by a planner.For example, in [87], an ADL is proposed for dynamic service-oriented product lines which allows representing variability of architecture as well as structural elements and con¯guration of it.
(ii) Architectural style: Architectural style de¯nes the highly granular entities of the system and how they are connected to each other.Although, selection of architecture style is not directly related to adaptation, the selected architecture style a®ects the selection of architecture model, variation entity, and runtime recon¯guration mechanism.Therefore, we have considered it as one of the dimensions.In the following, we discuss the suitability of two of the most common architectural styles for use in DSPL engineering approaches: . Component-based: In component-based architecture, components communicate through connectors to provide the required functionalities of the system.Although components are built to work independently from their context, they are not usually designed to be recon¯gurable at runtime.Thus, architectural pattern have been proposed to facilitate runtime variability [1,88].Gomma et al. [22] propose a process for developing a component-based DSPL, where the architecture is built using reusable architectural patterns (such as master/slave, client/server), and for each of these architectural patterns, a speci¯c recon¯guration pattern is de¯ned.Modeled with state and scenario-based models, these recon¯guration patterns provide a safe mechanism for recon¯guration. .Service-oriented: Both service-oriented architectures and software product lines share the common goal of reusing existing assets for developing new products.A number of approaches have already been proposed for developing service-oriented product lines [89][90][91][92].Service-oriented architecture has also been used for developing dynamic recon¯gurable systems because, it eases the dynamic composition of self-contained and loosely-coupled services [2,46,93].
Considering the motivations for using service-orientation both for software product lines and dynamic recon¯gurable systems, there have been a number of works that developed service-oriented DSPLs [11,16,27,42,[94][95][96].
Cetina et al. [16] propose a service-oriented DSPL engineering approach for pervasive systems (e.g.Smarthomes).Pervasive systems are highly dynamic in nature since new entities are frequently introduced to the system or removed.In their approach, Cetina et al. de¯ne two categories of components: devices and services which implement system functionality.These components are connected using communication channels.The system adapts by activating/ deactivating both services and communication channels. .Service component architecture: This hybrid architecture tries to combine components-based and service-oriented architecture in order to take the bene¯ts of both of them.In this architecture, the functionalities are provided by components which their interfaces are de¯ned as services.Therefore components interact by calling each other's services.This architecture takes advantage of service-oriented systems bene¯ts such as well-de¯ned communication interfaces, simpler integration, and dynamism in context of component-based environment.For example [27] adopts this approach in order to facilitate dynamic binding and unbinding of components at runtime.
(iii) Variation entity: Variation entities are parts of the system that change when the adaptation is carried out.The type and the granularity of the variation entities a®ect the type of adaptation which is supported by the system.
. Components: According to the de¯nition of a component by Szyperski [97], components can be deployed independently, and their context dependencies are always speci¯ed explicitly.This disconnection of the component from its environment allows the component to be used as the variation entity in the adaptation.However, it has been argued that components do not have the same granularity as features most of the time [69] and they may be more coarse or ¯ne grained.In order to support feature realization with a higher granularity than that seen in components, recon¯guration can be de¯ned over a component collection.For example, in the Genie approach, a collection of components which address a speci¯c area of concern is called a component framework.Component frameworks act as the variation entity in adaptations.One concern with using components as variation entities of the system is that certain features do not have corresponding components at the component level.For example, the implementation of an authorization feature may be distributed between multiple components.Another concern with using components as variation entities is in maintaining states of the components as they are replaced with other components while the system adapts. .Aspects: Aspect-oriented programming and dynamic aspect weaving can be used in order to enable runtime recon¯guration in a DSPL adaptation platform.However, e®orts for using aspect-oriented programming in both software product lines and DSPL have shown that this approach may lead to certain problems [11,98].Features are more abstract than aspects, and a feature may be represented by many aspects; therefore, handling the linking between the features of the system and the aspects may become unmanageable.In an example of using aspects for realizing features [99], each feature is implemented by a set of aspects.These aspects are implemented following a set of design patterns in order to enable both static and dynamic binding of the features in a system. .Services: Services can be simply deployed into a system and easily composed with each other.They also have characteristics such as being loosely coupled, self-describing and having well-de¯ned interfaces which make them viable candidates for runtime adaptive systems.For example, Rouvoy et al. [46] used services as the variation entities for ubiquitous environments, where new services constantly enter and leave the system.Additionally, alternative third-party services can be discovered and added to the system so they enable open adaptation, where the system can evolve into new variants which have not been considered at design time.However, a problem of using services as recon¯guration entities appears when we attempt to de¯ne the links between services and system features.Similar to components and aspects, services are not the most accurate representatives of the features in a system. .Connectors: Connectors de¯ne how the constituent elements of a system are connected together.The connectors in a system could be glue codes, communication channels, or work°ows.The connectors usually de¯ne the °ow of the data in the system.Therefore, they are selected as the variation entity when the °ow of data de¯nes the behavior of the system.Examples of this function for the connectors may be encountered in data processing systems (e.g.video ¯lters [65,86]) and business processes [88,100].An example of using connectors at runtime adaptation is the MoRe framework [22], where connectors activate/deactivate in order to introduce new services and devices in a Smarthome application.
(iv) Runtime recon¯guration: In order to execute the actual adaptation actions, the execution platform should provide the ability to modify the architectural con¯guration of the running system (such as the binding and unbinding of the components) and observe the running system's architectural con¯guration.These functionalities are usually provided by an application-independent middleware which frees the system from dealing with actual adaptation concerns by taking responsibility for performing the adaptation while providing interfaces for managing that.These middleware usually work by implementing a re°ection mechanism.Re°ection in the middleware [101] is the ability to provide introspection and intercession.A re°ective middleware provides a model of the system which allows for any system change to be re°ected on the model and likewise for any change on the model to be re°ected on the system.Therefore, the planner can access the representation of the architectural con¯guration of the system using this model (introspection).It can then recon¯gure the system by modifying this model (intercession).In this dimension, two of the mechanisms used by middleware that enable runtime recon¯guration in the system is reviewed.
. Component model: A component model is a de¯nition of the semantics and syntax of components which show what they do, how they are structured and how they are composed [102].A system can recon¯gure at runtime if the architecture and its component conform to a component model that allows runtime recon¯guration.For example, OpenCOM middleware [31] uses a component model for enabling runtime recon¯guration in the system.This middleware is used in the Genie tool for developing DSPLs.OpenCOM is a re°ective middleware which supports hierarchical implementation of the system using component frameworks.Component frameworks are sets of components addressing a speci¯c feature of the system.The Fractal component model [103] is another hierarchical component model that can be extended and customized.The OSGi framework [104] is yet another component model which works on services and supports runtime installation, starting, restarting and uninstallation of services. .Dynamic aspect weaving: Dynamic aspect weaving can be utilized to modify the aspects of the system at runtime.This ability can be used to adapt the system when the variation entities of the system is aspects [105].For example, in [106], features are implemented using dynamic aspects in AspectJ [107].These dynamic aspects are added or removed at runtime using dynamic aspect weaving.In another work, Baresi et al. [11] used dynamic aspect weaving in a business process to add/remove features at runtime, which were represented with aspects of BPEL code.

Comparing DSPL engineering approaches using the proposed framework
Table 3 shows the value of each dimension in our framework for each of the approaches that have been reviewed.In this table, columns show the MAPE-K loop steps and their respective model and mechanism dimensions and rows indicate the reviewed DSPL engineering approaches.
In the following, we use Table 3 to compare each of the selected approaches: Baresi et al.In this work adaptation planning is performed by a human expert through a user interface.As a result, monitoring and planning steps are not applicable to this approach.In addition, considering BPEL code as the variation entity is a distinctive feature.This has necessitated the use of dynamic aspect weaving as the runtime recon¯guration mechanism.However, the adoption of BPEL as variation entity restricts this engineering approach's application domain to systems which can be designed and implemented through business processes.
Bencomo et al. (Genie): The notable design decision in this approach is the use of two variability space models.Enumeration is used for de¯ning the context variability whereas variation points are used for determining the architectural variability of the system.These two variability models are linked directly using the OVM.Furthermore, planning is di®erent from other approaches as it is de¯ned by a state transition  diagram.These two features create an intiutive and simple adaptation management mechanism.As a drawback, however, the management of context variability and its link with the architectural variability becomes more di±cult as the system grows.
Cetina et al. (MoRE): In this approach, OWL is used to develop the context model of the system.The approach enables complex context reasoning using the SPARQL language.Another notable dimension of design in this system is the use of connectors as variation entities.This is specially useful in the context of Smarthomes, where new devices are introduced at runtime.

Floch et al. (MADAM):
The use of utility-based planning is a distinctive feature for this approach.The planning model for this approach is a utility function which is de¯ned over the architectural con¯guration of the system.The application of the utility-based approach liberates the adaptation manager designer from the task of explicitly de¯ning adaptation actions such as ECA rules and transition diagrams.However, de¯ning a precise utility functions is rather complex.

Gomaa et al. (REPFLC):
The distinctive feature of this approach is that it uses ECA rule planning such that the rule actions work directly on the architecture of the system.These rules are part of recon¯guration patterns which are de¯ned in the domain engineering process.As these recon¯guration patterns are directly applied to the architecture itself, de¯ning a transformation mechanism or architecture model becomes unnecessary.However, the design of these recon¯guration patterns is an arduous task since they directly impact the system's architecture.
Morin et al. (DiVA): The approach suggests a general architecture with °exibility for planing and execution.This allows the selection of appropriate planning and execution mechanisms based on the condition of the application domain.Additionally, this model uses the WildCAT context-sensing middleware which provides EQL, a language capable of querying the values for context reasoning.
Parra et al. (CAPucine): This approach uses the COSMOS framework in order to enable context-awareness.Additionally, as its important feature, this approach uses aspect model weaving to create the architecture model of the target system.This allows the system developer to de¯ne more complex relationships between the feature model and the architecture model of the system.However, the same also necessitates the design of rather more complicated (as a result, harder-to-maintain) aspect models.One other notable design decision, in this approach, is the selection of SCA as the architectural style, which takes advantage of several bene¯ts of both serviceoriented and component-based architectural style.

Guidelines for Selection of a DSPL Approach
Our proposed framework can be used for aiding one in selecting or designing a DSPL engineering approach.In order to adopt or develop a DSPL, one can select appropriate values for di®erent dimensions of the proposed framework according to the speci¯c needs of the problem domain.The selection of possible values for this framework is mostly reliant on the type of adaptation sought.This can be called expected DSPL speci¯cation.Then, the DSPL speci¯cation can be compared with the speci¯cation of existing approaches to ¯nd exact or partial matches, where models and mechanisms can be borrowed in order to build a new DSPL engineering approach.
In the following, we provide general guidelines for the selection of appropriate values for di®erent dimensions of the framework organized by the steps of the MAPE-K loop.Additionally, we discuss how selecting di®erent values for the dimensions a®ect adaptation properties of the ¯nal product whenever possible.
. Monitoring and analysis design À Context model: Design of a context model is mainly determined by properties of the context and aspects of those properties that are signi¯cant for the planner.These aspects include context properties history, quality, and interrelation, among others.Using property-sets for representing context provides simple yet e±cient solution which can be simply extended to represent those aspects.However, using ontologies provides a new set of capabilities for the context model which cannot be easily achieved using property-sets.For example, it allows semantic reasoning on the context model and enables possible sharing of context information between di®erent systems which can be useful in the case of decentralized adaptation when multiple agents work together to plan an adaptation.À Context reasoning model: Since the reasoning model is used to analyze the information represented by the context model, the selection of a reasoning model is essentially a®ected by the context model.For example, using ontologies for representing the context model calls for using semantic reasoning and therefore semantic reasoning models.However, the complexity of a context reasoning mechanism and as a result its reasoning model depends on the analysis required for the operation of the planner.This could range from a simple rule-based mechanism, where reasoning model would be simple rules such as thresholds, to complex machine learning mechanisms where a large number of context properties are considered at the same time to speculate about the context situation.À Context sensing: Generally, the design or adoption of a context sensing mechanism is mostly reliant on the sources of the changes resulting in an adaptation (e.g.context, system, or user), its type (e.g.functional, non-functional or technological) and the system platform (e.g.software or hardware) [37].We refer the interested reader to guidelines and taxonomies currently existing in the literature [93,108,109].
. Planner design À Variability space model: Variability space model can be used to represent a system variability in terms of its context, its features, or its architecture.Two or more variability space models can be used in a system to show its variability from two aspects at the same time.Di®erent variability space models may suit different aspects of the system.For example, in [13], enumeration is used to represent context variability while variation points are used for architecture variability.One other notable factor a®ecting the selection of a variability space model is the complexity of variability in the system.For example, although enumeration works e®ectively when the number of system variants is limited, it is not e±cient in systems with higher number of variants.À Planning model: Since the type of planning model is mainly speci¯ed by the planning type used in a DSPL engineering approach, we have incorporated discussion about it in the planning type part.À Planning level: Deciding on the features of the system separates planning concerns from implementation requirements.Such separations will result in a more elegant and readily understandable adaptation logic, which allows easier extension as it is less likely to be faulty.Furthermore, planning at the feature level is closer to the procedures in an SPL engineering process and has the bene¯t of easier adoption when an SPL engineering approach is extended to DSPL.However realizing this separation will require a mechanism to link highlevel features to the architecture level details.Developing a mechanism that creates this link is not generally e®ortless and will result in overhead at runtime.À Planning type: If planning is not autonomous and the variants of the system are selected by an external entity such as the user, planning does not necessarily need to be implemented in the system.Otherwise, the type of planning for the system depends largely on the type of the goal that is pursued by the adaptation.In cases, when the system adapts in a limited way and this adaptation can be speci¯ed at design time, rule-based approaches seem to be the better option for adoption.In circumstances, when the adaptation of the system may not be speci¯ed at design time and can only be ¯gured out at runtime according to speci¯c situations, goalbased and utility-based approaches are the more appropriate choice.Goal-based approaches are suitable when the goal of the adaptation is to enable the system to self-con¯gure and self-heal, and it can be speci¯ed formally.Utility-based approaches seem to be the better ¯t for a self-optimizing context when the desirability of the system can be speci¯ed with a quantitative value.Another important aspect in selecting the planning approach is the impact of the approach on the regular operations of the system.Factors such as criticality, overhead, reliability and resilience of adaptation should be taken into account when a planning approach is selected.For instance, rule-based approaches usually have less overhead on the system which should be considered in the running environments when system resources are limited.Given their easy veri¯cation at design time, rule-based approaches are generally more reliable.However, it should be noted that veri¯ers do exist that can be used to validate adaptation at runtime using methods such as simulation or model checking [23,110].À Transformation: The direct link between a system's feature model and its architectural model is simple to understand and establish.Since the features and architecture part of the system have di®erent natures, this mapping does not always exist.However, the limitation can be bypassed if the feature model is built by considering system architecture.In more complicated situations, more complex approaches such as transformation rules and aspect model weaving should be used.It is sometimes necessary to run a SAT solver at runtime when transformation rules are used.Running the SAT solver at runtime increases the adaptation overhead.Furthermore, developing and maintaining consistent aspect models which are used by aspect model weaving is itself an arduous task considering that aspect models are hard to understand.One other di®erence which should be considered when selecting a mechanism is that the direct link and aspect model weaving mechanisms do not address the implementation of cross-cutting variation (e.g.inclusion of a component excludes the existence of another one), while cross-cutting variation can be addressed using integrity constraints over feature models when transformation rules are used.
. Execution design À Architectural model: The architectural model works as a basis for changes performed by runtime recon¯guration middleware of a system.Use of an architectural model understandable by the recon¯guration middleware facilitates the adaptation process.Otherwise, additional transformation from architectural model produced by the planner to a model or a set of actions understandable by the runtime recon¯guration middleware is necessary.One other factor which should be considered in the selection or adoption of an architectural model is selection of appropriate level of abstraction, where all possible architectural variants of system can be expressed while unnecessary implementation related details are removed.Using appropriate level of abstraction for architectural models reduces the complexity of the planner.À Architectural style: The dynamism of a system is in°uenced by the architectural platform upon which the system is built.In systems with a componentbased architecture, behavioral and component adaptation can be performed by changing component parameters or by replacing a component with another component with the same interface.Yet, the component dependency in a component-based architecture usually prevents architectural adaptation.Therefore, an architectural pattern (e.g.C2 [111], Weaves [112]) should be used in order to enable architectural adaptation, which may not always be feasible.Furthermore, the service-oriented architecture is built on loosely-coupled services by explicitly de¯ning the manner in which these services interact using work°ow services, business process languages, or communication channels.Similarly, component adaptation can be achieved by replacing a service with another service with the same interface while architectural adaptation can be performed by changing services interactions.À Variation entity: Similar to the architectural platform, the selection of a variation entity depends on the degree of the dynamism required for the system.In the problem domains, where component adaptation satis¯es adaptation requirements, the variation entity is usually a component or a service.In cases, where an architectural adaptation is required, connectors such as channels should be adapted in addition to components and services.In the context of DSPL engineering and feature-based planning, aspects have smaller granularity than features, and implementing features using aspects would be e®ective.However, in order to adapt the system at feature-level at runtime, aspects can be used to modify code of the connectors (e.g.work°ow speci¯cation languages such as BPEL which work on services).Another important factor in selecting the variation entity of the system is state preservation; components usually have a state which should be preserved if the component is replaced with a new component.Component state preservation requires a supporting mechanism (such as [22,113]).However, services can be implemented in a stateless manner such that any adaptation over them does not a®ect the state of the system.À Runtime recon¯guration: The selection of runtime recon¯guration mechanisms is a®ected by the variation entity as well as the dynamism required for the adaptation.Dynamic aspect weaving is used when the variation entity is an aspect.Otherwise, other mechanisms are used to enable runtime recon¯guration (e.g.component models).Considering that the planner in a DSPL usually operates on the model of the running system, the middleware which is used for enabling runtime recon¯guration should support re°ection or allow extension for supporting re°ection.Extendibility of the middleware and its component model is usually essential.The component model usually needs to be extended to allow for sensors to be placed within the system or to implement mechanisms for getting and setting component state information.

Summary
With the burgeoning demand for runtime adaptation in emerging applications, the ¯eld witnesses considerable increase in research.However, developing runtime adaptive systems is considered a complex and challenging task, and existing knowledge in the ¯eld requires more research for a wide range of approaches.DSPL engineering approaches suggest the use of extensive product line engineering variability models and mechanisms for the management of runtime adaptation.Research in this area has shown that DSPL is a promising path for developing new solutions.This paper has focused on providing a comprehensive framework for comparing di®erent DSPL approaches as well as a set of guidelines used to select the appropriate one.We studied these approaches from two perspectives namely adaptation properties and adaptation realization.Di®erent properties of adaptation for a DSPL engineering approach were then reviewed.A framework for comparing adaptation realization in DSPL was consequently proposed.In this framework, the adaptation management was seen as a MAPE-K loop, and a taxonomy for adaptation realization was developed.Using this framework, seven prominent DSPL engineering approaches were compared.Additionally, guidelines were introduced to create the link between the adaptation and its realization properties by outlining dimension values for realization scenarios which best suit di®erent types of adaptations.

Fig. 5 .
Fig. 5.The taxonomy for dimension related planning step.

Table 1 .
Summary of the selected approaches.

Table 2 .
Adaptation dimension of DSPL engineering approaches.

Table 3 .
Features of di®erent DSPL engineering approaches.Re-use and distribution is strictly not permitted, except for Open Access articles.