UML-Based Software Product Line Engineering with SMarty

517 Pages·2023·38.621 MB·English

by  Edson OliveiraJr

Edson OliveiraJr   Editor
UML-Based
Software
Product Line
Engineering
with SMarty
UML-Based Software Product Line Engineering
with SMarty
Edson OliveiraJr
Editor
UML-Based
Software
Product Line
Engineering
with SMarty
Editor
EdsonOliveiraJr
InformaticsDepartment
StateUniversityofMaringá
Maringá,Paraná,Brazil
ThisworkwassupportedbyCAPES,CNPq,AraucáriaFoundationofParaná,andUEM
ISBN978-3-031-18555-7 ISBN978-3-031-18556-4 (eBook)
https://doi.org/10.1007/978-3-031-18556-4
©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
v
This publication incorporates portions of “A Framework for Software Product
Line Practice, Version 5.0” by Linda M. Northrop and Paul C. Clements with
Felix Bachmann, John Bergey, Gary Chastek, Sholom Cohen, Patrick Donohoe,
Lawrence Jones, Robert Krut, Reed Little, John McGregor, and Liam O’Brien,
DM-0004601 (c) 2009–2012 Carnegie Mellon University, and “Feature-Oriented
DomainAnalysis(FODA)FeasibilityStudy”byKyoC. Kang,SholomG.Cohen,
JamesA.Hess,WilliamE.Novak,andA.SpencerPeterson,CMU/SEI-90-TR-21,
(c) 1990 Carnegie Mellon University, with special permission from its Software
EngineeringInstitute.
ANY MATERIAL OF CARNEGIE MELLON UNIVERSITY AND/OR ITS
SOFTWARE ENGINEERING INSTITUTE CONTAINED HEREIN IS FUR-
NISHEDONAN“AS-IS”BASIS.CARNEGIEMELLONUNIVERSITYMAKES
NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY
OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR
RESULTSOBTAINEDFROMUSEOFTHEMATERIAL.CARNEGIEMELLON
UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH
RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT
INFRINGEMENT.
This publication has not been reviewed nor is it endorsed by Carnegie Mellon
UniversityoritsSoftwareEngineeringInstitute.
ArchitectureTradeoffAnalysisMethod(cid:2),ATAM(cid:2)andCarnegieMellon(cid:2)are
registeredintheU.S.PatentandTrademarkOfficebyCarnegieMellonUniversity.
To mylittlebear Beatriz.
Foreword
Introduction
Iwaspleasedtobeaskedtowriteaforewordforthisbookonsoftwareproductlines.
Software product lines and product line engineering emerged from the software
reuseandgenerativeprogrammingmovementsofthe1970s.Fastforwardtotoday,
product lines are ubiquitous. We can think of them as a highly developed, high-
payoff, and industry-relevant way to build variability-intensive (or configurable)
systems.Intoday’scompetitiveandfast-pacedmarketswhereusersexpectsoftware
to adapt to their specific needs, most modern software-intensive products and
services implement ideas and concepts that were first enabled through product
line engineering. Several chapters in this book cover the fundamental principles
of the field. However, deciding what a “highly configurable” system should do,
architecting and designing it, modeling it for different stakeholders, building and
deployingit,andevolvingitovertimearestillchallengingactivities.Thechapters
ofthisbookalsoaddressthesechallengesinvariousways.Inthisforeword,Iwant
totaketheopportunitytobrieflyexploresomeofthenon-technicalchallengesthat
arisewhendevelopingandmaintainingsuchsystems.Ialsowanttobrieflycontrast
productlineresearchandpractice.
ProductLines and“Value”
ThefirstchallengeIwanttodiscussisvalue.Whileproductlinespromise“value”
(e.g.,lesspainfuldevelopmentandmaintenanceofsoftwareproductsandservices
that share commonalities), it may be worth reflecting on what “value” (and, for
the sake of completeness, “waste”) means for different types of stakeholders. In
general, product lines promise a reduction in developmentand maintenance cost,
henceproviding“value”todevelopersinthesensethattheycancompletetheirtasks
inshortertimeandatlowercosts.Thisontheotherhandalso provides“value”to
ix
x Foreword
endusersandcustomerswhopotentiallygetsoftwareproductsandservicesfaster
andcheaper.Regarding“waste”insoftwaredevelopment,Sedanoandcolleagues1
identifiedninetypesofwaste:buildingthewrongfeatureorproduct,mismanaging
the backlog, rework, unnecessarily complex solutions, extraneous cognitive load,
psychologicaldistress,waiting/multitasking,knowledgeloss, andineffectivecom-
munication.Productlineshelp reducesome of these typesof waste. For example,
they reduce building the wrong product since product lines reuse proven features
acrossdifferentproductinstances.Ontheotherhand,productlinesmayintroduce
complexityandincreasecognitiveload,inparticularforlessexperienceddevelopers
whojoinanewproject.Propermodelingtoolsandtechniquesandlanguageslikethe
UnifiedModelingLanguage(UML)canhelpdevelopersrepresentandreasonabout
variabilityandproductlinedesigntoreducethistypeofwaste.Thisbookincludes
some chapters that present approaches that aim at reducing waste and increasing
valueduringproductlineengineering.
We can also look at “value” from a broader perspective and think beyond
business,economic,andtechnicalvalue.Valuecanthenalsoincludebroaderhuman
values, such as compassion, social responsibility, and justice.2 The question then
becomes how a software-intensive system built for different products or services
withinamarketsegmentortechnologydomaincansatisfythevaluesofstakeholders
ofthosedifferentproductsandservices.Orshouldweassumethatallstakeholders
within a market or domain agree on broader values their software should comply
with?
Modern ProductLines with Data-Driven Capabilities
The second challenge I want to discuss is somewhat related to the previous one.
Modern software systems (including productlines) are often “data-intensive” and
rely on artificial intelligence (AI) capabilities and related technologies, such as
machinelearning.Forthesesystems,ethicalconsiderationsbecomefirst-classciti-
zens.Infact,fromasoftwareengineeringpointofview,ethicalconsiderationscould
be considered “non-functional” requirements. Think of Tesla’s models Model S,
ModelX,Model3,andModelYwhichcouldallbeconsideredsoftware-intensive
systems that process huge amounts of data. Tesla vehicles’ software is regularly
updated via wireless Internet connections when new software versions become
available.Tesla alsoofferstheoptiontounlockfeaturesafterpurchase(e.g.,basic
“Autopilot,” “Full Self-Driving”). The software deployed across models could be
1T.Sedano,P.Ralph,C.Péraire,Softwaredevelopmentwaste,in:Proc.InternationalConference
onSoftwareEngineering,ICSE,2017,pp.130–140.
2H.Perera, W.Hussain,J.Whittle,A.Nurwidyantoro,D.Mougouei,R.A.Shams,G.Oliver,A
study on the prevalence of human values in software engineering publications, 2015–2018, in:
Proc.InternationalConferenceonSoftwareEngineering,ICSE,2020,pp.409–420.
Foreword xi
consideredaproductline.Also,thesoftwareusedinsuchcarshandlestremendous
amounts of data, and inappropriate access can compromise an individual’s safety
and privacy. Therefore, questions related to data governance are important, and
developersneedto considermanynon-technicalarchitecturaldecisionsduringthe
designoftheproductlinerelatedtoalargerdata(retention)lifecyclemanagement
process, and how and where the data will be collected, processed, preserved,
archived,versioned,ordeleted.Therefore,anyproductline in emergingand data-
intensivedomainsneedstoensurethatproductinstancessupporttransparency(i.e.,
understandingthedataandhowalgorithmschangethedata).
ProductLineResearch Versus ProductLinePractice
ThelastchallengeIwouldlike to touchonis aboutthe relevanceofproductlines
andproductlineresearch.Industry-academiacollaborationinsoftwareengineering
andtherelevanceofsoftwareengineeringresearchingeneralhavebeendiscussed
overmanyyears.Thisisnotdifferentforthefieldofsoftwareproductlines.Product
line engineering as a discipline started from joint initiatives of applied research
in academia, industry research, and software engineering practice (see, for exam-
ple, early industry initiatives driven by Carnegie Mellon’s Software Engineering
Institute (SEI) and industry-driven research projects in Europe in the early days
of product line engineering).3 Interestingly, investigations into what product line
researchers and practitioners find interesting found that topics that practitioners
think are relevant and emerging have often already been well researched.4 This
means,weasacommunityofacademicsandresearchersneedtodoabetterjobpre-
sentingandcommunicatingourworktopractitioneraudiences.Furthermore,when
welookatactualproductline researchpublishedbypractitionersandresearchers,
it seems that practitioners (unlike academic researchers) are more interested in
architectingandarchitecture-relatedissuesofproductlines.5Therefore,itisgreatto
seethatthisbookfeatureschaptersonmodelingthatalsoincludepracticalexamples
toillustratethereal-worlduseofproposedconceptsandideas.
3K.Schmid, R.Rabiser, M.Becker, G.Botterweck, M.Galster, I.Groher, D.Weyns, Bridging
thegap:voicesfromindustryandresearchonindustrialrelevanceofSPLC,in:Proc.25thACM
InternationalSystemsandSoftwareProductLineConference,SPLC,2021,184–189.
4R.Rabiser,K.Schmid,M.Becker, G.Botterweck,M.Galster,I.Groher,D.Weyns,Industrial
andAcademicSoftwareProductLineResearchatSPLC:PerceptionsoftheCommunity,in:Proc.
23rdInternationalSystemsandSoftwareProductLineConference,SPLC,2019,189–194.
5R.Rabiser,K.Schmid,M.Becker,G.Botterweck,M.Galster,I.Groher,D.Weyns,Astudyand
comparisonofindustrialvs.academicsoftwareproductlineresearchpublishedatSPLC,in:Proc.
22ndInternationalSystemsandSoftwareProductLineConference,SPLC,2018,14–24.
xii Foreword
ConcludingRemarks
This book contains many interesting chapters on the design, implementation,
and maintenance of software product lines. It focuses on how Stereotype-based
ManagementofVariability(SMarty)canbeusefultodesign,develop,andmaintain
software product lines. SMarty offers a UML profile and process to manage
variabilityandtorepresentasoftwareproductline.
I do hope that you find the chapters helpful in your own practice and research
to understand and develop next-generation software-intensive systems. Although
greatprogresshasbeenmade,westillstrugglewithbuildinghigh-qualitysoftware
systems “for the real world” that provide true value to users while remaining
maintainableovertheirlifetime.
UniversityofCanterbury,Christchurch,NewZealand MatthiasGalster
February2022