Model Driven Product Line Engineering: Core Asset and Process Implications

Model Driven Product Line Engineering:

Core Asset and Process Implications

Maider Azanzasupervised by Prof. Dr. Oscar Díaz

Onekin Research Group

Department of Computer Languages and Systems University of the Basque Country

San Sebastian – February 28th, 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

BackgroundCore Asset ImplicationsProcess ImplicationsConclusions and Future Work

Background

Maider Azanza 8

1. Models are the primary artifact2. Models are abstractions of reality3. Models conform to metamodels4. 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

f3 f4f2f1

f1

f2f4

Core Asset Implications

Maider Azanza 12

product 3

product 2

f2 base

Model Driven Product Line Engineering• Models are created incrementally

Context

f1

f2

f3

f3

f4base

f1 base

product 1

Maider Azanza 13

The Problem

Features are transformations (model to model maps)

How are features realized?

How are features composed?

Remember: SPL products must conform to their metamodel.

Maider Azanza 14

This Thesis

Feature

Realizatio

n

•Realizes features as model deltas•mod

els 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

BackgroundCore Asset Implications

• Case Study• Feature Realization• Feature Composition• Assessment

Process ImplicationsConclusions and Future Work

Maider Azanza 16

Case Study: Questionnaires

Maider Azanza

Case Study: CSS Product Line

17

Crime and Safety Survey

Female Age

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

Female Minority

Minor Adult

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

22Minor 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 metamodel’s 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

text = Where did it take place?

atq2 : Question

code = 07text = At school

atq2o7 : Option

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 MetamodelFaulty

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

f1 f3base

product 1

● ● =

How are deltas composed?

Maider Azanza 30

MAB = Compose (MA, MB, CAB)

1. MA, MB and MAB conform to the same MM.• i.e., the delta metamodel

2. MA and MB are designed to be composed.• Same object organization

• Same naming conventions (identifier based CAB)

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 33

Generic Composition: Objects

Superimposition by identifier.

text

atq2 : Question

code = 07text = At school

atq2o7 : Option

text = Where did it take place?

atq2 : Question

code = 01text = At home

atq2o1 : Option

code = 02text = In the street

atq2o2 : Option

code = 03text = In a parking lot

atq2o3 : Option

●=baseminorminor ● base

text = Where did it take place?

atq2 : Question

code = 01text = At home

atq2o1 : Option

code = 02text = In the street

atq2o2 : Option

code = 03text = In a parking lot

atq2o3 : Option

code = 07text = At school

atq2o7 : Option

Maider Azanza 34

Generic Composition: Attributes

If a1=null or a2=null or a1=a2 non null value

Otherwise error

text

atq2 : Question

code = 07text = At school

atq2o7 : Option

text = Where did it take place?

atq2 : Question

code = 01text = At home

atq2o1 : Option

code = 02text = In the street

atq2o2 : Option

code = 03text = In a parking lot

atq2o3 : Option

●=baseminorminor ● base

text = Where did it take place?

atq2 : Question

code = 01text = At home

atq2o1 : Option

code = 02text = In the street

atq2o2 : Option

code = 03text = In a parking lot

atq2o3 : Option

code = 07text = At school

atq2o7 : Option

Maider Azanza 35

Generic Composition: References

Union without duplicates.

text

atq2 : Question

code = 07text = At school

atq2o7 : Option

text = Where did it take place?

atq2 : Question

code = 01text = At home

atq2o1 : Option

code = 02text = In the street

atq2o2 : Option

code = 03text = In a parking lot

atq2o3 : Option

●=baseminorminor ● base

text = Where did it take place?

atq2 : Question

code = 01text = At home

atq2o1 : Option

code = 02text = In the street

atq2o2 : Option

code = 03text = In a parking lot

atq2o3 : Option

code = 07text = At school

atq2o7 : Option

Domain Specific Composition

36

Maider Azanza 37

Domain-Specific Composition: Time

sum

sum

10’ 20’

30’

SUM is liable to be reused in other domains.

Maider Azanza 38

Domain-Specific Composition: Acknowledgments

concat

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?

Metamodel Comp. Code

Composition Specification

41

Maider Azanza 42

Composition Specification

Composition Generation

43

Maider Azanza 44

Generic Composition Generation

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}

Metamodel Generated Code

Maider Azanza 45

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

Metamodel Generated Code

Maider Azanza 46

Domain Specific Composition Generation

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}

Metamodel Generated Code

Maider Azanza 47

Outline

BackgroundCore Asset Implications

• Case Study• Feature Realization• Feature Composition• Assessment

Process ImplicationsConclusions and Future Work

Maider Azanza 48

Assessment – Case Studies

Domain Product Line Product Size

Questionnaires CSS Product Line ≈ 101

UML Interactions Game Product Line ≈ 102

Jak AHEAD Product Line ≈ 103

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

C3C4

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

BackgroundCore Asset ImplicationsProcess 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

MPORTLET

CPORTLET

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

BackgroundCore Asset ImplicationsProcess Implications

• Motivating Case Study• Assembly Plan Management• Assessment

Conclusions and Future Work

Maider Azanza

Overview

58

Megamodel Assembly 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

C3C4

Result

Maider Azanza 65

Outline

BackgroundCore Asset ImplicationsProcess 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 ManagementAssembly 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 organization’s 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. [@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

Maider Azanza 78

Thank you!

Model Driven Product Line Engineering:

Core Asset and Process Implications

Maider Azanzasupervised by Prof. Dr. Oscar Díaz

Onekin Research Group

Department of Computer Languages and Systems University of the Basque Country

San Sebastian – February 28th, 2011