Vous êtes sur la page 1sur 25

Handlingvariationsinsystemfamilies:Asurvey

1.Introduction TheSoftwareEngineeringInstitute(SEI)definesSoftwareProductLine(SPL),alsoknownasSystem Family,asasetofsoftwareintensivesystemssharingacommon,managedsetoffeaturesthatsatisfy thespecificneedsofaparticularmarketsegmentormissionandthataredevelopedfromacommonset ofcoreassetsinaprescribedway [1].ThemotivationbehindSPLpracticeisthatorganizationsare findingthatthepracticeofbuildingsetsofrelatedsystems(systemfamily)fromcommonassetscan yield remarkable quantitative improvements in productivity, time to market, product quality, and customersatisfaction [1]. Softwareproductlineengineeringdistinguishestwosubprocesses: domain engineering and applicationengineering.Duringthedomainengineeringsubprocess,productline commonality(i.e.featuresthatarecommontoallproductsinthefamily)andvariability(i.e.features thatvaryamongproductsinthefamily)areidentifiedandcoreassetsaredevelopedtobereusedin application engineering subprocess to develop individual products in the family. As product line concerns a family of products, domain artifacts (developed during domain engineering) such as requirements,architecturesandcomponentsmustincorporatevariabilitytodealwithvariationamong those products and to enable the development of those different products. Variability is the main characteristic that distinguishes system families development from other approaches of software development[2]. 1.1Runningexample:CoffeeMachineFamily We take the Coffee Machine Family presented in [3] as a running example to illustrate different conceptsintroducedthroughoutthepaper.Therequirementsforthisfamilyareasfollows: 1) Acoffeemachineisactivatedbyacoin.Theonlyacceptedcoinsaretheoneeurocoin(1), exclusivelyfortheEuropeanproductsandtheonedollarcoin(1$),exclusivelyfortheUS products; 2) Afterinsertingacoin,theuserhastochoosewhetherornot(s)hewantssugar,bypressing oneoftwobuttons,afterwhich(s)hemayselectabeverage; 3) Thechoiceofbeverages(coffee,tea,cappuccino)variesbetweentheproducts.However, deliveringcoffeeisamustforeveryproductofthefamily,whilecappuccinoisonlyoffered byEuropeanproducts; 4) Afterdeliveringtheappropriatebeverage,optionally,aringtoneisrung.However,aringtone mustberungwheneveracappuccinoisdelivered; 5) Themachinereturnstoitsidlestatewhenthecupistakenbytheuser. 1.2Productlineandvariabilityrelatedconcepts Thissectionpresentsgeneralconceptsconcerningproductlineandvariability.SoftwareProductLine (SPL),domainengineering,applicationengineering,commonalityandvariabilityarealreadydefined insection1,introduction.Wewouldliketodistinguishbetweenvariabilityintimeandvariabilityin space.Variabilityintimeistheexistenceofdifferentversionsofanartifactthatarevalidovertime whilevariabilityinspaceisanexistenceofanartifactindifferentshapesatthesametime [4].While

variabilityintimeconcernssinglesoftwaredevelopmentaswellasSPLdevelopment,variabilityin spaceconcernsspecificallySPLdevelopment.Intherestofthispaper,weusethetermvariabilityto refertovariabilityinspace. Halmans defines two categories of variability: essential and technical variability [5]. Essential variabilitydescribesvariabilityoftheproductfamilyfromthecustomer/userviewpoint,i.e.froma systemusageperspectivewhileavariabilityisconsideredas technical variabilitywhenitdealswith aspectsabouttherealization/implementationofthevariabilityand/orifitstatesconsequencesonthe ITinfrastructure.Forthecoffeemachineexample,theabilitytochoosebetween1$coinand1cointo activatethemachineisconsideredasessentialvariabilityandtheabilitytochoosebetweendifferent databasetypestorecordpurchasebehaviorofcustomerscanbeconsideredastechnicalvariability. SimilarcategorizationisdefinedbyBckle [4] inwhich external (resp. internal)variabilityisused insteadofessential(resp.technical)variability. Becker distinguishes two levels of variability: on the specification and the realization level [6]. Variabilityonthespecificationlevelconcernsexternallyvisiblecharacteristicsofvariability,ignoring therealizationdetail.Variabilityontherealizationlevelisthevariabilitythatmustbeintroducedin productlineassetsorcoreassetstorealizevariabilityspecifiedonthespecificationlevel.Forexample onevariabilityonthespecificationlevelforthecoffeemachinefamilycanbe:useof1$coinor1coin toactivatethemachine.Torealizethisvariabilitydifferentvariabilitiesmustbeintroducedinproduct lineassets(e.g.introducetwoalternativetransitionsinbehavioralmodel:onelabeledwitheventof inserting1$coinandanotherlabeledwitheventofinserting1coin).In [7],similardistinctionof variabilitylevelisintroduced: ProductLine(PL)variability whichcorrespondstovariabilityonthe specificationlevelandsoftwarevariabilitywhichcorrespondstovariabilityontherealizationlevel. Themostcommontypeofvariabilitiesare optional variability(i.e.apropertymayormaynotbe presentinaproduct)and alternative variability(i.e.choose one among n variants).Forthecoffee machinefamilyexample,thefactthattheringingoftheringtoneisanoptionalrepresentsoptional variability while the use of 1$ coin or 1 coin to activate the machine represent an alternative variability. Softwareproductlinedevelopmentstarts withthehighleveldescriptionoftheproductlinetobe developed.In [4],thishighleveldescriptionisalsocalled productroadmap whichdeterminesthe majorcommonandvariablefeaturesofthefutureproductsaswellasschedulewiththeirplanned release date. We refer to this high level description of product line as high level product line description. Variability on the specification level is actually the variability concerning high level product line description. From that high level description, core assets (requirements, architecture, design,code...)arecreated.Coreassetsareproductlineassetsthatcanbereusedtodevelopindividual products.Variabilityincoreassetsisvariabilityontherealizationlevel.Instancesofhighlevelproduct line description are called high level products description which can be derived from high level productlinedescription.Highlevelproductsdescriptionisusedtoselectandconfigurecoreassetsto developindividualproducts. Variability concerning high level product line description is usually captured in feature model or dedicatedvariabilitymodelwhichisdetailedinthenextsection.

Variability,introducedincoreassetstorealizevariabilityonthespecificationlevel,ismodeledusing variationpoint.A variationpointisaspotinsoftwareassetwherevariationwilloccur [8].Asetof variants canbeassociatedwithavariationpointtoprovidedifferentoptionsforthecorresponding variability.Variationpointactsasplaceholdertobereplacedbyanumberofvariantschosenfromthe setofvariantsassociatedwiththevariationpointwhendevelopingaparticularproduct.Inthecoffee machinefamily,anexampleofavariationpointcanbecointypewithtwoassociatedvariants1$ coinand1coin.Whendevelopingaparticularproduct,cointypevariationpointcanbereplaced with1$coinvariantor1coinvariantdependingonwhetheritistheUSproductortheEuropean product. Inthelifecyclestagesbeforethedesignofthevariationpoint,thevariationpointisconsideredtobe implicit.Atorafterthestageatwhichthevariationpointisdesigned,thevariationpointis explicit.An explicitvariationpointcanbeboundtoanumberofvariantschosenfromtheprovidedsetofvariants. Forexample,cointypevariationpointisboundto1coinvariantfortheEuropeanproduct.For eachvariationpoint,thesetofvariantsmaybeopen,i.e.morevariantscanbeadded(e.g.1coin variantcanbeaddedtocointypevariationpoint),orclosed,i.e.nomorevariantscanbeadded(e.g. nomorecointypesuchas1coinvariantcanbeaddedtocointypevariationpoint) [9].Time whenwebindavariabilitytoaparticularvariantiscalled bindingtime.Typicalbindingtimesare designtime,compiletime,linktimeandruntime. Whendevelopingindividualproducts(alsocalled productderivation or productconfiguration),the variabilityhavetoberesolved.Resolvingavariabilityistomakedecisionconcerningthatvariability (e.g.whetherornottoincludeanoptionalvariant,chooseonefeatureamongmanyvariantstobe included).Choosingaparticularvariantforavariabilityisalsoreferredtoasbindingthevariabilityto that variant. Some variants maynotbe independent from others (e.g.when onevariant is chosen anothervariantmustalsobechosentomakeavalidproduct).Constraintsbetweenthosevariantscan bedefinedtorepresentthosedependencies.Themostcommonconstraintsarerequire(i.e.theselection ofonevariantrequirestheselectionofanothervariant) and exclude (i.e.ifonevariantisselected anothervariantmustnotbeselectedandviceversa).Anexampleofarequireconstraintisthefactthat thecoffeemachinethatcanprovidecappuccinomusthavethecapabilitytoringaringtone(cappuccino requiresringtone).AnexampleofexcludeconstraintisthefactthattheUScoffeemachinecannot providecappuccino(UScoffeemachineexcludescappuccino). Thefirststepindevelopingindividualproductsistoderivehighlevelproductsdescriptionfromhigh levelproductlinedescriptionbydecidingforeachvariabilitywhichvarianttochoose.Sothisconcerns essentially the decisionmaking process. For that reason, the model (e.g. feature model) used to represent variability concerning high level product line description is also called decision model. Instancesofdecisionmodelarecalledproductmodels.Productmodelisusedtoresolvedvariabilityin coreassets. 1.3Outline Inthispaper,wesurveyapproachesusedtohandlevariationsinsystemfamilies inthecontextof requirementsengineering.Therestofthepaperisorganizedasfollows.Section2showshowvariability onthespecificationlevelcanbemodeled.Insection3,wepresentdifferentmethodsusedtodescribe

