1. 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

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

3. Maider Azanza Context 3 Model Driven and Software Product Lines in Google Books Ngram Viewer (1990 – 2008) Model Driven Engineering and Software Product Line Engineering.

4. Maider Azanza General Problem 4 MODEL DRIVEN ENGINEERING SOFTWARE PRODUCT LINE ENGINEERING MODEL DRIVEN PRODUCT LINE ENGINEERING Process Implications Core Asset Implications

5. Maider Azanza This Thesis Core Asset Implications Feature Oriented Software Development Reuse Early Consistency Checking Process Implications Assembly Processes Reuse Abstraction Level Raise 5

6. Maider Azanza 6 Outline Background Core Asset Implications Process Implications Conclusions and Future Work

7. Background

8. Maider Azanza 8 1.Models are the primary artifact 2.Models are abstractions of reality 3.Models conform to metamodels 4.Models are transformed Model Driven Engineering (MDE) REALITY abstractedIn Metamodel transformation

9. Maider Azanza 9 Software Product Line 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. Maider Azanza 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 f3 f4f2f1 f2 f4

11. Core Asset Implications

12. Maider Azanza product 3product 2 f2 base 12 Model Driven Product Line Engineering Models are created incrementally Context f1 f2 f3 f4 base f1 base product 1

13. Maider Azanza The Problem Features are transformations (model to model maps) 13 How are features realized? How are features composed? Remember: SPL products must conform to their metamodel.

14. Maider Azanza 14 This Thesis Feature Realization Realizes features as model deltas models that contain the additions a feature makes to a model. Feature Composition Defines a composition algorithm for model deltas Handles domain-specific composition needs Composition Reuse Generates composition implementation Defines metamodel annotations to handle domain- specific composition algorithms

15. Maider Azanza 15 Outline Background Core Asset Implications Case Study Feature Realization Feature Composition Assessment Process Implications Conclusions and Future Work

16. Maider Azanza 16 Case Study: Questionnaires

17. Maider Azanza Case Study: CSS Product Line 17 Crime and Safety Survey FemaleAge Adult Minor choose1 Belongs to Minority* * Ethnic, religious or regarding sexual orientation Female Adult Minor Belongs to Minority*

18. Maider Azanza 18 Outline Background Core Asset Implications Case Study Feature Realization –What is a Feature? –How are Features Realized? –A Metamodel for Features Feature Composition Assessment Process Implications Conclusions and Future Work

19. Maider Azanza What is a Feature? Features are endogenous transformations same source and target metamodel 19 Female Base Questionnaire Female base Questionnaire

20. Maider Azanza What is a Feature? Features have been preplanned are designed to be compatible, composable 20 Domain Engineer FemaleMinority MinorAdult

21. Maider Azanza How are Features Realized? 1.Using transformation languages 21 Minor Feature using RubyTL

22. Maider Azanza How are Features Realized? 2. Using model deltas 22 Minor Feature using a Model Delta

23. Maider Azanza How are Features Realized? 23 Model Transformation Model Delta =

24. Maider Azanza 24 A Metamodel for Features Premise: Deltas do not need to fulfil all metamodels constraints Questionnaire Metamodel Minor Feature 1

25. Maider Azanza 25 A Metamodel for Features

26. Maider Azanza 26 A Metamodel for Features Created by removing constraints from the product metamodel Domain Engineers decide which constraints to remove. Delta Metamodel Product Metamodel

27. Maider Azanza 27 A Metamodel for Features Created by removing constraints from the product metamodel All discarded constraints should be checked once the composed model has been created. Delta Metamodel Product Metamodel Faulty Products

28. Maider Azanza 28 Outline Background Core Asset Implications Case Study Feature Realization Feature Composition –Composition Definition –Composition Realization Assessment Process Implications Conclusions and Future Work

29. Maider Azanza Feature Composition Features as transformations Features as model deltas 29 product 1 f1f3base product 1 = How are deltas composed?

30. Maider Azanza 30 M AB = Compose (M A, M B, C AB ) 1.M A, M B and M AB conform to the same MM. i.e., the delta metamodel 1.M A and M B are designed to be composed. Same object organization Same naming conventions (identifier based C AB ) Model Delta Composition in SPLs Not random models Models designed to be composed

31. Maider Azanza Generic vs. Domain Specific Composition Generic Composition Semantics: Content addition Domain Specific Composition Semantics: Domain expert specified 31

32. Generic Composition 32

33. Maider Azanza Generic Composition: Objects 33 Superimposition by identifier.

34. Maider Azanza Generic Composition: Attributes 34 If a1=null or a2=null or a1=a2 non null value Otherwise error

35. Maider Azanza Generic Composition: References 35 Union without duplicates.

36. Domain Specific Composition 36

