Handbook of Re-Engineering Software Intensive Systems into Software Product Lines PDF
Preview Handbook of Re-Engineering Software Intensive Systems into Software Product Lines
Roberto 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.
The list of books you might like
