Architectural evolution of FamiWare using cardinality-based feature models

Information and Software Technology 55 (2013) 563–580

Contents lists available at SciVerse ScienceDirect

Information and Software Technology

journal homepage: www.elsevier .com/locate / infsof

Architectural evolution of FamiWare using cardinality-based feature models

Nadia Gamez ⇑, Lidia FuentesDpto de Lenguajes y Ciencias de la Comunicación, Universidad de Málaga, Spain

a r t i c l e i n f o

Article history:Available online 16 July 2012

Keywords:Middleware familySoftware Product LinesFeature ModelsEvolution

0950-5849/$ - see front matter � 2012 Elsevier B.V. Ahttp://dx.doi.org/10.1016/j.infsof.2012.06.012

⇑ Corresponding author.E-mail addresses: [email protected] (N. Gamez), lff

1 http://www.aal-europe.eu.2 http://www.ewh.ieee.org/tc/its/.

a b s t r a c t

Context: Ambient Intelligence systems domain is an outstanding example of modern systems that are inpermanent evolution, as new devices, technologies or facilities are continuously appearing. This means itwould be desirable to have a mechanism that helps with the propagation of evolution changes indeployed systems.Objective: We present a software product line engineering process to manage the evolution of FamiWare,a family of middleware for ambient intelligence environments. This process drives the evolution of Fam-iWare middleware configurations using cardinality-based feature models, which are especially well sui-ted to express the structural variability of ambient intelligence systems.Method: FamiWare uses cardinality-based feature models and clonable features to model the structuralvariability present in ambient intelligence systems, composed of a large variety of heterogeneous devices.Since the management evolution of configurations with clonable features is manually untreatable due tothe high number of features, our process automates it and propagates changes made at feature level tothe architectural components of the FamiWare middleware. This is a model driven development processas the evolution management, the propagation of evolution changes and the code generation are per-formed using some kind of model mappings and transformations. Concretely we present a variabilitymodelling language to map the selection of features to the corresponding FamiWare middleware archi-tectural components.Results: Our process is able to manage the evolution of cardinality-based feature models with thousandsof features, something which is not possible to tackle manually. Thanks to the use of the variability lan-guage and the automatic code generation it is possible to propagate and maintain a correspondencebetween the FamiWare architectural model and the code. The process is then able to calculate the archi-tectural differences between the evolved configuration and the previous one. Checking these differences,our process helps to calculate the effort needed to perform the evolution changes in the customized prod-ucts. To perform those tasks we have defined two operators, one to calculate the differences between twofeature model configurations and another to create a new configuration from a previous one.Conclusion: Our process automatically propagates the evolution changes of the middleware family intothe existing configurations where the middleware is already deployed and also helps us to calculatethe effort in performing the changes in every configuration. Finally, we validated our approach, demon-strating the functioning of the defined operators and showing that by using our tool we can generateevolved configurations for FamiWare with thousands of cloned features, for several case studies.

� 2012 Elsevier B.V. All rights reserved.

1. Introduction

Recently, pervasive systems and Ambient Intelligence (AmI) [1]environments have gained in popularity to support people’s dailytasks. These systems are composed by a large variety of networkedheterogeneous devices with embedded software. For instance,Ambient Assisted Living1 (AAL) systems or Intelligent Transportation

ll rights reserved.

@lcc.uma.es (L. Fuentes).

Systems2 (ITS) can be formed by a large number of sensor nodes(grouped in Wireless Sensors Networks, WSNs [2]), smart phones,vehicles onboard computers or other devices with RFIDs or cameras.

From the point of view of engineering such systems, the develop-ment and deployment of AmI applications can be considered a verycomplex task, since they pose several distinct requirements, com-pared with traditional information systems. Some of these require-ments are critical resource limitations of nodes, the heterogeneity ofnodes, the management of a high variety of routing protocols be-tween the nodes and the low-level programming abstractions nor-mally used [3]. One of the alternatives being proposed to face suchrequirements is the development of a middleware. Middleware is

http://dx.doi.org/10.1016/j.infsof.2012.06.012

mailto:[email protected]

mailto:[email protected]

http://www.aal-europe.eu

http://www.ewh.ieee.org/tc/its/

http://dx.doi.org/10.1016/j.infsof.2012.06.012

http://www.sciencedirect.com/science/journal/09505849

http://www.elsevier.com/locate/infsof

564 N. Gamez, L. Fuentes / Information and Software Technology 55 (2013) 563–580

a class of software technologies designed to help manage the com-plexity and heterogeneity inherent in distributed systems [4]. It isthe software that helps an application to interact or communicatewith other applications, networks, hardware, and/or operating sys-tems. This software assists programmers by relieving them of thecomplex connections needed in a distributed system. It providestools for improving the quality of service, security, message passing,directory services, file services, etc. that can be invisible to the user[5]. Middleware platforms could play a key role in hiding the com-plexity and heterogeneity of lightweight devices connected viahigh-speed networks, by providing specific high level services (e.g.location, context-awareness, security, etc.) to support and facilitatethe development of AmI applications. But, instead of developing asingle middleware as usual, in our previous work we defined a familyof middleware for AmI systems (FamiWare [6,7]), following a Soft-ware Product Line (SPL) approach. The basis of this is that in theAmI application domain heterogeneity is present at any level, so itcan greatly benefit from SPL engineering [8], since it is specificallyfocused on variability modelling [9].

SPLs aim to provide techniques for creating infrastructures thatallow the rapid and systematic production of similar software sys-tems, promoting the reuse of common core assets. Feature Models(FM) [10,11] have been widely adopted by the SPL community tospecify which elements, or features, of the family of products arecommon, which are variable and the reasons why they are variable,i.e. if they are alternative elements or optional elements. Therefore,a feature model permits specifying where the variability is, inde-pendently of to the core asset, and enables reasoning about allthe different possible configurations of a family of products. Thus,we have used the SPL approach, to characterize the inherent vari-ability of the AmI domain using feature models.

According to the characteristics of AmI environments, Fami-Ware will be deployed in a networked system composed by a het-erogeneous set of AmI devices. This means that AmI environmentshave structural variability, defined as variations in type, cardinalityor naming of elements [12]. For instance, an AmI system can bemade up of 50 sensors, where 40 of them (cardinality variability)are MICAz motes (type variability) and 10 of them are Sun SPOTs,where each one must have its corresponding identification (namingvariability). We propose using cardinality-based features modelsand clonable features [13] to model the structural variability pres-ent in the AmI middleware domain. A clonable feature is a featurethat has [n..m] cardinality, then in a feature model configurationthat feature can appear from n to m times, i.e. it can be cloned thatnumber of times. Each feature cloned as part of the feature modelconfiguration, is called clone. The use of clonable features increasesthe expressiveness of feature models since they allow the creationof configurations where for each clonable feature (e.g. a device) it ispossible to include different configurations for each clone (e.g. oneconfiguration for a MICAz sensor device clone and another one fora Sun SPOT device clone). Concretely, in FamiWare we model thedevices as a clonable feature. The cloning of these device clonablefeatures leads to the cloning of the related structure (e.g. for 3 SunSPOTs sensor devices, the configuration will contain s1, s2 and s3clones of the device feature, joined with its sub-tree). This is veryuseful to model variability in AmI environments but increasesenormously the complexity of the resulting configurations, andmoreover the number of possible configurations increases a lot.

As required by the AmI domain, using this cardinality-based FMwith clonable features, we can model so that a system has a vari-able number of different kinds of devices (e.g. m TinyOS3 mote sen-sors, s Sun SPOT4 sensors, or sm smartphones). This cardinality-

3 http://www.tinyos.net4 http://www.sunspotworld.com

based FM is the basis of a model driven process that derives a Fam-iWare middleware configuration adapted to the requirements of allthe system devices. So, a FamiWare middleware configuration is com-posed by the individual middleware configurations of each net-worked device modelled as a clone. Each of the middlewareconfigurations deployed in each device only includes the specific ser-vices required by the device, adapted to its particular characteristics(e.g. network protocols) and to application necessities.

Once the FamiWare middleware is deployed, it will be continu-ously evolving, as new operating systems (e.g. Android5 for smart-phones) or special sensor units (e.g. new accelerometers) arefrequently appearing. Thus, FamiWare must be able to incorporatethese new devices or technologies into systems together with themiddleware already deployed. Furthermore, adding new functional-ity (e.g. a new and more efficient encryption algorithm or a new dis-covery service) required by a new system where the middleware isgoing to be installed, suggests performing the evolution of the wholefamily. This implies that this new functionality could be installed inalready deployed systems in order to make them more efficient or toprovide them with new facilities. In both cases, the changes of theevolved family must be propagated to the customized products ofthe family. Nevertheless, in these kinds of systems with a large num-ber of devices, each one with very specific characteristics the propa-gation of changes is very complex. Thus, it would be advantageous tohave an automatic process that supports the evolution changesmade in some characteristics of the middleware family to all the de-rived middleware products. Specifically, as the feature modelevolves, the impact of propagating changes made in the featuremodel to the possible configurations is much higher in a cardinal-ity-based FM. The evolution of a feature model may imply addingor removing a feature, which in a cardinality-based feature modelmay cause many changes in many clones. Furthermore, it wouldbe useful to know the effort required to make the changes in theproducts of the middleware family when the family evolves. Butthe challenge here is that in our AmI middleware, configurationscould have hundreds of clones making up a single middleware prod-uct configuration. Consider that many AmI systems have several in-stances of similar devices, but with different architectures.Therefore, both the propagation of changes and predicting the effortrequired to make those changes could be an unaffordable task to betackled manually.

In this paper, we present how we automatically manage theevolution of FamiWare using cardinality-based FM and clonablefeatures. To do this, in the scope of this paper we have extendedthe variability modelling language VML [14] in order to map thefeature model evolution changes to the FamiWare architecture. Afeature mapping between the FM and the Product Line Architec-ture (PLA) defines the correspondence between features and mid-dleware components. This mapping specifies which actions mustbe performed when some features are selected. These actionsrange from the setting of certain parameters to the inclusion/exclusion of certain components from a compilation unit. UsingVML we are able to create connections between components bymeans of interfaces and to remove them from a given architecture.However, in order to adapt it to the event-based [15] publish andsubscribe [16] FamiWare architecture [17] we have definedVML4FamiWare. With this extension we are able to expresswhether a service is a publisher or subscriber and which topic itwill publish or subscribe. In addition, with this language it is pos-sible to distinguish between different clones, and also specify thevalue of a parameter.

Furthermore, we have defined two operators between featuremodel configurations that are not trivial for cardinality-based FM

5 http://www.android.com

http://www.tinyos.net

