ContentslistsavailableatScienceDirect
The Journal of Systems and Software
journalhomepage:www.elsevier.com/locate/jss
Recovering software product line architecture of a family of object-oriented product variants
Anas Shatnawi
a,c,∗, Abdelhak-Djamel Seriai
a, Houari Sahraoui
baLIRMM, University of Montpellier, Montpellier, France
bDIRO, University of Montreal, Montreal, Canada
cLATECE, University of Quebec at Montreal, Montreal, Canada
a rt i c l e i n f o
Article history:
Received 17 June 2015 Revised 12 July 2016 Accepted 25 July 2016 Available online xxx Keywords:
Software reuse
Software architecture recovery Software product line Object-oriented product variants Software component
Formal concept analysis
a b s t r a c t
Software Product Line Engineering (SPLE) aims atapplying apre-planned systematicreuse of large- grainedsoftwareartifactsto increasethesoftwareproductivityand reducethe developmentcost.The ideaofSPLEistoanalyzethebusinessdomainofafamilyofproductstoidentifythecommonandthe variable parts betweenthe products. However, itis commonfor companies to develop,inan ad-hoc manner(e.g.cloneandown),asetofproductsthatsharecommonservicesand differintermsofoth- ers.Thus, manyrecent researchcontributionsareproposedtore-engineerexistingproductvariantsto asoftwareproductline.Thesecontributionsaremostlyfocusedonmanagingthevariabilityatthere- quirementlevel.Veryfewcontributionsaddressthevariabilityatthearchitecturalleveldespiteitsmajor importance.Startingfromthisobservation,weproposeanapproachtoreverseengineerthearchitecture ofasetofproductvariants.Ourgoalistoidentifythevariabilityanddependenciesamongarchitectural- elementvariants. Ourworkreliesonformalconceptanalysis toanalyzethevariability.To validatethe proposedapproach, weevaluatedontwo familiesofopen-sourceproductvariants; MobileMediaand HealthWatcher.Theresultsofprecisionandrecallmetricsoftherecoveredarchitecturalvariabilityand dependenciesare81%,91%,67%and100%,respectively.
© 2016ElsevierInc.Allrightsreserved.
1. Introduction
Instead ofdevelopingeachsoftwareproduct individually,Soft- wareProductLineEngineering(SPLE)promotesapre-plannedsoft- ware reuseby building andmanagingafamily ofsoftware prod- uctsthataredevelopedinthesamedomain(aka.SoftwareProduct Line (SPL)) (Clements andNorthrop, 2002; Pohl et al., 2005). An SPL is definedas “a set of software-intensivesystems that share a common, managedset of features satisfying the specific needs ofaparticularmarketsegmentormissionandthataredeveloped fromacommonsetofcoreassetsinaprescribedway” (Clements and Northrop, 2002). The main idea behind SPLE is to analyze the business domain of an SPL in order to identify the common and the variable parts betweenthe member products (Clements andNorthrop,2002; Pohlet al.,2005). Thisaims tobuild a soft- ware productionlineofafamilyofsoftwareproducts customized based on their common characteristics. Thus, a software product can be instantiated based on SPL core assets which are a set of
∗ Corresponding author.
E-mail addresses: shatnawi@lirmm.fr , anasshatnawi@gmail.com (A. Shatnawi), seriai@lirmm.fr (A.-D. Seriai),sahraoui@iro.umontreal.ca (H. Sahraoui).
reusablesoftwareartifacts(ClementsandNorthrop,2002).SPLEis composedoftwo phases;domainengineeringandapplicationen- gineering(Pohl etal., 2005). Thegoal ofthe domainengineering phaseistocreatereusablecoreassetsbasedontheanalysisofthe commonalityandthevariabilityofafamilyofproducts.Coreassets consistofrequirementspecifications,architecturedescriptions,de- signmodels, source codes,test cases, etc (Pohl etal., 2005). The goaloftheapplicationengineeringphaseisto (re)usecoreassets toderiveSPLproducts (Pohletal.,2005;Lindenetal.,2007).
Oneof themost importantsoftwareartifacts composingSPL’s coreassetsisSoftwareProductLineArchitecture(SPLA)(Clements andNorthrop,2002;Linden etal.,2007;Pinzgeretal.,2004).The aim of an SPLA is to highlight the commonality and the vari- ability of an SPL at the architecture level (Pohl et al., 2005). It doesnot onlydescribethesystemstructure atahighlevelofab- straction, but also describes the variability of an SPL by captur- ing the variability of architecture elements (Pohl et al., 2005).
SPLAcan beeitherdeveloped fromscratch,i.e.proactivestrategy (ClementsandNorthrop,2002;Pohletal.,2005;Krueger,2002),or re-engineeredbased on the analysisof existing softwareproduct variants,i.eextractivestrategy(Krueger,2002).However,develop- ingSPLAfromscratchisknowntobeahighlycostlyandriskytask
http://dx.doi.org/10.1016/j.jss.2016.07.039 0164-1212/© 2016 Elsevier Inc. All rights reserved.
Pleasecitethisarticleas:A.Shatnawietal.,Recoveringsoftwareproductlinearchitectureofafamilyofobject-orientedproductvariants,
(Clements andNorthrop, 2002;Pohl et al., 2005; Krueger,2002).
Inaddition,itis commonforcompanies todevelop a setofsoft- ware product variants that share common services anddiffer in termsof other ones. These products are usually developedin an ad-hoc manner (e.g.clone and own) by addingand/or removing some services to/from an existing software product to meet the requirementofa newneed (Dubinsky etal., 2013). Nevertheless, whenthenumberofproduct variantsgrows,managingthe reuse andmaintenance processesbecomesa severe problem(Dubinsky etal., 2013). As a consequence,it is necessaryto identifyand to manage the variability between product variants as an SPL. This allows to reduce the cost of SPL developmentby first startingit fromexisting products andthen beingable to manage the reuse andmaintenancetasksinproductvariantsusinganSPL.
In the literature, there are few approaches that recover SPLA from a set of product variants such as Frenzel et al. (2007); Koschke et al. (2009); Pinzger et al. (2004); Kang et al. (2005). Theseapproachessufferfromtwo main limitations.The firstone isthatthearchitecturevariabilityispartiallyaddressedsincethey recoveronly some variabilityaspects, no one recovers thewhole SPLA. The second one is that they are not fully-automatic since they rely on the expert domain knowledge which is not always available.
Toaddress theselimitations,we proposean approachtoauto- maticallyrecoverthearchitectureofasetofsoftwareproductvari- ants.Thisisdonethroughtheexploitationofthecommonalityand thevariabilityacrossthesourcecodeoftheseproductvariants.Our contributionistwofold:ontheonehand,werecoverthearchitec- turevariabilityconcerningbothcomponentandconfigurationvari- ability.Ontheother hand,we recoverdependenciesbetweenthe architectural-elementsbasedonformalconceptanalysis.
In order to validate the proposed approach, we evaluated on two familiesof open-source product variants; Mobile Media and HealthWatcher.Theevaluationshowsthatourapproachisableto identifythearchitecturalvariabilityandthedependenciesaswell.
Theresultsofprecision andrecall metricsofthe identificationof architectural variability and the dependencies are 81%, 91%, 67%
and100%,respectively.
Thisjournalpaperisanextendedversionofourconferencepa- perpublishedinShatnawietal.(2015b).This extensionincludes:
(i)identifyingnewcategoriesofarchitecture variability(e.g.inter- nalandexternalcomponentvariability,variabilityofgroupsofde- pendencies,anddependenciesrelatedto optionalcomponentdis- tribution).(ii)Deep analysisoftheproblemofSPLAidentification.
(iii)Moredetails anddeepanalysisofthe proposed solution.(iv) Relatedwork classification.(v) Presentationofnewresultsrelated totheidentificationofgroupsofvariability.(vi)Theprosandcons discussion.(vii)Threatstovaliditydiscussion.
The restof this paperis organized asfollows. Section 2puts theproblemincontext.Next,inSection3,we presenttherecov- eryprocessofSPLA.Section4presentstheidentificationofarchi- tecturevariability.Then,Section5presentstheidentificationofde- pendenciesamongarchitectural-elementvariants.InSection6,we identify groups of variability. Evaluation results of our approach arediscussed inSection 7. Adiscussion aboutthe prosandcons ofour approachis placed in Section 8.Related work isanalyzed inSection 9.Finally,concludingremarksandfuturedirectionsare presentedinSection10.
2. Puttingtheproblemincontext 2.1.Background
2.1.1. Softwareproductlinearchitecture
SPLA is a specialkind of software architecture. It is designed todescribe the software architecture ofa set of similar software
Fig. 1. UML object-to-component mapping model.
productsthataredevelopedinthecontextofanSPLClementsand Northrop(2002).Intheliterature,manydefinitionshavebeenpre- sented to define SPLA. Thesedefinitions consider SPLA asa core architecturethatcapturesthevariabilityofasetofsoftwareprod- uctsatthearchitecturelevel.However,theydifferintermsofthe variabilitydefinition.Forinstance,DeBaudetal.(1998)definedan SPLAasanarchitecturesharedbytheirmemberproductsandhas such avariabilitydegree.Thisisa verygeneraldefinitionsinceit doesnotspecifythenatureofthearchitecture variability.Incon- trast,Pohletal.(2005)provideamoreaccuratedefinitionbyspec- ifyingthenatureofarchitecturevariability.Inthisdefinition,SPLA includes variation pointsandvariants that are presented in such avariabilitymodel.Gomaa(2005)linksthearchitecturevariability withthe architectural-elements. Thus, in his definition, SPLA de- fines thevariabilityintermsof mandatory,optional, andvariable components,andtheirconnections.
2.1.2. Component-basedarchitecturerecoveryfromsinglesoftware:
theROMANTICapproach
For the evaluation, we use our previous works (Kebir et al., 2012b;Chardignyetal.,2008a),theROMANTIC1approach,toauto- maticallyrecoveracomponent-basedarchitecturefromthesource code of a single object-oriented software. Components are ob- tained by partitioning classesconstituting the implementation of this software. Each class is assigned to a unique subset forming the implementationofan object-oriented component, i.e.acom- ponentthatcanbeimplementedusinganobject-oriented compo- nentmodelsuch asOSGi(TavaresandValente,2008).ROMANTIC is based on two main models. The first concerns the object-to- component mapping model which allows to link object-oriented concepts (e.g.package, class)tocomponent-basedones(e.g.com- ponent,interface). Followingthismodel,a componentconsistsof two parts;internal andexternalstructures. Theinternal structure is implementedby a set ofclasses that havedirect linksonly to classes that belong to the component itself. The external struc- ture is implemented by the set of classes that have direct links toothercomponents’classes.Classesthatformtheexternalstruc- tureofacomponentdefinethecomponentinterface.Fig.1shows theobject-to-component mappingmodel. Thesecond modelpro- posedisusedtoevaluatethequalityoftherecoveredarchitectures andtheirarchitectural-element.Forexample,thequality-modelof recovered componentsis based onthree characteristics; compos- ability, autonomy and specificity. These refer respectively to the
1ROMANTIC: Re-engineering of Object-oriented systeMs by Architecture extrac- tioN and migraTIon to Component based ones.
Table 1
Formal context example.
Natural Artificial Stagnant Running Inland Maritime Constant
River X X X X
Sea X X X X
Reservoir X X X X
Channel X X X
Lake X X X X
ability of the componentto be composed without anymodifica- tion,tothe possibilitytoreusethecomponentinanautonomous way, and to the fact that the component implements a limited numberofclosedservices.Basedonthesemodels,ROMANTICde- fines a fitness function applied in a hierarchical clusteringalgo- rithm (Kebir etal., 2012b;Chardigny et al., 2008a) as well as in search-based algorithms(Chardignyetal., 2008b)to partitionthe object-orientedclassesintogroups,whereeachgrouprepresentsa component.
2.1.3. Formalconceptanalysis
Toanalyzethearchitecturalvariability,weuseFormalConcept Analysis (FCA). It is a mathematical data analysis technique de- veloped based on the lattice theory (Ganter andWille, 1996). It allows the analysisof the relationships betweena set of objects described by a set of attributes. In thiscontext, maximal groups ofobjects sharingthesame attributesarecalledformal concepts.
Theseareextractedandthenhierarchicallyorganizedintoagraph calledaconceptlattice.Eachformalconceptconsistsoftwoparts.
The first allows the representation ofthe objects covered by the concepts called theextent ofthe concept.The second allows the representation of the set of attributes shared by the objects be- longingtotheextent.Thisiscalledtheintentoftheconcept.Con- cepts canbe linked through sub-conceptand super-conceptrela- tionships(GanterandWille,1996)wherethelatticedefinesapar- tiallyorderedstructure.AconceptAisasub-conceptofthesuper- conceptB,iftheextentoftheconceptBincludestheextentofthe concept A andthe intent ofthe conceptA includes the intent of theconceptB.
TheinputofFCAiscalledaformalcontext.Aformalcontextis definedasatripleK=(O,A,R)whereOreferstoasetofobjects, A refers to aset ofattributesand Ris abinaryrelation between objects andattributes. This binary relation indicates a set of at- tributes that are heldby each object (i.e.R⊆OXA). Table1 shows an example of aformal context fora set ofbodies ofwater and their attributes.AnXreferstothefactthatanobjectholdsanat- tribute.
As statedbefore,a formalconceptconsistsofextentE andin- tent I,whereE a subset ofobjects O (E⊆O) andIa subset ofat- tributes A(I⊆A).Apair ofextentandintent(E,I)is considereda formalconcept,ifandonly,ifEconsistsofonlyobjectsthatshare allattributesinIandIconsistsofonlyattributesthataresharedby all objectsinE.Thepair(”river, lake”, ”inland,natural,constant”) isanexampleofaformalconceptoftheformalcontextinTable1. Fig.2showstheconceptlatticeoftheformalcontextpresentedin Table1.
2.2. Problemanalysis
Softwarevariabilityisthe maintheme ofSPLE.Itisrelatedto the susceptibility andflexibility ofsoftware to change (Clements andNorthrop,2002).ThevariabilityinanSPLisrealizedatdiffer- entlevelsofabstractionduringthedevelopmentlifecycle,e.g.re- quirement,anddesign.Forinstance,attherequirementlevel,itis originatedstartingfromthedifferencesinusers’wishes,anddoes notcarry anytechnicalsense(Pohletal.,2005).Thisisrelatedto
Fig. 2. The concept lattice of the formal context in Table 1 .
asetoffeaturesthatare neededtobe includedinsuch anappli- cation(e.g.theuserneedscamera,WIFI,andcolorscreenfeatures in the phone). Usually, this variability is documented by feature modelinglanguage(Kangetal.,1990).Atthedesignlevel,thevari- abilityhasmoredetails relatedtotechnicalsolutionsto formthe applicationarchitectures.Thesetechnicaldetailsdescribe howthe applicationsarebuiltandimplementedwithregardtothepointof view ofsoftwarearchitects (Pohl etal., 2005). Suchtechnicalde- tailsarethoserelatedtowhichsoftwarecomponentsareincluded inthe application (e.g. video recorder, photocapture, andmedia store components), howthese componentsinteractthrough their interfaces(e.g.videorecorderprovidesavideostreaminterface to mediastore),andwhattopologyformsthearchitecturalconfigura- tion(i.e.howcomponentsarecomposited)(Nakagawaetal.,2011).
All of these technical details are described via Software Product LineArchitecture(SPLA)(Pohletal.,2005).
SPLA realizesthe software variability atthe architecture level by exploring the commonality andthe variabilityof architecture elements, i.e.component, connectorand configuration variability.
Inthispaper,wefocusoncomponentandconfigurationvariability.
Wedonotconsiderconnectorvariabilitysincetheconnectorsare not considered asfirst classconcepts inthe mostofarchitecture descriptionlanguagessuch asMagee andKramer(1996)Luckham (1996) Canal et al. (1999). To better understand the architecture variability,werelyontheexampleprovidedinFig.3.Thisexample schemes the architecture of three product variants related to an audioplayer productfamily. Eacharchitecture variantdiverges in thesetof componentsconstituting itsarchitecture aswell asthe linksbetweenthesecomponents.
Componentsareconsideredasthemainbuildingunitofanar- chitecture. Their variability can be considered following two di- mensions.Thefirstoneisrelatedtotheexistenceofseveralcom- ponentshavingthesamearchitecturalmeaning,i.e.almostprovide
Fig. 3. An illustrative example of architecture variability.
thesameservices.Wecallthesecomponentvariants.Forexample, inFig. 3,MP3 Decoderand MP3Decoder/Encoder are examples of componentvariants.Thesecond dimensionisrelatedtothecom- monality andthevariabilitybetweencomponent variants.Thisis realizedthoughinternal andexternalvariability. Internalvariabil- ityrefersto thedivergence relatedtothe implementationdetails ofcomponentvariantswhichmaylead tovariabilityinthesetof servicesprovided by these componentvariants, e.g. Decoderonly orDecoder/Encoderservices. Externalvariability refers tothe way that the componentinteracts withother components. This is re- alizedthroughthe variabilityinthecomponentinterfaces.In our example,theSoundSourcecomponentvariantshaveeitherone or twointerfaces.
Furthermore, the architecture configuration does not only define the topology of how components are composited and connected, but also defines the set of included components.
Thus, the configuration variability is represented in terms of presence/absence of components, on the one hand, and pres- ence/absence of component-to-component-links on the other hand.Theserespectivelyrefertothecommonality(mandatory)and thevariability(optional) ofcomponentsandcomponent-links.For example,inFig.3,SoundSourceisamandatorycomponent, while PurchaseReminderisanoptionalone.ThelinksthatconnectPlayer andSoundSourcearemandatorylinks,whilethelinkthatconnects MP3Decoder/EncoderandSoundSourceisanoptionalone.
Theidentificationofcomponentsandcomponent-linksvariabil- ityis not enough to define a valid architectural configuration.It alsodependsontheidentificationofarchitectural-elementdepen- dencies, i.e. constraints,that mayexist between the elements of thearchitectures.Forinstance,components providingantagonism serviceshave an exclude dependency. Furthermore, a component mayneedothercomponentstoperformitsservices.Thisrefersto arequireddependency.
3. Architecturevariabilityrecoveryprocess
The goalof ourapproach isto recover SPLAof aset ofprod- uct variants.This isobtainedby identifying variabilityamong ar- chitecturesrespectivelyrecoveredfromeach singleproduct. Thus, weidentifycomponent-basedarchitecturebyanalyzingtheobject- orientedsource code of each singleproduct. This constitutesthe firststepoftherecoveryprocess.Toidentifyarchitecturalvariabil- ityamongtheidentifiedcomponent-basedarchitectures, weiden- tifycomponentvariantsbasedontheidentificationofcomponents providingsimilarfunctionalities.Thisistheroleofthesecondstep oftherecoveryprocess.Next,we identifyconfigurationvariability basedon boththe identificationofmandatory andoptionalcom- ponents aswell aslinksbetween thesecomponents.In addition, we capture the dependencies amongoptional components based on FCA. Theseare mined in thefourthstep of therecovery pro- cess.Fig.4showsthesesteps.
4. Identifyingthearchitecturevariability
The architecture variability is materialized eitherthrough the existence ofvariants ofthe samearchitectural-element (i.e.com- ponent variants) or through the configuration variability. In this section,weshowhowcomponentvariantsandconfigurationvari- abilityareidentified.
4.1. Identifyingcomponentvariants
The selection of a component to be used in an architecture isbased on itsprovided andrequired services.The providedser- vices define the role of the component. However, other compo- nentsmayprovidethesame,oratleastsimilar,coreservices.Each component may also provide other specific services in addition to the core ones. Considering these components, either ascom- pletelydifferentorasthe same,doesnotallowthevariabilityre- lated to components to be captured.Thus, we consider them as
Fig. 4. The process of architectural variability recovery.
component variants. We define component variants as a set of components providing the same coreservices and differing con- cerningafewsecondaryones.InFig.3,MP3DecoderandMP3De- coder/Encoder are considered as component variants. In this sec- tion, we identifycomponent variants based on the identification of components providingsimilar services.Next, we analyze their variabilityintermsofinternalandexternalvariability.
4.1.1. Identificationofcomponentsprovidingsimilarservices
Weidentifycomponentvariantsbasedontheirsimilarity.Simi- larcomponentsarethosesharingthemajorityoftheirclassesand differing inrelation to some others. The identification of similar componentsisbasedonthestrengthofsimilarityrealizedintheir implementing classes.Todothis, we usecosine similaritymetric (Han etal., 2006) whereeach componentisconsidered asa text document composed of the names of its classes. We use a hier- archical clustering algorithm (Han et al., 2006) to gather similar components into clusters. It startsby considering components as initialleafnodesinabinarytree.Next,thetwomostsimilarnodes aregroupedintoanewonethatformstheirparent.Thisgrouping process isrepeateduntilall nodesaregroupedintoa binarytree (seeAlgorithm1).Notethattwocomponentsfromthesameprod- uctcannot begroupedtogether inthesamecluster. Thecluster- ingalgorithmchecksthissituationandforbidsitAllnodesinthis binarytreeare consideredascandidatesto beselected asgroups ofsimilarcomponents.Toidentifythebestnodes,weuseadepth first search algorithm (see Algorithm 2). Starting from the tree root to findthe cut-off points, we compare the similarity ofthe currentnodewithitschildren.Ifthecurrentnodehasasimilarity value exceeding theaverage similarity value of its children, then thecut-off pointisinthe currentnode. Otherwise,thealgorithm continues through its children. The results of this algorithm are clusters whereeach one iscomposed ofa set of similar compo- nentsthatrepresentvariantsofonecomponent.
Algorithm 1: Building dendrogram for similar component identification.
Input:Components(PC)
Output:DendrogramTree(dendrogram) BinaryTreedendrogram=PC;
while(|dendrogram|>1)do
c1,c2=mostLexicallySimilarNodes(dendrogram);
c=newNode(c1,c2);
remove(c1,dendrogram);
remove(c2,dendrogram);
add(c,dendrogram);
end
returndendrogram
Algorithm 2: Dendrogram traversal for similar component identification.
Input:DendrogramTree(dendrogram)
Output:ASetofClustersofComponents(clusters) Stacktra
v
ersal;tra
v
ersal.push(dendrogram.getRoot());while(!tra
v
ersal.isEmpty())do Node f ather=trav
ersal.pop();Nodele ft=dendrogram.getLeftSon(f ather);
Noderight =dendrogram.getRightSon(f ather);
ifsimilarity(f ather)>(similarity(le ft)+similarity(right)/ 2)then
clusters.add(f ather) else
tra
v
ersal.push(le ft);tra
v
ersal.push(right);end end
returnclusters
Table 2
An example of formal context of three component variants.
Class 1 Class 2 Class 3 Class 4 Class 5 Class 6 Class 7 Class 8
Variant 1 X X X X X X
Variant 2 X X X X X X
Variant 3 X X X X X X
Fig. 5. A lattice example of component variants.
4.1.2. Identificationofinternalvariability
Internal structure variability is related to the implementation of components. Component variants are implemented by object- orientedclasses.Thus,we identifyinternal variabilityinterms of classvariability.Wedistinguishtwocategoriesofclasses.Thefirst one refers to classesrelated tocommonality. Thesebelong to all variantsofthecomponent.Wecallthemcommonclasses.Thesec- ondcategory refers to classesrelated tovariability. These donot belong to all variants of the component. We call them variable classes.
The identificationofcommonandvariableclassesandthedis- tributionofvariableclassesisachievedusingFormalConceptAnal- ysis(FCA). Tothisend,we build theformal context,so thateach componentvariantisconsidered asanobjectandeachclassisan attributeinthisformalcontext.Table2showsanexampleofafor- malcontext builtusing threecomponent variants.A crossinthe cell(V, C) denotesthat thevariantVholdstheclass C.In thelat- ticegenerated basedon this formal context,common classesare groupedintheroot,whilethevariableonesarehierarchicallydis- tributedto thenon-root nodes.The leaf nodesrepresentcompo- nentvariants.These variantshaveall classesthat areattachedto thenodesplacedinthepathtotherootnode.
Fig. 5 shows the lattice extracted based on the formal con- text presented inTable 2. Onthe one hand,the commonality of their implementation isrepresented by common classes grouped together on the top ofthe lattice (i.e. the root). Class 1, Class 2, Class 3and Class 4 are the common classes. Onthe other hand, thevariability oftheir implementation isrepresented by variable classesdistributedonthenonrootnodes.Forinstance,Class8be- longstotwovariants;Variant1andVariant3,whileClass6belongs onlytoonevariant;Variant2.
4.1.3. Identificationofexternalvariability
The interaction betweencomponents is realizedthrough their interfaces; provided and required interfaces. Provided interfaces are abstract descriptions of services provided by a component.
Fig. 6. An example of interface variability.
Theseservicesmayberequiredbyother componentsinthesame architecture.Inobject-orientedcomponents,aninterfaceistheab- stractionofagroupofmethodinvocations.Thisgroupprovidesan accesstothecomponentservices.Ascomponentvariantsareiden- tified from different products, thus each variant may havesome interfaces that are different compared to the other variants. For example,inFig.6,CD ReaderandCDReader/Writer variantsdiffer compared to their interfaces. Inthe former, it hasonly one pro- videdinterfacethatprovidestheserviceofreadingtheCDcontent.
In the latter,it has an additional required interface compared to thefirstvariant.Thisinterface requiresa sourceofinformationto bewrittenontheCD.Theinterfacesofacomponentcanbeclassi- fiedintomandatory andoptionalinterfaces.Mandatoryinterfaces are ones existing in all variants of the component(e.g. the pro- videdinterfaceinFig.6).Optionalinterfacesarethosethatarenot mandatory(e.g.therequiredinterfaceinFig.6).
Algorithm 3 shows the procedure for identifying mandatory and optionalinterfaces of a set of component variants. For each variant, we identify its interfaces in the corresponding products in which the variant hasbeen identified. This is done using our approach presentedinKebir etal.(2012b) which identifiesinter- facesasgroupsofmethods.Toidentifywhetherinterfacesaresim- ilar or not,we relyon the textual similarity betweenthe source
Algorithm3:Identifyinginterfacevariability.
Input:ASetofComponentVariants(CV)
Output:ASetofMandatoryandOptionalInterfaces(MI,OI)) MI=identifyInterfaces(CV.getFirstVariant());
allInter f aces=∅;
$Identifytheunionandintersectionofcomponentvariant interfaces$
foreach
v
∈CV doMI=MI∩identifyInterfaces(
v
);allInter f aces=allInter f aces∪identifyInterfaces(
v
);end
OI=allInter f aces−MC;
returnMI,OI
Fig. 7. A lattice example of similar configurations.
code oftheir implementedmethods. Inthiscontext,we compare the complete method implementations. If the similarity exceeds a pre-defined thresholdvalue defined by the software architects based on their knowledge about the variability degree of prod- uct variants,thenthey areconsideredasthesameinterface. Soft- warearchitectscanusesoftwaremetricspresentedinBergeretal.
(2010) that measure the variability degree of a product variants basedoncommonalitysize,impactofcommonality,etc.Theinter- section ofthe setsof interfacesfromall theproducts determines all mandatory interfacesfor thegivencomponent. Interfaces that donotbelongtothisintersectionareoptionalones.
4.2. Identifyingconfigurationvariants
Intheprevious section, weidentifiedcomponentvariabilityin termsofcomponentvariantsandtheirinternalandexternalvari- ability. In thissection, we present howto recover theconfigura- tionvariability.Thearchitecturalconfigurationisdefinedbasedon thelistofcomponentscomposing thearchitecture,aswell asthe topologyofthelinksexistingbetweenthesecomponents.Thus,the configurationvariabilityisrelatedtothesetwoaspects;thelistsof mandatory(core)andoptionalcomponentsandthelistofmanda- toryandoptionallinksbetweentheselectedcomponents.
4.2.1. Identificationofcomponentvariability
To identify mandatory andoptional components, we use For- malConceptAnalysis(FCA)toanalyzearchitectureconfigurations.
Wepresenteachsoftwarearchitectureasanobjectandeachmem- ber componentasan attribute intheformal context. Inthe con- cept lattice, common attributes are grouped into the root while thevariableonesarehierarchicallydistributedamongthenon-root concepts.
Fig.7showsanexampleofalattice forthreesimilar architec- ture configurations. The mandatory components are grouped to- getherattherootconceptofthelattice(thetop). InFig.7,Com1 andCom4arethemandatory componentspresentedinthethree architectures.Bycontrast,optionalcomponentsarerepresentedin alllatticeconcepts excepttheroot.e.g.,accordingtothelatticeof Fig.7,Com2andCom5arepresentedinArch1andArch2butnot inArch3.
4.2.2. Identificationofcomponent-linkvariability
A component-link is defined as a connection that material- izesthecompositionoftwocomponentsrespectivelythroughtheir providedandrequiredinterfaces.Fig.8showsanexampleofhow componentsarelinkedthroughtheirinterfaces.
Fig. 8. An example of component-link.
Acomponentmaybelinkedwithdifferentcomponents.Acom- ponentmayhavelinkswithaset ofcomponentsinone product, and it may have other links with a different set of components inanotherproduct.Thus,thecomponent-linkvariabilityisrelated tothecomponentvariability.Thismeansthat theidentificationof thecomponent-link variabilityis based on theidentified compo- nentvariability.Forinstance,theexistenceofalinkbetweenCom- ponentAandComponentBisrelatedtotheselectionofComponent AandComponentBinthearchitecture.Thusconsideringamanda- torylinkisbasedontheoccurrenceofthelinkedcomponents,but notontheoccurrenceinthearchitectureofproducts.Inthisway, amandatory linkisdefinedasalink thatshould beoccur inthe architectureconfigurationaswellasthelinkedcomponentsarein- cluded inthe configuration.To identify thecomponent-link vari- ability,we proceedsimilar toAlgorithm 3intermsof identifying theunionandtheintersection.Foreacharchitecturalcomponent, wecollectthesetofcomponentsthatare connectedto itineach product.The intersectionofthe sets extractedfromall theprod- uctsdeterminesallmandatorylinksforthegivencomponent.The otherlinksareoptionalones.
5. Identifyingarchitecturedependencies
Intheprevioussections,weidentifiedcomponentandconfigu- rationvariability.Inthissection,wecompletetheidentificationof SPLAbyrecoveringthearchitecturaldependencies.
5.1. Identificationofdependenciesrelatedtofeaturevariability
Themostcommontypesofdependenciescanbeoffivekinds:
alternative,OR,AND,require, andexclude dependencies.Toiden- tifythesedependencies,we relyonthesameconcept latticegen- erated in Section 4.2.1. In the lattice, each node groups a set of componentsrepresentingtheintent(e.g.Com5andCom2)anda setofarchitecturalconfigurationsrepresentingtheextent(e.g.Arch 2).Theconfigurationsarerepresentedbypathsstartingfromtheir conceptstothelatticeconceptroot.Theideaisthateachobjectis generatedstartingfromitsnodeupgoingtothetop.Thisisbased on sub-conceptto super-concept relationships (c.f.Section 2.1.3).
Thisprocessgenerates apath foreach object.Apathcontainsan ordered listof nodesbased on their hierarchicaldistribution; i.e.
sub-concepttosuper-conceptrelationships).
The extractionof thesepaths is basedon two steps. The first one is node numbering. This is done using Breadth First Search (BFS)algorithm(Cormenetal.,2009). Inthiscontext,BFSisused toidentifyatreerepresentationofagivengraph.Startingfromthe rootnode (i.e. the top), BFSvisits the nodes at distance 1, then itvisitsthe nodesatdistance2andsoon. Fig.9showsthepro- cessofhow BFSorders the nodes,wherenode numberingrefers tothe distanceofvisiting agivennode and∞ denotes unvisited nodes.In thesecondstep,startingfromanode thatholds anex- tent(e.g.Arch1),wegoupthroughlinksguidingustonodesthat carry a lower numbering andso on.This is recursivelyrepeated,
Fig. 9. An example of BFS process.
Fig. 10. An example of paths extracted from FCA lattice.
where the termination condition is reaching the node having 0 numbering.Fig. 10 presents the paths identified in our example.
Therearethreepaths respectivelypresentedbysolid,dashed and doubledashedarrows.Forinstance,thepathcorrespondingtoArch 1includes thenodeofCom3,thenodeofCom5andCom2and thenodeofCom1andCom4. Accordingtothesepaths,we pro- poseextractingthe dependencies betweeneach pair ofnodes as follows.
5.1.1. Requireddependencyidentification
Required dependency refers to the obligation selection of a componenttoselectanother one;i.e.ComponentB isrequiredto selectComponentA.Basedontheextractedpaths,weanalyzetheir nodesby identifying parent-to-child relation (i.e. top to bottom).
Thus,node Arequiresnode Bifnode Bappearsbefore nodeA in allpaths,i.e.,node Aisasub-conceptofthesuper-conceptcorre- spondingtonodeB.Inother words,toreachnode Ainanypath, itisnecessarytotraversenodeB.Forexample,ifweconsiderthe latticeinFig.7,Com6requiresCom2andCom5sinceCom2and Com5aretraversedbeforeCom6inallpathsincludingCom6and linkingrootnodetoobjectnodes.
5.1.2. Excludeandalternativedependenciesidentification
Excludedependency referstotheantagonisticrelationship; i.e.
ComponentAandComponentBcannotoccurinthesamearchitec- ture.Thisdependencyisidentifiedbasedontheextractedpaths.A
Algorithm4:Identifyingexcludepairs.
Input:AllPairsofLatticeNodesandPaths(Pairs,Paths) Output:ASetofPairsHavingExcludeDependency(ED) ED=∅;
$Searchforpairshavinganexclude$
foreachpair∈Pairsdo isFound=false;
foreachpath∈Pathsdo if path.contains(pair)then
isFound=true;
break;
end
$Ifthepairisnotfoundinthepaths$
ifisFound==falsethen ED=ED∪pair; end
returnED
node is excluded withrespect to anothernode ifthey never ap- pear together in any of the existing paths; i.e. there is no sub- concept to super-concept relationshipbetween them.This means that there exists no object containing both nodes. For example, ifwe consider thelattice inFig. 7, Com6 andCom 7are exclu- sivessincetheyneverappeartogether inanyofthelattice paths.
Algorithm4 presentsthe procedureof extractingpairs ofnodes thathavetheexcludedependency.
Alternative dependency generalizesthe exclude one by exclu- sivelyselectingonly onecomponentfromasetofcomponents.It canbeidentifiedbasedontheexcludedependencies.Indeed,aset of nodesin the lattice havingeach an exclude dependency with allothernodesformsanalternativesituation.Forexample,ifnode A is excluded compared to nodesB andC onthe one hand, and node Bisexcluded comparedto nodeC,on theother hand,then thegroupofA,BandCformsanalternativegroup.
5.1.3. ANDdependencyidentification
ANDdependencyisthebidirectionalformoftherequiredone;
i.e.Component ArequiresComponent Bandvice versa.Moregen- erally,theselectionofonecomponentamongasetofcomponents requirestheselectionofalltheothercomponents.Accordingtothe builtlattice,thisdependencyisidentifiedwhenagroupofcompo- nentsis groupedin thesame conceptnode in thelattice; i.e.all componentsgroupedinthisnodeshouldbeselectedtogetherand notonlyapartofitscomponents.Forexampleifweconsiderthe
Algorithm5:IdentifyingOR-groups.
Input:AllPairs(ap),RequireDependencies(rd),Exclude Dependencies(ed)andAlternativeDependencies(ad) Output:SetsofNodesHavingORDependencies(orGroups)
$Removepairsandgroupshavingrequired,excludeand alternative$
OrDep=ap.exclusionPairs(rd,ed,ad);
$Removepairshavingtransitiverequired$
OrDep=orDep.removeTransitiveRequire(rd);
$Identifynodesthatsharesomecomponents$
ORPairsSharingNode=orDep.getPairsSharingNode();
$Processthedependenciesamongtheunsharedcomponents$
foreachp∈ORPairsSharingNodedo
ifotherNodes.getDependency()==requirethen orDep.removePair(childNode);
elseifotherNodes.getDependency()=exclude||alternative then
orDep.removeAllPairs(p);
end
orGroups=orDep.getPairsSharingOrDep();
returnorGroups
lattice inFig. 7,Com2andCom 5are concernedby an AND de- pendency.
5.1.4. ORdependencyidentification
When components are concerned by an OR dependency, this meansthatatleastoneofthemshouldbeselected;i.e.theconfig- urationmaycontainanycombinationofthecomponents.Thus,in thecaseofabsenceofotherdependency, anypairofcomponents is concerned by an ORdependency. Accordingly, pairs concerned with required, exclude, alternative, or AND dependencies are ig- nored aswell asthose concerned with transitive requiredepen- dencies; e.g. Com6 andCom7 areignored sincethey are exclu- sives.
The process ofidentifying theOR groupsis asfollows.Firstly, we checktherelationshipsbetweeneachpairofnodes.Pairsthat haverequired,exclude,alternative,andANDdependenciesareig- nored.Allpairshavingtransitiverequiredependenciesarealsoig- nored. The reason for this exclusion is that these dependencies breaktheORone.Then,theremainingpairsofnodesareassigned anORdependency.Next,weanalyzethesepairsbytestingthere- lationoftheirnodes.Pairssharinganodeneedtoberesolved(e.g.
inFig.7,apairof(Com5-Com2,Com7)andapairof(Com5- Com2,Com3),whereCom5-Com2isasharednode).Thereso- lutionisbasedon therelationbetweentheother two nodes(e.g.
Com3andCom7).Ifthesenodeshavearequiredependency,then weselectthehighestnodeinthelattice(i.e.theparentcausesthe OR dependencyto itschildren).Ifthe dependencyis excluded or alternative, then we remove all OR dependencies(i.e. an exclude dependencyviolatesanORone).InthecaseofsharinganORde- pendency,the pairsare groupedtoone ORdependency.AND de- pendencywillnot occurinthiscaseaccordingtoAND definition.
Algorithm5 showstheprocedureofidentifyinggroupsofORde- pendency.
5.2. Identificationofdependenciesrelatedtooptionalcomponent distribution
These dependenciesreflect association rules betweenoptional components. Association rules refer to the frequency of co- occurrences between two groups of components. These can be used todiscover interesting correlationsbetweena largenumber ofoptionalcomponents.Forinstance,ifanarchitecturalconfigura-
tioncontains Component A andComponent B,it hasa probability of70%ofalsocontainingComponent CandComponentD.We rely onFPGrowthalgorithm(Hanetal.,2006)tominetheassociation rules. Eacharchitectural configurationis considered asa transac- tionandeach componentisanitem thatcanexistinsuchacon- figuration. For example, in Fig. 7, we see that ifa configuration containsCom1, Com2,andCom 4,there isa 100%probably that italsocontainsCom5.Inadditiontoassociationrules,werecover the ratioof componentoccurrences in theproducts (e.g.Compo- nentAhasoccurredin80%ofproducts).Thesecanbeusedtopro- vide informationaboutwhichcomponentsare frequentlyused in theproducts.Fig.7shows,forexample,thatCom6andCom3are presentrespectivelyin33%and67%oftheconfigurations.
6. Identificationofgroupsofvariability
Intheprevious steps,mandatory andoptionalcomponents,as wellasthedependenciesamongthemareidentified.However,un- derstanding a large number of dependencies is a challenge fac- ing software architects. Furthermore, some of these are overlap- pingdependencies.Thismeansthatmanydependenciesrepresent constraintsona sharedset ofcomponents(e.g.a componenthas an OR dependency with components having AND dependencies amongthemselves). Such dependencies need to be hierarchically representedin atree form, inorderto facilitatethe taskofsoft- warearchitects(e.g.similartofeaturemodel).
6.1. Variabilitybetweengroupsofdependencies
The idea isto identify dependenciesamong groupsof depen- dencies. Forexample,agroup ofcomponents holdingan alterna- tivedependency canhavean ORdependencywithanothergroup holdingan AND one. Toidentifythese dependencies, ourconsid- erations are as follows. Since an AND can be considered asone coherent entity,it is not allowed for its components to partially have internal dependencies, e.g. dependent through an OR with other groups. This implies that all components belonging to an AND group should have the dependency. For alternative and OR dependencies,itisallowed totake ANDonesasamember.Inad- dition,theinternal dependenciesbetweenalternativeandORde- pendenciesareallowed.Inotherwords,analternativedependency canbeamemberanORdependencyandviceversa.Accordingto that,theAND dependencyhasahighprioritytobe addedbefore theotherswhileORandalternativehavethesamepriority.
6.2.Theidentificationalgorithm
Algorithm6 describestheproceduretoidentifythehierarchi- caltree.Firstly,westartfromtherootofthetreeby directlycon- nectingallmandatorycomponentstoit.Atthisstage,thetreedoes not have a hierarchy. Then, we add optional components based ontheir relationships.Groupsofcomponents havingAND depen- dencies are added by creating an abstract node that carries out thesecomponents.Therelation betweentheparentandthe chil- dren is an AND dependency. Next, alternative dependencies are representedbyanabstractnodethatcarriesoutthesecomponents.
Next,ORdependenciesare appliedbyaddingan abstractnodeas aparent tocomponents havingan OR.In thecasewherethe re- lation is between a set of components having AND dependency as well as alternative dependency, the connection is made with their abstractnodes (i.e.the abstract nodescorresponding to the ANDdependency andthealternative one become childrenof the ORparent).Next,theremaining componentsaredirectlyaddedto therootwith optionalnotation. Finally,the cross-treedependen- ciesareadded(i.e.requiredandexcludeones).
Algorithm6:Identifyinghierarchicalrepresentation.
Input:SetsofDependencies
(OR,AND,Require,Exclude,Alternati
v
e)andMandatory andOptionalComponents(MC,OC)Output:ATree(tree)
$Addingmandatorycomponentstotherootnode$
tree.root.addChildren(MC);
$AddingANDgroupstotherootnode$
foreachand∈ANDdo tree.addChild(and);
end
$AddingORgroupstothetree$
foreachor∈ORdo foreachnode∈ordo
$CheckiftheORcontainsamembercomposedofan ANDgroup$
ifAND.isContiant(node)then
$RemovetheANDfromtherootandadditasa childintheOR$
tree.remove(node);
nodeOR.addChildren(node);
else
nodeOR.addChildren(node);
end
tree.addChild(nodeOR);
end end
$Addingalternativegroupstothetree$
foreachalt∈Alternati
v
edo foreachnode∈alt do$Checkifitisamemberinanyalreadyaddedgroup$
ifOR.isContiant(node)then break;
elseifAND.isContiant(node)then tree.remove(node);
nodeAlt.addChildren(node);
else
nodeAlt.addChildren(node);
end
tree.addChild(nodeAlt);
end end
$Addtherestofthecomponentsasoptional$
tree.addChildren(OC.getRemainingOptional());
$addcrosstreedependencies$
tree.addExcludeCrossTree(Exclude);
tree.addRequireCrossTree(Require);
returntree
7.Evaluationresults 7.1.Evaluationdesign
7.1.1. Datacollection
We select two sets ofproduct variants. Thesesets are Mobile Media2 (MM) andHealth Watcher3 (HW). We selectthese prod- uctsduetotheavailabilityoftheirsourcecodes,theavailabilityof architecturalmodelforMobile Media.Thisiswaytheywereused in many published research papers such as Tizzei et al. (2012); EyalSalman etal. (2015). Ourstudy considers 8 variants ofMM and10variantsofHW.MMvariantsmanipulatemusic,videoand
2Available at: http://ptolemy.cs.iastate.edu/design-study/#mobilemedia .
3Available at: http://ptolemy.cs.iastate.edu/design-study/#healthwatcher .
photoonmobilephones.Theyaredevelopedstartingfromthecore implementationofMM.Then, theotherfeatures areaddedincre- mentallyforeachvariant.HWvariantsareweb-basedapplications thataimatmanaginghealthrecordsandcustomercomplaints.The sizeofeachvariantofMMandHW, intermsofclasses,isshown inTable3.
7.1.2. Researchquestionsandevaluationmethod
Our evaluation aims to show how the proposed approach is applied to identifythe architecturalvariabilityand validatingthe obtainedresults. To thisend, we applied it to the collectedcase studies. We utilize the ROMANTIC approach (Kebir et al., 2012b) to extract architectural components from each variant indepen- dently. Then, the components derived from all variants are clus- teredtoidentifycomponentvariants.Next,weidentifythe archi- tecture configurations ofthe products that are used as a formal context toextract aconcept lattice. Then,we extract themanda- toryandoptionalcomponentsaswellasthedependenciesamong optional components.Next, we present the results of identifying groupsofvariability.Finally,weshowtheidentifiedvariability.
In order to evaluate the resulting architecture variability, we studythefollowingresearchquestions:
• RQ1: What is the accuracy of the recovered architectural variability? This research question focuses on measuring the precision of theresulting architecture variability. This isdone by comparing it with a pre-existing architecture variability model.
• RQ2: Arethe identified dependencies correct? Thisresearch questionaimstomeasurethecorrectnessoftheidentifiedcom- ponentdependencies.
7.2. Results
7.2.1. Component-basedarchitectureextraction
Table 4shows the resultsof component extractionfrom each productvariantindependently,intermsofthenumberofcompo- nents,foreachproductvariantofMMandHW.Wechecktheser- vicesprovidedbyeachgroupofclassesbasedontheirsourcecode documentation.The resultsshowthat classesrelatedtothesame service are grouped into the same component. The difference in thenumbersoftheidentifiedcomponentsineachproductvariant hasresultedfromthefactthateachproductvarianthasadifferent set of user requirements.On average, a product variantcontains 6.25and7.7mainservicesrespectivelyforMMandHW.
7.2.2. Identifyingcomponentvariants
Table5summarizestheresultsofcomponentvariantsinterms ofthenumberofcomponentshavingvariants(NOCV),theaverage numberof variantsof acomponent (ANVC), themaximumnum- ber ofcomponent variants(MXCV)and theminimum numberof componentvariants(MNCS).Theresultsshowthattherearemany setsofcomponentssharingmostoftheirclasses.Eachsetofcom- ponents mostly provides the same service. Thus, they represent variantsofthesamearchitecturalcomponent.Table6presentsan instance of 6 component variants identified from HW, where X means that the corresponding class is a member in the variant.
Byanalyzingthesevariants,itisclearthatthesecomponentsrep- resent the samearchitectural component. Inaddition to that, we noticedthat thereare somecomponentvariants havingthesame setofclassesinmultipleproductvariants.Forinternalcomponent variability,weprovidethelattice thatpresentsthedistributionof classescomposing the componentvariants,see Fig.11.From this lattice,wecannotethatthereare8commonclassesbetweenthe variants. These represent the implementation of shared services.
Table 3
Size of MM variants and HW ones.
Variant no. 1 2 3 4 5 6 7 8 9 10 Avg.
No. of classes in MM 25 34 36 36 41 50 60 64 X X 43 .25 No. of classes in HW 115 120 132 134 136 140 144 148 160 167 136 .9
Table 4
Component extraction results.
Variant no. 1 2 3 4 5 6 7 8 9 10 Avg. Total
No. of components in MM variants 3 5 5 5 7 7 9 9 X X 6 .25 50 No. of components in HW variants 6 7 9 10 7 9 8 8 7 6 7 .7 77
Fig. 11. The distribution of classes composing the component variants.
Table 5
Component variants identification.
Name NOCV ANVC MXCV MNCV
MM 14 3 .57 8 1
HW 18 4 .72 10 1
Additionally, thedistribution of variable classesis easy to recog- nize.Forexample,thedifferencebetweenVariant3andVariant6is thatVariant6hasanadditionalvariableclass(i.e.Connection).
7.2.3. Analyzingarchitectureconfiguration:communalityand variability
Theidentificationofcomponentvariantsallowstoidentifythe architecture configurations.Table7andTable8showrespectively the configuration of MM and HW variants, where X means that thecomponentisapartoftheproductvariants.Theresultsshow that the products are similar in their architectural configurations anddifferconsideringotherones.Thereasonbehindthesimilarity andthedifference isin thefact thattheseproducts are common in some of their userrequirements and variablein some others.
These architecture configurationsare used asaformal context to Fig. 12. The concept lattice of MM architecture configurations.
Table 6
Instance of 6 component variants.
Class Name Variant 1 Variant 2 Variant 3 Variant 4 Variant 5 Variant 6
BufferedReader X X X X X X
ComplaintRepositoryArray X X X X X X
ConcreteIterator X X X X X X
DiseaseRecord X
IIteratorRMITargetAdapter X X X X X X
IteratorRMITargetAdapter X X X X X X
DiseaseType X
InputStreamReader X X X X X X
Employee X X
InvalidDateException X X X X
IteratorDsk X X X X X X
PrintWriter X X X X X
ObjectNotValidException X X X
RemoteException X X X
PrintStream X X X
RepositoryException X X
Statement X X X X X X
Throwable X X X
HWServlet X
Connection X X
Table 7
Architecture configuration for all MM variants.
Variant No. Com 1 Com 2 Com 3 Com 4 Com 5 Com 6 Com 7 Com 8 Com 9 Com 10 Com 11 Com 12 Com 13 Com 14
1 X X X
2 X X X X X
3 X X X X X
4 X X X X X
5 X X X X X X X
6 X X X X X X X
7 X X X X X X X X X
8 X X X X X X X X X
Table 8
Architecture configuration for all HW variants.
Variant No. Com 1 Com 2 Com 3 Com 4 Com 5 Com 6 Com 7 Com 8 Com 9 Com 10 Com 11 Com 12 Com 13 Com 14 Com 15 Com 16 Com 17 Com 18
1 X X X X X X
2 X X X X X X X
3 X X X X X X X X X
4 X X X X X X X X X X
5 X X X X X X X
6 X X X X X X X X X
7 X X X X X X X X
8 X X X X X X X X
9 X X X X X X X
10 X X X X X X
extractthe concept lattice.We usethe ConceptExplorer4 tool to generatetheconcept lattice. We give the conceptlattices ofMM andHWrespectivelyinFig.12andFig.13.
InTable9,thenumbersofmandatoryandoptionalcomponents aregivenforMMandHW, together withexamplesoftheir asso- ciationrules andcomponentoccurrenceratios.An exampleofan association rule inMM is “when a configuration has Com5 and Com8, it is 86% likely to also contain Com 9”. The results show thattherearesomecomponentsthatrepresentthemandatoryar- chitecture,whilesomeothersrepresentoptionalcomponents.
7.2.4. Identifyingcomponentsdependencies
The resultsoftheidentificationofoptionalcomponentdepen- denciesare given in Table 10 and Table 11 respectively for MM andHW (Com 5from MM andCom 2, Com 3 fromHW are ex- cludedsince they aremandatory components). The dependencies
4Presentation of the Concept Explorer tool is available in Yevtushenko (20 0 0)
are represented between all pairs ofcomponents in MM (where R= Require, E= Exclude,O= OR,RB= Required By,TR = Transi- tiveRequire,TRB=TransitiveRequireBy,andA=AND).Table12 showsasummaryofMMandHWdependenciesbetweenallpairs ofcomponents.Thisincludesthenumberofdirectrequiredepen- dencies (NRC),the number of exclude ones (NE), the number of ANDgroups(NOA),andthenumberofORgroups(NO).Alternative dependencies are represented as exclude ones. The results show that therearedependenciesamongcomponentsthat helpthe ar- chitecttoavoidcreatinginvalidconfigurations.Forinstance,ade- signdecisionofANDcomponentsindicatesthatthesecomponents dependoneachother,thus,theyshouldbeselectedalltogether.
7.2.5. Identifyinggroupsofvariability
Basedontheidentifiedmandatoryandoptionalcomponentsas well as the dependencies among the optional ones, we use the
Fig. 13. The concept lattice of HW architecture configurations.
Table 9
Mandatory and optional components.
Product Name MM HW
Mandatory 1 2
Optional 13 16
Some Association Rules Com 5, Com 8 = > Com 9 : 86% Com 2, Com 3, Com 11 = > Com 6 : 100%
Com 1, Com 5 = > Com 8, Com 9 : 80% Com 2, Com 3, Com 4 = > Com 6 : 86%
Com 5, Com 12 = > Com 8, Com 9, Com 11 : 100% Com 2, Com 3, Com 12 = > Com 4, Com 6, Com 7, Com 11 : 100%
Some Component Occurrence Ratio Component Ratio Component Ratio
Com 8 80% Com 6 90%
Com 12 38% Com 7 50%
Com 4 12% Com 14 20%
Table 10
Component dependencies of MM.
Com 1 Com 2 Com 3 Com 4 Com 6 Com 7 Com 8 Com 9 Com 10 Com 11 Com 12 Com 13 Com 14
Com 1 X R E E O E E E
Com 2 X E A RB R TR A RB RB
Com 3 RB E X E E O E E E
Com 4 A E X RB R TR A RB RB
Com 6 E R E R X TR TR E R E E A A
Com 7 E RB RB TRB X R O RB TRB TRB
Com 8 TRB O TRB TRB RB X RB TRB TRB TRB TRB TRB
Com 9 E O R X RB TRB E E
Com 10 A E A RB R TR X RB RB
Com 11 O E TR R X RB E E
Com 12 E E TR TR R X E E
Com 13 E R E R A TR TR E R E E X A
Com 14 E R E R A TR TR E R E E A X
