Change Impact Analysis for Evolving Configuration Decisions in Product Line Use Case Models

ContentslistsavailableatScienceDirect

The Journal of Systems and Software

journalhomepage:www.elsevier.com/locate/jss

Controversy Corner

Change impact analysis for evolving configuration decisions in product

line use case models

Ines Hajri

^a

, Arda Goknil

^a,∗

, Lionel C. Briand

^a

, Thierry Stephany

^b

a SnT Centre for Security, Reliability and Trust, University of Luxembourg, Luxembourg

b International Electronics & Engineering (IEE), Contern, Luxembourg

a rt i c l e i n f o

Article history:

Received 19 June 2017 Revised 22 December 2017 Accepted 5 February 2018 Available online 15 February 2018 Keywords:

Change impact analysis Product line engineering Use case driven development Use case configurator Evolving decisions Incremental reconfiguration

a b s t r a c t

ProductLineEngineeringisbecomingakeypracticeinmanysoftwaredevelopmentenvironmentswhere complexsystemsaredevelopedformultiplecustomerswithvaryingneeds.Inmanybusiness contexts, usecasesarethemainartifactsforcommunicatingrequirementsamongstakeholders.Insuchcontexts, ProductLine(PL)usecasescapturevariableandcommonrequirementswhileusecase-drivenconfigura- tiongeneratesProductSpecific(PS)usecasesforeachnewcustomerinaproductfamily.Inthispaper, wepropose,apply,andassessachangeimpactanalysisapproachforevolvingconfigurationdecisionsin PL usecasemodels.Ourapproach includes:(1) automated supporttoidentifytheimpact ofdecision changesonpriorandsubsequentdecisionsinPLusecasediagramsand(2)automatedincrementalre- generation ofPSusecase modelsfrom PL usecase modelsand evolving configuration decisions.Our toolsupportisintegratedwithIBMDoors.Ourapproachhasbeenevaluatedinanindustrialcasestudy, whichprovidesevidencethatitispracticalandbeneficialtoanalyzetheimpactofdecisionchangesand toincrementallyregeneratePSusecasemodelsinindustrialsettings.

© 2019 The Authors. Published by Elsevier Inc.

ThisisanopenaccessarticleundertheCCBY-NC-NDlicense.