http://www.sunspotworld.com

http://www.android.com

LegendMandatory FeatureOptional Feature

1..* Clonable FeatureXOR groupOR group

Fig. 1. Feature model with Hydra.

N. Gamez, L. Fuentes / Information and Software Technology 55 (2013) 563–580 565

[18]. The create_configuration operator allows the creation of a newconfiguration from a previous configuration and the features thatmust be added or removed in the new configuration. The differ-ences operator calculates the differences between two configura-tions of a feature model. We use the create_configuration operatorto create evolved configurations from the previous configurationand the evolved feature model. Furthermore, we use the differencesoperator to help the calculation of the effort of evolving the mid-dleware family, reusing and preserving the elements of the previ-ous configuration. Finally, we validate our approach showing thatby using our tool we can easily evolve feature models with clon-able features, automatically generating new configurations, forFamiWare configurations with a high number of clones. Further-more, we demonstrate the correctness of our operators.

The remainder of the paper is organized as follows. In Section 2,we present the FamiWare FM and the necessity of evolving themiddleware family. In Section 3, we show our approach and theVML4FamiWare variability language, and Section 4 details the dif-ferences and create_configuration operators. The validation and thetool support of our approach are presented in Section 5. In Section6, we compare our approach with related work. Finally, in Section 7we outline some conclusions.

2. Motivation

In this section, we first describe some background concepts offeature models and clonable features and how our own featuremodelling tool, called Hydra6, works with them and we introducea running example with a small feature model that help us to under-stand the concepts and the functioning of the operators described inSection 4. Then, we present FamiWare feature model and discuss thenecessity of evolution and the specific challenges of evolving AmIsystems.

2.1. Feature models with Hydra

In the feature-oriented approach, commonalities and variabili-ties are analyzed in terms of features. A feature is any prominentand distinctive concept or characteristic that is visible to variousstakeholders. The features can be organized into a feature modelthat represents all possible products of a SPL, where commonalitiesare modelled as mandatory features and variabilities as variablefeatures (alternative or optional). Furthermore, feature depen-dency analysis can identify constraints between features.

Fig. 1 represents a feature model in Hydra (all the feature mod-els and configurations presented throughout this paper are mod-elled using our feature modelling tool, Hydra). In a feature model[11] each feature has one parent except the root feature (as WSNin Fig. 1). The features can be mandatory (as Role), optional (asDataFusion, which represents the capability of fusing data gener-ated by sensor nodes) or clonable (as Sensor, that has a 1 to infinitecardinality) features. Apart from the features, Hydra also definestwo groups of features: xor-group (as the group composed by thekind of roles that a sensor must play: ordinary (Ord), cluster-head(CH) or Sink) and or-group. So in Hydra, we can distinguish twokinds of relationship: between a feature and its child features(and-relationship, as the relationship between the Sensor and itsRole or its Services) and between a feature and one group (as inthe relationship between the Role and the xor-group).

A configuration of a feature model is the selection of a set of fea-tures belonging to the feature model. A configuration is valid if allfeatures contained in the configuration and the absent features arecontained is allowed by the feature model [19,20]. Thus, a valid

6 http://caosd.lcc.uma.es/spl/hydra

configuration must satisfy the tree-constraints and the dependen-cies or interactions between features (cross-tree constraints). InHydra, the cross-tree constraints are expressed in a textual wayusing the combination of these regular expressions:

– Feature Constraint: f (it implies that this feature must beselected in a valid configuration).

– Unary Operator: neg f.– Binary Operators:f impliesg, f and g, f Or g.– Quantify Operators:� all f. It implies that f must be selected in all the clones in a

valid configuration (e.g. all Routing means that in all the sen-sors the Routing service must be selected).

� any f. It implies that f must be selected in at least one clone ina valid configuration (e.g. all DataFusion means that in atleast one sensor the Data Fusion service must be selected).

� N f. N is a positive integer which implies that in a valid con-figuration there must be exactly N clonable features fselected (e.g. 10 sensors means that there will be exactly10 node sensors).

– Comparison Operators: <,<=,=,=>,> are used to compare the num-ber of selected clones (e.g. Sink <=CH means that the number ofsinks must be less than or equal to the number of cluster-heads).

In order to check whether a configuration is valid, Hydra uses aJava library for Constraint Satisfaction Problems (CSP) [21–23],called Choco [24]. Hydra also permits the automatic generationof the minimal valid configuration given a set of initial constraints.This is the valid configuration with the least number of featuresthat satisfies these initial constraints. To do this, Hydra uses theCSP objective function to minimize the number of featuresselected.

2.2. FamiWare feature model

Fig. 2a represents the partial feature model of FamiWare in Hy-dra. The only clonable feature in FamiWare is Device that has a 1 toinfinite cardinality and represents the devices that can be presentin an AmI environment, as sensors or smartphones.

To illustrate our proposal, we introduce an Ambient AssistedLiving (AAL) home to enhance the quality of life of disabled or el-derly people. This kind of home may be equipped with sensors,smartphones, alarms, cameras, and other devices. The user’s neces-sities or the structure of the house are different for every customer,but both the tasks to be performed and the devices used are simi-lar. Therefore, instead of building a single product for each cus-tomer, these systems may take advantage of the benefitsprovided for SPL to build an AAL home by using the FamiWare mid-dleware family that also provides low level facilities to the applica-tions. Requirements for each customer must be specified, and theFamiWare customization process automatically obtains the config-uration of each specific product corresponding to each home. The

http://caosd.lcc.uma.es/spl/hydra

LegendMandatory Feature

Optional Feature

0..* Clonable FeatureXOR groupOR groupReferencedReference

(a)

(b)

(c)

Fig. 2. (a) FamiWare partial family feature model, (b) middleware configuration and (c) features of a sensor device.


home of our example is equipped with 12 sensors, 8 cameras, 4alarms, and 2 smartphones. Fig. 2b shows a valid FamiWare config-uration for this AAL home.

Fig. 2b represents all the devices in this configuration andFig. 2c depicts the configuration of a concrete device, a TinyOSmote sensor. Note that Fig. 2 does not show all the features ofthe FamiWare FM and of the configurations for the sake of sim-plicity. The home of our example has video surveillance facilitiesto transmit periodically video to the health center by means ofcameras. A user can communicate directly with the health centerthrough a smartphone. An automatic control of the lights andheat, as well as the handling of alarms is provided. Furthermore,all data transmitted must be encrypted. This configuration has 12basic sensors. For instance, sensor Sensor01 (Fig. 2c) is a staticTinyOS mote sensor whose development technology is nesC andradio technology is ZigBee. This sensor has movement, tempera-ture, and distance sensing units. It provides several services tomonitor the environment, to be aware of the context, to reconfig-ure the system, to deliver and to encrypt data. Similarly, the restof the sensors have the aforementioned or other sensing units,such as light, sound, and so on, and they provide some of the pre-vious services. The 4 alarms and 8 cameras represented in Fig. 2care also TinyOS motes, but special motes equipped not only withsensing units if not also with alarm actuators and camera devices,respectively. The 2 smartphones have Android operating system,and provide facilities to transmit the video received from thecamera to the health center, as well as to hold video-conferences.The UserBadge is a Sun SPOT sensor equipped with an accelerom-eter sensing unit to check the movements of a person.

2.3. Necessity of evolution

Normally, only a subset of the family variants are developed andmarketed. Later, these products are mainly subject to two evolu-tion scenarios: (1) the hardware and software technology for AmIis continuously evolving. New operating systems (e.g. Android forsmartphones) or special sensors (e.g. new laser accelerometers)frequently appear. So, FamiWare must incorporate these new de-vices or facilities into their already derived products, if the applica-tions require them; (2) a new system where the middleware willbe developed demands a new functionality (e.g. a new and moreefficient encryption algorithm or a new discovery service for theInternet of Things) for the family of middleware, so each productthat has already been developed may need to be evolved in orderto incorporate the new facilities.

Thus, when an SPL evolves, the changes must be propagated tothe customized products of the family. Nevertheless, in these kindsof systems with a high number of devices, each one with very spe-cific characteristics, the propagation of changes is very complex.So, we need an automatic process that supports the evolutionchanges made in some characteristics of the SPL to all the derivedproducts of the middleware family. We provide a tool support toautomatically propagate the changes made at feature model levelinto all customized configurations. Note that representing featuremodel configurations graphically with many cloned features willenhance the complexity of the representation and therefore thecomplexity of the management of the evolution. This is important,since some AmI systems may be composed of hundreds of devices,so it would be impossible to handle changes one by one manually.


Furthermore, since most AmI systems are composed of severalor many different clones of each device, this implies that evolutionchanges must be performed in every clone in a different way. Let usimagine that we want to remove the encryption algorithm of thesensors in our AAL home. But the middleware architecture maybe different for every sensor, and the encryption removal processis also different. Thus, it is necessary to evaluate the effort requiredto make the changes in the products of the family when the familyevolves, due to similar devices with different architectures. Weautomatically calculate the differences between a previous config-uration and the new evolved configuration for all the existing con-figurations. We use this difference, the feature model and amapping (using the extension of VML that we will present in Sec-tion 3.2) between every feature and the corresponding architectureto obtain which components of the architecture must be added orremoved in every device. In this way, we can help the quantifica-tion of the effort of evolving a product and the impact of changewhen the feature model evolves. This may also help the SPL engi-neer to assess the person months required to produce upgradedversions of previous middleware products.

However, AmI systems and devices have several restrictionsthat we have to take into account in order to manage the evolutionof such systems:

– Structural Variability: A special characteristic of AmI systems isthat many instances of the same kind of device may composethe same product, but each device, although being of the sametype may have a different middleware configuration. Thedevice infrastructure would be similar for all products, butmust be customized to the physical structure of, for instance,an AAL home or an ITS road. Such structural variability mustbe explicitly modelled in the SPL, but also its evolution mustbe part of a SPL engineering process. In FamiWare, we modelsuch structural variability with clonable features, and manageits evolution, not at the feature, but at the clone level. Then, aswe model every device as a clonable feature, the evolution isperformed for every particular device (i.e. at clone level). Forinstance, for the FamiWare configuration of the AAL homeshown in Fig. 2b, it is possible to evolve Sensor01 and Cam-era01 but not the rest of devices (others sensors and cameras,the alarms and the smartphones).

