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

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

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.

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

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

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

Background

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

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.

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

Core Asset Implications

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

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.

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

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

Maider Azanza 16 Case Study: Questionnaires

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*

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

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

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

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

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

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

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

Maider Azanza 25 A Metamodel for Features

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

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

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

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

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

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

Generic Composition 32

Maider Azanza Generic Composition: Objects 33 Superimposition by identifier.

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

Maider Azanza Generic Composition: References 35 Union without duplicates.

Domain Specific Composition 36

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

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

Composition Realization 39

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

Composition Specification 41

Maider Azanza Composition Specification 42

Composition Generation 43

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

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

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

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

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

Process Implications

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

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

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

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

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

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

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

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

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

Maider Azanza Megamodel Engineering 59 Megamodel Engineer Portlet Megamodel

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

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

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

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

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

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

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.

Conclusions and Future Work

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

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

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

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.

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.

Future Work 73

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

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

Related Publications 76

Maider Azanza Related Publications Core Asset Implications Maider Azanza, Don Batory, Oscar Díaz, and Salvador Trujillo. Domain-Specific Composition of Model Deltas. 2010] Process Implications Maider Azanza, Oscar Díaz and Salvador Trujillo. Software Factories: Describing the Assembly Process. 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. 2010] Don Batory, Maider Azanza and João Saraiva. The Objects and Arrows of Computational Design. 2008] 77

Maider Azanza 78 Thank you!

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