(http://creativecommons.org/licenses/by-nc-nd/4.0/)

1. Introduction

ProductLineEngineering(PLE)isbecomingcrucialinmanydo- mainssuchasautomotiveandavionicswheresoftwaresystemsare gettingmorecomplexanddevelopedformultiplecustomerswith varying needs. In such domains, manydevelopment contexts are usecase-drivenandthisstronglyinfluencestheirrequirementsen- gineeringandsystemtestingpractices(Nebutetal.,2006a,2006b;

Wangetal.,2015a,2015b).

For example, IEE S.A. (in the following “IEE”) (IEE, Interna- tionalElectronics &Engineering),aleadingsupplier ofembedded software and hardware systems in the automotive domain, fol- lows a use case-drivendevelopmentprocess to develop automo- tive sensingsystemsformultiplemajorcarmanufacturers world- wide.Todevelopanewproductinanewproject,IEEanalystselicit requirements as use case models from the initial customer. For each newcustomeroftheproduct, IEEanalysts clonethe current models and identify differences to produce new use cases.With such practice,analystsloosetrackofcommonalitiesandvariabili-

∗ Corresponding author.

E-mail addresses: [email protected] (I. Hajri), [email protected] , [email protected] (A.

Goknil), [email protected] (L.C. Briand), [email protected] (T. Stephany).

tiesacrossproductsandthey,togetherwiththecustomer,needto evaluatethe entireuse cases.Thispracticeisfullymanual, error- proneandtime-consuming,whichleadstoad-hocchangemanage- mentforrequirementsartifacts,e.g.,usecasediagramsandspec- ifications, inthe context ofproduct lines. Therefore,product line modelingandconfigurationtechniquesareneededtoautomatethe reuseofusecasemodelsinaproductfamily.

Theneed forsupporting PLE inthecontext ofusecase-driven development has already been acknowledged and many product line use case modeling and configuration approaches have been proposed in the literature (e.g., Eriksson et al., 2005; Eriksson et al., 2004; Fantechi et al., 2004a; Fantechi et al., 2004b; Czar- neckiandAntkiewicz,2005; Alférezetal., 2009).Mostoftheex- isting approaches rely on feature modeling, including establish- ing and maintaining tracesbetween features anduse case mod- els(Sepulvedaetal.,2016;Santosetal.,2015).Theanalystsshould capturevariabilityinformationasfeatures,andestablishtracesbe- tween feature and use case models to model variability in use cases.Foreachnewproductinaproductfamily,featuresshouldbe selectedtomakeconfigurationdecisionsandautomaticallygener- ateusecasemodels.Inpractice,manysoftwaredevelopmentcom- paniesfindsuch additionaltraceability andmodelingefforttobe impractical.Inaddition,requirementsevolutionresultsinchanges https://doi.org/10.1016/j.jss.2018.02.021

0164-1212/© 2019 The Authors. Published by Elsevier Inc. This is an open access article under the CC BY-NC-ND license. ( http://creativecommons.org/licenses/by-nc-nd/4.0/ )

in configuration decisions and variability information, e.g., a se- lectedvariantusecasebeingunselectedforaproduct.Itiscritical fortheanalysts to identify inadvance theimpact of such evolu- tion forbetter decision-making duringthe configuration process.

Forinstance, impacted decisions,i.e., subsequent decisions to be madeand prior decisions cancelled or contradicting when a de- cisionchanges,needtobe identifiedtoreconfigurethe generated usecasemodels.

To the best of our knowledge, there is no existing approach that explicitly supports automated change management of prod- uct lineuse cases forevolving configurationdecisions. There are approaches(Thüm et al., 2009; Bürdek etal., 2015; Pleuss etal., 2012; Heider et al., 2012b; Paskevicius et al., 2012) that study the evolution of feature models in terms of identifying the im- pactoffeaturechangesonother features,buttheydonotaddress thechangeimpactonconfigurationdecisionsorongenerateduse cases.

In addition, existing configurators (e.g., Eriksson et al., 2005;

Fantechi et al., 2004b; Czarnecki and Antkiewicz, 2005) do not support incremental reconfiguration of use case models, a capa- bilitythat is essential in practice. For a variety of reasons, ana- lystsmanuallyassign tracesfromtheconfiguredusecasemodels toothersoftwareandhardwarespecificationsaswellastothecus- tomers’requirementsdocumentsforexternalsystems(Rameshand Jarke,2001). Evolvingconfigurationdecisions resultinthe recon- figurationofProductSpecific(PS)usecasemodels.When theuse case models are reconfigured for all decisions, including unim- pacted decisions, manually assigned traces are lost. The analysts need to reassign all the traces after each reconfiguration. It is therefore vital to enable the incremental reconfiguration of use casemodels focusing only on changed decisions and their side- effects.Withsuchsupport,theanalystscould thenreassigntraces onlyforthepartsofthereconfiguredmodelsimpactedbydecision changes.

In our previous work (Hajri et al., 2015), we proposed and assessed the Product Line Use case modeling Method (PUM) to support variability modeling in Product Line (PL) use case dia- grams and specifications, intentionally avoiding any reliance on featuremodelsandthusavoidingunnecessarymodelingandtrace- ability overhead. PUM adopts the existing PL extensions of use case diagrams in the work of Halmans and Pohl (Halmans and Pohl, 2003). In order to model variability in use case specifica- tions,weintroducednewproductlineextensionsfortheRestricted UseCase Modeling method(RUCM) (Yue etal., 2013). We devel- opedausecase-drivenconfigurationapproach(Hajrietal.,2016a, 2016b)basedon PUM.Ourconfigurationapproachsupportsguid- ingstakeholders inmaking configurationdecisions (e.g.,checking consistencyof a decisionwith prior decisions) andautomatically generatingPSusecasemodelsfromthePLmodelsandconfigura- tiondecisions.Itissupportedbyatool,PUMConf(ProductlineUse caseModelConfigurator)(Hajrietal.,2016b).

In thispaper, we propose, apply and assess a change impact analysisapproach,basedonourusecase-drivenmodelingandcon- figuration techniques, to support the evolution of configuration decisions.We do not address hereevolving PL use case models, whichneed tobe treatedin a separate approach.Change impact analysisprovidesasoundbasistodecidewhetherachangeisade- quate,andtoidentifywhichdecisionsshouldbechangedasacon- sequence(Passosetal., 2013).Inourcontext,weaimtoautomate theidentification of decisionsimpacted by changes in configura- tiondecisionsonPLusecasemodels.Ourapproachsupportsthree activities.First,the analystproposesachange butdoesnot apply ittothecorresponding configurationdecision.Second,theimpact oftheproposedchangeonotherconfigurationdecisionsforthePL usecasediagram are automatically identified. Inthe PLuse case diagram, variantuse cases andvariation points are connectedto

each other with some dependencies, i.e., require, conflict and in- clude.Inthecaseofachangeddiagramdecisioncontradictingprior and/or subsequent diagram decisions,such asa subsequentdeci- sionresultinginselectingvariantusecasesviolatingsomedepen- dencyconstraintsbecause ofthenew/changeddecision, we auto- matically detect and report them. To thisend, we improved our consistencycheckingalgorithm(Hajrietal.,2016a),whichenables reasoningon subsequentdecisions aspartofour impactanalysis approach.Theanalystisinformedaboutthechangeimpactonde- cisions for the PL use case diagram. One crucial and innovative aspect is that our approach identifies not only the impacted de- cisionsbutalso thecauseof theimpact, e.g.,violation ofdepen- dencyconstraints,changingdecisionrestrictions,andcontradicting decisionrestrictions.Inpractice,thereasonoftheimpactisimpor- tanttohelptheanalystidentifywhatfurtherchangestomakeon impacteddecisions. Using the output of our impact analysis, the analyst should decide whetherthe proposed change is to be ap- pliedtothecorrespondingdecision.Third,thePSusecasemodels are incrementallyregeneratedonly forthe impacteddecisionsaf- ter the analystmakes all the requiredchanges.To doso, weim- plementedamodeldifferencingpipelinewhichidentifiesdecision changestobeusedinthereconfigurationofPSmodels.Thereare twosetsofdecisions:(i)thesetofpreviouslymadedecisionsused toinitiallygeneratethePSusecasemodelsand(ii)thesetofde- cisionsincludingdecisions changed afterthe initialgeneration of thePSmodels.Ourapproachcompares thetwosetstodetermine for which decisions we need to incrementally regenerate the PS models.Tosupporttheseactivities,weextendedPUMConf.

This paper is an extension of our work published in REFSQ 2017(Hajrietal.,2017b).Thepublishedwork reportedonthein- cremental reconfiguration of PS use case models. In the current paper, we introduce the automated impact analysis of decision changesonotherdecisionsandweprovidethedetailsofthepro- posedtoolsupport,whichismadepubliclyavailable.Wealsoim- prove theevaluationofour entireapproach withaquestionnaire studyandsomestructured interviewswithexperiencedengineers atIEE.Tosummarize,thecontributionsofthispaperare:

• A change impact analysis approach that informs the analysts aboutthecausesofchangeimpacts onconfigurationdecisions inorderto improvethedecision-makingprocess andtoincre- mentallyreconfigurethegeneratedPSusecasemodelsforthe impacteddecisionsonly;

• Apubliclyavailabletoolintegratedasaplug-ininIBMDOORS, whichautomatically identifies theimpact ofconfiguration de- cision changes and incrementally regenerates the PS usecase models;

• An industrial case study demonstrating the applicability and benefitsofourchangeimpactanalysisapproach.

Thispaperisstructuredasfollows.Section2providestheback- groundonPUMandPUMConfonwhichthispaperbuildsthepro- posedchange impact analysisapproach. Section 3 introduces the industrialcontextofourcasestudytoillustratethepracticalmoti- vationsforourapproach.InSection4,weprovidean overviewof theapproach.Sections5and6providethedetailsofitscoretech- nical parts.In Section 7,we presentourtool while Section 8re- portson an industrialcasestudy, involvingan embeddedsystem calledSmart Trunk Opener (STO).Section 9 discusses therelated work.InSection10,weconcludethepaper.

2. Background

Inthissectionwepresentthebackgroundregardingtheelicita- tionofPLusecasemodels(seeSection2.1),andourconfiguration approach(seeSection2.2).

Fig. 1. Part of the Product Line use case diagram for STO.

Inthe restofthepaper, weuseSmart TrunkOpener (STO) as a casestudy,to motivate,illustrate andassessour approach.STO is a real-time automotive embedded systemdeveloped by IEE. It providesautomatic,hands-freeaccesstoavehicle’strunk,incom- binationwithakeylessentrysystem.Inpossessionofthevehicle’s electronicremotecontrol,theusermovesherleginaforwardand backward direction at the vehicle’s rear bumper. STO recognizes themovementandtransmitsasignaltothekeylessentrysystem, whichconfirmsthattheuserhastheremote.Thisallowsthetrunk controllertoopenthetrunkautomatically.

2.1. ElicitationofvariabilityinPLusecases

Elicitation ofPLusecase modelsis basedon theProduct line Use casemodelingMethod(PUM) (Hajrietal., 2015). Inthissec- tion,wegiveabriefdescriptionofthePUMartifacts.

2.1.1. UsecasediagramwithPLextensions

Forusecasediagrams,weemploy thePLextensionsproposed by Halmans andPohl (2003)and Buhne etal. (2003) since they support explicit representation of variants, variation points, and their dependencies (see Fig. 1). We do not introduce anyfurther extensions.

A usecaseis eitherEssential or Variant. Variantuse casesare distinguished from essential (mandatory) use cases, i.e., manda- tory forall the products ina product family, by using the ‘Vari- ant’stereotype.A variationpoint givenasa triangleisassociated to one, or more than one use case using the ‘include’ relation.

The mandatory variation pointsindicate wherethe customer has

to make a selection for a product (the black triangles in Fig. 1).

A ‘tree-like’ relation, containing a cardinality constraint, is used toexpressrelations betweenvariantsandvariation points, which are called variability relations.The relation uses a [min.max] no- tationinwhichminandmaxdefinetheminimumandmaximum numbers ofvariants that can be selectedfor the variation point.

Avariability relationis optionalwhere (min=0) or(min>0and max<n);nis thenumberofvariantsina variationpoint.Avari- abilityrelationismandatorywhere(min=max=n).Optionaland mandatory relations are depictedwith light-grey andblackfilled circles,respectively(see Fig. 1).For instance,the‘Provide System UserData’ essential usecasehasto supportmultiplemethods of providing data where the methods of providing data via IEE QC modeandStandardmodearemandatory.Inaddition,thecustomer can select the methodof providing data via diagnostic mode. In STO,thecustomermaydecidethesystemdoesnotstoretheerrors determinedwhiletheoperatingstatusisbeingidentified(see the

‘StoringErrorStatus’optionalvariationpointinFig.1).Theexten- sions supportthe dependencies require andconflict among varia- tionpointsandvariantusecases(Buhneetal.,2003).Withrequire, theselectionofthevariantusecasein‘StoringErrorStatus’implies theselectionofthevariantusecasein‘ClearingErrorStatus’.

Some further variability information is given in PL use case specifications.Forinstance,onlyPLusecasespecificationsindicate inwhichflowsofeventsavariationpointisincluded.

2.1.2. RestrictedUseCaseModeling(RUCM)withPLextensions This section introduces the RUCM template and its PL exten- sions which we proposed. RUCM provides restriction rules and

Table 1

Some STO use cases in the extended RUCM.

1 USE CASE Recognize Gesture 2 1.1 Basic Flow

3 1. INCLUDE USE CASE Identify System Operating Status.

4 2. The system VALIDATES THAT the operating status is valid.

5 3. The system REQUESTS the move capacitance FROM the sensors.

6 4. The system VALIDATES THAT the movement is a valid kick.

7 5. The system SENDS the valid kick status TO the STO Controller.

8 1.2 < OPTIONAL > Bounded Alternative Flow 9 RFS 1–4

10 1. IF voltage fluctuation is detected THEN 11 2. RESUME STEP 1.

12 3. ENDIF

13 1.3 Specific Alternative Flow 14 RFS 2

15 1. ABORT.

16 1.4 Specific Alternative Flow 17 RFS 4

18 1. The system increments the OveruseCounter by the increment step.

19 2. ABORT.

20

21 USE CASE Identify System Operating Status 22 1.1 Basic Flow

23 1. The system VALIDATES THAT the watchdog reset is valid.

24 2. The system VALIDATES THAT the RAM is valid.

25 3. The system VALIDATES THAT the sensors are valid.

26 4. The system VALIDATES THAT there is no error detected.

27 1.4 Specific Alternative Flow 28 RFS 4

29 1. INCLUDE < VARIATION POINT: Storing Error Status > . 30 2. ABORT.

31

32 USE CASE Provide System User Data 33 1.1 Basic Flow

34 1. The tester SENDS the system user data request TO the system.

35 2. INCLUDE < VARIATION POINT : Method of Providing Data > . 36

37 < VARIANT > USE CASE Provide System User Data via Standard Mode 38 1.1 Basic Flow

39 V1. < OPTIONAL > The system SENDS calibration TO the tester.

40 V2. < OPTIONAL > The system SENDS sensor data TO the tester.

41 V3. < OPTIONAL > The system SENDS trace data TO the tester.

42 V4. < OPTIONAL > The system SENDS error data TO the tester.

43 V5. < OPTIONAL > The system SENDS error trace data TO the tester.

keywords constraining the use of natural language (Yue et al., 2013). Since RUCM was not designedfor PL modeling, we intro- ducedsome PLextensions(see Table1).InRUCM,usecaseshave basicandalternative flows (Lines2,8,13,16,22,27, 33and38).

InTable1,we omitsome alternativeflows andbasicinformation suchasactorsandpre/postconditions.

A basic flow describes a main successful path that satisfies stakeholderinterests(Lines3–7,23–26and39–43).Itcontainsuse casesteps anda postcondition. Astep can be a system-actor in- teraction:an actor sends a request ordata to the system (Lines 34);thesystemrepliestoanactorwitharesult(Line7).Inaddi- tion,thesystemvalidatesarequestordata(Line4),oritaltersits internal state (Line18). The usecaseinclusion is givenin a step withthe keyword‘INCLUDEUSECASE’(Line3).The keywordsare incapital letters. ‘VALIDATES THAT’ (Line 4) indicates a condition thatmust be truetotake the next step,otherwisean alternative flowistaken.

Analternativeflowdescribesotherscenarios,bothsuccessand failure.It alwaysdependson aconditionina specificstepof the basicflow.RUCMhasspecific,boundedandglobalalternativeflows.

Aspecific alternativeflowreferstoastepinthebasicflow(Lines 13,16,and27).Aboundedalternativeflowreferstomorethanone stepinthebasicflow(Line8),whileaglobalonereferstoanystep inthebasicflow.‘RFS’isusedtorefertoreferenceflowsteps(Lines 9,14,17,and28).Boundedandglobalalternativeflowsbeginwith

‘IF..THEN’fortheconditionsunderwhichtheyaretaken(Line10).

Specificalternativeflowsdonotnecessarilybeginwith‘IF.. THEN’ sinceaguardconditionisalreadyindicatedintheirreferenceflow steps(Line4).

Ourextensionsare(i) newkeywords formodelinginteractions inembeddedsystemsand(ii)newkeywordsformodelingvariabil- ity.Thekeywords‘SENDS..TO’and‘REQUESTS.. FROM’aretodis- tinguishsystem-actor interactions (Lines5,7,34,and39–43).We introducethenotionofvariationpointandvariantusecase,com- plementarytotheextensionsinSection2.1.1,intoRUCM.Variation pointscanbeincludedinbasicoralternativeflowswiththekey- word‘INCLUDE<VARIATIONPOINT:...>’(Lines29and35).Variant usecasesaregivenwiththekeyword‘<VARIANT>’(Line37).

Somevariabilitycannotbe capturedinPLdiagramsduetothe required level of granularity for product configuration. To model such variability, as partof our extensions,we introduce optional steps,optionalalternative flows andavariantorder ofsteps.Op- tionalstepsandalternativeflows beginwith‘<OPTIONAL>’(Lines 8and39–43).‘V’isusedbeforeanystepnumbertoexpressvariant steporder(Lines39–43).

2.1.3. Discussion

Considerable research has already been devoted to docu- menting variability inuse cases.Many approachespropose using variabilitymodels,e.g.,featuremodels,thataretracedtousecase specifications and diagrams (Alferez et al., 2008; Eriksson et al., 2005, 2009; Buhne et al., 2006; Braganca and Machado, 2007;

Griss et al., 1998). With the PL extensions, our method enables analyststodocumentvariabilitydirectlyinusecasediagramsand specifications. This is a departure from the most common ap- proachofhavingseparatevariabilityandusecasemodelstogether withtheirtracelinks.

Our decisionwas motivatedby our discussions withIEE ana- lysts and engineers. In the current practice at IEE, like in many otherenvironments,thereisnosystematicwaytomodelvariabil- ity information in use case diagrams and specifications. The IEE analystswrite briefandinformalnotesattachedtousecasemod- elstoindicatewhatmayvaryintheusecases.IEEisreluctantto usefeaturemodelstracedtousecasemodelsbecauseoftwomain issues: (i) having feature models requiresconsiderable additional modeling artifactsofa verydifferentnature andadditionaltools, withmanualassignmentoftracesataverylow levelofgranular- ity,e.g.,sequencesofusecasesteps;and(ii)theyfinditdifficultto switchfromfeaturemodelstousecasesandviceversaduringthe decision-makingprocess.Bydocumentingvariabilitydirectlyinuse casemodels,theanalystscould focusonone artifactatatime to makeconfigurationdecisions.InourmeetingsatIEE,the analysts statedthattheeffortrequiredtoapplyourPLextensionsformod- eling variability information was reasonable (Hajri etal., 2016a).

They considered the extensions to be simple enough to enable communication between analysts and customers, but they also mentioned that training customers is necessary. Thus, the costs andbenefitsoftheapproachshouldbemadecleartocustomers.

The separation of variability and development models was originally motivated by the need to provide representations tar- geting different stakeholders with distinct expertise and inter- ests (Pohl et al., 2005). However, based on our observations in practice, it is often not the case that people who need to read variabilitymodelsdon’tneedtoreaddevelopmentmodels,orvice- versa.Thesetwogroupsarenotmutuallyexclusive.Resultsinthe casestudyandquestionnairestudyfromourprevious work(Hajri etal.,2015,2016a)suggestthat thePLusecasemodelextensions we proposed were easy to read andused by automotive system engineers.

Wedonot claimthat ourmodelingmethodisgenerallysupe- rior tofeature modeling,orthat feature modelingshould be dis- carded. We only provide an alternative way to model variability

Fig. 2. Generated product specific use case diagram.

in the context of use case-driven development, which may be a preferred solution in certain contexts. Companies who already adopted feature modeling intheir practice mostprobably havea differentperception.

2.2. ConfigurationofPSusecasemodels

PUMConf relieson variability informationgiven inthe PLuse casemodels.The userselects(1)variant usecasesinthePLdia- gram and(2)optionaluse caseelementsinthePL specifications, togeneratethePSusecasemodels.

The user makes decisions forthe variation pointsin Fig. 1.A decision is about selecting, for the product, variant use cases in thevariationpoint.TheuserselectsStoreErrorStatusandClearEr- ror Statusin thevariation pointsStoring Error Status andClearing ErrorStatus,respectively.SheunselectsClearErrorStatusviaDiag- nostic Mode inthevariation pointMethod ofClearingErrorStatus, while ClearErrorStatus viaIEE QC Modeis automaticallyselected because of the mandatory variability relation.The user unselects ProvideSystemUserDataviaDiagnosticModeinthevariationpoint Method of ProvidingData.The PS diagram isautomatically gener- ated from the PL diagram andthe diagram decisions (see Fig. 2 generatedfromFig.1).

The decision-makingis aniterativeprocess.Wedevised anal- gorithm to check the consistency of a decision with prior deci- sions(Hajrietal.,2016a).Inthecaseofcontradictingconfiguration decisions,such astwodecisions resultinginselectingvariantuse cases violatingsome dependency constraints,thealgorithm auto- maticallydetectsandreportsthem.Theusermustthenbacktrack andrevisethedecisionstoresolvethecontradictions.Assumethat the user first makes a decision in ClearingError Status, which is unselecting Clear ErrorStatus.No contradiction isidentified since thereisnopriordecision.TheuserproceedswithStoringErrorSta- tusandselectsStoreErrorStatus.Ouralgorithmidentifiesacontra- dictionwiththedecisioninClearingErrorStatussincetheselection ofStore Error Statusimpliesthe selectionof ClearErrorStatus via the requiresdependency (see Fig.1).The useris askedtoresolve thecontradictionbyupdatingoneofthedecisionsforStoringError Status andClearingErrorStatus.The userselectsClearErrorStatus toresolvethecontradiction.

Next, the user makes decisions for the PL specifications. In Table1,therearetwovariationpoints(Lines29and35),onevari- ant usecase(Lines37–43), fiveoptionalsteps(Lines 39–43),one

optionalalternativeflow(Lines8–12),andonevariantordergroup (Lines 39–43). The decisions for the variation points are already madeinthePLdiagram.Theuserselectsonlythreeoptionalsteps withtheorderV3,V1,andV5.Theoptionalalternativeflowisun- selected.

ThePSusecasespecificationsareautomaticallygeneratedfrom thePL specifications,the diagram decisions andthe specification decisions(seeTable2generatedfromTable1).Forinstance,based on the diagram decision for Method of Providing Data in Fig. 1, PUMConfcreates two includestatements for Provide System User Datavia Standard Modeandvia IEE QCMode (Lines31 and34in Table2),avalidationstep(Line30),andaspecificalternativeflow whereProvideSystemUserDataviaIEEQCModeisincluded(Lines 32–35).The validation step checksif the precondition of Provide SystemUserDataviaStandardMode holds.Ifitholds,ProvideSys- temUserDataviaStandardModeisexecutedinthebasicflow(Line 31).Ifnot,ProvideSystemUserDataviaIEEQCModeisexecutedin thealternativeflow(Lines32–35).The selectedoptionalstepsare generated with the decided order in the PS specifications (Lines 39–41).

3. Motivationandcontext

Ourchangeimpactanalysisapproachisdevelopedasanexten- sionofourconfigurator,PUMConf,inthecontextofsoftwaresys- tems configured for multiple customers withvarying needs, and developedaccordingto a usecase-drivenprocess. Insuch a con- text,configurationdecisionsfrequentlychangeduetotechnological developmentsandevolvingbusinessneeds.Achangeimpactanal- ysisapproach is therefore needed foridentifying other impacted decisionsforthereconfigurationofPSmodels.

Changesonconfiguration decisionsmayhaveimpact onother decisionsinvariousways.Forinstance,inthePLdiagraminFig.1, theanalyst changes the decisionfor thevariation point Clear Er- rorStatusinordertoresolve thecontradictionwiththepriorde- cision for the variation point Store Error Status (see Section 2.2).

This is done by selecting the variant use case Clear Error Status, which was previously unselected. This change has the following consequences:(i)thevariationpointMethodofClearingErrorStatus shouldnowbeconsideredinsubsequentdecisions;(ii)thevariant usecaseClearErrorStatusviaIEEQCModeisautomaticallyselected because ofthe mandatory variabilityrelation; (iii) the newly se- lectedusecasesshouldbeaddedtothePSusecasediagramwhile

Table 2

Some of the generated product specific specifications.

1 USE CASE Recognize Gesture 2 1.1 Basic Flow

3 1. INCLUDE USE CASE Identify System Operating Status.

4 2. The system VALIDATES THAT the operating status is valid.

5 3. The system REQUESTS the move capacitance FROM the sensors.

6 4. The system VALIDATES THAT the movement is a valid kick.

7 5. The system SENDS the valid kick status TO the STO Controller.

8 1.2 Specific Alternative Flow 9 RFS 2

10 1. ABORT.

11 1.3 Specific Alternative Flow 12 RFS 4

13 1. The system increments the OveruseCounter by the increment step.

14 2. ABORT.

15

16 USE CASE Identify System Operating Status 17 1.1 Basic Flow

18 1. The system VALIDATES THAT the watchdog reset is valid.

19 2. The system VALIDATES THAT the RAM is valid.

20 3. The system VALIDATES THAT the sensors are valid.

21 4. The system VALIDATES THAT there is no error detected.

22 1.4 Specific Alternative Flow 23 RFS 4

24 1. INCLUDE USE CASE Store Error Status.

25 2. ABORT.

26

27 USE CASE Provide System User Data 28 1.1 Basic Flow

29 1. The tester SENDS the system user data request TO the system.

30 2. The system VALIDATES THAT ‘Precondition of Provide System User Data via Standard Mode’.

31 3. INCLUDE USE CASE Provide System User Data via Standard Mode.

32 1.2 Specific Alternative Flow 33 RFS 2

34 1. INCLUDE USE CASE Provide System User Data via IEE QC Mode.

35 2. ABORT.

36

37 USE CASE Provide System User Data via Standard Mode 38 1.1 Basic Flow

39 1. The system SENDS the trace data TO the tester.

40 2. The system SENDS the calibration data TO the tester.

41 3. The system SENDS the error trace data TO the tester.

thecorresponding usecasespecificationsshould be addedtothe PSspecifications;and(iv)newoptionalstepsandalternativeflows areintroducedforconsiderationifthereisanyintheaddedspec- ifications. Insome cases,subsequent decisions are also impacted becauseofdecisionrestrictions. Assumethat thevariantusecase StoreErrorStatusinthevariationpointStoringErrorStatusisuns- elected,andnodecisionhasbeenmadeyetforthevariationpoint ClearingErrorStatus.Whentheanalystchangesthedecisionbyse- lectingStoreErrorStatus,thesubsequentdecisionforthevariation point ClearingError Status is restricted becauseClear Error Status shouldbeselectedinthesubsequentdecisiontoavoidfurtherde- cisioncontradictions.

Inpractice,fromamoregeneralstandpoint,theanalystsshould beawareoftheimpactsofdecisionchangestopossiblyreconsider someofthem. Afterchanging adecision, impactanalysissupport isneededto guidesubsequentdecisions orto changeprior deci- sions.Withinourcontext,weidentifytwochallengesthatneedto be considered in identifying the impact of decision changes and supportingthereconfigurationofPSusecasemodels:

Challenge 1: Identifying the cause of the impact of chang- ingdecisionsforPLusecasediagrams.Changestoconfiguration decisions driven by the PL usecase diagram have an impact on prior decisions as well as on subsequent decisions to be made.

Change impacts can have a variety of causes, which the analyst needstotakeintoaccounttodecidewhethertheproposedchange isadequate andto identify what further changes are neededon impacted decisions. For instance, a prior decision might be im-

Fig. 3. Part of an STO use case specification with trace links.

pacted because of the violation of some dependency constraints (i.e., requires andconflicts). A subsequent decisionfor a variation pointmightbeimpactedbecauseithasanewrestrictiontosatisfy thecardinalityconstraintofthevariationpoint.Therefore,impact analysisshould provide not onlyimpacteddecisions butalso de- tailedinformationabouttheircauses.

Challenge2:IncrementalregenerationofPSusecasemodels.

In practice,fora varietyof reasons,the analysts manually assign tracesfromthePSusecasemodelstoothersoftwareandhardware specificationsaswellastothecustomers’requirementsdocuments forexternalsystems(RameshandJarke,2001).Forinstance,inor- dertoverifytheinteractionbetweenthesystemandtheexternal systems,IEE’s customersrequirethattracesbe assignedfromthe PSusecasespecifications totherelated, externalsystemrequire- ments. Fig.3 givespartofthe basicflow ofa PS usecasespeci- fication inIBMDOORS withatrace to acustomer’srequirements specification.

Letusconsiderthetrace inFig.3,whichisfromthefirststep of the basic flow to an external system requirement in the cus- tomer’ssoftwarerequirementsspecification.Thisusecasestepde- scribestheoperatingstatusrequestsentbytheSTOcontroller,i.e., anexternalsystemimplementedbythecustomer,whilethetraced externalsystemrequirementdescribestheconditioninwhichthe STO controller sends this request to the system. When the PS use casemodels are reconfigured for all the decisions, including unimpacteddecisions,manuallyassignedtracessuchastheonein Fig. 3 are lost. The analysts need to reassign all the traces after eachreconfiguration.Itisthereforevitaltoenabletheincremental regenerationofPSmodelsbyfocusingonlyonimpacteddecisions.

Asaresult,theanalystswouldreassigntracesonlyforthepartsof thePSusecasemodelsimpactedbydecisionchanges.

In the remainder of this paper,we focus on how to best ad- dressthesechallengesinapracticalmanner,inthecontextofuse case-driven development, while relying on PUM for modeling PL usecasemodels,andonPUMConffortheconfigurationofPSuse casemodels.

4. Overviewoftheapproach

Theprocess inFig.4presentsan overviewofourapproach.In Step1,Proposeachangeforadecision,theanalystisaskedtopro- poseachangeforaconfigurationdecisionmadepreviouslyforthe PLusecasediagram.

The configuration decision change proposed by the analyst is not actually applied tothe corresponding decisionyet.In Step2, Identify the change impact on other decisions, our approach auto- matically identifies the impact of the proposed change on other configurationdecisionsforthePLusecasediagram.Theanalystis informed about the impact of the decision change on prior and subsequent decisions, e.g., contradicting decisions and restricted subsequentdecisions(Challenge1).

Theanalystevaluatestheimpacteddecisionstodecidewhether theproposedchangeistobeapplied.InStep3,Applytheproposed change,theanalystappliestheproposedchangetothecorrespond- ing decision. Steps 1,2, and3 are iterative:the analystproposes andapplies changesuntilalltherequiredchangesareconsidered.

WediscussthesethreestepsinSection5.

Table 3

Change types for diagram decisions.

Change types . Add a decision . Delete a decision . Update a decision

- Select some unselected variant use case(s) - Unselect some selected variant use case(s)

- Unselect some selected variant use case(s) and select some unselected variant use case(s)

Fig. 4. Overview of the approach.

After theanalyst applies all the required changes to the con- figuration decisions,inStep4,Regenerateproductspecific usecase models, thePSuse casediagramandspecificationsare incremen- tallyandautomaticallyregeneratedforonlythechangeddecisions (Challenge2).ThedetailsofthesteparedescribedinSection6.

5. IdentificationofchangeimpactondecisionsforPLusecase diagrams

Decision-making duringproduct configuration is iterative. The analyst may update or delete some of the prior decisions while newdecisions are beingmadeforundecided variants.A diagram decision is about selecting, for the product, variant use cases in

Table 4

Example decisions for the PL use case diagram in Fig. 5 . Decision ID Explanation of the decision d1 Selecting UC1 and UC2 in VP1

d2 Selecting UC9 and unselecting UC10 in VP4 d3 Unselecting UC15 in VP6

d2’ Selecting UC9 and UC10 in VP4

thevariationpoint.Table3liststhechangetypesfordiagramde- cisions.

The first two change types in Table 3 are obvious manipula- tions over the diagram decisions.The subtypes of ‘Update a De- cision’matchthe(un)selectionofvariantuse casesina variation point.

When a changeis introduced to a diagram decision, the ana- lystneedstoidentifynotonlytheimpacteddecisionsbutalsothe reasonoftheimpact,e.g.,violationofdependencyconstraints,new restrictionsforsubsequentdecisions,andcontradictingdecisionre- strictions(Challenge1).

Automated analysis for configuration support often relies on translating models to propositional logic and using satisfiability (SAT) solvers (Benavides et al., 2010; Mendonca et al., 2009). As we discussin Section 9,employingSAT solvers can help identify impacteddecisionsbut doesnot providefurther explanations re- gardingthereasonoftheimpact. However,thisis criticalforthe analyststomakefurtherdecisionsbasedonthechangeimpact.To thisend, we devised a custom change impact analysis algorithm thatidentifiestheimpactofdiagramdecisionchangesonotherdi- agramdecisionsandprovideanexplanationregardingthecauseof theimpact.Inthefollowing,weexplainthestepsofthealgorithm withan illustrative exampledepicted inFig. 5.The example is a slightadaptationof apiece ofourindustrial casestudysincewe neededsomeadditionalmodeling elementsto illustratethecom- pletesetoffeaturesofthealgorithm.Fig.5depictsanexamplePL usecasediagramincludingsevenvariationpoints,fourteenvariant usecases,andoneessentialusecase.

As an example,let usassume the analyst makes the decision d1 forVP1, whichis selectingUC1 andUC2forthe product. Fur- ther,thedecisionsd2andd3aremadeforVP4andVP6,whichare selectingUC9andunselectingUC10inVP4andunselectingUC15in VP6,respectively.Further,letusassume thattheanalystproposes to change d2 withd2^ by selecting unselected UC10 in VP4 (see Table4).

Fig.6 describesthe changeimpact analysis algorithm fordia- gram decisions.Thealgorithm takesaset ofpriordecisions,a PL usecasediagram,andadecisionchangeasinput.Itreportsadded anddeleted contradicting prior decisions, added anddeleted re- strictionsforsubsequentdecisions,andsetsofaddedanddeleted contradictingrestrictionsasoutput.

The decision d, which precedes the decision change c, is a quadruple of the variation point vp, the use case uc including vp, the set of selected variant use cases SUC in vp, and the set of unselected variant use cases NSUC in vp (Line 6). The deci- sion d^, which results from the change c, is given as a similar

Fig. 5. An example product line use case diagram.

Fig. 6. Change impact analysis algorithm for diagram decisions.

quadruple (Line7). For instance, inour example, d2 andd2^ are (VP4,null,{UC9},{UC10})and(VP4,null,{UC9,UC10},∅),respectively.

We callcheckandinferfunctionswithdandd^to identifythe impactofc(Lines11–16).

• checkPriorDecisionConsistency determines contradicting prior decisions forvariation points. Twoormorediagram decisions maycontradicteachotheriftheyresultinviolatingsomevari- ationpointandvariantdependencyconstraints(i.e.,requireand conflict);

• inferDecisionRestrictions determines restrictions on theselec- tionofvariantusecasesinundecidedvariationpoints.Theex-

isting decisions may entail (un)selection of some variant use casesinsubsequent decisionsthrough thevariation pointand variantdependencies;

• checkDecisionRestrictionsdeterminescontradictingrestrictions for subsequent decisions. Two or more decision restrictions maycontradicteach otheriftheyresultinviolatingsome car- dinality constraints or result in selecting and unselecting the samevariantusecase.

The algorithm of checkPriorDecisionConsistency was developed as part of our configurator, PUMConf, described in our previous work(Hajrietal.,2016a, 2016b). Thealgorithmisbased onmap- pingvariationpoints,usecasesandvariantdependenciestopropo- sitionallogic formulas. Fora givendecisionregarding a variation point,itonlychecksthesatisfactionofthepropositionalformulas derived fromthedependenciesofthevariationpoint (Hajrietal., 2016a).Forexample,assume therearetwoconflictingvariantuse cases Ua and Ub (i.e., Ua conflicts with Ub). Ua and Ub are se- lectedindecisionsDaandDb,respectively.DaandDbarecontra- dictingbecauseUaandUbcannotexistforthesameproduct(i.e.,

¬(Ua∧Ub)).

Forchanging d2 withd2^ inFig. 5,we call checkPriorDecision- Consistency first withd2 (DC=

{

^d1,d3

}

^andd= d2 in Line 11), andthenwithd2^(DC=

{

^d1,d3

}

^andd= d2^inLine12).Ford2, the function returns no contradicting prior decision. When UC10 isunselectedind2,UC11,UC12andUC13 inVP5areautomatically unselectedbecausethereisnootherusecaseincludingVP5.UC13 whichisunselectedind2requiresUC15whichisunselectedind3 (i.e.,U13→U15). Therefore,d2andd3arenot contradicting.UC12 and UC13 are automatically selected in d2^ because of selected UC10 and the mandatory variability relation in VP5. UC13 which isselectedind2^ requiresUC15which isunselected ind3.There- fore,ford2^,checkPriorDecisionConsistencyreturnsd3 contradicting d2^. Thedecision change introduces a newcontradictionwith d3 (CD^

\

^CD=

{

^d3

}

^{in Line 17). No existing} contradiction is removed bythechange(CD

\

^CD=∅inLine17).d3isimpactedsinceitcon- tradictsd2^afterthechange.

As part of ourimpact analysisapproach, the algorithm of in- ferDecisionRestrictions also relies on propositional logic mappings for variation points, use cases and variant dependencies (see

Table 5

Restrictions inferred from the example decisions in Table 4 .

Restriction ID Explanation of the restriction r1 UC6 in VP3 should not be selected r2 UC8 in VP3 should not be selected r3 UC14 in VP7 should not be selected

Section 5.1 forthedetails of thealgorithm). For agiven decision regarding a variation point, inferDecisionRestrictions infers restric- tionsforsubsequentdecisionsbyonlycheckingthesatisfactionof thepropositionallogicformulasderivedfromthedependenciesof the variation point. Assume two variant use casesUa and Ubin variationpointsVaandVbwitharequiresrelation(i.e.,Uarequires Ub). Ua isselected in decisionDa forVa while there is no deci- sionyetforVb.ThesubsequentdecisionforVbisrestrictedasUb needs to beselected toavoida contradictionwithDabecauseof therequiresrelation(i.e.,Ua→Ub).

For the input decisions d1, d2 andd3, inferDecisionRestrictions returns restriction r1 forUC6 in VP3 (Line 13). When UC1 is se- lected ind1,UC4isautomaticallyselectedbecauseofthemanda- toryvariabilityrelationinVP2.UC4conflictswithUC6,andthereis nodecisionmadeforUC6.TheselectionofUC4restrictsthesubse- quentdecisionforVP3sothatUC6shouldnotbeselectedtoavoid thecontradictionwithd1(i.e.,restrictionr1inTable5).Ford1,d2^ andd3, thefunction returnsrestrictions r1forUC6in VP3,r2 for UC8inVP3,andr3forUC14inVP7(Line14).UC12inVP5isauto- maticallyselectedind2^,anditconflictswithUC8inVP3forwhich there isnodecisionmadeyet.The selectionofUC12restrictsthe subsequentdecisionforVP3throughtheconflictsrelationthatUC8 should notbe selected (i.e.,r2in Table5).The restrictionforthe subsequent decisionforUC8restrictsthe subsequentdecision for VP7throughtherequiresrelation(i.e.,r3inTable5).IfUC8should notbe selected,UC14 shouldalsonotbe selectedsinceitrequires UC8. The subsequent decisions forVP3 andVP7 are impacted by the change because of the new restrictions (R^

\

^R=

{

^r2,r3

}

^and

R

\

^R=∅inLine17).

We devise the algorithm of checkDecisionRestrictions as part of our change impact analysis approach (see Section 5.2 for the details of the algorithm). For a given set of decision restric- tions, checkDecisionRestrictionsidentifies contradicting restrictions for subsequent decisions in terms of violating cardinality con- straints andrestricting the same variant use cases for being se- lected andunselected.Forexample,assumetherearetworestric- tionsr1andr2whichstatethevariantusecasesUaandUbinthe variationpointVneedtobeselected,respectively.Vhasthe[0..1]

cardinalityconstraint.r1andr2donotcomplywiththiscardinal- ityconstraint.

Fortherestrictions beforethedecisionchangeinourexample (i.e.,r1),checkDecisionRestrictionsdoesnotreturnanycontradicting restriction (Line 15). r1 restricts the subsequent decisionfor VP3 so that UC6should not beselected. Thereis noother restriction, andr1complieswiththecardinalityconstraintofVP3(i.e.,[2..3]).

Fortherestrictions afterthechange(i.e.,r1, r2andr3),thefunc- tion returns{{r1, r2}},i.e., theset ofsetsof contradictingrestric- tions. UC6andUC8inVP3should notbe selectedaccordingtor1 and r2, respectively. The cardinalityconstraint in VP3 requires at leasttwo ofthreevariant usecasesinVP3 tobe selected.There- fore,r1andr2cannotexisttogetherbecauseofthecardinalitycon- straint.Anewcontradictionisintroducedafterthedecisionchange (CR^

\

^CR=

{{

^r1,r2

}

^{} andCR}

\

^CR=∅in Line 17).To resolve it,the decisions causing it need to be updated. r2 is inferred fromd2^ throughUC12,whiled1resultsinr1 throughUC4.Therefore,d1is identifiedasimpacted.

Changingd2 with d2^ impacts d1 forVP1, d3 forVP6 and the subsequentdecisionsforVP3andVP7.

5.1. Identificationofsubsequentdecisionrestrictions

Decisionrestrictions are inferred by mapping variationpoints, usecases andvariantdependenciesto propositional logic formu- las.WeassumethataPLusecasediagramPLDisdefinedasaset, whereeachusecaseisamemberoftheset.ThePLdiagramcon- sistsofnuse casesPLD=

{

^u1,...,un

}

^{; eachuse caseu}iinPLD is represented by a boolean variable withthe same name. Boolean variableu_ievaluatestotrueifusecaseu_iisselectedandfalseoth- erwise.Ifthereisnodecisionmadeyetforusecaseu_i,variableu_i isnotvalued(unknown).Pleasenotethatallessentialusecasesare automaticallyselected.

Fig. 7 provides the corresponding propositional formulas for eachpatterninvolvingdependencies,variation points,andvariant usecases,wherepropositionscapturelogicalrelationshipsamong variant use cases. For instance, according to the corresponding propositionalformulainFig.7(a),ifusecaseUCAmisselectedfor aproductthenthislogicallyimpliesthatusecaseUCB_nisalsose- lected.Fig.7(c)depictsthemappingwhenthereisarequiredepen- dencybetweentwovariationpointsAandB.Insuchacase,ifone ofthe variantuse casesin variation point A (UCA1∨...∨UCAm) isselected,then atleastone ofthevariantusecases invariation pointB(→UCB₁∨...∨UCBn)shouldalsobeselected.

Fig.8describesthealgorithmforinferDecisionRestrictions.Toil- lustratethealgorithm,werelyontheexamplewiththeinputde- cisionsd1,d2^ andd3 inFig. 5.Foreach decisiond inthe setof decisionsD,thealgorithmcallssomeinferfunctionstoidentifythe decisionrestrictionsforsubsequentdecisionsinwhichthepropo- sitionallogicformulas,derivedfromthedependenciesto/fromthe diagram elementsdecided ind,are satisfied(Lines 11,12, 15,18, 19and21).EachinferfunctioninFig.8infersrestrictionsforsub- sequentdecisionsusingthepropositionalformulasinoneormore mappingsinFig.7.

• inferConflictingVPusestheformulasinFig.7(d)and(g)toinfer decisionrestrictionsforvariationpointsandusecasesconflict- ingwithselectedvariationpointvpindecisiond;

• inferConflictingUCusestheformulasinFig.7(b)and(g)toinfer decision restrictionsforvariation pointsandvariantuse cases conflictingwithselectedvariantusecaseuind;

• inferRequiringVPusestheformulasinFig.7(c)and(e)toinfer decision restrictionsforvariation pointsandvariantuse cases requiringunselectedvariationpointvpind;

• inferRequiredByVPusestheformulasinFig.7(c)and(f)toinfer decision restrictionsforvariation pointsandvariantuse cases requiredbyselectedvariationpointvpind;

• inferRequiringUC usestheformulasinFig.7(a)and(f)toinfer decision restrictionsforvariation pointsandvariantuse cases requiringunselectedvariantusecaseuind;

• inferRequiredByUC uses the formulas in Fig. 7(a) and (e) to infer decision restrictions forvariation points andvariant use casesrequiredbyselectedvariantusecaseuind.

InFig.5,inferConflictingUCinfersr1andr2fromUC4,automat- icallyselectedind1,andfromUC12,automaticallyselectedind2^, respectively.The algorithm ofinferConflictingUCis givenin Fig.9. Fortherestoftheinferfunctions,thereaderisreferredtoSupple- mentaryMaterial¹.

Thealgorithm of inferConflictingUCinFig. 9uses the formulas inFig.7(b)and(g)torestrict thesubsequentdecisionsforvariant usecasesandvariationpointsthatconflictwithselectedusecase

1http://people.svv.lu/hajri/change _ impact/SupplementaryMaterial.pdf .

Fig. 7. Mapping from PL use case diagram to propositional logic.

Fig. 8. Algorithm for inferDecisionRestrictions .

u. For instance, inFig. 7(b), when UCAm is selected, it checks if there is anydecision made for UCBn. If there is no decision for UCBn, thesubsequent decisionisrestricted that UCBnshould not beselected.

inferConflictingUCtakesasinputselectedvariantusecaseu,set ofdecisionsD,andPLusecasediagram PLD,whileitreturnsthe set ofdecision restrictionsIR. Adecisionrestriction is givenasa triple(uc,vpo,b) whereucisavariantusecase,vpoisthevaria- tionpointofucandbisabooleanvariable(Line1inFig.9).Ifthe restriction is aboutthe whole variation point,not about a single variantusecaseinthevariationpoint,ucbecomesnull.bindicates whetherthevariantusecase(s)should beselectedornot.Forin- stance,(null,Va,false) statesthat noneofthevariantusecasesin variationpointVashouldbeselected,while(UCA1,Va,true) states variantusecaseUCA1inVashouldbeselected.

Thealgorithmstartswithidentifyingthevariantusecasescon- flicting withthe input selected variantusecaseu (see Fig.7(b)).

Theconflictingvariantusecaseswhichhavenotbeendecidedyet shouldbe unselectedinsubsequentdecisions(Line8).Thesubse- quentdecisionsshouldalsoberestrictedforotherundecidedvari- antusecasesandvariationpointswhichrequirethoseconflicting usecases(Lines9and10).Whentheconflictingvariantusecases areunselectedbecauseoftherestriction,somevariantusecasesin thevariationpointsincludedbythoseconflicting usecasesmight alsobe automaticallyunselected,andthereforethecorresponding subsequentdecisionsneedtoberestricted(Lines11–17).Inourex- ample,UC4isselectedind1(i.e.,u=UC4),andonlyUC6conflicts withUC4(i.e.,CUC= {UC6}inLine3). Thereisnodecisionmade for UC6which should not be selected(i.e., r1 = (UC6, VP3, false) inLine8).UC4doesnotincludeanyvariationpointwherevariant usecasesmightbe automaticallyunselected(i.e.,AUC=∅inLine 12). As another input use case, UC12 is selected in d2^ (i.e., u = UC12),andonlyUC8conflictswithUC12(i.e.,CUC={UC8}inLine 3).There isnodecisionmadeforUC8.Therefore,itshouldnotbe selectedinsubsequentdecisions(i.e.,r2=(UC8,VP3,false)inLine 8).UC8isrequiredbyUC14inVP7whichhasnotbeendecidedyet

Fig. 9. Algorithm for inferConflictingUC .

(see inferRequiringUCinLine 9).Anotherdecisionrestriction r3 is inferredforVP7(i.e.,(UC14,VP7,false)).

The algorithm also identifies the variation points conflicting withtheinputselectedvariantusecaseu(seeFig.7(g)).Thevari- antusecasesintheundecidedconflicting variationpointsshould be unselected in the subsequent decisions (Line 23). The variant usecasesandvariationpointsrequiringthoseconflictingvariation pointsortheir variantusecasesshouldalso beunselected inthe subsequentdecisions(Lines 24–27).The subsequentdecisionsare restrictedforvariantusecaseswhichareautomaticallyunselected whenthevariantusecases intheundecidedconflicting variation pointsareunselected(Line28–34).FortheexampleinFig.5,there isnovariationpointconflictingwiththeinputusecases.Thealgo- rithmreturnsalltheinferredrestrictions(Line37).

5.2.Identificationofcontradictingdecisionrestrictions

Fora givensetofdecisionrestrictions,ourapproachidentifies (i) restrictions violating cardinalityconstraints invariation points and(ii)contradicting restrictions regarding theselection andun- selection ofthe same variantuse case. Assume we have two re-

Fig. 10. Algorithm for checkDecisionRestrictions .

strictionsrt1andrt2wherert1=(null,Va,false)andrt2=(Ua,Va, true).rt1andrt2contradicteachotherbecauseUainVashouldbe selectedaccordingtort2whilert1statesallthevariantusecases inVashouldbeunselected.

Fig.10 describesthealgorithmofcheckDecisionRestrictionsthat identifiescontradictingrestrictions.Acontradictionisdescribedas aset ofcontradicting decisions.Foreach variationpoint pin the PL diagram (Lines 3 and 4), the algorithm first checks if there are multiple restrictions (Lines 10–12). A contradiction is identi- fiedfortworestrictionsrequiringtheselectionandunselectionof thesamevariantusecase(Lines11and16).Morethantworestric- tionsresultinacontradictionwherearestrictionrequiresatleast onevariantusecaseinavariationpointtobeselectedwhileeach variantusecaseinthesamevariationpointisrequiredtobeun- selectedbyyetanotherrestriction(Line22).Restrictionswhichdo notcomplywithcardinalityconstraintsalsocontradicteachother (Line25).WecalltwofunctionsinFig.10(Lines22and25).

• checkSeveralRestrictions returnsaset ofcontradictions forre- strictions inDR inwhichmorethantworestrictions forvaria- tionpointpcontradicteachother;

• checkCardinalityreturnsasetofcontradictionsforrestrictions inDR whichdonotcomplywiththe cardinalityconstraintsin variationpointp.

For example, checkDecisionRestrictions checks the example re- strictionsforeach variation pointinFig. 5whereR ={r1, r2,r3} andPLDisFig.5.Restrictionsr1andr2applytothesubsequentde- cisioninVP3whiler3restrictsanothersubsequentdecisioninVP7.

r1andr2restrictthedecisionfordifferentvariantusecasesinVP3 (i.e.,r1.uc = r2.uc inLine10,r1.uc = null inLine13,andr2.uc = nullinLine13).UC6andUC8inVP3shouldbeunselectedaccord- ingto r1 andr2 whilethe cardinalityconstraintrequires atleast twoofthreevariantusecasesinVP3tobeselected(i.e.,checkCar-

dinalityreturns {{r1, r2}} inLine 25).r3 complies withthe cardi- nalityconstraintinVP7.checkDecisionRestrictionsreturns {{r1, r2}}

forthecontradictingrestrictionsinFig.5(Line27).

Tosummarize,herearethemainbuildingblocksofourchange impactanalysisalgorithm:

• Weautomatically selectvariantusecasesvia the includerela- tionsandthemandatoryvariabilityrelations.Forinstance,UC4 isautomatically selected via theinclude relation(i.e., UC1in- cludesVP2)andthemandatoryvariabilityrelation(i.e.,there- lationwith thecardinality constraint‘1..1’)when the userse- lectsUC1.

• Weuse therequires andconflicts relations toinfer restrictions onsubsequent decisions.For instance,whenUC4 isautomati- cally selected,the subsequentdecisionforVP3 is restrictedto UC6beingunselectedbecauseoftheconflictsrelationbetween UC4andUC6.IftheuserselectsUC14,thesubsequentdecision forVP3 is restricted to UC8being selected becauseof the re- quiresrelationbetweenUC14andUC8.

• Ourapproach doesnot haveanylimitation onthe numberof navigationstepsinthePLusecasediagramsince wehavere- cursioninthe infer functionswhich traversethe graphof de- pendencies we derive from the PL use case diagram. For in- stance,thefunctioninferConflictingUCinFig.9hasfunctioncalls toinferfurtherrestrictions (Lines9,10,15,16,24, 26,32and 33).Wedonothaveanyupperboundinourreasoning.Assume there are variantuse cases A, B,C andD where A requires B conflictingwithCrequiredby D.When theuserselectsA,we infer the restrictions that B should be selected, and C and D shouldnotbeselected.

6. IncrementalreconfigurationofPSusecasemodels

Afterallthedecisionchangesaremade,thePSusecasemodels needtobeincrementally reconfigured(Challenge2).Thereconfig- uration of PS models is implemented as a pipeline (see Fig. 11).

Configuration decisions are captured in a decision model during thedecision-makingprocess.Thedecisionmodelconformstoade- cisionmetamodel,describedinourpriorwork(Hajrietal.,2015).

PUMConfkeepstwo decisionmodels,i.e., thedecisionmodel be- forechanges(M1inFig.11) andthedecisionmodelafterchanges (M2 in Fig.11). Fig.12 provides thedecision metamodelandthe twoinputdecisionmodelsforthePLusecasemodelsinFig.1and Table1.

Thepipelinetakesthedecisionmodels,andthePSdiagramand specificationsasinput.ThePSmodelsarereconfigured,asoutput, togetherwithanimpactreport,i.e.,listofreconfiguredpartsofthe PSmodels.Thepipelinehasthreesteps(Fig.11).

InStep1,Matchingdecisionmodelelements,thestructuraldiffer- encingofM1andM2is doneby lookingforthecorrespondences inM1andM2.Tothatend, wedeviseanalgorithmthatidentifies thematchingmodelelementsinM1andM2.TheoutputofStep1 isthecorrespondingelements,representingdecisionsforthesame variations,inM1andM2(Section6.1).

ThedecisionmetamodelinFig.12(a)includesthemainusecase elementsforwhichtheusermakesdecisions(i.e.,variationpoint, optional step, optional alternative flow, and variant order). In a variationpoint,theuserselectsvariantusecasestobeincludedfor theproduct.ForPLusecasespecifications,theuserselectsoptional stepsandalternativeflows tobeincludedanddeterminestheor- der of steps (variant order). Therefore,the matching elementsin Step 1 are the pairs of variation points and use cases including the variation points, the pairs of use casesand optionalalterna- tive flows inthe usecases, andthetriples of usecases,flows in theusecases,andoptionalstepsintheflows.

Fig. 11. Overview of the model differencing and regeneration pipeline.

InStep2,Changecalculation,decision-levelchangesareidenti- fied from thecorresponding model elements(see Section 6.1). A set of elements in M1 which doesnot have a corresponding set of elementsin M2 is considered to be a deleted decision, which we refer to as DeleteDecision inthe decision-levelchanges. Anal- ogously, a set of model elements in M2 which does not have a corresponding set of elements in M1 is considered to be added (AddDecision). Each set of corresponding model elements with non-identical attribute values (see the red-colored attributes in Fig.12(c))isconsideredto bea decision-levelchangeofthetype UpdateDecision. Alternatively,we could record changesduringthe decision-making process. However, the usermight make changes cancellingprevious changesorimplying some furtherchanges.In suchacase,wewouldhavetocomputecancelledchangesandin- fernewchanges.Torecordthesechanges,theapproachwouldalso haveto dependonIBM DOORS,inwhichit isintegrated. Wede- signedan approachwhichisasindependentaspossiblefromany requirementsmanagementtool.

In Step 3,Regeneration of PS models, the PS usecase diagram andspecificationsareregeneratedonlyfortheadded,deletedand updateddecisions(seeSection6.2).Forinstance,usecasesselected inthedeleteddecisionsareremovedfromthePSusecasemodels, while usecasesselected intheadded decisionsare addedinthe PSmodels.

6.1. Modelmatchingandchangecalculation

We devisean algorithm(see Fig.13)forthe firsttwopipeline steps, Matchingdecisionmodel elementsandChangecalculation,in Fig. 11. The algorithm calls some match functions (Lines 7–9 in Fig.13)toidentifythecorrespondingmodelelements,whichrep- resentdecisionsforthesamevariations,intheinputdecisionmod- els.ThematchfunctionsimplementStep1inFig.11.

• matchDiagramDecisions returns the set of pairs (variation point,usecase) matchinginthedecisionmodels(M1andM2), whicharecapturingwhichvariationpointsareincludedinthe usecasesinvolvedindiagramdecisions;

• matchFlowDecisionsreturnsthe setofpairs (usecase,optional alternativeflow)matchingintheinputdecisionmodels(M1and M2), which arecapturing whichoptionalalternative flows are intheusecasesinvolvedinflowdecisions;

• matchStepDecisions returns the set of triples (use case, flow, step) matching in the input decision models (M1 and M2), which are capturing which steps are in the flows of the use casesinvolvedinstepdecisions.

The corresponding model elementsin the decision models in Fig.12(b)and(c)areasfollows(Lines7–9inFig.13):

• Fordecisionsinthevariationpoints, U3=

{

(^B6,B7),(^C6,C7)

}

,

• Fordecisionsintheoptionalalternativeflows,F3=∅,

• For decisions in the use case steps, S3=

{

(^B11,B12,B13), (^B11,B12,B14),(^B11,B12,B15),(^B11,B12,B16),(^B11,B12,B17), (^C11,C12,C13),(^C11,C12,C14),(^C11,C12,C15),(^C11,C12,C16), (^C11,C12,C17)

}

^.

A variant use case in a variation point (vp) may include an- other variationpoint (vp^).Changingthe decisionforvpmayim- ply another decision to be added or deleted for vp^. As part of Step 2, Change Calculation, the algorithm first identifies deleted and added diagram decisions by checking the pairs of variation pointsandusecaseswhichexistonlyinoneoftheinputdecision models((U1\U3) and(U2\U3) inLines 10–11).Similar checksare done forflow andstep decisions inthe specifications (Lines 10–

11).ForthedecisionmodelsinFig.12,thereisnodeletedoradded decision((^U1

\

^U3=∅),(^U2

\

^U3=∅),(^F1

\

^F3=∅),(^F2

\

^F3=∅), (^S1

\

^S3=∅),and(^S2

\

^S3=∅)^).

Thematchingpairs ofvariationpointsandtheir includinguse casesrepresentdecisionsforthesamevariationpoint((B6,B7)and (C6,C7)inFig.12(b)and(c)).Iftheselectedvariantusecasesfor thesamevariationpointarenotthesameinM1andM2,thecor- respondingdecisioninM1 isconsidered asupdated inM2 (Lines 12–19).ThevariantusecaseProvideSystemUserDataviaDiagnostic ModeofthevariationpointMethodofProvidingDataisunselected inM1(B6,B7andB9inFig.12(b)),butselectedinM2(C6,C7and C9inFig.12(c)).Thediagram decisionforthepair(B6,B7) inM1 isidentifiedasupdated(Line17).Toidentifyupdatedspecification decisions,thealgorithmcomparesdecisionsacrossM1andM2that involveoptionalalternativeflows, optionalsteps andsteps witha variantorder(Lines22–24,28–30and31–33).Inourexample,the triples(B11,B12,B14),(B11,B12,B15),(B11,B12,B16),and(B11,B12, B17)inFig.12representupdateddecisions.

6.2.RegenerationofPSusecasemodels

After all the changes are calculated by matching the corre- spondingmodelelementsintheinput decisionmodels,the parts ofPSusecasemodelsaffectedbythechangeddecisionsareauto- maticallyregenerated(Step3inFig.11).

Ourapproachfirsthandlesthediagramdecisionchangestore- configurethePS usecasediagram. Forselectedvariant usecases intheaddeddiagramdecisions(i.e.,inthepairs(vp,uc)inADDin Line36 inFig.13), we generatethe corresponding usecasesand includerelationsinthe PSdiagram.Forselectedvariantusecases indeleted diagram decisions (i.e.,in the pairs (vp,uc) inDELETE in Line 36), we remove the corresponding use cases andinclude relations from the PS diagram. If a selected variant use case is unselected in an updated diagram decision (i.e.,in the pairs (vp, uc)inUPDATEinLine36),we removethecorrespondingusecase fromthe PSdiagram. Forunselected variant usecases whichare selectedintheupdated diagram decisions,thecorresponding use cases andinclude relations are added to the PS diagram. Fig. 14 givestheregeneratedpartsofthePSusecasediagraminFig.2for M1andM2inFig.12.

Thereis no addedordeleted diagram decisionin M1andM2 inFig.12.ThedecisionforthevariationpointMethodofProviding Data (i.e.,(B6, B7) inUPDATE inLine 36) is updated by selecting thevariantusecaseProvideSystemUserDataviaDiagnosticMode. Onlythecorrespondingusecaseanditsincluderelationareadded tothePSusecasediagram(red-coloredinFig.14).

Fig. 12. (a) Decision metamodel, (b) Part of the example decision model before changes ( M1 ), and (c) Part of the example decision model after changes ( M2 ). (For interpre- tation of the references to colour in this figure legend, the reader is referred to the web version of this article.)

Changesfordiagramandspecificationdecisionsareusedtore- generatethe PS specifications. For diagram decision changes, we add or delete the corresponding use case specifications. Table 6 providestheregeneratedpartsofthePS specificationsinTable2, forM1andM2inFig.12.

ForthevariationpointMethodofProvidingDataincludedbythe usecaseProvideSystem UserData (i.e.,(B6,B7)),wehaveoneup- dateddiagram decision inwhich theunselected usecaseProvide

SystemUserDataviaDiagnostic Modeis selected.Thecorrespond- ingusecasespecificationisadded(Lines24–29inTable6).Anew specific alternativeflow isalsogenerated fortheinclusion ofthe newlyselectedusecaseinthespecificationoftheusecaseProvide SystemUserData(Lines12–15,red-colored).

Thespecificationdecisionchangesareaboutselectingoptional alternative flows, optional steps and steps with a variant order (e.g., the triples (B11, B12, B14), (B11, B12, B15), (B11, B12, B16),