– Devices Compatibility: In AmI systems, the applicationsinstalled in all devices normally interact and collaborateamong each them. This means that the SPL process must guar-antee that the configurations running in each device of a cer-tain system are compatible with each other. An example ofcompatibility in the context of sensor nodes is that all of themhave to use the same routing protocol, otherwise the commu-nication is impossible. The SPL evolution process must ensurethat new configurations of different devices are compatible.We also use the cross-tree constraints to guarantee that theconfigurations of all the devices (i.e. clones) of a certain systemare compatible with each other (e.g. all sensors workingtogether use the same routing protocol or if one sensorencrypts its messages the receptor of these messages mustdecrypt them). This use of the constraints specified betweenclones makes it possible to specify which architectural ele-ments must be present in all interacting devices.

– Efficiency: As many AmI systems are composed of a large num-ber of devices (as hundreds or thousands of sensor nodes exe-cuting several sensing tasks), the number of configurations ofour middleware would be really high. The FamiWare FM con-figuration of a particular system may contain thousands offeatures due to the cloning of each device related structure(sub-tree) for every device. Thus, we must ensure that thetime taken by our tool support for creating new evolved

configurations or for searching the difference between theevolved and the previous configuration is acceptable for largeconfigurations. We define and implement two operators differ-ence and create_configuration paying particular attention toefficiency and as we will show in the evaluation, the executiontime is acceptable, being appropriate for thousands of fea-tures, typical of AmI systems, as an ITS having 500 devices.

3. Middleware family evolution

We have proposed an automatic process to derive differentFamiWare configurations depending on the input constraints,determined by mainly hardware and software requirements [6].We apply model-driven and SPL engineering techniques to auto-mate this configuration process (Fig. 3, label CONFIGURATION).In SPL terminology, the Domain Engineering (DE) phase deals withthe creation of the infrastructure from which specific or custom-ized products will be constructed. This phase needs to be carriedout only once per family of products, so we did this once for Fam-iWare. The next phase in SPL is the Application Engineering (AE). Itconcerns the creation of specific or customized products using theinfrastructure that has been previously created in the domain engi-neering phase and it must be performed each time we want toinstantiate a new product belonging to the family. Furthermore,if the family needs to evolve, we must update the infrastructurecreated at the domain engineering, as we will see later in this sec-tion (Fig. 3, label EVOLUTION).

At Domain Engineering, the first step is to analyze the intrinsicvariability of the application domain and create the feature model(Fig. 3, label 1). In the next step, the global architecture of the sys-tem (Product Line Architecture, PLA) is defined, which containscomponents implementing both the commonalities and the vari-abilities specified by the feature model (Fig. 3, label 2). A FeatureMapping between the FM and the PLA defines the correspondencebetween features and architectural components (Fig. 3, label 3). Inthis work, we have extended the variability modelling languageVML [14] to adapt it to the necessities of the mapping betweenour feature model and the FamiWare architecture. Apart fromthe abilities of VML, this new extended language, VML4FamiWare,is able to map the clones of each clonable feature into the architec-ture of the middleware for each specific device. Moreover, it is ableto express the composition between the architectural entitiesadapted to the Publish/Subscribe paradigm used by the middle-ware family [7]. Finally, it is able to express mappings between se-lected features and component parameters.

In the Application Engineering phase, the customization of thearchitecture is determined by a set of high-level parameters (e.g.number and type of sensors or the services required by the appli-cation) (Fig. 3, label 4). Using this set of parameters as input fea-tures, Hydra is able to automatically infer the rest of the featuresneeded for each product making use of tree and cross-tree con-straints (i.e. feature interaction), defined as part of the featuremodel. So the output of Hydra is then a configuration of a middle-ware product (Fig. 3, label 5) for a specific system device. Thismiddleware configuration and the mapping between the FMand the PLA specified in VML4FamiWare are the inputs of a mod-el transformation that automatically generates a customized Fam-iWare architectural model for every device (Fig. 3, label 6).Finally, this architectural model is the input of a model-to-texttransformation, which produces the code for deploying the spe-cific middleware to each device (Fig. 3, label 7). In the case ofFamiWare, the microkerenel and services are pre-implementedand previously proven, so the automatic code generation entailsthe selection of FamiWare middleware components and some ini-tialization code. So, the process does not generate code fromscratch, it reuses the FamiWare middleware components. Then,

Fig. 3. Configuration and evolution of FamiWare.


the part of code automatically generated is that corresponding tothe specific middleware configuration saying which version ofwhich services will be instantiated with which parameters andwhich topics will be published/subscribed. So far, our processgenerates code and deployment files for several platforms oroperating systems: TinyOS, Android and Sun SPOT. For TinyOS,it generates the high level configuration file (�.nc) with declara-tions and connections between the selected services and theMakefile, used to control the build process of a project. For An-droid, an Android Activity (�.java) is generated. This activity initi-ates the selected services by using Android Intents and calls theAndroid startService() method. Furthermore, our process gener-ates an Android Manifest (�.xml) with the needed middlewareinformation for the Android system. Finally, for Sun SPOT, theprocess generates a MIDlet (�.java) that initiates the selected ser-vices and the Manifest (�.mf) that declares these services. Fig. 6shows an excerpt of the code automatically generated by our pro-cess for a TinyOS sensor device.

However, the hardware and software technology for pervasivesystems is continuously evolving. New operating systems (e.g. An-droid for mobile phones) or special sensors (e.g. new accelerome-ters) are appearing too often. So, the FamiWare provider mustincorporate these new devices or facilities into the products al-ready derived, in order to be competitive in the market. In this sec-tion, we will detail how our process automatically propagates theevolution changes made in the FamiWare FM into current configu-rations, and we also help with the evaluation of the effort requiredto propagate those changes to the final FamiWare architecture.

3.1. Feature model evolution

As we have already said, the middleware family needs to evolvein order to satisfy new user or application requirements, such asnew facilities to achieve energy efficiency or enforce the securityof the system; or to incorporate new technological advances. Thesenew requirements are modelled as evolution scenarios imple-mented by means of modifications in the FamiWare feature model.We have identified what elements of the feature model maychange as a consequence of an evolution scenario: (i) adding orremoving features, (ii) adding or removing groups of features (oror xor-group), (iii) adding or removing constraints between fea-tures and (iv) modifying the variability of a feature (e.g. a manda-tory feature is transformed in optional). Note that the modificationof a feature can be defined by means of removing a previous fea-ture and adding a new one. The same happens with the modifica-tion of groups of features and with the constraints.

Let us imagine that we want to evolve FamiWare with a newsensing unit, a new laser accelerometer and its correspondingmonitoring service to sense the movement with this new device.This service is added as an optional feature and the new accelerom-eter unit is added as a child of the SensingUnits or-group (seeFig. 2b). Furthermore, we have added a constraint related to thesenew services, for example, MonMovLaser implies AccLaser� whichmeans that to use the monitoring of movement service with laser,the sensor node has to be equipped with this new sensing unit.Furthermore, a new more energy efficient routing protocol forWSNs has been developed for FamiWare, called AODV. So, we want


to provide the possibility to all the deployed systems with Fami-Ware to replace its routing protocol with this new one.

After evolving the feature model we have to propagate thechanges in all the previous configurations that could need thisnew accelerometer or require the new protocol. Our process auto-matically obtains the new configuration from the previous one, theevolved feature model and the requirements with respect to theevolved features for this specific middleware product. For the con-figuration shown in Fig. 2b, these requirements are, that the newlaser accelerometer and its monitoring service is required in someof the sensors and the new protocol is required for a certain sys-tem. The output of our process after this evolution will be the addi-tion of both of these new features in each sensor that requiresthem and changing the routing protocol in all the sensor devices.

Note that the FamiWare middleware is designed to be deployedin pervasive networked systems with hundreds of nodes, soaddressing the evolution of these apparently simple changes isnot a trivial task. In these kinds of systems the number of changesentailed in a single evolution scenario increases exponentially,since we have to apply the changes in multitude of sensors. There-fore, we need a tool support that creates this new configuration inan efficient way, considering that the number of features of AmIsystems may be really large. As is shown in Fig. 3, in order to auto-matically obtain this new configuration the Create Configuration(Fig. 3, label 9) facility of Hydra takes as input the evolved featuremodel (Fig. 3, label 8), the previous running configurations and theconstraints with the new requirements of this configuration for theevolved features (Fig. 3, label 10), and it returns new configuration.To implement the Create Configuration we use the create_configura-tion operator, defined in Section 4.

3.2. Evolution of existing configurations

In order to help with the evaluation of the impact of changewhen a FamiWare family is evolved, we need to know the specificdifferences between the previous configuration and the newevolved configuration. To do this, the Differences facility of Hydratakes as inputs the previous and, the new configurations and theevolved feature model and it returns the difference between con-figurations by means of a set of features that must be selectedand unselected in the new configuration. Obtaining the differencesof FM configurations with clonable features is not a trivial task,since it cannot be calculated as a simple difference of sets as couldbe done for normal feature models. So, in the following section wedefine a difference operator for the special case of FM configura-tions with clonable features. Our process then uses this differencesset of features and the mapping between FM and the PLA inVML4FamiWare to automatically see the architectural differences.

Thanks to VML4FamiWAre, it is also possible to automate thecustomization of the family FamiWare architecture in an SPL con-text. Using VML4FamiWare, we specify which actions must be per-formed on the architectural model when a certain feature isselected or unselected. We detail the extension of VML in the nextsubsection and after we will see the mapping of an evolved FMconfiguration with the FamiWare architecture.

3.2.1. VML4FamiWareAs previously mentioned, VML [14] is a variability language to

support SPL configuration processes for architectural models. Themain contribution of VML is that it provides automation at thesame time that it hides low-level details of general-purpose modeltransformation languages. Using high-order model transforma-tions, VML compiles a description of the configuration process intoa set of low-level general purpose model transformations, which,when executed, are able to customize the product line architec-tural model according to a feature selection. This allows the VML

to be used even by software architects without skills in modeltransformations. Using VML the mapping between the selectedfeatures and the components that must be instantiated can bespecified. However, it has some limitations when applied to Fami-Ware. In VML it is not possible to specify input parameters for thecomponents, it does not work with cardinality-based feature mod-els and it is not possible to express the event-driven communica-tion model of a Publish/Subscribe architecture like that ofFamiWare. Thus, we have extended the VML to adapt it to thenecessities of the mapping between our feature model and theFamiWare architecture, defining a new language called VML4Fam-iWare. Apart from the abilities of VML, this new extended lan-guage, VML4FamiWare, is able to map the clones of eachclonable feature into the architecture of the middleware for eachspecific device. Furthermore, it is able to express the compositionbetween the architectural entities adapted to the Publish/Sub-scribe paradigm used by our middleware family. Finally, it is ableto express mappings between selected features and componentparameters.