variability in requirements artifacts (variability on the realization level). Section 4 describes how variability on the specification and variability on the realization (in requirements artifacts) are interrelated.Derivingproductartifactsfromproductlineartifactsisdescribedinsection5.Section6 presentsanalysesthatcanbeperformedonthedescribedvariabilitymodels.Elaborationtechniquesfor differentvariabilitymodelsarepresentedinsection7.Finally,section8concludesthepaper. 2.Variabilityonthespecificationlevel Inthissectionwepresentdifferentapproachesusedtomodelvariabilityonthespecificationlevel. 2.1Featuremodel Featuremodel: Featuremodelisusedtocapturecommonandvariablefeaturesinasystem.Featurediagram(FD) whichisagraphicalrepresentationoffeaturemodelwasfirstintroducedbyKangaspartofFODA (FeatureOrientedDomainAnalysis)methodinwhichfeatureisdefinedasaprominentordistinctive uservisibleaspect,qualityorcharacteristicofasoftwaresystemorsystems[10].Aftertheintroduction ofFODAFD,variousextensionsofitwereintroducedtocompensateforapurportedambiguityand lackofprecisionandexpressiveness[11]. Figure1showsFODAfeaturedigramofthecoffeemachine.Itisatreelikestructurethatcaptures variousfeaturesofthecoffeemachineandrelationshipsbetweenthem.Nodesrepresentfeatures.Root noderepresentsconceptbeingdescribed.Featuresathigherlevel(parentfeatures)isrelatedtofeatures atlowerlevel(childfeatures)byconsistsofrelationshipswhichisrepresentedbyedges.Optionaland alternativefeaturesarerepresentedbyhollowcircleandsmallarcrespectively.Forexampleinfig.1, the1$and1arealternativefeaturesandtheRingtoneisoptionalfeature.Featureswhicharenot optional or alternativearemandatory features.Mandatoryfeature mustbe selected if its parent is selected.Optionalfeaturecanbeselectedifitsparentisselected.Exactlyoneofthealternativefeatures belongingtothesameparentmustbeselectedifthatparentisselected.Compositionrulescanbeused toexpressadditionalconstraintsbetweenfeatures.Therearetwotypesofsuchconstraints:requires andmutuallyexclusivewithorexcludes.FeatureArequiresfeatureBmeansthatiffeatureAis selectedthenfeatureBmustalsobeselected.mutuallyexclusivewithconstraintbetweentwofeatures meansthatifonefeatureisselectedtheotherfeaturemustnotbeselected.Forexampleinfig.1, CappuccinorequiresRingtoneand1$excludesRingtone. ExtensionstoFODAfeaturemodelincluderepresentingfeaturediagramusingdirectedacyclicgraph (DAG)insteadoftree [12,13,14,15,16],theabilitytochooseoneormorefeaturesfromagroupof featuresinsteadofchoosingonlyonefeature [8,13,14,17,18,19,20,21,22,23],featurecardinalitiesalso calledfeaturecloning(i.e.multiplecopiesofasamefeaturemayexistinaproduct)[18,19,20,22,23], featuregroupcardinalities(theabilitytochooseatleastminandatmostmaxfeaturesfromagroupof features)[14,19,20,22,23],theabilitytouselogicalformulasorOCL(ObjectConstraintLanguage)to expressadditionalconstraintsbetweenfeatures [20],usingtextuallanguageinsteadofdiagrammatic language[17,23].

Figure1.FeaturediagramFODA:CoffeeMachine Useoffeaturemodeltomodelvariabilityonthespecificationlevel: Many approaches [10,12,14,15,16,17,19,24,25,26] use feature model to model variability on the specificationlevel.Withthisapproach,highleveldescriptionoftheproductlineisdescribedintermof featuresavailablefortheproductsinthefamily.Variabilityiscapturedintermofvariablefeatures(i.e. optionalandalternativefeatures).Forthecoffeemachinefamily,featurediagraminfig.1modelsthe followingvariabilities:alternativechoiceofcointypebetween1$and1(themachinecanbe activatedusing1$coinor1coin),optionalbeveragetypesTeaandCappuccino(themachinecan optionallyserveteaandcappuccino)andoptionalringtoneRingtone(themachinemayormaynot ring the ringtone). It also captures constraints between features, that is Cappuccino requires Ringtone (the machine that serves cappuccino must have a ringtone) and 1$ excludes Cappuccino(cappuccinoisonlyofferedbyEuropeanproductwhichuses1cointype). 2.2Orthogonalvariabilitymodel(OVM) Orthogonalvariabilitymodel: OrthogonalVariabilityModel(OVM)isusedtodocumentvariabilityinseparatemodel,meaningthat variabilityisnotdirectlyincorporatedinbasemodels.InSPLengineeringcontext,modelsforming coreassetssuchasrequirementsmodels,architecturemodelsortestmodelsarecalledbasemodels.In [27],theyuseOVMmodelstodocumentPLvariability(variabilityonthespecificationlevel)andrelate thoseOVMmodelstobasemodels. In OVM [27], variability is modeled using variation points and variants. A variation point (VP) representsavariableitem.Variants(V)documentspossibleinstancesofaVPandthusarerelatedto VP.Fig.2showsgraphicalnotationforOVMandfig.3showsOVMmodeldocumentingvariabilityon thespecificationlevelofthecoffeemachine.VPisrepresentedbytriangle(e.g.Coininfig.3)and variantisrepresentedbyrectangle(e.g.1$infig.3).VariantslinkedtoVPthroughdashedlines (resp.solidlines)areoptionalvariants(resp.mandatoryvariants).Infig.3,Teaisanoptionalvariant while Coffee is a mandatory variant for Beverage variation point. Mandatory variant must be selectedifitsVPisselected.OptionalvariantcanbutdoesnothavetobeselectedifitsVPisselected. Alternativechoicecanbeusedtogroupoptionalvariantsandcardinalityintheformof[min..max]can bespecifyforthegrouptoindicatethatatleastminandatmostmaxvariantsmustbeselectedfromthe

groupiftheirVPisselected.Thedefaultrange,[1..1],isomittedinthediagram.Forexample,variants 1$and1formanalternativechoicewithcardinality[1..1]whichisomittedinfig.3.Constraints betweenvariationpoints,betweenvariants,andbetweenvariantandvariationcanbemodeledusing variousconstraintdependencies:requires_V_V(avariantrequiresanothervariant),requires_V_VP(a variantrequiresavariationpoint),requires_VP_VP(avariationpointrequiresanothervariationpoint), excludes_V_V (avariantexcludes anothervariant),excludes_V_VP (avariantexcludes avariation point)andexcludes_VP_VP(avariationpointexcludesanothervariationpoint).Asexamples,fig.3 showsrequires_V_VconstraintbetweenvariantCappuccinoandvariantRingtonewhichmeans that if Cappuccino is selected Ringtone must also be selected, and excludes_V_V constraint between variant 1$ and variant Cappuccino which means that if variant 1$ is selected Cappuccinomustnotbeselectedandviceversa.Artifactdependency(resp.VPartifactdependency) isusedtorelatevariant(resp.VP)toelementsinbasemodels.Forexample,therecanbeartifact dependencylinkfromvariant1$totransitionlabeledwitheventofinserting1$coininbehavior model.

Figure2.Graphicalnotationforvariabilitymodel[27]

Figure3.OVMmodelofthecoffeemachine UseofOrthogonalVariabilityModeltomodelvariabilityonthespecificationlevel: Variability concerning high level product line description can be documented using OVM. Unlike featuremodelwhichcontainsbothvariablefeaturesandcommonfeatures,OVMmodelcontainsonly variabilityinformation.Inthisapproach,variabilityisdescribedintermofvariableitem(whichis modeledusingvariationpoint)andinstancesofvariableitem(whicharemodeledusingvariants).For example,infig.3,thevariabilityincoffeemachineismodeledusingthreevariationpoints:Coin,