37. Maider Azanza 37 Domain-Specific Composition: Time sum 102030 SUM is liable to be reused in other domains.

38. Maider Azanza 38 Domain-Specific Composition: Acknowledgments concat CONCAT also liable to be reused.

39. Composition Realization 39

40. Maider Azanza Composition Realization 40 Generic: Metamodel Agnostic Domain Specific: Reusable Can composition implementation be generated? MetamodelComp. Code

41. Composition Specification 41

42. Maider Azanza Composition Specification 42

43. Composition Generation 43

44. Maider Azanza Generic Composition Generation 44 rule MergeQuestion merge l:Left!Question with r:Right!Question into t:Target!Question extends MergeObject { t.text:=l.text.defaultAttributeMerge (text,r.text); --Code Omitted } MetamodelGenerated Code

45. Maider Azanza rule MergeQuestionnaire merge l:Left!Questionnaire with r:Right!Questionnaire into t:Target!Questionnaire extends MergeObject { t.title:=l.title.defaultAttributeMerge (title,r.title); --Code Omitted t.acknowledgments:= l.acknowledgments+ r.acknowledgments; t.time:=l.time+r.time; } Domain Specific Composition Generation 45 MetamodelGenerated Code

46. Maider Azanza Domain Specific Composition Generation 46 rule MergeBlock merge l:Left!Block with r:Right!Block into t:Target!Block extends MergeObject { var lsb: new Target!Block; var rsb: new Target!Block; lsb.title:=l.title; lsb.implements:=l.implements; rsb.title:=r.title; rsb.implements:=r.implements; --Code Omitted } MetamodelGenerated Code

47. Maider Azanza 47 Outline Background Core Asset Implications Case Study Feature Realization Feature Composition Assessment Process Implications Conclusions and Future Work

48. Maider Azanza Assessment – Case Studies DomainProduct LineProduct Size QuestionnairesCSS Product Line 10 1 UML Interactions Game Product Line 10 2 JakAHEAD Product Line 10 3 48

49. Process Implications

50. Maider Azanza 50 Most Development in MDPLE is Assembly 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 Context Assembly Program C1 C2 C3 C4 Result Application

51. Maider Azanza 51 The Assembly Process in MDPLE becomes complex: new operations are introduced. needs design: distinct assembly alternatives may need to be contrasted and assembly counterpoints can arise. is repetitive: assembly is typically geared towards the reuse of source code, but its realization often lacks such reuse. The Problem

52. Maider Azanza This Thesis Defines Assembly Plan Management: discipline that promotes program assembly as a main activity.

53. Maider Azanza 53 Result Program This Thesis Applies MDE to Assembly Processes assembly programs are generated from declarative specifications. Assembly Process Specification Assembly Process Implementation

54. Maider Azanza 54 Outline Background Core Asset Implications Process Implications Motivating Case Study Assembly Plan Management Assessment Conclusions and Future Work

55. Maider Azanza 55 Flight Booking Portlets Motivating Case Study Portlet 1 Portlet 2 Portlet 3 Software Product Lines M PORTLET C PORTLET Model Driven Engineering PinkCreek: Model Driven Product Line of Flight Booking Portlets

56. Maider Azanza An assembly program to realize one product in PinkCreek consisted of around 500 LOC of batch processes used 300 LOC ant makefiles and 2 KLOC Java code took around 4 person/day Repetitive, time-consuming and very cumbersome. Paradox: Lacked reuse mechanisms. 56 Motivating Case Study

57. Maider Azanza 57 Outline Background Core Asset Implications Process Implications Motivating Case Study Assembly Plan Management Assessment Conclusions and Future Work

58. Maider Azanza Overview 58 MegamodelAssembly Machine Tool Family Assembly Model Assembly Equation Assembly Program

59. Maider Azanza Megamodel Engineering 59 Megamodel Engineer Portlet Megamodel

60. Maider Azanza Megamodel Engineering 60 Portlet Assembly Machine Tool GROVE Tool Suite

61. Maider Azanza Family Assembly Engineering 61 Domain Engineer PinkCreek Family Assembly Model

62. Maider Azanza Assembly Program Engineering 62 Application Engineer Product1 Assembly Equation assembly_equation product1 do composition base composition seat composition checkin transformation sc2ctrl transformation ctrl2act transformation act2jak transformation ctrl2vw transformation vw2jsp end