Fig. 4 shows the syntax of the extension that we have made fromVML to adapt it to our middleware architecture. VML considers themapping between the selection or deselection of some features andthe corresponding architectural actions. Apart from this, VML4Fam-iWare also considers the selection of a feature with cardinality (i.e.:a clonable feature) and certain clones of a clonable feature. Thus,the variant is made up by the selection of some regular features(without cardinality), clones or clonable features followed by thearchitectural actions to perform when those features are selected(line 01). Therefore, the selection refers to a combination of somefeatures (including clonable features) or the specific clone of a clon-able feature (line 03). The feature selection is one simple feature(that means that this feature is selected), the negation of a featureselection, or the combination (and or or) of two feature selections(lines 05–08). For example, Context_Awareness and (MonBattery orMonEnergy). When a regular feature (that is not under a clonedstructure) is selected, this means that this feature is selected forthe whole system and its corresponding architectural actions mustbe done for the system. However, if we want to refer to actions forsome specific clones, we have to use the clone selection in order toexpress the conditions of the clones of the clonable feature that weare talking about (line 10). For example, (nesC and MonMov) of De-vice. This means that the associated architectural actions have to beperformed for all the clones of Device that has the nesC and the Mon-Mov features selected (i.e.: all the TinyOS/nesC sensors with themovement monitoring service selected).

The architectural actions of the VML mean connecting two com-ponents through an interface and removing one component from acertain architecture (lines 16–17). We have added other architec-tural actions (lines 12–14). Firstly, to subscribe a service to a topicor to indicate that a service will publish a topic (lines 18–19). Sim-ilarly, to allow the service to unsubscribe and unpublish topics(lines 20–21). Finally, as AmI devices have very scarce resources itis normally desirable to be able to also specify fine-grained modifi-cations instead of only coarse-grained ones (i.e. replace compo-nents or services). Accordingly, VMLFamiWare allows for thespecification of a value for a specific parameter of a component orservice (lines 22–23).

3.2.2. Architectural mapping evolutionFig. 5a shows an excerpt of the mapping between some features

of our middleware feature model and the FamiWare architectureusing VML4FamiWare. We only include in Fig. 5a the mappingfor the features involved in the evolution scenario presented above,but in a full version of this VML4FamiWare file, all the featureswhich have any influence on the architecture are included. Lines01–05 excerpt of VML4FamiWare specify the architectural modifi-

Fig. 4. VML4FamiWare language syntax.

Fig. 5. (a) Mapping between Features and architecture with VML4FamiWare and (b) architectural evolution.


cations that must be performed in all the TinyOS sensors devices(nesC) that have the new monitoring service by laser selected(MonMovLaser). For these sensors the new service will be a pub-lisher that publishes the Movement topic and the application (AA-Lapp) must subscribe to this topic. The default frequencyparameter for sensing the possible movements is 60 s. In lines06–08, we define that the MonMov component must be removed

in all the TinyOS sensors with the feature MonMov not selected. Fi-nally, we connect the new routing protocol selected for all theTinyOS sensors with the DataDelivery component in lines 09–11and we remove other unselected protocols for instance the onein lines 12–14.

As we have previously explained, since the architecture in somesensors is distinct, how to add or remove some services or compo-


nents has to be defined exactly for each sensor. We illustrate this inFig. 5b for sensors Sensor10 and Sensor05. Sensor10 had a move-ment monitoring service installed, so before installing the newone, the older component must be removed. This action (line 07)does not have to be applied to Sensor05 that did not have anymovement monitoring service. Thus, this action does not influencethe Sensor05 architecture. However, all the other actions are thesame in both sensors (adding the new service, removing the previ-ous protocol and adding the new protocol). Finally, for all the sen-sors that do not have selected the new monitoring service, the onlyarchitectural actions that they must consider are the ones concern-ing the routing protocol (lines 09–14).

In this way, we show how we can automatically manage thearchitectural modifications in different clones of the same featurethat have different architectures for the same configuration. Thuswith our approach we can manage the evolution at clone level,and not only at feature level. In Fig. 5, we highlight only the com-ponents and architectural parts that are involved in the evolution.Taking the differences between the previous and the new architec-ture for all the devices, our process is able to infer the list of reusedcomponents, the list of reused components that must be modifiedand the new components that have to be implemented and in-stalled. These lists of components will help the architect to assessand evaluate, for each particular case, the effort required to evolveeach existing product when the feature model evolves.

Since our process addresses the architectural evolution usingfeature models, not specific to the architecture level, it does notdeal with possible mismatches between components after an evo-lutionary change. For instance, in FamiWare, the addition of newfeatures could entail: (1) the addition of a new implementationof an already defined service; or (2) the addition of a new servicenot previously considered in the SPL. In the first case (1), as the ser-vice interface is already defined at architectural level, the SoftwareArchitect must verify that the new service implements this inter-face accurately, which is not difficult. Note that this process man-ages the evolution at architectural level, so it does not deal withrunning code problems. This evolution scenario appears in Fami-Ware for example, when a new operating system emerges ontothe market. In this case, the kernel and some of the services ofFamiWare must be implemented for the new operating system.In the second case (2), a new service with its corresponding inter-face must be added to the product line. In this case, the serviceinterface must comply with the publish/subscribe architectural

Fig. 6. FamiWare code automaticall

pattern used by FamiWare. At architectural level, it is then possibleto verify that a service may be subscribed to a topic that no otherservice is going to publish. But, since we are focusing on evolution-ary changes of AmI systems with thousands of devices, the advan-tage of using our process is that the Software Architect knowsexactly the list of new components added to the architecture, sothat only their composition with the rest of the architecture mustbe verified. Likewise for components that disappear. Note that thisverification is out of the scope of our evolution process.

Finally, once the evolved configuration is obtained, our processautomatically generates the FamiWare code ready to be installedin every device. For instance, Fig. 6a shows an excerpt of the con-figuration nesC file for the TinyOS Sensor05 and Sensor10. The asso-ciated makefile is shown in Fig. 6b. In the configuration file, firstlythe MainC mandatory component of TinyOS (line 07) and the Fam-iWare microkernel (called MicroDDSC, see line 08) are declared.Then, a component for the new movement monitoring is created(Fig. 6a, line 10) and is associated as a DomainParticipant, Publisherand DataWriter with the microkernel (Fig. 6a, lines 11–13). Thisconfiguration file (ConfigApp.nc) is called in the Makefile (Fig. 6b.line 2). For a more detailed description of the architecture of Fam-iWare using DDS [16] we remit the interested reader to [7].

4. Differences and create configuration operators

This section details the syntactic and semantic definitions andalso the algorithms of the two operators defined and used in thiswork: the differences operator and the create_configuration opera-tor. Firstly, we describe the running exampled used.

4.1. Running example

We have chosen as running example the one presented in Fig. 1,since it is easy to understand but complex enough to illustrate howour operators work and the motivation of our approach. The fea-ture model presents a WSN composed of one or more node sensorsthat play one role (sink, cluster-head or ordinary) and can have twoservices (routing and/or data fusion). The routing protocol serviceselects the routes for disseminating the data sensed by sensors tothe rest of the network. The data fusion service aggregates datafrom multiple sensors or several sensed data. In total the WSN ismodelled with 9 features: the root feature (WSN), a clonable fea-

y generated for TinyOS sensors.


ture (Sensor), three optional features (Services, Routing and DataFu-sion), a mandatory feature (Role) and a xor-group (Ord, CH andSink).

Clonable features are necessary in this example because it is theonly way to express that in a WSN we can have a variable (withoutupper limit) number of sensors and that all these sensors have thesame structure of features (they must have a role and can have oneor two services).

We can observe that with this small example and considering avariable number of sensors there will be thousands of differentconfigurations. If we consider only one sensor (note that now wedo not consider cross-tree constrains in this example for simplic-ity) there are 15 valid configurations where the differences couldbe easy to detect. Nevertheless, with 4 sensors, as the specializa-tion shown in Fig. 7, there will be more than 50000 configurations.In real WSNs with hundreds or thousands of sensors, the numberof configurations (and features per configurations) increases expo-nentially and in this case the differences are impossible to detectmanually. So, using our differences operator, the differences be-tween two configurations with cloned features are obtained auto-matically. Also, knowing the modifications to be performed in aconfiguration, our create_configuration operator will generate thecorresponding new configuration.

Fig. 7. Feature model with four senso

Fig. 8. Two configuratio

Fig. 9. Two configuration

4.2. Differences operator

The differences operator obtains the set of different features be-tween two configurations of the same feature model. This means,the features that were selected in the previous configuration arenot selected in the new configuration and the features selected inthe new configuration that were not selected in the previousconfiguration.

Let us consider the two configurations of Fig. 8. Both configura-tions have only one sensor. In the previous configuration (Fig. 8a)the sensor is a sink that has selected the two services, and in thenew configuration (Fig. 8b.) the sensor is an ordinary sensor withonly one service. Then, the difference between them (Fig. 8c) is thatthe new configuration has selected the Ord feature and it has notselected the Sink and the DataFusion features, compared to the pre-vious configuration. Here, the differences are expressed as con-straints in Hydra using the feature constraint and the neg unaryoperator detailed in Section 2.

The next step is to consider the differences with cloned featuresas the two configurations of Fig. 9, where both have two sensors. Inthe previous configuration (Fig. 9a), there are two ordinary sensors,one with a routing service and the other without services. In thenew configuration (Fig. 9b), there are a sink sensor with the two

rs in a wireless sensor network.

ns with one sensor.

s with two sensors.


services and an ordinary sensor with one service. So, the differencebetween them (Fig. 9c) is that in the new configuration, the Sensor1has selected the Sink and DataFusion features and it has not se-lected the Ord feature, compared to the previous configuration.Also, in the new configuration, the Sensor2 has selected the Servicesand Routing features. Note that we have prefixed all the cloned fea-tures with the name of the clonable feature (e.g. Sensor) and thename of the clone (e.g. Sensor1), to know to which clone theybelong.

Finally, we have to consider the differences between two con-figurations with different numbers of clones, like the ones shownin Fig. 10. The previous configuration (Fig. 10a) is the same previ-ous configuration of Fig. 9a. But now in the new configuration(Fig. 10b.) there are three sensors: a sink with the two services,an ordinary sensor with the routing service and a new cluster-headsensor with the routing service. So, the differences (Fig. 10c) arethe same detailed in Fig. 9c plus the selected features for thenew clone Sensor3: Role, CH, Services, Routing.

When considering feature models without cardinality, the prob-lem for getting the differences between two configurations can besimplified to the differences between two sets. Likewise, if we re-name all the cloned features with a unique name, a first approachcould be to also reduce the problem to a simple difference betweensets. In order to have a unique name for every feature, we can pre-fix the name of all the clones with the original name of the feature(e.g. Sensor_Sensor1) and all the features of the cloned structureswith the name of the clone (e.g. Sensor1_Role).