BeverageandNotification.Thefactthatonlyonecointype(1$or1)canbeselectedismodeledusing alternativechoicewithdefaultrange([1..1]).Theoptionalbeverages(teaandcappuccino)servedbythe coffeemachinearemodeledusingoptionalvariants.OptionalvariantRingtonemodelthefactthat themachinemayormaynothaveringtone.Finally,thefactthatringtonemustberungafterserving cappuccinowhichmeansthatthemachinemusthaveringtoneismodeledusingrequires_V_Vlink fromCappuccinotoRingtoneandthefactthatcappuccinoisofferedonlybyEuropeanproducts which means that cappuccino is not offered by US products (use 1$ coin) is modeled using excludes_V_Vbetween1$andCappuccino. 2.3Goalmodel Goalmodel: Goalmodel captureshowthesystem'sfunctionalandnonfunctionalgoalscontributetoeachother throughrefinementlinksdowntosoftwarerequirementsandenvironmentassumptionswheregoalis definedasaprescriptivestatementofintentthatthesystemshouldsatisfythroughthecooperationofits agents [28].ItisgraphicallyrepresentedbyanAND/ORgraphcalleda goaldiagram.Fig.4shows exampleofportionofagoaldiagramforthecoffeemachine.Thetopgoalsarethehighestlevelones still in the system scope while the bottom goals represent software requirements or domain assumptions.AgoalmaybeANDrefinedintomultiplesubgoalsdenotedbyarrowjoiningsubgoalsto theparentgoal.ThemeaningofANDrefinementisthataparentgoalcanbesatisfiedbysatisfyingall itssubgoals.Forexample,thegoalBeverageServed(toservebeverage)infig.4canbesatisfiedby satisfyinggoalsCoinInserted(toinsertcoin),BeverageChosen(tochoosebeverage)andalsoother goalsthatarenotmentionedlikeBeverageDelivered(todeliverbeverage)andBeverageTaken(to take beverage). A goal can be ORrefined into multiple ANDrefinements denoted by multiple incomingarrows.EachoftheseANDrefinementsiscalledanalternativeforachievingtheparentgoal. ThemeaningofORrefinementisthattheparentgoalcanbesatisfiedbysatisfyingtheconjoined subgoalsinanyofthealternativerefinements[29].Asexample,infig.4,thegoalCoinInserted(to insertcoin)canbesatisfiedbyeither1$CoinInserted(toinsert1$coin)or1CoinInserted(to insert1coin).

Figure4.Portionofgoalgraphforthecoffeemachine UseofGoalModeltoModelVariabilityontheSpecificationLevel: Inthisapproach,highlevelproductlinedescriptioniscapturedintermofgoal.Variabilityismodeled usingORrefinementthatcapturedifferentwaystosatisfyagoal.Forthecoffeemachineexample, variability concerning the coin type is captured by ORrefining the goal CoinInserted into two subgoals1$CoinInsertedand1CoinInserted.Similarly,thevariabilityconcerningbeveragetype maybecapturedbyORrefiningthegoalBeverageChosenintomultiplesubgoalseachrepresenting goaltochoosebeveragefromasetbeverages(i.e.{Coffee},{Coffee,Tea},{Coffee,Cappuccino},

{Coffee,Tea,Cappuccino})thatcanbeservedbythemachine.Constraintscanbeexpresseddirectly using goals. Constraint stating that cappuccino is only offered by European products may be represented with the goal g1: CappuccinoOnlyForEuropean. With that goal, choosing g2: 1$CoinInsertedandg3:BeverageChosenFromCoffeeCappuccino(chooseonebeveragefromthe set{Coffee,Cappuccino})togethercanbepreventedbecausethatchoicecausesconflictsamongthe threegoalsg1,g2andg3.Thethreegoalsareinconflictbecauseg2issatisfiedbyUSproducts,g3can besatisfiedbychoosingcappuccinowhichmeansthatUSproductscanservecappuccino,causing conflictwithg1.Anotherconstraintstatingthatringtonemustberungifcappuccinoisservedmaybe expressedusinggoalg4:RingtoneRungIfCappuccinoServed.Therearetwoalternativewaystosatisfy thatgoal:cappuccinoisnotserveddenotedbyg5:CappuccinoNotServedorringtoneisrungdenoted byg6:RingtoneRung.Soif,forexample,thegoalg3ischosen(g3canbesatisfiedbychoosing cappuccino),alternativechoiceg5cannotbechosenforg4asg5isinconflictwithg3. 2.4Decisionmodel Decisionmodel: Decisionmodelconsistsofasetofdecisionsalongwithpossibleoptionsforeachdecision.Models presentedabovelikefeaturemodel,OVMmodelandgoalmodelmayalsobeconsideredasdecision modelbecauseeachofthosemodelcontainsdecisionstomakebutthosedecisionsareimplicit.Inthis section,weconsiderdecisionmodelinwhichdecisionsareexplicit.In[30],decisionmodelconsistsof asetofdecisionvariables.Adecisionvariablecorrespondstoavariability.Table1showsdecision modelofthecoffeemachine.Eachrowcontainsadecisionvariable.Adecisionvariablehasaunique namethatservesasitsidentity,adescriptiondescribingthevariabilityrepresentedbythisvariable,a rangethatgivepossiblevalues forthatvariable,aconstraintspecifyingconstraintconcerningthat variableandbindingtimesshowingpossiblestagesatwhichtotakedecisionaboutthisvariable.For example,considerthedecisionvariableRingtone.Itsdescriptionspecifythevariabilityonwhether the machine has ringtone or not which is specified by the range (TRUE, FALSE). Constraint concerningthisvariableisthatifthemachinecanserveCappuccino(CappuccinoinBeverage),ithas tohaveringtone(Ringtone=TRUE).Thevaluemustbeassignedtothisvariableatorbeforedesign time.ThereisanothercolumnRelevance (notshownintable1)inwhichwecanputcondition concerningtherelevanceofthevariable.Iftheconditionevaluatestofalse,thevariableisnotrelevant andthusdoesnotneedtobeconsidered.Forinstance,thevariableMEMORY_SIZE(decisionvariable concerningthesizeofthememory)isrelevantonlyifHAS_MEMORY=True(decisionvariable concerningwhethertoincludememoryornot). Useofdecisionmodeltomodelvariabilityonthespecificationlevel: Withthisapproach,variabilityismodeledintermofdecisionvariablewithrangerepresentingpossible instancesofthevariability.Forexample,variabilityinthecoffeemachine(table1)ismodelingusing three decision variables: Coin (variability concerning coin type), Beverage (variability concerning beveragetype)andRingtone(variabilityconcerningringtone).Therangeofeachdecisionvariable providespossibleoptionsforthecorrespondingvariability.Constraintscanbeexpressedinconstraint column.

Name Coin

Description Type of coin used to activate 1$, themachine(1$forUSproduct 1 and1forEuropeanproduct)

Range

Constraint

Binding Times

Cappuccino in Compile Beverage => Time Coin=1

Beverage Setofbeveragesservedbythe {Coffee}, Coin = 1$ => Installation machine {Coffee,Tea}, Cappuccino not {Coffee,Cappuccino}, inBeverage {Coffee,Tea,Cappuccino} Ringtone Does the machine have TRUE, ringtone? FALSE Cappuccino in Design Beverage=> Time
Ringtone=TRUE

Table1.Decisionmodelofcoffeemachine 2.5Commonalityandvariabilityanalysis Commonalityandvariabilityanalysis(CVA) [31] isusedtodocumentrequirementscommontoall productsintheproductline(i.e.thecommonality)andrequirementsspecifictoonlysomeproducts(i.e. variabilityorvariation).TheCVAdocumenthasthreeparts:commonality,variationanddependency. Withthisapproach,productlinedescriptionisdescribedusingtextualrequirementswhicharesplitinto threepartscorrespondingtothethreepartsoftheCVAdocument.Variabilityisprovidedinvariations section.Table2showsexceptsfromcoffeemachinefamilycommonalityandvariabilityanalysis. Commonalities C1.Themachineshallbeabletoservecoffee. C2.Theusershallbeabletochoosewhethershewantsthesugarornot. C3.Themachineshalldisplaydonemessageafterdeliveringthebeverage. Variations V1.Coinusedtoactivatethemachinemaybe1$coinor1coin.[1$,1] V2.Themachinemayincluderingtone.[TRUE,FALSE] V3.Themachinemayservetea.[TRUE,FALSE] V4.Themachinemayservecappuccino.[TRUE,FALSE] Dependencies D1.Themachinethatisabletoserveteamustincluderingtone. D2.OnlyEuropeanproduct(use1coin)canservecappuccino. Table2.Exceptsfromcoffeemachinefamilycommonalityandvariabilityanalysis 3.Variabilityontherealizationlevel Thissectiondescribeshowvariabilityontherealizationlevelforvariousrequirementsmodelscanbe