63. Maider Azanza 17 PMDD_Model result2=featurecheckin.dot(result1); 18 featurebase.t_sc2ctrl(); 19 featureseat.t_sc2ctrl(); 20 featurecheckin.t_sc2ctrl(); 21 result0.t_sc2ctrl(); 22 result1.t_sc2ctrl(); 23 result2.t_sc2ctrl(); 24 featurebase.t_ctrl2act(); 25 /*Content omitted*/ 26 result2.t_ctrl2act(); 27 /*Content omitted*/ 28 result2.t_act2jak(); 29 /*Content omitted*/ 30 result2.t_ctrl2vw(); 31 /*Content omitted*/ 32 result.t_vw2jsp(); /*This is the result*/ 32 } 33 } 1 package org.product1; 2 import java.io.File; 3 import org.PMDD; 4 5 public class AssemblyProgram { 6 public static void main(String [] args) { 7 /*Build objects for equation features*/ 8 File fbaseSC = new File (../base/sc.ecore.xmi); 9 PMDD_Model featurebase=new PMDD_Model (fbaseSC); 10 File fseatSC = new File (../seat/sc.ecore.xmi); 11 PMDD_DeltaModel featureseat=new PMDD_Model (fseatSC); 12 File fcheckinSC = new File (../checkin/sc.ecore.xmi); 13 PMDD_DeltaModel featurecheckin=new PMDD_Model (fcheckinSC); 14 /*Operations in equation*/ 15 PMDD_Model result0=featurebase; 16 PMDD_Model result1=featureSeat.Dot(result0); Assembly Program Engineering 63 GROVE Tool Suite Product1 Assembly Program

64. Maider Azanza Product Assembling 64 Application Engineer Enact Assembly Program C1 C2 C3 C4 Result

65. Maider Azanza 65 Outline Background Core Asset Implications Process Implications Motivating Case Study Assembly Plan Management Assessment Conclusions and Future Work

66. Maider Azanza 66 Assessment The Assembly Process becomes complex. Before: 500 LOC of batch processes using 300 LOC of ANT makefiles and 2 KLOC of Java code and around 4 people/day. After: Equation of 15 LOC (providing that the first two phases have been performed). The Assembly Process needs to be designed. Before: Design was tangled in code. After: An abstract specification permits to concentrate on essentials. The Assembly Process becomes repetitive. Before: Clone&own was the only reuse mechanism. After: The Assembly Machine Tool and model transformations foster systematic reuse.

67. Conclusions and Future Work

68. Maider Azanza 68 Outline Background Core Asset Implications Process Implications Conclusions and Future Work Conclusions: Core Asset Implications –Feature Realization –Feature Composition Conclusions: Process Implications –Assembly Plan Management –MDE for Assembly Programs Future Work Related Publications

69. Maider Azanza Conclusions: Feature Realization We defined features as model deltas. Early Consistency Checking: certain constraints can be checked at delta building time. Reuse: separates what a feature adds from how it is added composition becomes reusable. Declarativeness: model deltas are easier to read and write than transformations. 69

70. Maider Azanza Conclusions: Feature Composition Composition implementation is generated from the annotated metamodel. Automatization: implementation automatically generated from the annotated metamodel. Understandability: annotations permit designers to focus on the what rather than on how the composition is achieved. Maintenance: additional composition algorithms can be added or removed with minimal effort. 70

71. Maider Azanza 71 Conclusions: Assembly Plan Management Assembly Plan Management was defined as a discipline inside Software Development. Guided Process: roles, tasks and workproducts are explicitly described. Automatization: parts of the process are automated using GROVE TS. Reuse: the result of each phase is reused in the next one.

72. Maider Azanza 72 Conclusions: MDE for Assembly Programs MDE was applied to assembly programs. Design: designers can concentrate on the essentials. Automatization: assembly programs are generated from abstract specifications. Reuse: reuse is also increased by the use of transformations.

73. Future Work 73

74. Maider Azanza Future Work: Core Asset Implications Generalization: consider deletion in model deltas. Safe Composition: guarantee that models composed from deltas are metamodel compliant. Delta Decomposition: to improve SPL maintainability. 74

75. Maider Azanza Future Work: Process Implications Variability of the Assembly Process: E.g.: Different transformations that yield the product. A Process for MDPLE: Support the complete development process. Variability for the MDPLE Process: Tailoring the process for each organizations needs. 75

76. Related Publications 76

77. Maider Azanza Related Publications Core Asset Implications Maider Azanza, Don Batory, Oscar Díaz, and Salvador Trujillo. Domain-Specific Composition of Model Deltas. [@ICMT 2010] Process Implications Maider Azanza, Oscar Díaz and Salvador Trujillo. Software Factories: Describing the Assembly Process. [@ICSP 2010] Others Roberto Lopez-Herrejon, Alexander Egyed, Salvador Trujillo, Josune de Sosa, and Maider Azanza. Using Incremental Consistency Management for Conformance Checking in Feature-Oriented Model-Driven Engineering. [@VAMOS 2010] Don Batory, Maider Azanza and João Saraiva. The Objects and Arrows of Computational Design. [@MoDELS 2008] 77

78. Maider Azanza 78 Thank you!

79. 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