Feature diagram är ett populärt sätt att dokumentera variabilitet i programvara produktlinje teknik. När vi undersökte funktionsdiagram i litteraturen och från industrin, observerade vi att samma modellering begrepp används för att dokumentera två olika typer av variabilitet: (1) produktlinjevariabilitet, som återspeglar beslut av produkthantering om hur de system som hör till produktlinjen bör variera, och (2) programvara variabilitet, som återspeglar förmågan hos återanvändbara produktlinje artefakter att anpassas eller konfigureras. För att reda ut variabilitetsdokumentationen följer vi tidigare förslag om att relatera ortogonala variabilitetsmodeller (OVM) till funktionsdiagram. Detta papper återanvänder en befintlig formalisering av funktionsscheman, men introducerar en formalisering av OMMs. Sedan formaliseras också relationerna mellan de två typerna av modeller. Förutom en exakt definition av språken och länkarna, är den viktiga fördelen med denna formalisering att den fungerar som en grund för ett verktyg som stöder automatiserat resonemang om variabilitet. Detta verktyg kan t.ex. analysera om produktseriens artefakter är tillräckligt flexibla för att bygga alla system som ska tillhöra produktserien. Många industrisektorer står inför utmaningen att tillfredsställa den ökande efterfrågan på individanpassade programvarusystem och programvaruintensiva system. Programvaran produktlinje (PL) engineering paradigm (SPLE, se [24]) har visat sig ge organisationer för att utveckla en mångfald av liknande system till lägre kostnad, på kortare tid, och med högre kvalitet jämfört med utvecklingen av enskilda system [24]. Nyckeln till SPLE är att utnyttja de gemensamma egenskaperna hos de system som tillhör PL och att hantera variationen (dvs. skillnaderna) mellan dessa system. Gemensamma egenskaper är egenskaper och kvaliteter som delas av alla system i PL [14], t.ex. alla mobiltelefoner låter användare ringa samtal. I SPLE kan två typer av variabilitet urskiljas: Programvarans variabilitet och PL-variabilitet. Variabilitet i programvara avser "möjligheten hos ett programvarusystem eller artefakt att effektivt utökas, ändras, anpassas eller konfigureras för användning i ett visst sammanhang" [31]. Denna typ av variabilitet är väl känt från utvecklingen av enskilda system. Som exempel, en abstrakt Java super-klass tillåter olika specialiseringar att användas där superklassen används; ett gränssnitt tillåter olika implementationer att väljas. PL variabilitet [14, 24, 21 ] är specifik för SPLE och beskriver variationen mellan de system som tillhör ett PL när det gäller egenskaper och kvaliteter, såsom funktioner som tillhandahålls eller krav som uppfylls. Det är viktigt att förstå att definiera PL variabilitet, dvs. bestämma vad som bör variera mellan systemen i ett PL och vad som inte bör, är ett uttryckligt beslut om produkthantering (se [21, 24] ). Som ett exempel kan produkthanteringen ha beslutat att mobiltelefonerna i deras PL antingen skulle erbjuda GSM eller UMTS-protokollet. En utmanande uppgift i SPLE är att kartlägga PL-variabiliteten till programvariabilitet. Detta innebär att de återanvändbara artefakter från vilka PL:s system byggs (s.k. kärntillgångarna, som utgör PL-plattformen [24]) bör konstrueras tillräckligt flexibelt för att möjliggöra ett effektivt och ändamålsenligt byggande av dessa system [18, 26]. Detta problem kan ses som ett exempel på problemet med krav på formgivning i SPLE-sammanhang. Beslut att vara 15:e IEEE International Requirement Engineering Conference
Dessutom Metzger et al. formaliserade ortogonala variabilitetsmodeller som ett instrument för produkthantering och funktionsmodeller för att uttrycka mjukvaruvariabilitet REF.
Disambiguating the Documentation of Variability in Software Product Lines: A Separation of Concerns, Formalization and Automated Analysis
{'venue': '15th IEEE International Requirements Engineering Conference (RE 2007)', 'journal': '15th IEEE International Requirements Engineering Conference (RE 2007)', 'mag_field_of_study': ['Computer Science']}