expressed. Requirements are documented using natural language text (textual requirements documentation) or a requirements modeling language such as data models, behavioral models or functionalmodels[32]. 3.1Textualrequirementsdocumentation Variability can be expressed directly in natural language. Due to the ambiguous nature of natural language,itisnotsuitabletoexpressvariabilityusingnaturallanguagealone.Forexamplefromthis requirementthecoffeemachinecanbeactivatedby1$coinor1coin,itisnotclearwhethertheor isinclusiveororexclusiveor.Pohlproposestoeitherdocumentvariabilityoftextualrequirements inaseparatemodelusingOVMordocumentvariabilityusingXML [32].Fig.5showsexampleof documentingvariabilityoftextualrequirementsofthecoffeemachinefamilyusingOVM.Thereisone variationpointCoinwithtwovariants:1$and1.Eachvariantpointstothecorrespondingtext fragments.

Figure5.Orthogonalvariabilitymodelintextualrequirements Thevariabilityintextualrequirementsinfig.5canalsobedocumentedbyenrichingtextualdocument withXMLtagsasshownbelow: Thecoffeemachineshallbeactivatedwith <textfragmentvariantid=V1_1>1$coin</textfragment> <textfragmentvariantid=V1_2>1coin</textfragment> 3.2.Requirementsmodel Thissectionpresentsmethodstodocumentvariabilityinrequirementsmodel.First,methodsthatcan beappliedtoallrequirementsmodelsarepresented.Afterthat,methodstomodelvariabilityonlyin specificrequirementsmodelarepresentedineachsubsection. BachmannandPohlproposetouseOVMtodocumentvariabilityinallrequirementsmodels[33],[32]. Similar to what is shown in fig. 5, variability is modeled using OVM models. Requirements are modeledusingclassicmodelslikestructural,functionalorbehavioralmodels.ThoseOVMmodels,that

modelvariability,arerelatedtorequirementsmodelstohighlightvariabilityinrequirementsmodel. In[14],<<variant>>stereotypeisusedtomarkUMLmodelelementsasvariableelements,andtagged valuewiththekeyfeature({feature=feature_name})torelatemodelelementtofeatureinfeature model.Anelementispresentinthemodelofaparticularproductifthecorrespondingfeature(tagged valueinthatelement)isselectedfortheproduct.Fig.6showportionofstructuralmodelofthecoffee machineinUMLclassdiagramusing<<variant>>stereotypetomarkvariableelements.Inthisfigure, variableclasses1$Coin,1CoinandRingtonearemarkedwith<<variant>>stereotypeandare taggedwiththecorrespondingfeaturestakenfromfeaturediagrampresentedinfig.1.Soforinstance, ifthefeature1$ischosenforaparticularproduct,theclass1$Coinisincludedinthemodelofthat product.

Figure6.Portionofstructuralmodelofthecoffeemachineusing<<variant>> Czarneckiannotatesmodelelementswithpresenceconditionexpressedintermoffeaturestomodel variableelements[34,35].Asshowninfig.7,eachpresenceconditionisassociatedwithdifferentcolor accompaniedbyauniquenumberincasethemodelisviewedintheenvironmentthatdoesnotsupport viewingcolor.Thosepresenceconditionsareexpressedintermoffeaturesinfeaturediagramoffig.1. Commonelementsarerepresentedbyblackcolor(withconditionTrue)withoutnumberannotating them.As anexampleofavariableelement,infig. 7,the presence condition 1$(this condition evaluatestoTrueiffthefeature1$isselected)isassociatedwithbluecolorandthenumber1.The class 1$Coin is shown in blue color with number 1 annotating it and thus corresponds to that presencecondition.

Figure7.Portionofstructuralmodelofthecoffeemachineusingpresencecondition BeckerusesXMLtodescribevariabilityincoreassets[36].Asanexample,thevariabilityconcerning the coin type in coffee machine can be represented as shown below (vsl stands for variability

specificationlanguage): <vsl_selectid="Coin"> <vsl_optionvalue="1$"/> <vsl_optionvalue="1"/> </vsl_select> Schmidusesvariationpointtorepresentvariabilityinrequirementsmodelsinwhichvariationpointis expressedintermofdecisionvariables[30].Asanexample,theportionofthetextualrequirementsof thecoffeemachineconcerningcointypevariabilityisshownbelow: Themachineshallbeactivatedusing <<altCoin=1$/TRUE/1$coin /FALSE/1coin>> Inthisexample,thevariationpointisexpressedusingdecisionvariableCoinindecisionmodel presentedintable1.IftheCoinvariabletakesvalue1$thisvariationpointwillbereplacedwith 1$coin,otherwiseitwillbereplacedwith1coin. Inthefollowingsubsections,wepresentapproachestodocumentvariabilityinspecificrequirements model. 3.2.1Structuralmodel StructuralmodelcanberepresentedusingUMLclassdiagram.VariabilitycanbeexpressedinUML classdiagramusingcardinalityinrelationship(e.g.[0..1]canbeusedtomodeloptionality)andbuiltin specializationrelationship(torepresentalternativeoption).Variabilityexpressedinthis wayis not explicit.Wecan'tdistinguishbetweennormaluseofcardinalityanduseofcardinalitytorepresent variability.Thesameistrueforspecializationrelationship. Claussuses<<variationPoint>>,<<variant>>and<<optional>>stereotypestorepresentvariabilityin classdiagram [37].Classrepresentingvariationpointismarkedwith<<variationPoint>>whileclass representingvariantismarkedwith<<variant>>.<<variationPoint>>classislinkedto<<variant>> classthroughspecializationrelationship.Optionalclassismarkedwith<<optional>>.Inthisapproach, taggedvalues arealsousedtoprovide additional variabilityrelatedinformation likemultiplicities, bindingtimesandconditionsonwhetherornottochooseaparticularvariant.Similartothisapproach, in[38]<<variation>>isusedinsteadof<<variationPoint>>.Forexample,theclassCoininfig.8is markedwith<<variationPoint>>torepresentavariationpointinclassdiagram.Bindingtimeand multiplicityarealsospecifiedforthisvariationpoint.Multiplicity=1meansthatonlyonevariantcanbe chosenforthisvariationpointfromthesetofvariantscontaining1$Coinand1Coinmarkedwith <<variant>>.Similarly,optionalvariabilityRingtoneismarkedwith<<optional>>.

Figure8.Portionofstructuralmodelofthecoffeemachineusing<<variationPoint>> 3.2.2Usecasemodel In[39],<<variant>>stereotypeisusedtomarkvariableusecaseandvariableactorinusecasediagram whilevariabletextfragmentsinusecasescenarioaremarkedwithexplicitXMLliketags<variant> and</variant>.Whetherausecaseisoptionaloralternativeandhowtoselectavariableusecaseis capturedinthedecisionmodel.Forthecoffeemachineexample,usecaseInsert1coinmightbe markedwith<<variant>>stereotypetoindicatethatitisvariableusecase,andthetextfragmentInsert 1coinintothemachineinusecasescenariomightbeenclosedwith<variant>and</variant>.The decisionmodelforcoffeemachinemightsaythatif1$coinischosenforthecointype,thenremove usecaseInsert1coinandremovetextfragmentInsert1coinintothemachineinusecase scenario. Bertolinoinsertstagsintousecasescenariotoidentifyandspecifythevariations [40].Tagsactas placeholders.Differentoptionsthatcanbeusedtoreplacethetagsaresupplieddirectlyinusecase.As example,inthecoffeemachine,theremightbeatagtospecifywhichcointypetoinsertintothe machine(e.g.insert{[V0]coin}intothemachine)intheusecasescenarioforBuybeverage.The twoalternativeoptionstochooseforthetag{[V0]coin}mightalsobespecifiedinthescenario(e.g. V0:alternative;option1:1$coin;option2:1coinmeaningthatwecanchoose1ofthe2optionsto replacethetag{[V0]coin}). Halmansintroducesadditionalgraphicalnotationtriangleinusecasediagramtoexplicitlyrepresent variationpoint[5].Blacktrianglerepresentsmandatoryvariationpointwhilegraytrianglerepresents optional variation point. Variation point is associated with one or more use cases using the <<include>> relationship. Variant use case is marked with <<variant>>. A variation point can be associatedwithasetofvariants.Cardinalities[min..max]isusedtoindicatethatatleast min andat most max variantshavetobeselectedforthevariationpoint.Forthecoffeemachineexample,the variabilityconcerningcointypeinusecaseInsertCoincanberepresentedinscenariooftheusecase orintheusecaseitselfasshowninfig.9.ThevariationpointCoinTypeisassociatedwithtwo variantusecasesInsert1$CoinandInsert1Coinwhicharemarkedwith<<variant>>.The cardinality1..1indicatesthatoneofthetwovariantsmustbechosen.Notethat,inthefig.9,the variabilityinusecaseChooseBeverageisnotshownintheusecaseitselfandthusissupposedtobe modeledinthescenario.