In this case, to obtain the differences, firstly, we have to coverall the features of the new configuration in order to know whichones are not in the previous configuration. In Fig. 10, we find thatSink and DataFusion features of the first sensor have to be selected.Also, Services and Routing features of the second sensor have to beselected. Finally, all the features below the third sensor are newand have to be selected. Secondly, we have to cover all the featuresof the previous configuration in order to know which ones are notin the new configuration. For our example, the only feature thatdisappears in the new configuration is the ordinary role (Ord fea-ture) of the first sensor.

The methodology previously described would be correct, sinceall the differences are returned, but it is inefficient. First, we wouldhave to rename all the features. Next, we would have to navigatethrough all the features of the previous configuration and findthem in the new configuration. This last step should be repeatedin order to find the features of the previous configuration in thenew one. Therefore, the main disadvantage of this approach is thatall the features selected in the two configurations have to besearched twice. For instance, we may want to obtain the differ-ences between two similar configurations, where only some ofthe features in a few clones are different, so the effort of searchinginto the configuration set twice is not justified. Furthermore, fea-ture models representing a real SPL, usually have a big core asset,so they have many mandatory features. It is known in advance that

Fig. 10. Two configurations with

mandatory features have to be selected in both configurations, sowe do not need to search for them in order to obtain the differ-ences. This approach would work well in small feature modelsand small configurations, i.e. configurations with a few cloned fea-tures. But the configurations for real distributed systems may havea high number of clones, so they are usually very big (e.g. thou-sands of sensors). To summarise, this approach which calculatesthe difference between two configurations is extremely inefficientfor real SPL systems. In addition, as we will show in Section 5, thetime needed to find the difference increases greatly when the num-ber of clones increases. Hence, we need a more efficient algorithmin order to make our approach scalable to configurations with sev-eral thousands of total features. This motivates the definition of anew algorithm more efficient for this operator.

Syntactic Definition. The differences operator is syntactically de-fined as follows:

differences : PC;NC; Fcl; Fopt; For; Fxor ! SEL;UNS

It takes six sets of features as input arguments. The features se-lected in the previous configurations (PC) and in the new configu-ration (NC), the clonable (Fcl) and optional features (Fopt) and thefeatures belonging to an or (For) and a xor-group (Fxor). Also, it re-turns two sets of features. SEL is the set of the features that are se-lected in the new configuration but were not selected in theprevious configuration. Similarly, UNS is the set of the features thatare not selected in the new configuration but that were selected inthe previous one.

For the FM of Fig. 1, the set of features are:

Fcl ¼ fSensorg

Fopt ¼ fServ ices;Routing;DataFusiong

For ¼ ;

Fxor ¼ fOrd;CH; Sinkg

For the configurations presented in Fig. 8, we have:

PC ¼ fWSN; Sensor;Role; Sink; Serv ices;Routing;DataFusiong

NC ¼ fWSN; Sensor;Role;Ord; Serv ices;Routingg

And as result of the differences operator, we will have:

SEL ¼ fOrdg UNS ¼ fSink;DataFusiong

Semantics. The semantic of the differences operator is repre-sented by the relationship that exists between the previous andthe new configuration and the selected and unselected features.Intuitively, the new configuration minus the previous configura-tion is equal to the selected set of features. And in the same way,the previous configuration minus the new configuration is theunselected features set. More formally the semantics are definedas follows:

different number of sensors.


SEL ¼ NC n PC UNS ¼ PC n NC

Note that the difference ðnÞ is not the typical difference betweensets. ‘n’ is the difference between the structure used for the config-uration, as is later explained in the algorithm.

So, in our particular example:

SEL ¼ fWSN; Sensor;Role;Ord; Services;Routinggn fWSN; Sensor;Role; Sink; Serv ices;Routing;DataFusiong

¼ fOrdg

UNS ¼ fWSN; Sensor;Role; Sink; Services;Routing;DataFusiongn fWSN; Sensor;Role;Ord; Services;Routingg

¼ fSink;DataFusiong

Algorithm. The algorithm to obtain the differences between two con-figurations takes six sets of features as input arguments (see Algo-rithm 1). The features selected in the previous and in the newconfigurations, the clonable and optional features and the featuresbelonging to an or and a xor-group. It returns a tuple with the set(SEL) of features that are selected in the NC and which were not se-lected in the PC and other set (UNS) with the features that were se-lected in the PC and which are not selected in the NC.

As an illustrative example, let us consider the configurationsshown in Fig. 10. In this case the previous configuration and thenew configuration sets are:

PC ¼ fWSN; Sensor Sensor1 : fRole;Ord; Services;Routingg;Sensor Sensor2 : fRol;Ordgg

;
NC¼fWSN;Sensor Sensor1 : fRole;Sink;Serv ices;Routing;DataFusiongSensor Sensor2 : fRole;Ord;Services;Routingg;Sensor Sensor3 : fRole;CH;Serv ices;Routinggg
This algorithm firstly obtains the differences of thenon-clonable fea-tures. To do so, it uses the diff_simple algorithm (Algorithm 2) thatobtains the difference between two configurations with non-clon-able features. diff_simple covers all the optional, or and xor featuresin order to know which ones are in the new configuration but werenot in the previous configuration to construct the SEL set, and whichones were in the previous configuration but are not in the new con-figuration to construct the UNS set. Note that we avoid looking forthe mandatory features, since they will be selected in both configu-rations. Also, using this algorithm we avoid covering all the featuresfor the PC and the NC twice.

The differences algorithm uses diff_simple algorithm giving as in-put the previous configuration minus the cloned structures, thenew configuration minus the cloned structures and the optional,or and xor features (Algorithm 1, lines 1–3). The only feature outof a non-clonable structure is WNS, so SimplePC = {WSN} and Simp-leNC = {WSN}. After that, applying diff_simple algorithm SEL = £

and UNS = £.Then, for each clonable feature, the algorithm extracts the

clones of the previous and new configurations (lines 5–6). The ex-tract_clones function returns a tuple with the names of the clonesand with the cloned structures. The cloned structures are the fea-tures under a clone but only those that are not clonable again, sincethey will be considered later in the algorithm, as we will explainfurther on. The only clonable feature in our example is Sensor, sofor this feature we will obtain:

ClPC ¼ ðSensor1; Sensor2Þ

StPC ¼ ðfRole;Ord; Serv ices;Routingg; fRole;OrdgÞ

ClNC ¼ ðSensor1; Sensor2; Sensor3Þ

StNC ¼ ðfRole; Sink; Serv ices;Routing;DataFusiong;fRole;Ord; Services;Routingg; fRole;CH; Services;RoutinggÞ

Then, for each clone of the previous configuration, if they appearin the new configuration, the diff_simple algorithm calculates the dif-ferences between both corresponding cloned structures (line 11).This happens with Sensor1 and Sensor2. For Sensor1, the diff_simplebetween {Role, Ord, Services, Routing} and {Role, Sink, Services, Rout-ing, DataFusion} is CSEL = {Sink, DataFusion} and CUNS = {Ord}. Thus,preceding the features with the clones, using the precede_clonesfunction, (lines 12–13):

SEL ¼ fSensor Sensor1 : fSink;DataFusiongg and

UNS ¼ fSensor Sensor1 : fOrdgg:

For Sensor2, diff_simple of {Role, Ord} and {Role, Ord, Services,Routing} is CSEL = {Services, Routing} and CUNS = £. Therefore, bymaking the union with the former SEL and UNS sets:

SEL ¼ fSensor Sensor1 : fSink;DataFusiong;Sensor Sensor2 : fService;Routinggg


If the clone it is not present in the new configuration, all thestructure (preceding the feature with name of the clone) must beadded to the UNS set (line 15). This does not happen with anycloned feature in our example.

Following on, for each clone of the new configuration, if it doesnot appear in the previous configuration, all the structure (preced-ing the features with name of the clone) must be added to the SELset (lines 18–21). This happens with the Sensor3 feature, so finally:

SEL ¼ fSensor Sensor1 : fSink;DataFusiong;Sensor Sensor2 : fServ ice;Routingg;Sensor Sensor3 : fRole;CH; Serv ices;Routinggg


Algorithm 1. Differences returns two sets of features with thedifferences

inputs six sets of features PC, NC, Fcl, Fopt, For, Fxoroutput a tuple of two sets of features diff = (SEL, UNS)1:SimplePC: = remove_clones(PC)2:SimpleNC: = remove_clones(NC)3:(SEL, UNS): = diff_simple(SimplePC, SimpleNC, Fopt, For, Fxor)4: foreach f e Fcl do5: (ClPC, StPC): = extract_clones(PC, f)6: (ClNC, StNC): = extract_clones(NC, f)7: for i: = 1..length(ClPC) do8: c: = ClPC(i)//clone of the i position9: if (c e ClNC) then10: j: = pos(c, ClNC) //search for the position of the

