Table Of ContentRoberto E. Lopez-Herrejon · Jabier Martinez ·
Wesley Klewerton Guez Assunção ·
Tewfik Ziadi · Mathieu Acher ·
Silvia Vergilio Editors
Handbook
of Re-Engineering
Software
Intensive Systems
into Software
Product Lines
Handbook of Re-Engineering Software Intensive
Systems into Software Product Lines
Roberto E. Lopez-Herrejon • Jabier Martinez (cid:129)
Wesley Klewerton Guez Assunção (cid:129) Tewfik Ziadi (cid:129)
Mathieu Acher (cid:129) Silvia Vergilio
Editors
Handbook of Re-Engineering
Software Intensive Systems
into Software Product Lines
Editors
RobertoE.Lopez-Herrejon JabierMartinez
ÉcoledeTechnologieSupérieure Tecnalia,BasqueResearchandTechnology
UniversiteduQuébec Alliance(BRTA)
Montreal,QC,Canada Derio,Spain
WesleyKlewertonGuezAssunção TewfikZiadi
PontificalCatholicUniversityofRiode SorbonneUniversités&CNRS-LIP6
Janeiro Paris,Paris,France
RiodeJaneiro,Brazil
JohannesKeplerUniversityofLinz
Linz,Austria
MathieuAcher SilviaVergilio
IRISA-Inria DepartamentodeInformática
InstitutUniversitairedeFrance(IUF)& FederalUniversityofParana(UFPR)
UniversityofRennes1 Curitiba,Brazil
Rennes,France
ISBN978-3-031-11685-8 ISBN978-3-031-11686-5 (eBook)
https://doi.org/10.1007/978-3-031-11686-5
©SpringerNatureSwitzerlandAG2023
Thisworkissubjecttocopyright.AllrightsarereservedbythePublisher,whetherthewholeorpartof
thematerialisconcerned,specificallytherightsoftranslation,reprinting,reuseofillustrations,recitation,
broadcasting,reproductiononmicrofilmsorinanyotherphysicalway,andtransmissionorinformation
storageandretrieval,electronicadaptation,computersoftware,orbysimilarordissimilarmethodology
nowknownorhereafterdeveloped.
Theuseofgeneraldescriptivenames,registerednames,trademarks,servicemarks,etc.inthispublication
doesnotimply,evenintheabsenceofaspecificstatement,thatsuchnamesareexemptfromtherelevant
protectivelawsandregulationsandthereforefreeforgeneraluse.
Thepublisher,theauthors,andtheeditorsaresafetoassumethattheadviceandinformationinthisbook
arebelievedtobetrueandaccurateatthedateofpublication.Neitherthepublishernortheauthorsor
theeditorsgiveawarranty,expressedorimplied,withrespecttothematerialcontainedhereinorforany
errorsoromissionsthatmayhavebeenmade.Thepublisherremainsneutralwithregardtojurisdictional
claimsinpublishedmapsandinstitutionalaffiliations.
ThisSpringerimprintispublishedbytheregisteredcompanySpringerNatureSwitzerlandAG
Theregisteredcompanyaddressis:Gewerbestrasse11,6330Cham,Switzerland
Foreword
Formorethan30years,IhavebeeninvolvedinSoftwareProductLineEngineering.
I started recording the good practices in a small department of Philips. These
practices were adopted by larger departments, which led to the development of
the platform presently in use everywhere in the company. We faced the same
problems that companies still encounter when moving towards Software Product
LineEngineering.Forthosewhowanttoembarkonthejourneyofre-engineering
systems into Software Product Lines, this book provides several approaches for
addressing some of these common issues. The focus of this book is on the
technical/architecturesideofthedevelopment.Irecognisemanyofthesepractices
and approaches within Philips as well as in other companies, which have been
pioneeredbymanypeople.
Inmyexperience,forsuccessfulintroductionofaSoftwareProductLineculture,
the Business, Architecture, Process, and Organisation (BAPO) dimensions need
to go in balance to ensure a good transition towards Software Product Line
Engineering. The Business dimension needs to address not only how to market
and sell the diverse products but also to select the right incentives for those that
do Software Product Line Engineering. Also, additional incentives need to be
selected for those that deliver internal value to the company but will not provide
endproducts.IntheArchitecturedimension,variabilityneedtobemanaged,from
requirementsuptotestinganddeployment.Goodmodelsareneededtoshowwhatis
availableandwhatcanbeadded.TheProcessdimensiondealswithallactivities,and
theirrelationships,thatneedtobedoneduringSoftwareProductLineEngineering.
TheOrganisationdimensiondealswiththemappingoftheprocessestotheofficial
andvirtualdepartmentsintheorganisation.Italsodealswithstrategiesforsoftware
outsourcing.
Over the years, I found it difficult to define what is a Product Line, although
I can explain what Software Product Line Engineering is. For me, the simplest
solutionistodefineaSoftwareProductLineastheoutcomeofaspecificinstance
ofSoftwareProductLineEngineering,whichinpracticeisacontinuouslyevolving
setofmoreorlesssimilarproducts.InthePhilipscase,ithasbeenevolvingoverthe
last 25 years. I have seen, several times, that Product Lines from different origins
v
vi Foreword
are merged into one. Because of this, I prefer to use the term “Software Product
Line Engineering” over “Software Product Line”. During the evolution of the
Philips’SoftwareProductLineEngineering,thewaytohandleitalsohasevolved.
In practice, it has been able to incorporate any new trend that was introduced
in software engineering. During this evolution, in the Business dimension, the
development moved from only a single platform team to the whole of Philips. In
the Architecture dimension, the platform was initially defined with components
and then moved to services. This service architecture allowed cloud and edge
processing, and introduced dependability solutions for the whole family. Parallel
to this architectural evolution, programming languages used in the platform also
changedfromObjective-CtowardsJava,C#,andPythonamongothers.Regarding
the Process dimension, agility and lean development was introduced. This meant
adopting extensive automated testing, and supporting maintenance with a logging
system and error prediction. In the Organisation dimension, we introduced inner
sourcedevelopmentthatbecamethemainwayofadaptingthecodebase.
In the following, I describe shortly my experience with Software Product Line
Engineering,illustratingitalongthewaywithexamplesoftheissuesaddressedin
thisbook.In1991,IbecameinvolvedinthePhilipstelecom-switchdepartmentin
Nürnberg,Germany,wheretheywantedtomodernisetheirwaytocreatesoftware.
Atthattime,theywantedtoknowwhetherobject-orienteddesignmightbeagood
idea for them or even if they were close to doing object-oriented development.
My impression was that they were not doing something related to object-oriented
design, but they included all best software engineering ideas of the 1970s and
1980sintheirdevelopmentprocess.Theyappliedallthesetechnologiestobeable
to deliver high dependable real-time systems in a niche market that had a large
amount of variety in number of subscribers, hardware configurations, legal rules,
and commercial requirements. In fact, they were doing Software Product Line
Engineering,evenbeforethattermwascoined.
The development at Phillips had the following characteristics: component-
oriented, aspect-oriented design with code generation for several dependability
aspects,plug-inarchitecture,call-backinterfaces,adigitaltwinofthehardwareand
softwareconfigurationtosupporterrormanagement,maintenance,reconfiguration,
and load balancing. Note that many of these terms were not yet coined in 1991.
The development was largely supported by the use of CHILL, at that time, a
common programming language in the telecommunications domain. The modular
structureoftheprogramsmakesiteasytodevelopcomponentsasseparateentities
for development, testing, and deployment, a critical aspect of their development.
Althoughthedevelopmentwasnotobject-oriented,weevaluatedithigher,because
of the aspects mentioned above, which were not easily available in the object-
oriented languages at that time. Of course, if they wished they could have used
object-orientation in parts of the development, because it was possible to have a
CHILLmoduleborderaroundforeignlanguagecode.However,werecommended
nottodosobecausethatwouldnotgivealotofprofit.
AvariabilitymodelwascrucialforthedevelopmentofPhillips’system.Inthis
system, the variability model was captured in the digital twin, which in turn was
Foreword vii
configuredfromageneratedscriptforitsinitialisation,andthatwasactiveatruntime
fordescribingtheactualvariant.Errormessagescouldalterthestatusofthetwin,
leading to repair functions. There was a global model that described all possible
configurations,andeachrunningsystemhaditsownrunningmodels.Therunning
models describe, in their own terminology, the abstract resources in the system.
Theglobalmodeldescribedmainlytheplug-inpointstobeused(variationpoints).
Each one was called a generic resource, and there was a list of actual resource
componentsthatcouldbeplugged-in,constructinginthiswaythepossiblesystem
variants.Theglobalmodelwastheoriginofthedevelopmentofnewsystems.First,
thecomponentsalreadyavailablewereselected,andthen,thedecisionwastakenon
whatnewcomponentstodevelop.Oncecompleted,thespecificmake-fileofvariant
wasautomaticallygeneratedbasedonthesedecisions.
Two years later, Philips decided to sell to telecommunication department to
AT&T (later AVAYA). This means that we lost contact with the developers after
that. However, we have captured enough knowledge to introduce product family
engineering, as we called it at that time, in another department. We started with
the TV-set development, which was a very important product for Philips, and that
involved a large variety in the systems. The development at that time was based
offormalmethods(COLD)andcodegeneration.Themostimportantimprovement
was the creation of components, and the definition of ways for combining them
differently. The variability model was part of the formal description. There was
massivecodegeneration,notonlytoensurethatthesystemwasbuildaccordingto
the chosen variant but also to ensure enough performance. Notably, the variability
modeldescribedthecouplingofthecomponents,andthecodegenerationremoved
the majority of indirections in calls. Until Philips sold the TV-set development
departmentin2010,thisSoftwareProductLineEngineeringwasinuse.
In 1997, we started to introduce Software Product Line Engineering in the
medicaldepartmentofPhilips.Thisgroupprovidedsupportingsoftwareformedical
image processing and transfer. They transformed their software into a platform
to be used by departments that applied medical image processing. Initially, a set
of core components were defined and a road map was set to incorporate more
softwareintocomponents.Thearchitecturewassetupinawaythatfacilitatedplug-
in components, and also required for separate interfaces for different development
aspects, some related to dependability. In about 8 years, all software was either
transformed or rewritten into the new format. Of course, also new software was
added, mainly related to dependability aspects, Internet access, and interchange
standards and requests from new departments using the platform. Because of
requests made by several departments, the architecture needed to be able to work
in a service-oriented environment. At the same time, experiments were done to
introduceopensourceindevelopmentandproducts,andalsoopensourcepractices
in the Process dimension. This led to “inner source” development within Philips.
Allplatformsourceswereopeninthecompany,thusanybodywhoneededachange
coulddoitontheirown.
Of course management was involved to set the right priorities. This decision
enabled people from separate departments to form short-term virtual teams to
viii Foreword
address specific software needs. By that time, agility and lean development were
introduced.Theirintroductionwaseasedbytheexistinginnersourcedevelopment
as this can easily be done in an agile way. In the meantime, Philips was moving
manyproductdivisionsoutofthecompany,butthemedicaldepartmentremained.
Sincethen,theplatformbecamethestandardwayofdevelopingandusingsoftware
in Philips. The architect that started the first architecture in 1997 is still in Philips
as“Chiefarchitect”.Duringthiswholeevolution,Philipsacquiredmanycompanies
inthemedicaldomain.Allhadtheirownsoftwarearchitecture.Sooneofthefirst
steps in integrating them was to ensure that they were merged efficiently into the
productlinebusiness,architecture,processes,andorganisation.Thisalwaysledto
animportantstepintheevolutionofthearchitectureandplatform.
Forthereadersofthebook.MyconvictionisthatSoftwareProductLineEngi-
neeringispresentlythebestwayofdevelopingsoftwareforasetofproducts.My
experience is that it can incorporate almost all new trends in software engineering
but still stay strong because of its focus on variability and the ways to manage
and implement it. If you plan to transform your development into a product line
engineering,thebenefitswillallowprofitsinthefuture,byreducingtheengineering
effort.Therearenospecificroadblocks,asSoftwareProductLineEngineeringcan
deal with many different development styles, architectures, languages, etc. Only,
if you are not dealing with enough variability, a move towards Software Product
Line Engineering may not pay off. However, in all the cases, plan well and make
future-proof decisions on the architectures. Ensure the availability of future-proof
interfaces,andinvolvetheBusinessdimensionatanearlypoint.Finally,Iencourage
youtoapplythetechnologiespresentedinthisbookatthemomentyouencounter
therelatedproblems.
Eindhoven,theNetherlands FrankvanderLinden
February2022
Preface
Software Product Lines (SPLs) are families of systems that share common assets
allowing a disciplined software reuse. The adoption of SPLs practices has been
showntoenablesignificanttechnicalandeconomicbenefitsforthecompaniesthat
employ them. However, successful SPLs rarely start from scratch. Instead, they
usuallystartfromasetofexistinglegacysystemsthatmustundergoawell-defined
re-engineeringprocess.
Manyapproachestoconductsuchre-engineeringprocesseshavebeenproposed
anddocumentedintheliterature.Thishandbookistheresultofthecollectivecom-
munity expertise and knowledge acquired in conducting theoretical and empirical
research alsoinpartnership withindustry. The topic discussedinthis handbook is
a recurrent and challenging problem faced by many companies. Conducting a re-
engineering process could unlock new levels of productivity and competitiveness.
Thechapterauthorsareallexpertsindifferenttopicsofthere-engineeringprocess,
which brings valuable contributions to the content of this handbook. Additionally,
organizingtheinternationalworkshoponREverseVariabilityEngineering(REVE)
has contributed to this topic during the last decade. REVE has fostered research
collaborations between Software Re-engineering and SPL Engineering (SPLE)
communities. Thus, this handbook is also a result of our expertise and knowledge
acquiredfromthefruitfuldiscussionswiththeattendantsofREVE.
Ourhandbookaimstobringtogetherintoasingle,comprehensive,andcohesive
reference the wealth of experience and expertise in the area of re-engineering
softwareintensivesystemsintoSPLs.Wecovertheentirere-engineeringlife-cycle,
fromrequirementsgatheringtomaintenanceandevolutiontasks.Also,weprovide
futuredirectionsandperspectives.Thehandbookistheresultofourcollectiveeffort
over the last 3 years. It underwent a rigorous and careful selection and edition
process. The selected contributors are worldwide experts in their field, and all
chapterswerepeerreviewed.
ix
x Preface
What Is This Handbook About?
The scope of the book includes different aspects of re-engineering software
systemsintoSPLs:processesandactivitiesinvolved,techniques,supporttools,and
empiricalstudiesrelatedtoextractionorrefinementofSPLs.
The handbook comprises four parts with a total of 20 chapters divided as
illustrated in the next figure. The first part, Feature Location and Variability
Model Extraction (Chaps. 1–7), focuses on a core aspect of SPLE and the re-
engineering process, related to the variability management and mining existing
assets. This part gathers an assemble of approaches based on different techniques.
Chapter 1 describes an Information Retrieval (IR) approach for feature location
fromvariants.TheapproachesdescribedinChaps.2and3arebased,respectively,
on natural language requirements and software version history slicing. Chapter 4
introducesapproachesforfeaturelocationinmodels,byusingaGeneticAlgorithm
atdesigntime,andarchitecturalmodelsandIRatruntime.Synthesisofvariability
models is addressed in Chaps. 5 and 6, which describe, respectively, a multi-
objective optimization approach for reverse engineering of feature models and a
FormalConceptAnalysisapproachforextractingcomplexvariabilityrelationships
from non-boolean descriptions. The approach of Chap. 7 uses Machine Learning
to prevent the derivation of invalid products through the synthesis of feature
constraints.
Part I Part II
Feature location and Re-engineering
variability model product line
Part IV
extraction architectures
Chapters 1-7 Chapters 8-12
Perspectives
Part III
Frameworks
Chapters 13-17 Chapters 18-20
The second part, Re-engineering Product Line Architectures (Chaps. 8–12),
focuses on the extraction of SPL architectures (SPLAs) from existing software
variants. Chapter 8 discusses challenges and good practices proposed in the state
oftheartoftheSPLAextraction.TheapproachofChap.9allowsthegenerationof
UML models to represent the SPLA, such as class diagrams. Chapter 10 presents
astudyforextractionandevolutionofasoftwareproductlinefromexistingWeb-
based systems.Chapter 11 describes an approach to extract amicroservices-based
product line that combines the feature diagram with the UML class diagram from
existingsystemstodesignthearchitecture.TheapproachofChap.12exploresideas
oftraditionalsoftwarearchitecturalrecoveryfortheSPLcontext.