Figure9.Usecasediagramofthecoffeemachineincludingvariationpointsandvariants In[21],thestepidentifierinusecasescenarioisextendedtoexpressvariability.Astepidentifiedwitha number is mandatory step as in classic scenario. Several steps identified by the same number correspond to a number of mutually exclusive alternatives for one mandatory step. Several steps identifiedwiththesamenumberandaconsecutiveletteridentifyanumberofalternativesforone mandatorystepinthescenariooutofwhichatleastonemustbeselected.Astepidentifiedbyanumber withinparenthesisidentifiesanoptionalstepinthescenario.Severalstepsidentifiedwiththesame numberwithinparenthesisandaconsecutiveletteridentifyanumberofalternativeforoneoptional stepinthescenariooutofwhichatleastonemustbeselected.Severalstepsidentifiedwiththesame numberwithinparenthesisidentifyanumberofmutuallyexclusivealternativesforoneoptionalstepin thescenario.Thosevariablestepsarerelatedtofeaturesinthefeaturemodel.Table3showshowto representvariabilityinscenarioofusecaseBuyBeverageofthecoffeemachineusingthisapproach. Step Action
Mutuallyalternative steps Mandatorystep

1 1 2 3 3 3 3 4 5

Userinserts1$coinintothemachine Userinserts1coinintothemachine Userchooseswhetherornotshewantsthesugarbypressingoneof thetwobuttons Userchoosesbeveragefromtheset{Coffee} Userchoosesbeveragefromtheset{Coffee,Tea} Userchoosesbeveragefromtheset{Coffee,Cappuccino} Userchoosesbeveragefromtheset{Coffee,Tea,Cappuccino} Themachinedeliversthebeverage Themachinedisplaysdonemessage Themachineringaringtone

Optionalstep

(6)

7 Usertakesthebeverage Table3.ScenarioofusecaseBuyBeverageofthecoffeemachine

3.2.3Behavioralmodel Kangusesfeatureasconditionontransitionofstatechartdiagramtomodelvariabilityinstatechart diagram [10].Forthecoffeemachineexample,thecondition1$(whichevaluatestoTrueiffthe feature1$fromfeaturediagraminfig.1ischosen)mightbeaddedtothetransitionfiredwhenthe eventofinserting1$coinoccurs. ExtensiontoUMLsequencediagramisproposedin[38]torepresentvariabilityinsequencediagram. For that extension, <<optionalLifeline>> stereotype is used mark optionality for object and <<optionalInteraction>>stereotypeisusedtomarkoptionalinteractions.Alternativeinteraction(i.e. only one interaction can be present is a given product) can be modeled using <<variation>> and <<variant>>stereotypes.Aninteractionenclosesasetofsubinteraction.Eachalternativevariantis markedwith<<variant>>stereotype.Asetofalternativeinteractionsformingalternativeoptionis enclosedinaninteractionmarkedwith<<variation>>stereotype.<<virtual>>stereotypeisusedto definedvirtualpartinsequencediagramthatcanbereplacebyanothersequencediagramforeach product.Fig.10showsportionofsequencediagramBuyBeverageofthecoffeemachine.Interaction sdCoinmarkedwith<<Variation>>representsavariationpointwithtwovariantinteractionsd1$ andsd1markedwith<<Variant>>andtaggedvalueshowingthevariationpointtheyareassociated with.:Ringtoneisanoptionalobjectandthusismarkedwith<<OptionalLifeline>>whileRing Ringtoneismarkedwith<<OptionalInteraction>>torepresentoptionalinteraction.

Figure10.PortionofsequencediagramBuyBeverageofthecoffeemachine

Labeled Transition System (LTS) is one of the most popular formal methods for modeling and reasoningaboutsystembehaviorforsinglesystemsdevelopment.ModalTransitionSystems(MTSs) havebeenproposedtomodelafamilyofsuchLTSs[41].TherearetwotypesoftransitionsinMTS: mustandmaytransitions.MusttransitionsmustbepresentineveryLTSsderivedfromtheMTSwhile may transitionscanbutdon'thavetobepresentinLTSsderivedfromMTS.VariabilityinMTSis modeledusingmaytransitions.Fig.11showsbehavioralmodelofthecoffeemachineusingMTS. maytransitionisrepresentedbydashedlinewhilemusttransitionisrepresentedbysolidline.As example,transitionslabeledwith1$and1aremaytransitionsbecausetheymayormaynotbe present in some products. Similarly, transitions labeled with tea and cappuccino are may transitions.Incontrast,transitionlabeledwithcoffeeismusttransitionbecauseitmustbepresent ineveryproduct.

Figure11.BehavioralmodelofthecoffeemachineusingMTS[3] LarsendescribestheuseofModalI/OAutomatatomodelbehaviorofaproductline[42].LikeMTS, ModalI/OAutomatahastwotypesoftransitions:mustandmaytransitionsinwhichmaytransitionsare usedtomodelvariabilityinbehavior.FantechiproposesExtendedModalTransitionSystem(EMTS), anextensionofMTStoaddthecapabilitytomodelthefactthatatleastoneofntransitionsandatmost oneofntransitionsmustbepresentinanyproductofthefamily[43].ShortlyafterEMTS,Generalized ModalTransitionSystem(GEMTS)isproposedbythesameauthortoexpressatleastkofntransitions andatmost k of n transitionsmustbepresentinanyproductofthefamily [44].Asirellishowshow deonticlogiccanexpressvariabilityofafamilybyshowingthecapabilityofadeonticlogicformulato finitelycharacterizeafinitestateModalTransitionSystem[45].Deonticlogicisabletoexpressboth theevolutionintimeofasystembymeansofanaction(e.g.fromstate0tostate1infig.11),andthe factthatcertainactionsareobligatoryornotinagivenstate(e.g.infig.11theaction1$isnot obligatorywhiletheactionpour_coffeeis)andthuscancharacterizeaMTS.Moreover,properties suchasitispermittedtogetacoffeewith1anditispossibletoaskforsugarcanbeexpressed usingdeonticoperators.Hence,thosepropertiescanbecheckedagainstdeonticformulacharacterizing aMTSbyusingaxiomsystemofdeonticlogic.

FeaturedTransitionSystemisproposedin [46] tomodelbehavioralvariabilityinafamily.Inthis approach,variabilityismodeledbylabelingeachtransitionwithafeatureinfeaturemodelanddefining priority relation over the labeled transitions. Transitions labeled with features at higher hierarchy (ancestor features) have less priority than transitions labeled with features at lower hierarchy (descendantfeatures)infeaturediagram.Priorityrelationbetweentwotransitionsisnotdefinedifone transitionlabeledwithonefeature(f1)andanothertransitionlabeledwithanotherfeature(f2),andf1is notdescendantorancestorofoff2.Thebehaviorofoneparticularproductisobtainedbyremovingall transitionsassociatedwithfeaturesnotincludedinthatproductandforasetoftransitionscomingfrom thesamestate,keepingonlytransitionwiththehighestpriority.Theideaisthatbecauseancestor featurerepresentsmoregeneralizedfeatureanddescendantfeaturerepresentsmorespecializedfeature, transitionlabeledwithmorespecializedfeature(higherpriority)overridestransitionlabeledwithmore generalizedfeature(lowerpriority). 4.Traceabilitylinkbetweenvariabilityonthespecificationandontherealizationlevel Featuremodel: Variability on the specification level is expressed using feature model. Links from features to requirementsartifactscanbeexplicitorimplicit.Intheformercase,thereareexplicitlinksbetween features and requirements artifacts [13,21]. In the later case, the links between features and requirementsartifactsaredescribedimplicitlybyassociatingconditionexpressedintermoffeatures withrequirementsartifacts [14,34,37].Artifactswithconditionthatevaluatestofalsewithregardto featuresselectedforaparticularproductarenotconsideredforthedevelopmentofthatproduct. OrthogonalVariabilityModel: Withthisapproach,variabilityonthespecificationlevelisdocumentedinOVMmodelandexplicit linksfromthatOVMmodeltobasemodelsareusedtohighlightvariabilityinbasemodels(variability ontherealizationlevel)andthuscanserveastraceabilitylinkbetweenvariabilityonthespecification levelandontherealizationlevel[27]. Goalmodel: Variabilityonthespecificationlevelismodeledingoalmodel.Variouslinksbetweengoalandother models (requirements models) can be used to trace variability between goal and other models: Obstructionlinkisusedtotracegoaltoobstruction,Concernlinkisusedtotracegoaltoobject, Responsibilitylinkisusedtotracegoaltoagent,Operationalizationlinkisusedtotracegoalto operationandCoveragelinkisusedtotracegoaltobehavior[28]. Decisionmodel: Forthisapproach,variabilityonthespecificationlevelismodeledindecisionmodel.Traceabilitylinks between decision model and requirements models are described implicitly by expressing variation points in requirements models in term of decisions in decision model (see section 4.2, the part concerninguseofvariationpointtomodelvariabilityinrequirementsmodel)[30].

