Upload
duane-burnell
View
217
Download
1
Tags:
Embed Size (px)
Citation preview
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