1 / 79

Model Driven Product Line Engineering: Core Asset and Process Implications

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

Faraday
Download Presentation

Model Driven Product Line Engineering: Core Asset and Process Implications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related