5.Derivingindividualproducts Derivingindividualproductsindoneinapplicationengineeringsubprocess.First,highlevelproduct descriptionisderivedfromhighlevelproductlinedescription.Afterthathighlevelproductdescription isusedtoselectedandconfigurevariousartifactstobeusedtodevelopindividualproducts. 5.1Derivingproductdescription Featuremodel: Inthiscase,theproductisdescribedintermoffeatures.Productderivationisalsoreferredtoas productconfiguration.Classicderivationofproductdescriptionconsistsofnavigatingthroughfeature graph and select the desired features by respecting feature dependencies and constraints. In [19], productdescriptioncanbederivedinseveralstages.Eachstageproducesamorespecializedfeature diagramfromthepreviousstagebymakingdecisionforsomevariabilities.Eventuallyallvariabilities areresolvedafterthelaststagewhereproductdescriptioncanbeobtained.Thesameauthorhaslater proposedtosplitfeaturediagramintorelatedchunkscalledlevels[47].Thenumberofstagesandlevels areequal.Fornlevels,atstagej(j<n),featurediagramatleveljisconfiguredmanuallyfollowedby automaticspecializationoffeaturediagramatlevel j+1 basedonchoicesmadeatlevel j. Atthelast stage,stagen,featurediagramatlevelnismanuallyconfiguredtoobtainfeaturediagramrepresenting theproductdescription.Thisconfigurationprocessisdonesequentiallyi.e.stagej+1isdoneafterstage j.Toallowmoresophisticatedprocessinsteadofsequentialone,HubauxsuggeststouseYAWL(Yet AnotherWorkflowLanguage),aworkflowlanguage,torepresenttheconfigurationworkflowoffeature diagramsatdifferentlevels[48]. Yuproposestoconfigurefeaturediagramtakingintoaccountstakeholders'goals [49].Tothisend, hardgoalisconvertedintofeature.Thatfeatureislabeledwithsoftgoalstowhichthecorresponding hardgoalcontributepositivelyornegatively.Thestakeholderscanthenusedsoftgoalsinformationto decidewhichfeaturestoselect. OrthogonalVariabilityModel: WithOVM,highlevelproductdescriptioncanbeobtainedbychoosinganumberofvariantsfroma givensetofvariantsforeachvariationpointwhilerespectingconstraintsanddependenciesinthat OVMmodel.Tohelpinthederivationprocess,usecasescenarioisusedalongwithOVMtoderive productdescriptiontakingintoaccountstakeholders'requirements [50].VariantsinOVMthatareof interesttostakeholdersarediscussedindetailbyemployingtheassociatedscenarios.Fromscenarios, additionalvariantscanbeidentifiedinOVMbyusingassociationbetweenscenariosandvariants.This processcontinuesrecursivelyuntilallvariabilitiesareresolved. Goalmodel: Forthisapproach,productisdescribedintermofgoals.Toderivetheproductdescription,weneedto navigatethroughgoalgraphandmakechoicebetweendifferentalternativeswhichsatisfythesame goal.Lamsweerdedescribeshowtochoosevariantthatcontributesbesttoaparticularsoftgoalusing qualitativeandquantitativeapproachesforsinglesystem [28].Tosupportsoftwareproductline,he proposestolabeleachvariantwithalistofproductstowhichthevariantbelongs.Withthoselabels, derivinggoalmodelforaparticularproductPconsistsoftraversinggoalmodelrepresentingproduct family top down and breadth first. At each variation point, the upwards commonalities and the

successorvariantwhoselabelincludesParekeptandallothersuccessorsarediscarded. Decisionmodel: Forthisapproach,productdescriptionisderivedbyansweringquestionconcerningeachdecisioninthe decisionmodelwhiletakingintoaccountdependenciesbetweendecisions. 5.2Selectingandconfiguringproductlineartifacts Fromproductdescription,productlineartifactscanbeselectedandconfiguredusingtraceabilitylinks betweenvariabilityonthespecificationandontherealizationlevelasdiscussedinsection5.For explicittraceabilitylinks,wetakeallartifactsrelatedtoelementsinproductdescriptionbytraceability links.Inthecaseofimplicitlinks,artifactswiththeassociatedconditionthatevaluatestofalsewith regardtotheproductdescriptionarediscarded.Someelementsinproductdescriptionmaybeusedas parameterstoconfiguresomeartifacts. 6.Analyses Mannionproposestoconvertrequirementsvariabilityanddependenciesintopropositionalformula(for example, requirement R1 requires requirement R2 is converted to R1 => R2, requirement R1 is mutuallyexclusivewithrequirementR2isconvertedtoR1<=>R2)andtousepropositionalcalculus toanalyzepropertiesoftheproductlinesuchas1)doesthereexistanysinglesystemthatsatisfiesthe relationshipintheproductlinemodel?2)givenasubsetofproductlinerequirements,canweknowifit formsavalidsinglesystem?3)Howmanyvalidsinglesystemcanbebuiltusingthisproductline model?4)whatrequirementsdovalidsinglesystemscontain?[51],[52]. In[53],featurediagramisconvertedintogrammarfromwhichaparsercanbegeneratedtoserveas configuration validator. For example, feature diagram in fig. 1 can be converted to the following grammar(?marksoptionalterm): CoffeeMachine:CoinBeverageRingtone? Coin:1$|1 Beverage:CoffeeTea?Cappuccino? Batory shows the connexion between feature diagram, grammar and propositional formulas by convertingfeaturediagramtogrammarandthenfromgrammartopropositionalformulas [54].For example,thegrammarCoin:1$|1canbeconvertedintothefollowingformula: (Coin=>(1$xor1))/\(1$=>Coin)/\(1=>Coin) Withthosepropositionalformulas,LogicTruthMaintenanceSystem(LTMS)canbeusedtopropagate constraintsasusersselectfeaturesinproductspecificationandSATsolverscanbeusedtohelpdebug featuremodel. MendoncaexplorespossibilitiestoimproveBDDandSATSolverforanalysisoflargescalefeature model[55].HedefinedheuristicsforBDDvariablesorderingthatyieldbetterBDD.ForSATSolver, he found that the logical formulas derived from the structure of feature diagram can be analyzed efficiently using SATSolver even though SAT is NPComplete. However, additional constraints

expressedusinglogicalformulascanposeperformanceproblemfortheanalysesoflargemodels. In [35],amethodtoverifythewellformednessoffeaturebasedmodeltemplateisproposed.The modeltemplatemetamodelmustbeexpressedinMetaObjectFacility(MOF)andwellformedness constraintsareexpressedinObjectConstraintLanguage(OCL).Forexample,thecheckcanensurethat abinaryrelationshipbetweentwoclassesmustberemovedifoneorbothoftheclassesareremoved. Liudescribeshowtoverifysafetypropertiesagainstbehavioralmodelinproductlineexpressedinstate chart[56].Inthismethod,productlinestatemodelrepresentedinstatechartandproductlinescenarios satisfyingorviolatingsafetypropertiesarebuilt.Afterthat,foreachproductP,eachcustomizedstate model(derivedfromproductlinestatemodelforP)isexecutedagainstthecorrespondingcustomized scenarios(derivedfromproductlinescenariosforP)usingTestConductortooltocheckwhetherany safetypropertiesareviolated.Notethatthecheckisdoneattheproductlevelnotproductlinelevel. Classen uses Featured Transition System (FTS) to model behavior in product line and describes algorithmstocheckregularandomegapropertiesagainstFTS [46].AsirellidefinesDHML,anovel deonticextensionofHennessyMilnerandCTLlikelogicforproductfamiliesthatallowsbothstatic constraintsovertheproductsandconstraintsoverbehaviorstobeexpressedinasingleframework[3]. ModelcheckingcanbeusedtocheckthoseconstraintsagainstbehavioralmodelexpressedinMTS. 7.Elaborationtechnique Kangdescribestheelaborationprocessoffeaturemodelconsistsof(1)collectingsourcedocuments, (2)identifyingfeatures,(3)abstractingandclassifyingtheidentifiedfeaturesasamodel,(4)defining thefeaturesand(5)validatingthemodel[10].Czarneckiproposesmethodtoconstructfeaturediagram frompropositionalformulas[57].UseofOpenOMEtooltogenerateinitialfeaturediagramfromgoal graph is described in [49]. Antnio extends i* framework by adding cardinality to the intentional elements,makingiteasiertoderiveafeaturemodelfromi*models[58]. Commonality and Variability Analysis (CVA) which is the process to identity commonality (i.e. requirementscommontoallproductintheproductline)andvariability(i.e.requirementsspecificto onlysomeproducts)ispresentedin[31]. AnapproachforelicitationandspecificationofUseCasesforproductlinesbasedonexistinguser documentationisdescribedin[59]. Kim proposes method to identify domain requirements through goals and scenarios [60]. Liaskos describe goalbased variability acquisition by associating goal to a set of concerns from which alternativerefinementsofgoalcanbeintroduced [61].Forexample,forthegoalSendaMessage, there are a set of associated concerns each described with question such as Who will Send a Message?, To Whom?, When?, Where?, How fast?, What Message?. Answering those questionsresultinalternativerefinementsofthegoal.Forinstance,answeringthequestionWhowill SendaMessage?canyieldtwoalternatives:theuserorthemachine. Gomaadescribestheprocessofbuildingstatemachinesforsoftwareproductlineusinginheritedstate

