Model Driven Product Line Engineering: Core Asset and Process Implications

1. Model Driven Product Line Engineering:Core Asset and Process Implications Maider Azanza supervisedbyProf. Dr. Oscar Díaz Onekin Research Group Department of Computer Languages and Systems University of theBasque Country San Sebastian – February 28th, 2011

2. Context The software industry remains reliant on the craftsmanship of skilled individuals engaged in labor intensive manual tasks. Greenfield and Short, 2003

3. Context • ModelDrivenEngineeringandSoftware Product Line Engineering. ModelDrivenand Software ProductLinesin Google BooksNgramViewer (1990 – 2008)

4. General Problem ProcessImplications CoreAssetImplications MODEL DRIVEN PRODUCT LINE ENGINEERING MODEL DRIVEN ENGINEERING SOFTWARE PRODUCT LINE ENGINEERING

5. ThisThesis

6. Outline • Background • CoreAssetImplications • ProcessImplications • Conclusions and FutureWork

7. Background

8. Metamodel Model Driven Engineering (MDE) • Models are the primary artifact • Models are abstractions of reality • Models conform to metamodels • Models are transformed abstractedIn REALITY transformation

9. Software ProductLine Engineering • Precursors: McIlroy 60s, Parnas 70s • Definition • “A software product line is a set of software-intensive systems, sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way” [Clements 2001] • A Software Product Line… • (1) Set of products “SPL is a set of software-intensive systems..” • (2) Features“..sharing a common, managed set of features..” • (3) Domain “..that satisfy the specific needs of a particular market segment or mission..” • (4) Core Assets “..are developed from a common set of core assets..” • (5) Production Plan “..in a prescribed way.”

10. Feature Oriented Software Development • Feature Oriented Software Development(FOSD) • paradigm for creating software product lines • programs are synthesized by composing features • features • are not only increments in program functionality • are building blocks of products (i.e., core assets) • are realized by a set of artifacts • products • are differentiated by their features • different compositions of features yield different products f1 f2 f3 f4 f3 f1 f2 f4

11. Core Asset Implications

12. Context • ModelDrivenProduct Line Engineering • Models are createdincrementally f3 product 3 product 2 product 1 f1 f2 base f1  base base f3 f2 f4

13. The Problem • Remember: SPL productsmustconformtotheir metamodel. Features are transformations (model to model maps)

14. This Thesis

15. Outline • Background • CoreAssetImplications • Case Study • FeatureRealization • FeatureComposition • Assessment • ProcessImplications • Conclusions and FutureWork

16. Case Study: Questionnaires

17. Case Study: CSS Product Line Crime and Safety Survey Belongs to Minority* Female Age Belongs to Minority* Female choose1 Adult Minor Adult Minor * Ethnic, religiousorregarding sexual orientation

18. Outline • Background • CoreAssetImplications • Case Study • FeatureRealization • Whatis a Feature? • How are FeaturesRealized? • A MetamodelforFeatures • FeatureComposition • Assessment • ProcessImplications • Conclusions and FutureWork

19. Whatis a Feature? Female base Questionnaire Female Base Questionnaire • Features are endogenoustransformations • samesource and target metamodel

20. Whatis a Feature? Female Minority Minor Adult DomainEngineer • Featureshavebeenpreplanned • are designedtobe compatible, composable

21. How are FeaturesRealized? MinorFeatureusingRubyTL Usingtransformationlanguages

22. How are FeaturesRealized? MinorFeatureusing a Model Delta 2. Usingmodel deltas

23. How are FeaturesRealized? = ModelTransformation Model Delta

24. A MetamodelforFeatures • Premise: Deltas do notneedtofulfilallmetamodel’sconstraints 1 Minor Feature QuestionnaireMetamodel

25. A MetamodelforFeatures

26. Createdbyremovingconstraintsfromtheproductmetamodel DomainEngineers decide whichconstraintstoremove. Delta Metamodel ProductMetamodel A MetamodelforFeatures

27. Createdbyremovingconstraintsfromtheproductmetamodel Alldiscardedconstraintsshouldbechecked once thecomposedmodel has beencreated. Delta Metamodel ProductMetamodel A MetamodelforFeatures FaultyProducts

28. Outline • Background • CoreAssetImplications • Case Study • FeatureRealization • FeatureComposition • CompositionDefinition • CompositionRealization • Assessment • ProcessImplications • Conclusions and FutureWork

29. FeatureComposition base f1 f3 product 1 How are deltas composed? ● ● = product 1 Features as transformations Features as model deltas

30. Notrandommodels Modelsdesignedtobecomposed ModelDelta Compositionin SPLs • MAB = Compose (MA, MB, CAB) • MA, MB and MAB conformtothesameMM. • i.e., thedelta metamodel • MA and MB are designedtobecomposed. • Sameobjectorganization • Samenamingconventions (identifierbased CAB)

31. Generic vs. DomainSpecificComposition

32. GenericComposition

33. GenericComposition: Objects • Superimpositionbyidentifier.

34. GenericComposition: Attributes • If a1=nullor a2=nullor a1=a2  non nullvalue • Otherwise  error

35. GenericComposition: References • Unionwithoutduplicates.

36. DomainSpecificComposition

37. Domain-SpecificComposition: Time • SUM isliabletobereusedin otherdomains. sum 10’ 20’ 30’ sum

38. Domain-SpecificComposition: Acknowledgments concat concat • CONCAT alsoliabletobereused.

39. CompositionRealization

40. CompositionRealization Generic: MetamodelAgnostic DomainSpecific: Reusable Can compositionimplementationbegenerated? Metamodel Comp. Code

41. CompositionSpecification

42. CompositionSpecification

43. CompositionGeneration

44. GenericCompositionGeneration ruleMergeQuestion mergel:Left!Question withr:Right!Question into t:Target!Question extendsMergeObject { t.text:=l.text.defaultAttributeMerge (‘text’,r.text); --CodeOmitted } Metamodel GeneratedCode

45. DomainSpecificCompositionGeneration ruleMergeQuestionnaire mergel:Left!Questionnaire withr:Right!Questionnaire intot:Target!Questionnaire extendsMergeObject { t.title:=l.title.defaultAttributeMerge (‘title’,r.title); --CodeOmitted t.acknowledgments:= l.acknowledgments+ r.acknowledgments; t.time:=l.time+r.time; } Metamodel GeneratedCode

46. DomainSpecificCompositionGeneration ruleMergeBlock mergel:Left!Block withr:Right!Block into t:Target!Block extendsMergeObject { varlsb: new Target!Block; varrsb: new Target!Block; lsb.title:=l.title; lsb.implements:=l.implements; rsb.title:=r.title; rsb.implements:=r.implements; --CodeOmitted } Metamodel GeneratedCode

47. Outline • Background • CoreAssetImplications • Case Study • FeatureRealization • FeatureComposition • Assessment • ProcessImplications • Conclusions and FutureWork

48. Assessment – Case Studies

49. Process Implications

50. Context • MostDevelopment in MDPLE isAssembly • Application developers will build about 30% of each application. The remaining 70% will be supplied by ready-built vertical and horizontal components. Greenfield and Short, 2003 C1 C2 C4 C3 Assembly Program Result Application