clone c11: (CSEL, CUNS): = diff_simple(StPC(i), StNC(j), Fopt,

For, Fxor)12: SEL: = SEL [ precede_clones(c, CSEL)13: UNS: = UNS [ precede_clones(c, CUNS)14: else15: UNS: = UNS [ precede_clones(c, StPC(i))16: end if17: end for


18: for i: = 1..length(ClNC) do19: c: = ClNC(i)20: if (c R ClPC) then21: SEL: = SEL [ precede_clones(c, StNC(i))22: end if23: end for24: end for25: diff: = (SEL, UNS)26:return diff

Algorithm 2. diff_simple returns two set of features with thedifferences for FMs without clones.

inputs five sets of features PC, NC, Fopt, For, Fxoroutput a tuple of two sets of features diff = (SEL, UNS)1:SEL: = £

2:UNS: = £

3: foreach f e (Fopt [ For [ Fxor) do4: if (f e NC) ^ (f R PC) then5: SEL: = SEL [ {f}6: elseif (f e PC) ^ (f R NC) then7: UNS: = UNS [ {f}8: end if9: end for10:diff: = (SEL, UNS)11:return diff

Finally, we have to consider the possibility that some descendantfeatures of a clonable feature will also be clonable (nested clones).Our algorithm takes into account this possibility since, as we men-tioned before, the extract_clones function return all features in thecloned structure minus the clonable ones. And, as the algorithmcovers all the clonable features, when it is the turn of a clone thatbelongs to a cloned structure, the extract_clones function obtainagain the substructure of this clone features (without clonable fea-tures). For example, if we consider several sensing units per sensor,each of them equipped with temperature, accelerometer or lightsensors:

PC ¼ fWSN; Sensor Sensor1 : fRole;Ord;Unit Unit1 : fTemp;Accg;Unit Unit2 : fAccgg; Sensor Sensor2 : fRol;Ordgg

NC ¼ fWSN; Sensor Sensor1 : fRole;Ord;Unit Unit1 : fTemp; Lightgg;Sensor Sensor2 : fRol;Ordgg

As a result of the extract_clones function, respect to the Unit clone,we will obtain:

ClPC ¼ ðSensor Sensor1 Unit1; Sensor Sensor1 Unit2Þ

StPC ¼ ðfTemp;Accg; fAccgÞ

ClNC ¼ ðSensor Sensor1 Unit1Þ

StNC ¼ ðfTemp; LightgÞ

The differences between these two configurations are:

SEL ¼ fSensor Sensor1 : fUnit Unit1 : fLigthggg

UNS ¼ fSensor Sensor1 : fUnit Unit1 : fAccg;Unit Unit2 : fAccggg

4.3. Create configuration operator

The create_configuration operator creates a new configurationfrom a previous one and the two sets of features: the ones thatmust be selected in a new configuration (SEL), and the ones thatmust be unselected (UNS). To generate the new configuration,firstly, we have to remove the unselected features from the previ-ous configuration set. Thereafter, with this set plus the set of se-lected features we use the facility provided by Hydra to create aminimal valid configuration. In this way, Hydra adds to this setthe necessary features to satisfy the cross-tree constraints if it ispossible to generate a valid configuration.

For the previous configuration shown in Fig. 8a, the sensor is asink that has two services. The unselected features (Fig. 8c) are Sinkand DataFusion, so we remove them from the previous configura-tion set. The new selected feature is Ord, so we have to add it tothe previous configuration. This set (NC = {WSN, Sensor, Role, Ord,Services, Routing}) has all the features that we want to select in anew configuration. So we translate this set in the form of featureconstraints (as the differences shown in Fig. 8c) as the initial con-straints used by Hydra to generate a minimal valid configuration,if it is possible. This new configuration will be the one shown inFig. 8b.

Syntactic Definition. The create_configuration operator is syntac-tically defined as follows:

create configuration : PC; SEL;UNS; FM ! NC;Valid

It takes the feature model (FM) and three sets of features as inputarguments: the features selected in the previous configurations(PC), the set of features that has to be selected in the new configu-ration but they were not selected in the previous configuration(SEL), and the set of features that must not be selected in the newconfiguration but they were selected in the previous configuration(UNS). This operator returns the set features that must be selectedin the new configuration and a Boolean that indicates if it is possibleto create a valid configuration with those inputs.

Semantics. The semantic of the create_configuration operator isrepresented by the relationship that exists between the previousconfiguration and the new configuration. Similarly to the differenceoperator, the new configuration is equal to the previous configura-tion minus the unselected features plus the new selected one. For-mally, the semantics is defined as:

NC ¼ ðPC n UNSÞ [ SEL

Similarly as before, difference ðnÞ and the union ([) are not thetypical difference and union between sets, but rather the differenceand the union between the structure that we use for the featuremodels configuration. In our example:

NC ¼ ðfWSN; Sensor;Role; Sink; Serv ices;Routing;DataFusiongn fSink;DataFusiongÞ [ fOrdg

¼ fWSN; Sensor;Role; Services;Routingg [ fOrdg¼ fWSN; Sensor;Role;Ord; Serv ices;Routingg

Algorithm. The algorithm to create_configuration (see Algorithm3) has as inputs the three sets of features with the previous config-uration, the selected and the unselected features. Also, it has as in-put the feature model. The algorithm returns the newconfiguration and indicates if it is possible to construct a valid con-figuration with these inputs.

This algorithm firstly assigns to the new configuration the fea-tures of the previous configuration (line 1). Then, for each featureof the UNS set checks if it is a clone, to remove it using the remo-ve_clone function (lines 3–4). This function has two inputs, the


clone and the features of the configuration. For example, to removethe clone Sensor Sensor1:{Ord} of

fWSN; Sensor Sensor1 : fRole;Ord; Serv ices;Routingg;Sensor Sensor2 : fRol;Ordggresults :

fWSN; Sensor Sensor1 : fRole; Serv ices;Routingg;Sensor Sensor2 : fRol;Ordgg

If the feature is not a clone, i.e. it is simple feature; the algorithmremoves it directly (lines 5–6).

Similarly, for each feature of the SEL set, checks if it is a clone, toadd it using the add_clone function (lines 10–11). This function hastwo inputs, the clone and the set of features of the configuration.To add the clone Sensor Sensor1 : fSink;DataFusiongto

fWSN; Sensor Sensor1 : fRole; Serv ices;Routingg;Sensor Sensor2 : fRol;Ordggresults

fWSN; Sensor Sensor1 : fRole; Sink; Serv ices;Routing;DataFusiong;Sensor Sensor2 : fRol;Ordgg:

Finally, if the feature is not a clone, i.e. is a simple feature, thealgorithm adds it directly (lines 12–13).

Algorithm 3. create_configuration returns the new configurationand a Boolean value

inputs three sets of features PC, SEL, UNS and a feature modelFM

output a tuple with the new configuration NC and a Booleanvalue Valid

1:NC: = PC2: foreach f e UNS do3: if (is_clone(f)) then4: NC: = remove_clone(f, NC)5: else6: NC :¼ NC n ffg;7: endif8:end for9: foreach f e SEL do10: if (is_clone(f))then11: NC: = add_clone(f, NC)12: else13: NC: = NC [ {f};14: endif15:end for16: (NC, Valid): = minimal_valid_conf(NC, FM)//implemented

by Hydra17: return (NC, Valid)

After all the features in UNS and in SEL sets are covered, we have allthe features that we want and that will be selected in a new config-uration. Then, this new configuration set is given as input togetherwith the feature model to the Hydra minimal valid configurationfunction (minimal_valid_conf, line 16). This function returns true ifa valid configuration can be generated (i.e. the new configurationgiven as initial constraints satisfy the tree and cross-tree con-straints) or false in the other case. Also, this function returns thedefinitive set of the new configuration. Maybe other features mustbe added to satisfy some constraints. For example, if we have a con-straint saying that if a sensor has the data fusion service then therouting service must be selected (DataFusion implies Routing),although in the initial constraints we only make explicit that datafusion must be present in a specific sensor (we do not say anything

about routing), Hydra automatically selects the Routing feature tosatisfy the constraint.

5. Evaluation

Hydra, was first implemented as an Ecore-based Eclipse plugin[25,26], to provide support for the modelling of cardinality-basedfeature models in an intuitive and graphical way. Hydra also pro-vides support for the automatic generation and validation of min-imal configurations for these kinds of feature models with clonablefeatures. In this section, we present the experimental results ofusing the evolution support provided by Hydra, by means of theoperators differences and the create_configuration presented in thispaper, for the FamiWare middleware.

Firstly, we test that the algorithms that implement those oper-ators are efficient and scalable to large feature model configura-tions with thousands of clonable features. Then, we evaluate thecorrectness of the algorithms implementing the evolution opera-tors checking that: (i) they work as expected in several case studiesconstructed with the FamiWare middleware; (ii) the application ofthe differences and create_configuration algorithms separately tothe same case study, gives consistent results and (iii) they producethe same results as an equivalent CSP program but in less time. Fi-nally, we outline the applicability and usefulness of the evolutionprocess presented in this paper and we discuss the limitations ofour approach.

5.1. Scalability of SPL evolution algorithms

As presented in [20,27], due to the complexity of large featuremodels resulting in configurations of thousands of features, it isvery important to measure the response time and the scalabilityof feature models algorithms. Furthermore, in our case as we dealwith cardinality-based feature models, where small feature modelscan produce really large and complex configurations, the scalabil-ity issue is even more important. Operators defined over featuremodels have to demonstrate their scalability in terms of the num-ber of features [20,27], normally using randomly generated featuremodels. In our case, we refer to configurations with cloned fea-tures, so we have to prove the scalability of the proposed algo-rithms in terms of the number of clones of the configurations. Inorder to demonstrate this, we could use a unique feature model(i.e. the feature model of FamiWare middleware), and simply varythe size of the generated configurations. Instead of generating ran-dom configurations we consider it more useful to experiment withthe configurations generated from real case studies (e.g. a smarthome) as we will show later. So, we will show that Hydra withits evolution operators works well with concrete case studies con-sidering a large number of cloned features, representing the num-ber of devices that can be interconnected in typical AmI systems.

The time needed to create a configuration depends on the num-ber of clonable features selected for the configurations. Since inFamiWare, the clonable feature is the Device, the time needed tocreate a configuration depends very much on the number of de-vices connected in the same AmI system. In Fig. 11a, we showthe result of measuring the response time considering between 1and 500 clones. Our experiments consider 500 clones representing500 devices (different kind of sensors and smartphones), which issignificantly larger than the AmI case studies we came across inthe literature. The experiments were done in a PC Intel Core 2Quad, 2, 5 GHz, 2 GB of memory and with 1.6 JVM. This means thatfor evolving a given configuration for a case study with 500 devicesusing the create_configuration algorithm, the response time isaround 2 min. On the other hand, the time required to know thedifferences between two configurations is reduced (Fig. 11b). Con-cretely, for 500 clones it takes less than 1 min. This is because


when Hydra creates a new configuration, executing the create_con-figuration algorithm, it also has to paint the model of the configu-ration, which is the most time consuming task. By contrast, thedifference only produces a file with the constraints. This meansthat, the times depicted in Fig. 11, include not only the calculationtime (as other experiments over feature models do), but otheroperations such as painting or writing to a file. So, these can beconsidered realistic times since they are calculated from the pointof view of an end user of Hydra. Considering that 500 devices aretoo much for regular AmI systems, we can conclude that bothtimes are more than acceptable for huge configurations. Since thesub-tree under a cloned feature has also a variable size, the config-urations considered, have a much larger size in terms of features.Concretely for the FamiWare configurations, we calculated anaverage of 22 features per device. So, the response times shown re-fer to configurations with an average of 11000 features, which isthe largest number of features used in testing operators over fea-ture models [20].

Although the evolution process presented here can be appliedto any SPL, in the scope of this paper, we did our experiments withseveral instantiations of FamiWare for different case studies. Spe-cifically, we have implemented several versions of smart homes,AAL homes and ITSs, which were evolved using our evolution pro-cess with expected results as Table 1 shows.

We show results for four case studies: an AAL home with 11devices, a large smarthome with 34 devices, a small ITS systemwith 110 devices and a big ITS system with 432 devices. In thethird column, the total number of features for each configurationis detailed. The number of features of the FamiWare feature mod-el that will be evolved in every specific example is shown in thefourth column. In order to show the complexity of managing con-figuration evolution with several clones, most of the featuresevolved affect several clones of the specific configuration. As weshowed above, the calculation time of the create_configurationfacility is higher than the difference. We can see that for concreteAmI case studies, the calculation time for both operators is lessthan 1 s or takes a few seconds (3.2 s). The highest times arefor the ITS big case study with more than 400 clones and a num-ber of total features of more than 8000.

From the results in Table 1, we obtained experimental evidencethat indicates for these and for other case studies similar in size, itis not possible to manage the configuration evolution manuallydue to the high number of possible configurations and features

Fig. 11. (a) Create configuration and (b) difference operators time in seconds.

per configuration. So, the evolution operators presented here helpto do this automatically and in a few seconds, being the worst caseconsidered less than 2 min.

This shows that managing evolution of configurations withclonable features is a computational hard problem. Similar publi-cations define operators over feature models [20] defining 10000as the highest number of considered features. In the FamiWaremiddleware, the number of highest number of features that couldbe present in a given configuration could be around 25000, muchhigher than the size of feature models considered to check theadequacy of feature models operators. This shows that workingwith clonable features increases the computational complexitywith respect to feature models operators.

5.2. Correctness of SPL evolution algorithms

Our algorithms are not so complex, but it is better to verify theircorrectness in order to ensure that the evolution process does notintroduce any errors. It is possible to prove the correctness of ouralgorithms either (i) via their execution with different case studiesor (ii) via some kind of formal reasoning. We have performed bothkinds of correctness verifications.

Firstly, we used both operators of Hydra to evolve the four casestudies in Table 1, but taking into account only a few features wereadded and removed. We repeated the same experiments, but weevolved the configurations manually. The results of these experi-ments were satisfactory since the configurations generated withHydra and manually were the same, which is a good indicator thatthe operators work well.

On the other hand, we have applied the differences and cre-ate_configuration algorithms separately to the case studies in Table1, obtaining consistent results. Following the semantic definition ofthe create_configuration operator, the new configuration is the pre-vious configuration where the features of the UNS set are removedand the features of the SEL set are added ðNC ¼ ðPC n UNSÞ [ SELÞ.Then, for every case study in Table 1, we have used the create_con-figuration facility of Hydra for evolving the previous configurationsand creating new ones giving the UNSi and SELi sets as inputs. Afterthis step, we have a new configuration (NC) for each previous con-figuration (PC). Then, taking advantage of the fact that both algo-rithms are complementary (i.e. the differences algorithm returnthe UNS and SEL sets between PC and NC; SEL ¼ NC n PC andUNS ¼ PC n NC), we execute the differences algorithm for every cou-ple of PC and NC getting as outputs the UNSj and SELj sets. Then wecheck that UNSi is equal UNSj and that SELi is equal SELj, whichmeans that at least both algorithms give consistent results.

Furthermore, in order to demonstrate the correctness of the cre-ate_configuration algorithm we have modelled this problem with aCSP taking advantage of the Choco Library used by Hydra. What weneed to prove is that the semantic definition of the create_configu-ration operator, which is: NC ¼ ðPC n UNSÞ [ SEL, specified in CSPgives the same results as our algorithm. A CSP is defined by a trip-let (X, D, C), where X is the set of variables of the problem, D is afunction that associates the domain to each variable, and C is aset of constraints. In our case, the variables are the names of thefeatures, the domain is 0 for the non-selected features and 1 forthe selected features of a configuration and the constraints arethe semantic definition of the create_configuration operator:ðPC n UNSÞ [ SEL. So, we have the next triplet for our CSP problem:

– Variables: the names of the all features of a cloned featuremodel: F = {Fi|i e [1, n]} were Fi is a feature that belongs tothe feature model or a clone name and n the number of fea-tures plus clones. Although features with cardinality 1. . .�

could have infinite clones, the specific number of clones in aparticular configuration is finite. Therefore, features with car-

Table 1Create configuration and difference times for different case studies.

Case study Number of clones (devices) Number of total features Number of evolved features Create_configuration time (s) Difference time (s)

AAL 11 254 2 0.4 0.1SmartHome 34 925 13 0.7 0.5ITS small 110 2341 1 3.2 0.1ITS big 432 8823 5 110 41


dinality are translated into variables of a CSP with a uniquename that we use as a feature identifier, and this is what wecall a cloned feature model.

– Domains: for all variables Fi e F, D(Fi) = {0, 1} that correspondwith the semantic of the unselected feature/clone or selectedfeature/clone respectively.

– Constraints: the set of constraints is defined by the followingconstraints, C ¼ ðPC n UNSÞ [ SEL:� The previous configuration PC = {P1, . . ., Pn} where Pi = {0,

1} depending whether the Pi were selected (1) or unse-lected (0) in the previous configuration.

� The selected set SEL = {S1, . . ., Sn}where Si = {0, 1}. FeatureSi is 1 if this feature must be added to the new configu-ration and 0 otherwise.

� The unselected setUNS = {U1, . . ., Un}where Ui = {0, 1}.Feature Ui is 1 if this feature must be removed to thenew configuration and 0 otherwise.

The CSP obtains a tuple v = {v1, . . ., vn} e D = {0, 1} that satisfiesthe constraints C (i.e. the semantic definition of the create_configu-ration algorithm). In order to prove the functioning of our algo-rithm, we check that this resulting tuple is equal to the newconfiguration (NC) obtained using our create_configuration algo-rithm. We have done some small experiments, and all of them givethe expected results. But, our implementation is more efficientthan CSP. Also, as we have already shown, our implementationscales well in terms of number of features, but CSP run out of mem-ory for 5000 features. This is not acceptable for SPL with clonablefeatures as we showed in Table 1 (the size of the ITS big case studyis around 8000).

5.3. Applicability of the SPL evolution algorithms

Here we have applied the results of the operators to evolve ourmiddleware, but it can be used to evolve other kinds of systems de-fined using feature models and specifically cardinality-based fea-ture models. The evolution process presented here is able tomanage changes produced in configurations with clones, at designtime. But, in general, SPL engineering processes can also be appliedat runtime, as proposed in the Dynamic Software Product Lines[28] (DSPL) approach. Following a DSPL approach, we extendedthe FamiWare middleware to support dynamic reconfigurationusing the operators presented here. The details of how the recon-figuration is defined in FamiWare using these operators can befound in [29,30]. We use the create_configuration operator to obtainthe next configuration at runtime, after a new context situation re-quires the evolution of the running system. Also, we use the differ-ence operator to generate implementation level plans that must beexecuted at runtime to make the system evolve to a next configu-ration from a previous one.

In addition, the results obtained from both operators are veryeasy to understand and use. On one hand, the create_configurationoperator returns a new configuration depicted in Hydra that is rep-resented in an XML file. The new configuration obtained is definedin terms of features. It is then possible to perform some kind ofmapping to an architectural description language or even to code.

So, evolution would be performed at feature level, and the changescan be propagated to architectural description or to code using ouroperators as input. On the other hand, the difference operator ob-tains two sets with features. These sets are represented also inXML files and could be used also to check the differences betweento existent products.

Although our process helps in the quantification of the effort re-quired to produce the upgraded versions of previous middlewareproducts, it cannot automatically calculate it in terms of the num-ber of person months. Thanks to the use of VML4FamiWare, ourprocess is able to observe the differences at architecture level be-tween the previous middleware configuration and the next one.With these differences it can directly conclude how many compo-nents will be reused in an evolved configuration, how many mustbe modified, how many must be implemented from scratch and inwhich devices we have to make these modifications. However, wecannot automatically calculate the cost (e.g. person months) ofmodifying or implementing a new component. The output of ourprocess for this, is simply the list of components reused (those thatwere found in the component repository), and those which have tobe modified or implemented. We consider this is valuable for theSoftware Architect, who does not have to calculate by hand howmany components are affected as a consequence of requirementchanges. With our process he/she can obtain this information ina few seconds, and know it is correct. Then, the architect will haveto assess, for each specific case, the person months per each newcomponent or modification and then make a final calculation ofthe estimated cost of evolving each product asset. Knowing thisin advance can also have an impact in reducing the time to marketfor producing upgraded versions of products.

One desirable situation is that running middleware productsmust continue their execution after evolution, so the initialrequirements imposed by both the physical infrastructure andthe applications, which continue to be valid, must be preservedin the upgraded versions. Our process preserves the requirementsand architecture, introducing the architectural modifications in theleast intrusive way possible.

6. Related work

There are several texts that focus on cardinality-based featuremodels [13,31–33]. In [13,31,34] a cardinality-based notation forfeature models, on which our feature modelling tool Hydra is based,is presented. Also, the concept of staged configuration based on thespecialization of a feature model is defined, where in each stage theproducts described by the specialized models is a subset of the prod-ucts described by the feature model. Furthermore, in [31] a transla-tion for cardinality-based feature models into context-freegrammars and a semantic interpretation of feature models is pre-sented. The Graphical User Interface of Hydra is more intuitive andusable than the tree-based representation of the tool provided bythe authors of those papers, fmp [35]. In particular, we need a usefultool for large scale feature models like the ones representing AmIsystems with a large amount of devices. Then, using Hydra we canvisualize and more easily manage large feature model configura-tions of FamiWare for different systems. Thus, we have used the


notation presented and formalized in [13,31] but like the work of[22,23], Hydra transforms the feature model configurations into aConstraint Solver Problem and uses the Java Choco ConstraintSolver.

Other proposals working with cardinality-based feature modelsare [33,32]. In [33] a verification of a feature model with clonablefeatures using binary decision diagrams is presented. This approachfocuses on cardinality-based FM but they do not deal with the evo-lution of this kind of feature model. In [32] a synchronizing opera-tion in cardinality-based feature models is presented. They considerthe possibility of propagating the changes produced in a featuremodel to previously existing configurations of this feature model.So, to a degree, they deal with the evolution of the whole softwareproduct line (i.e. a feature model) and the corresponding changes tothe specific products. Nevertheless, they do not provide a solutionto the problem of propagating these changes at architecture level,as we do. Our model-driven process to evolve SPLs means the cre-ation of new products and the evaluation of the effort of the evolu-tion. Furthermore, in our approach, we address the problem of theevolution of a particular product (i.e. a configuration).

A classification of the evolution of feature models via modificationssuch as refactoring, specializations, generalizations or arbitraryedits is presented in [20,36]. Thus, an algorithm for classifying fea-ture models with differences is defined. Similarly, in [37] an insertoperator (to add a feature to a feature model) and a merge operator(to compose two feature models) were proposed. With these opera-tors, the development of large feature models by composing smallerfeature models is enabled. In some ways, both proposals are similarto our defined operators but at feature model level instead of at con-figuration level as our operators are. So, these proposals tackle theevolution of feature models but they do not address how to propa-gate the changes made at feature model level into configuration le-vel or how to dynamically reconfigure a specific feature modelconfiguration, which is the focus of our approach.

Finally, at feature model configuration level, in [38] the work pre-sented is similar to our approach in motivation, as the authorspoint out the necessity for the automated diagnosis of configura-tions in large feature models. Also, they deal with the automaticconfiguration evolution. Nevertheless, although they deal with fea-ture models with cardinality groups this is not the same as cardi-nality-based feature models with clonable features; which areone of the contributions of our work. Therefore, they do not takeinto account the feature model with clonable features, which isthe main difficulty that we found in the definition of the two re-quired operators. Moreover, they mainly focus on developing tech-niques for producing a minimal set of feature selection anddeselection, to bring a flawed configuration to a valid configura-tion. Hydra does not permit the building of invalid configurations,since the tool to design the configurations checks at each stagewhether the constraints are satisfied by the current specialization.Also, when we want to create a minimal valid configuration, wegive as inputs the initial constraints and check if this input pro-duces a flawed configuration.

7. Concluding remarks

We have presented a model-driven process for managing theevolution of FamiWare, a family middleware for AmI domain usinga cardinality-based feature model. Our process automatically prop-agates the evolution changes of the middleware family into theexisting configurations where the middleware is already deployedand also helps us to calculate the effort in performing the changesin every configuration. To do this, our tool Hydra creates new Fam-iWare configurations from previous ones and the evolved featuremodel. Furthermore, having the previous and the new configura-tion and using the described extension of the variability language

VML, VML4FamiWare, we can identify which parts of the Fami-Ware architecture must be changed to evaluate the impact of thechanges. We have defined the differences and the create_configura-tion operators and we have developed efficient algorithms to showtheir functioning. We have shown that Hydra is able to create newconfigurations and to see differences for FamiWare configurationsin different case studies with a large number of clones.

We think that the potential of cardinality-based feature modelswas not sufficiently explored until the moment. We consider thatwith the boom of the Internet-of-Things [39] (IoT), promotingthe development of structurally complex systems (e.g. smart cit-ies), the possibility of modelling their structural variability withcardinality-based feature models will make possible to apply SPLapproaches to develop and manage the evolution of such systems.We hope our work will provide a catalyst for a wider use of cardi-nality-based feature models, and encourage feature model tooldevelopers to integrate the operators presented here.

Acknowledgments

This work has been partially supported by the projectsTIN2008-01942 funded by Spanish Ministry of Science andInnovation and P09-TIC-05231 (FamWare) funded by AndalusianGovernment.

References

[1] M. Weiser, The Computer for the Twenty-First Century. Scientific American,vol. 165, 1991.

[2] I. Akyildiz, I. Kasimoglu, Wireless sensor and actor networks: researchchallenges, Ad Hoc Networks Journal, Elsevier 2 (4) (2004) 351–367.

[3] M.M. Wang et al., Middleware for wireless sensor networks: a survey, Journalof Computer Science and Technology. 23 (3) (2008) 305–326.

[4] D. Bakken, Middleware. Encyclopedia of Distributed Computing, KluwerAcademic Publisher, 2003.

[5] T. Bishop, R. Karne, A survey of middleware, in: Proceedings of the ISCA 18thInternational Conference Computers and Their Applications, Hawaii, USA,2003.

[6] L. Fuentes, N. Gámez, Configuration process of a software product line for AmImiddleware, Journal of Universal Computer Science 16 (12) (2010) 1592–1611.

[7] N. Gámez, L. Fuentes, FamiWare: a family of event-based middleware forambient intelligence, Personal and Ubiquitous Computing 15 (4) (2011) 329–339 (Springer).

[8] K. Pohl, G. Böckle, F. Linden, Software Product Line Engineering – Foundations,Principles, and Technique, Springer, Heidelberg, New York, 2005.

[9] S. Apel, K. Böhm, Towards the development of ubiquitous middleware productlines, in: ASE’04 SEM Workshop, LNCS, vol. 3437, 2005.

[10] K.C. Kang, S.G. Cohen, J.A. Hess, W.E. Novak, A.S. Peterson, Feature-OrientedDomain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-021, Software Engineering Institute, Carnegie Mellon University, 1990.

[11] K. Lee, K. Kang, J. Lee, Concepts and Guidelines of Feature Modeling for ProductLine Software Engineering, LNCS, vol. 2319, Springer, Heidelberg, 2002. pp. 62–77.

[12] P. Sánchez, N. Gámez, L. Fuentes, N. Loughran, A. Garcia, A Metamodel forDesigning Software Architectures of Aspect-Oriented Software Product Lines.Technical Report D2.2, AMPLE Project, 2007.

[13] K. Czarnecki, S. Helsen, U.W. Eisenecker, Staged configuration throughspecialization and multilevel configuration of feature models, SoftwareProcess: Improvement and Practice 10 (2005) 143–169.

[14] N. Loughran, P. Sanchez, A. Garcia, L. Fuentes, Language Support for ManagingVariability in Architectural Models, LNCS, vol. 49, 2008, pp 36–51.

[15] C. Pohl et al., Survey of Existing Implementation Techniques With Respect toTheir Support for The Practices Currently in Use at Industrial Partners, AMPLEProject Deliverable D3.1, 2007.

[16] OMG Data Distribution Service for Real-Time Systems, v1.2. Retrieved August25, 2008.

[17] L. Fuentes, N. Gámez, FAmIWare: a middleware family for ambientintelligence, in: Proceedings of 4th International Symposium on UbiquitousComputing and Ambient Intelligence, UCAmI 2010 at CEDI, Valencia (Spain),2010.

[18] N. Gámez, L. Fuentes, Software product line evolution with cardinality-basedfeature models, in: Proceeding of the 12th International Conference onSoftware Reuse, ICSR 2011, Pohang (South Korea), LNCS, vol. 6727, Springer,2011, pp. 102–118.

[19] D.S. Batory, Feature models, grammars, and propositional formulas, in: J.H.Obbink, K. Pohl, (Eds.), Proc. of the 9th IC on Software Product Lines, LNCS, vol.3714, 2005, pp. 7–20.


[20] T. Thüm, D. Batory, C. Kästner, Reasoning about edits to feature models, in:Proceedings of the 31th International Conference on, Software Engineering,2009.

[21] E. Tsang, Foundations of Constraint Satisfaction, Academic Press, 1933.[22] D. Benavides, A. Ruiz, P. Trinidad, Using constraint programming to reason on

feature models, in: The 17th International Conference on Software Engineeringand Knowledge, Engineering, SEKE’05, 2005.

[23] D. Benavides, S. Segura, P. Trinidad, A. Ruiz, Using Java CSP solvers in theautomated analyses of feature models, in: Proceedings of Generative andTransformational Techniques in Software Engineering, International SummerSchool, GTTSE 2005, Braga, Portugal, 2005, pp. 399–408.

[24] Choco Solver Home Page, December 2010. <http://www.emn.fr/z-info/choco-solver/index.html>.

[25] M. Stephan, M. Antkiewicz, Ecore.fmp: A Tool for Editing and InstantiatingClass Models as Feature Models. Technical Report 2008-08, University ofWaterloo, 2008.

[26] F. Budinsky, D. Steinberg, E. Merks, R. Ellersick, T.J. Grose, Eclipse ModelingFramework, Addison-Wesley Professiona, 2003.

[27] J. White et al., Automated diagnosis of feature model configurations, Journal ofSystems and Software 83 (7) (2010) 1094–1107.

[28] N. Bencomo, P. Sawyer, G. Blair, P. Grace, Dynamically adaptive systems areproduct lines too: using model-driven techniques to capture dynamicvariability of adaptive systems, in: 2nd Int. Workshop on Dynamic SoftwareProduct Lines, 2008.

[29] N. Gámez, FamiWare: A Middleware Family for Ambient Intelligence, Ph.D.Thesis, 2012.

[30] N. Gámez, L. Fuentes, M.A. Aragüez, Autonomic computing driven by featuremodels and architecture in FamiWare, in: Proceedings of the 5th European

Conference on Software Architecture, ECSA 2011, Essen (Germany), LNCS, vol.6903, Springer, 2011, pp. 164–179.

[31] K. Czarnecki, S. Helsen, U.W. Eisenecker, Formalizing cardinality-based featuremodels and their specialization, Software Process: Improvement and Practice10 (1) (2005) 7–29.

[32] C.H.P. Kim, K. Czarnecki, Synchronizing cardinality-based feature modelsand their specializations. In: ECMDA-FA ’05. LNCS, vol. 3748, 2005, pp 331–348.

[33] W. Zhang et al., A BDD-based approach to verifying clone-enabled featuremodels’ constraints and customization, in: ICSR 2008, LNCS, vol. 5030, 2008,pp. 186–199.

[34] D. Benavides, A. Ruiz, P. Trinidad, Automated reasoning on feature models, in:LNCS, Advanced Information Systems Engineering, 17th InternationalConference, CAiSE 2005, vol. 3520, 2005, pp. 491–503.

[35] K. Czarnecki, M. Antkiewicz, C. Hwan, P. Kim, S. Lau, K. Pietroszek, fmp andfmp2rsm: eclipse plug-ins for modeling features using model templates.OOPSLA Companion, 2005, pp. 200–201.

[36] M. Kuhlemann, D. Batory, S. Apel, Refactoring feature modules, in: ICSR2009,LNCS, vol. 5791, 2009, pp. 106–115.

[37] M. Acher, P. Collet, P. Lahire, R. France, Composing feature models. In: 2nd Int.Conference on Software Language Engineering. LNCS, vol. 5969, 2009, pp. 62–81.

[38] J. White, D. Benavides, D. Schmidt, D. Trinidad, A. Ruiz, Automated diagnosis ofproduct-line configuration errors in feature models, in: Proc. 12th SoftwareProduct Line Conference, 2008, pp. 225–234.

[39] H. Sundmaeker, P. Guillemin, P. Friess, S. Woelffle, Vision and challenges forrealising the internet of things, in: European Research Cluster on the Internetof Things, European Commission, 2010.

http://www.emn.fr/z-info/choco-solver/index.html

http://www.emn.fr/z-info/choco-solver/index.html

Date post:	27-Dec-2016
Category:	Documents
Upload:	lidia
View:	217 times
Download:	4 times

Architectural evolution of FamiWare using cardinality-based feature models

Documents