machinesandparameterizedstatemachines [62].Forinheritedstatemachinesapproach,basestate machine(statemachinecommontoallproductsinthefamily)calledkernelstatemachineisbuiltand thenstatemachineforindividualproductcanbeobtainedbyspecializingkernelstatemachineby addingnewstates,neweventsandnewtransitions,andbyaddingorremovingactionsandactivities correspondingtofeaturesinthatproduct.Withparameterizedstatemachinesapproach,statemachineis designedwithallthestates,transitions,events,actions,andactivitiescorrespondingtoallthefeatures. Transitions,actionsandactivitiesthatdependonsomefeaturesareguardedwithconditionsexpressed intermofthosefeatures.Thenotation{feature=feature_name}state_nameisusedtoindicatethat thestatestate_nameisdependentonthefeaturefeature_nameforitsexistence. 8.Conclusion We described different approaches used to model variability onthe specification level and onthe realizationlevelinrequirementsengineeringcontext.OVManddecisionmodelrepresentvariability usingveryabstractconceptsnamelyvariabilitiesforOVManddecisionsfordecisionmodel.Moreover, thereisnostructuringmechanismbesidesbasicconstraintssuchasrequiresandexcludesinOVMand constraintsexpressedusingsetandlogicaloperatorsindecisionmodel.Therefore,wecannotdomuch analysesonthosemodels.CommonalityandVariabilityAnalysis(CVA)isdescribedusingtextual documentandthusisnotsuitableforanalysis.Becauseofitscompactrepresentationandthefactthat stakeholders arefamiliarwithfeatures,featuremodelisthemostpopularapproachusedtomodel variability. Despite its popularity, feature model does have some disadvantages. On the one hand, featuresarejuststringswithoutanysemantic.Ontheotherhand,decompositionsoffeaturesintosub featuresarearbitrary,thereisnopreciseruletocheckdecompositionadequacy.Moreover,because featuremodellacksinformationonwhyaparticularfeatureexists,usingfeaturemodelalonemake feature configuration process difficult. KAOS (Keep All Objectives Satisfied), Goaloriented requirements engineering method, described in [28] provides an approach covering the entire requirements life cycle that provides modeling notations as well as whole set of techniques for elicitation, evaluation, specification, analysis and evolution for single systems development. Even thoughorrefinementcanbeusedtomodelvariabilityinsystemfamilies,goalmodelisoriginally intendedforsinglesystemsdevelopment,hencemostofsystemfamiliesrelatedissueshavenotyetbeen exploredingoalmodel. Onedirectioninhandlingvariabilityinsystemfamiliesistoexplorefeaturemodelbecauseitisthe most used approach to model variability. To cope with the lack of semantic in features, we can investigatehow,bylabelingothermodelswithfeatureslikeinFeaturedTransitionSystem(FTS)[46], wecanprovidesemantictofeatures.Similarly,wecaninvestigatehow,byrelatingfeaturestoothers models,adequacyoffeaturesdecompositionorfeaturemodelcorrectnesscanbeverifiedandhow featureconfigurationcanbemadeeasier.Amongthoseothermodels,goalmodelisworthconsidering. AsKAOSprovidesanapproachcoveringtheentirerequirementslifecycle,anotherdirectionmightbe toexploregoalbasedrequirementsengineeringmethodtoseehowvariabilityrelatedissuescanbe handled.Insection2.3,wehaveshownhowconstraintsexpressedintermofgoalscanbeusedto eliminate alternative options that do not satisfy the constraints (goals) when selecting goals for a particularproduct.

References [1]"SoftwareProductLines,"http://www.sei.cmu.edu/productlines/. [2]C.Krueger,"Variationmanagementforsoftwareproductionlines,"SoftwareProductLines,2002, pp.113. [3]P.Asirelli,M.terBeek,S.Gnesi,andA.Fantechi,"Adeonticlogicalframeworkformodelling productfamilies,"matrix.isti.cnr.it,2010,pp.3744. [4]G.Bckle,K.Pohl,andF.Linden,"SoftwareProductLineEngineering,"SoftwareProductLine Engineering,Berlin/Heidelberg:SpringerVerlag,2005,pp.1938. [5]G.HalmansandK.Pohl,"Communicatingthevariabilityofasoftwareproductfamilyto customers,"SoftwareandSystemsModeling,vol.2,2003,p.1536. [6]M.BeckerandG.Kaiserslautern,"Towardsageneralmodelofvariabilityinproductfamilies," SoftwareVariabilityManagement,2003. [7]G.S.AndreasMetzger,KlausPohl,PatrickHeymans,PierreYvesSchobbens,"Disambiguatingthe DocumentationofVariabilityinSoftwareProductLines:ASeparationofConcerns, FormalizationandAutomatedAnalysis,"15thIEEEInternationalRequirementsEngineering Conference,2007,pp.243253. [8]J.vanGurp,J.Bosch,andM.Svahnberg,"Onthenotionofvariabilityinsoftwareproductlines," ProceedingsWorkingIEEE/IFIPConferenceonSoftwareArchitecture,2001,pp.4554. [9]J.Bosch,G.Florijn,D.Greefhorst,J.Kuusela,J.H.Obbink,andK.Pohl,"Variabilityissuesin softwareproductlines,"SoftwareProductFamilyEngineering,2002,pp.1321. [10]K.Kang,S.Cohen,J.Hess,W.Novak,andA.Peterson,Featureorienteddomainanalysis (FODA)feasibilitystudy,TechnicalReportCMU/SEI90TR21,SEI,1990. [11]P.Schobbens,P.Heymans,andJ.Trigaux,"Featurediagrams:Asurveyandaformalsemantics," 14thIEEEInternationalRequirementsEngineeringConference(RE'06),2006,pp.139148. [12]K.Kang,S.Kim,J.Lee,K.Kim,E.Shin,andM.Huh,"FORM:Afeatureorientedreusemethod withdomainspecificreferencearchitectures,"AnnalsofSoftwareEngineering,vol.5,1998,p. 143168. [13]M.Griss,J.Favaro,andM.D'Alessandro,"IntegratingfeaturemodelingwiththeRSEB," SoftwareReuse,1998.Proceedings.FifthInternationalConferenceon,IEEEComput.Soc, 1998,p.7685. [14]M.Riebisch,K.Bllert,D.Streitferdt,andI.Philippow,"ExtendingfeaturediagramswithUML multiplicities,"6thConferenceonIntegratedDesign&ProcessTechnology(IDPT2002), Pasadena,California,USA,2002. [15]K.Lee,K.Kang,andJ.Lee,"Conceptsandguidelinesoffeaturemodelingforproductline softwareengineering,"SoftwareReuse:Methods,Techniques,andTools,2002,p.6277. [16]D.Fey,R.Fajta,andA.Boros,"Featuremodeling:ametamodeltoenhanceusabilityand usefulness,"SoftwareProductLines,2002,p.198216. [17]A.vanDeursenandP.Klint,"DomainSpecificLanguageDesignRequiresFeatureDescriptions," JournalofComputingandInformationTechnology,vol.10,2002,pp.117.

[18]K.Czarnecki,T.Bednasch,P.Unger,andU.Eisenecker,"Generativeprogrammingforembedded software:Anindustrialexperiencereport,"GenerativeProgrammingandComponent Engineering,Springer,2002,p.156172. [19]K.Czarnecki,S.Helsen,andU.Eisenecker,"Stagedconfigurationusingfeaturemodels,"Software ProductLines,2004,p.266283. [20]K.CzarneckiandC.Kim,"Cardinalitybasedfeaturemodelingandconstraints:Aprogressreport," InternationalWorkshoponSoftwareFactories,Citeseer,2005. [21]M.Eriksson,J.Brstler,andK.Borg,"Theplussapproachdomainmodelingwithfeatures,use casesandusecaserealizations,"SoftwareProductLines,2005,p.3344. [22]M.ReiserandM.Weber,"Multilevelfeaturetrees,"RequirementsEngineering,vol.12,2007,pp. 5775. [23]Q.Boucher,A.Classen,P.Faber,andP.Heymans,"IntroducingTVL,aTextbasedFeature ModellingLanguage,"ProceedingsoftheFourthInternationalWorkshoponVariability ModellingofSoftwareintensiveSystems(VaMoS10),Linz,Austria,January,2010,p.2729. [24]C.Krueger,"ThePragmatic3TieredSoftwareProductLineMethodology,"2007,pp.112. [25]C.Schwanninger,I.Groher,C.Elsner,andM.Lehofer,"Variabilitymodellingthroughoutthe productlinelifecycle,"ModelDrivenEngineeringLanguagesandSystems,2009,p.685689. [26]F.BachmannandL.Northrop,"StructuredVariationManagementinSoftwareProductLines," hicss,IEEEComputerSociety,2009,p.17. [27]K.LauenrothandK.Pohl,"SoftwareProductLineEngineering,"SoftwareProductLine Engineering,Berlin/Heidelberg:SpringerVerlag,2005,pp.5788. [28]A.V.Lamsweerde,RequirementsEngineering:FromSystemGoalstoUMLModelstoSoftware Specifications,Wiley,2009. [29]A.V.Lamsweerde,"Requirementsengineering:fromcrafttodiscipline,"onFoundationsof softwareengineering,2008. [30]K.SchmidandI.John,"Acustomizableapproachtofulllifecyclevariabilitymanagement," ScienceofComputerProgramming,vol.53,2004,pp.259284. [31]M.a.ArdisandD.M.Weiss,"Definingfamilies:TheCommonalityAnalysis,"Proceedingsofthe 19thinternationalconferenceonSoftwareengineeringICSE'97,1997,pp.649650. [32]K.PohlandT.Weyer,SoftwareProductLineEngineering,Berlin/Heidelberg:SpringerVerlag, 2005. [33]F.Bachmann,M.Goedicke,J.Leite,R.Nord,K.Pohl,B.Ramesh,andA.Vilbig,"Ametamodel forrepresentingvariabilityinproductfamilydevelopment,"SoftwareProductFamily Engineering,2004,p.6680. [34]K.CzarneckiandM.Antkiewicz,"Mappingfeaturestomodels:Atemplateapproachbasedon superimposedvariants,"GenerativeProgrammingandComponentEngineering,Springer,2005, p.422437. [35]K.CzarneckiandK.Pietroszek,"Verifyingfeaturebasedmodeltemplatesagainstwell formednessOCLconstraints,"ofthe5thinternationalConferenceon,2006,p.211.

[36]M.BeckerandG.Kaiserslautern,"XMLEnhancedproductfamilyengineering,"Proceedingsof theSixthBiennialWorldConferenceonIntegratedDesignandProcessTechnology(IDPT2002), Pasadena,USA,2002. [37]M.Clau,"GenericModelingusingUMLextensionsforvariability,"DSVL2001,2001. [38]T.Ziadi,L.Hlout,andJ.Jzquel,"TowardsaUMLprofileforsoftwareproductlines," SoftwareProductFamilyEngineering,vol.29,2004,p.129139. [39]I.JohnandD.Muthig,"Tailoringusecasesforproductlinemodeling,"Proceedingsofthe InternationalWorkshoponRequirementsEngineeringforproductlines,Citeseer,2002,p.26 32. [40]A.Bertolino,A.Fantechi,S.Gnesi,G.Lami,andA.Maccari,"Usecasedescriptionof requirementsforproductlines,"ProceedingsoftheInternationalWorkshoponRequirements EngineeringforProductLines,Citeseer,2002,p.2002033. [41]D.Fischbein,S.Uchitel,andV.Braberman,"Afoundationforbehaviouralconformancein softwareproductlinearchitectures,"InternationalSymposiumonSoftwareTestingandAnalysis, 2006. [42]K.Larsen,U.Nyman,andA.W\kasowski,"ModalI/Oautomataforinterfaceandproductline theories,"ProgrammingLanguagesandSystems,2007,p.6479. [43]A.FantechiandS.Gnesi,"Abehaviouralmodelforproductfamilies,"FoundationsofSoftware Engineering,2007. [44]A.FantechiandS.Gnesi,"Formalmodelingforproductfamiliesengineering,"SoftwareProduct LineConference,2008.SPLC'08.12thInternational,Ieee,2008,p.193202. [45]P.Asirelli,M.terBeek,A.Fantechi,andS.Gnesi,"DeonticLogicsforModelingBehavioural Variability,"ProceedingsoftheThirdInternationalWorkshoponVariabilityModellingof SoftwareintensiveSystems(VaMoS09),ICBResearchReport,2009,p.7176. [46]A.Classen,P.Heymans,P.Schobbens,A.Legay,andJF,"Modelcheckinglotsofsystems: Efficientverificationoftemporalpropertiesinsoftwareproductlines,"ConferenceonSoftware, 2010. [47]K.Czarnecki,S.Helsen,andU.Eisenecker,"Stagedconfigurationthroughspecializationand multilevelconfigurationoffeaturemodels,"SoftwareProcess:ImprovementandPractice,vol. 10,2005,pp.143169. [48]A.Hubaux,A.Classen,andP.Heymans,"FormalModellingofFeatureConfiguration Workflows,"fundp.ac.be,SPLC,2009. [49]Y.Yu,J.C.doPradoLeite,A.Lapouchnian,andJ.Mylopoulos,"Configuringfeatureswith stakeholdergoals,"Proceedingsofthe2008ACMsymposiumonAppliedcomputingSAC'08, NewYork,NewYork,USA:ACMPress,2008,p.645. [50]S.Bhne,G.Halmans,K.Lauenroth,andK.Pohl,SoftwareProductLines,Berlin,Heidelberg: SpringerBerlinHeidelberg,2006. [51]M.Mannion,"Usingfirstorderlogicforproductlinemodelvalidation,"SoftwareProductLines, 2002,p.149202. [52]M.MannionandJ.Camara,"Theoremprovingforproductlinemodelverification,"Software

ProductFamilyEngineering,2004,p.211224. [53]M.deJonge,J.Visser,andA.CWI,"Grammarsasfeaturediagrams,"ICSR7Workshopon GenerativeProgramming,Citeseer,2002,p.2324. [54]D.Batory,"Featuremodels,grammars,andpropositionalformulas,"SoftwareProductLines, 2005,p.720. [55]M.Mendonca,"Efficientreasoningtechniquesforlargescalefeaturemodels,"Ph.D.dissertation, UniversityofWaterloo,2009. [56]J.Liu,J.Dehlinger,andR.Lutz,"Safetyanalysisofsoftwareproductlinesusingstatebased modeling,"JournalofSystemsandSoftware,vol.80,2007,pp.18791892. [57]K.CzarneckiandA.Wasowski,"FeatureDiagramsandLogics:ThereandBackAgain," InternationalConferenceonSoftwareProductLine,2007. [58]S.Antnio,J.Arajo,andC.Silva,"Adaptingthei*FrameworkforSoftwareProductLines," LectureNotesInComputerScience;Vol.5833,2009. [59]A.Fantechi,S.Gnesi,I.John,G.Lami,andJ.Drr,"Elicitationofusecasesforproductlines," SoftwareProductFamilyEngineering,2004,p.152167. [60]J.Kim,M.Kim,andS.Park,"Goalandscenariobaseddomainrequirementsanalysis environment,"JournalofSystemsandSoftware,vol.79,2006,pp.926938. [61]S.Liaskos,A.Lapouchnian,Y.Yu,E.Yu,andJ.Mylopoulos,"Ongoalbasedvariability acquisitionandanalysis,"14thIEEEInternationalConferenceRequirementsEngineering,Ieee, 2006,p.7988. [62]H.Gomaa,"DesigningSoftwareProductLineswithUML,"29thAnnualIEEENASASoftware EngineeringWorkshopTutorialNotesSEW05,2005,pp.160216.