phd maintainability of transformations in evolving mde ecosystems

Maintainability of Transformations in Evolving MDE Ecosystems

Jokin García PérezSupervisor: Prof. Oscar

Díaz

[email protected]

Index1. Background

2. Problem statement

3. Model transformation co-evolution

4. Adapter-based approach to co-evolve generated SQL in M2T transformations

5. Testing MOFScript transformations with HandyMOF

6. Conclusions

7. Future work

What is MDE?

It’s all about modelsWhat is MDE?

Models are the primary artifact

1


Models are abstractions of reality

REALITY

abstractedIn

1 2



Models conform to metamodels

REALITY

abstractedIn

Metamodel

1 2

3



Models conform to metamodels

Models are transformed

REALITY

abstractedIn

Metamodel

transformation

1 2

3 4

Human

Phitoplankton Zooplankton FishMussel

eats

EcosystemBalance

M2MTransf.

M2TTransf.

Metamodel

MDE Ecosystem

Conforms To

M2MTransf.

Holistic maintenance

Maintainability

50-90% of the total sw cost

MDE Maintainability- Increase of the number of artifacts

- Increase in the complexity of artifacts

- Larger upfront investment

EvolutionMultidimensional

Co-EvolutionAdaptation

Index1. Background





6. Conclusions

7. Future work

Problem statement

Change impact analysis

Change propagatio

nVerify and validate

Change detection

Problem statement

Change detection

Problem statement

Ma MbTab

MMa MMt MMb

Platform

M2T

MMb’

Platform’

Δ?

Δ?

Problem statement


Change detection

Problem statement

Ma MbTab

MMa MMt MMb

Platform

M2T

MMb’

Platform’

??

Problem statement


Change propagatio

nChange

detection

Problem statement

Ma MbTab

MMa MMt MMb

Platform

M2T

MMb’

Platform’

Δ

Δ

Problem statement


Change propagatio

nVerify and validate

Change detection

Problem statement

Ma MbTab

MMa MMt MMb

Platform

M2T

MMb’

Platform’

Index1. Background





6. Conclusions

7. Future work



2. Solution

3. Case study

Index

4. Proof-of-concept

Context Problemstatem

ent

Metamodel evolutionAlternative versions, adapt to formalism, correct errors,

refactor, …1

Model co-evolution to metamodel changesBibliography2

Problem Problemstatem

ent

Metamodel evolutionImpacts on transformations1

Manual migration of these transformationsCumbersome and error-prone2

Ma MbTab

MMa MMt MMb


ent

Semi-automatic migration processImpacts on transformations1



2. Solution

3. Case study

Index

4. Proof-of-concept

Process Solution

MM and evolved

MM

Detection: simple

changes

1

Normalized transf.Transf.

Simple changes

Changes

Similarity model Co-

evolved transf.

Detection: complex changes

Similarity analysis

CNF conversion

Co-evolution

2

3

4

Detection stage Solution

Retrieve simple changesUsing a comparison tool1

Convert simple changes to complexIf they are semantically related2

AddModelElement

UpdateAttribute

RemoveModelElement

SplitClass

Co-evolution stage Solution

Define correspondences that map the original transformation into an evolved transformation

Taxonomy of changes based on the impactNon Breaking Changes (NBC)Breaking and Resolvable Changes (BRC)Breaking and Unresolvable Changes (BUC)

“Everything is a model” philosophy: implemented as HOTs

Co-evolution stage Solution

Auxiliary stepsConjunctive Normal Form conversion

Similarity analysis

not ((A and B) or C) -> (not A or not B) and not C

Source 1

Target 1

Target 2

Similarity = 1

Similarity = 0

Minimum deletion Solution

Delete only the strictly necessary rule fragments

String concatenations3 <- s1 + s2. If s1 is removed: s3 <- s2

CollectionsSet{A, B, C}. If A is removed: Set{B, C}

Boolean expressionsnot ErasmusGrant or (speakEnglish and enrolledLastYear). If

speakEnglish is removed: not ErasmusGrant or enrolledLastYear



2. Solution

3. Case study

Index

4. Proof-of-concept

Metamodels Case study

Extract superclass Case study

The AssistantMVC's Multiple class is introduced in the target metamodel

Extract superclass is a NBC case. No action is needed

1

Delete metaproperty Case study

The metaproperty optional is deleted from ExamElement

minimum deletion is applied

2

Delete metaproperty Case study

Opposite filters in two rulesRule

2

(value>5 and optional) or long

(value > 5 or long)

Rule

1

2not ((value>5 and optional) or long)

(not value>5 or not optional) and not long

(not value>5 and not long)

Type change Case study3

The AssistantMVC's fontName metaproperty is changed from string to integer

BUC in most of the cases. Only few cases are NBC

Split class Case study4

The AssistantMVC's OpenElement class is splitted into OpenElement_1 and

OpenElement_2

Split class Case study4

One rule will become two, and bindings will be moved to the corresponding rule depending on the used metaproperty

Add class and property Case study5

New subclass ExerciseElement and metaproperty style



2. Solution

3. Case study

Index

4. Proof-of-concept

Proof of concept

Prototype for Ecore-based MMs and ATL Simple changes -> Complex changesHOT to adapt transformation to changes

Index1. Background





6. Conclusions

7. Future work



2. Case study

3. Solution

4. Evaluation

Index

5. Proof-of-concept


ent

Software componets on top of platformsDependencies1

Platform evolution is a common situationDB, API, …2

CMSBlog

Wiki

API

Application


ent

Perpetual beta state of platformsIncrease frequency of releases3

External dependencyOut of our control4


ent

Domain model M2T Transf. Code

Transformationcode

Model refs. Embedded platform code


ent

Different versions of the platform leave the code

and M2T transformation outdated

DB DB’

Code

M2T

Δ

?

Solution Problemstatem

ent

Adapter to adapt generated code to new platform

DB DB’

Code

M2T

Δ

Code

Adapter



2. Case study

3. Solution

4. Evaluation

Index

5. Proof-of-concept

MediaWiki DB in Wikiwhirl Case study

MediaWiki Case study

+ 40.000

+ 200

Used by Wikipedia and more than 40.000 wikis

Schema upgrades

MediaWiki DB in Wikiwhirl Case study

Platform-dependent conceptsRefs. to domain

model



2. Case study

3. Solution

4. Evaluation

Index

5. Proof-of-concept

Solution overview Solution

Synchronize the generated code with platformUsing adapters at runtime

DB’

Code

Adapter

M2T print("INSERT into categorylinks (cl_from, cl_to, cl_sortkey, cl_timestamp) VALUES (@pageId, '" + categoryTitle + "','" + pageTitle)

INSERT INTO categorylinks (cl_from, cl_to, cl_sortkey, cl_timestamp, cl_type, cl_sortkey_prefix, cl_collation) VALUES (@pageId, ‘Softwareproject’, ‘House_Testing’, (DATE_FORMAT(CURRENT_TIMESTAMP(), ‘%Y%m%d%k%i%s’), ‘page’, ‘’, ‘0’);

New columns “cl_type”, “cl_sortkey_prefix” and“cl_collation”

Process outline Solution

Code(MediaWiki

DB)

New MediaWikischema

Domainmodel

Differencemodel

New schemamodel

Old schemamodel

Old MediaWikischema

Transformation

(M2T + adapter)

Injection(Schemol)

Injection(Schemol)

Comparison(EMFCompar

e)

1

2

3

Process outline Solution

Code(MediaWiki

DB)

New MediaWikischema

Domainmodel

Differencemodel

New schemamodel

Old schemamodel

Old MediaWikischema

Transformation

(M2T + adapter)

Injection(Schemol)

Injection(Schemol)


e)

1

2

3

All in one click

Differences between platforms: DB schema Solution

Injection(Schemol)


e)

Process: Schema Modification Operators (SMO) Solution

SMO % of usage

Change type

Adaptation

Create table 8.9 NBC New comment in the transformation on the existence of this table in the new version

Drop table 3.3 BRC Delete statement associated to the tableRename table 1.1 BRC Update name

Copy table 2.2 NBC (None)

Add column 38.7 NBC/ BRC

For insert statements: if the attribute is Not Null, add the new column in the statement with a default value (from the DB if there is available or according to the type if there is not)

Drop column 26.4 BRC Delete the column and the value in the statementRename column 16 BRC Update name

Copy column 0.4 BRC Like add column case

Move column 1.5 BRC Like drop column + add column cases

Adaptation Solution

“println” instructions are replaced with “printSQL”1

Plaform-specific, schema-independent

Import “printSQL” libraryZQL extension

For each printSQL invocationIterate over the changes reported in the Difference model

Checks if any of the changes impacts the current statement Needed information to adapt the statement is retrieved and added to a list of parameters: the statement, affected table, column, …

234

A function that adapts the statement is called and new statement is printed

Adaptation output Solution

AddedcolumnsDeletetables

Deletecolumns

Dump changes from code to transformation Solution

M2Ttransformatio

n

M2Ttransformatio

n’HOT

Assist manual propagationRecord generation with change to be done and where (line and column in the transformation)

print(“select * from …”)

printSQL(“select * from …”, line, column)

RECORD:#Added columns cl_type, cl_sortkey_prefix and cl_collation#transformation line: 12, column: 11INSERT INTO categorylinks (cl_from, cl_to, cl_sortkey, cl_timestamp, cl_type, cl_sortkey_prefix, cl_collation) VALUES (@pageId, ‘Softwareproject’, ‘House_Testing’, (DATE_FORMAT(CURRENT_TIMESTAMP(), ‘%Y%m%d%k%i%s’), ‘page’, ‘’, ‘0’);

Roles Solution

ProducerInjector for target platform

ConsumerImport adapter library in the transformation

Implement adapter as a library for transformation

Execute the batch



2. Case study

3. Solution

4. Evaluation

Index

5. Proof-of-concept

Cost equations Evaluation

Manual Cost = D + P * #ImpactsD: Detection time

Assisted Cost = C + V * #ImpactsC: Configuration time

P: Propagation time

V: Verification time

Manual vs Assisted Evaluation



2. Case study

3. Solution

4. Evaluation

Index

5. Proof-of-concept

Proof of concept

Library for MOFScript transformationBatch that automatized the whole process: injection, comparison, execution

Empirical evaluation

Index1. Background





6. Conclusions

7. Future work


1. Motivating scenario

2. Problem

3. Solution

Index

4. Proof-of-concept

5. Demo

Motivating scenario Case study

M2T

Motivating scenario Case study

MofScript

Java

Transformation

Model



2. Problem

3. Solution

Index

4. Proof-of-concept

5. Demo

Problem

M2T

Traceability

?

line line1 line line2



2. Problem

3. Solution

Index

4. Proof-of-concept

5. Demo

Traceability in HandyMOF Solution

M2T M2T Calculates physical positions

M2TTraces

HOT transformation1

Execution2

Solutionexecuted3 ?

White-box testingHighly coupled to the languageM2T: no winner language

Hybrid approach Solution

Generate test suite with black-box testing1

Check lines covered by this suite2

?

Testing in HandyMOF Solution

Test model generation1

Trace generation2

Pramana

Testing in HandyMOF Solution

Finding minimal model suite3

Model suite Minimal model suite

Architecture Solution

metamodels

models

Pramana

TraceGenerator

HandyMOF

MinimalModelSuiteFinder

transformations

traces

generatedcode



2. Problem

3. Solution

4. Proof-of-concept

Index

5. Demo

Proof of concept

HandyMOF toolVisualizes graphically traceability between transformation and codeCoverage analysis of test suite in transformation



2. Problem

3. Solution

Index

4. Proof-of-concept

5. Demo

http://onekin.org/downloads/public/screencasts/handyMOF.htm



Index1. Background





6. Conclusions

7. Future work

Model transformation co-evolution Conclusions

Semi-automatic process to adapt transformations to metamodel evolution

Minimum deletionMap the original transformation into an evolved transformation that tackles MM changesEcore-based MMsATL transformations

Derive complex changes from simple changes

Co-evolve generated code Conclusions

Mechanism to adapt code generated by M2T transformations to platform evolution

Premises: platform instability and transformation coupling

Apply in a specific case studyMediaWiki DB

Assist dumping changes to the transformation

Testing M2T transformations Conclusions

line line1

line line2

executed3 ?

General contributions Conclusions

Improve traceability mechanisms

Point out and study the coupling between artifacts in MDE ecosystem and its implication

Synchronization techniques for co-evolution

MM – M2M transf., Platform – M2T transf.

M2T transf. - code

MM – M2M transf. (HOT), Platform – M2T transf. (Adapter)

Index1. Background





6. Conclusions

7. Future work

Model transformation co-evolution Future work

Empirical assessmentReal scenario

Co-evolve generated code Future work

Generalization: other platforms

Methodology for adapter development

Testing M2T transformations Future work

Assist in creating missing models

Improve minimal model suite algorithm

Add other M2t transformation languages

Evaluation

Future research Future work

Good practices in transformations

M2T transf.: model world – text world

Dissemination & contrast

Model Transformation Co-evolution: A Semi-automatic Approach

Software Language Engineering (SLE) 2012, Dresden (Germany)

An Adapter-Based Approach to Co-evolve Generated SQL in M2T TransformationsAdvanced Information Systems Engineering (CAiSE) 2014,

Thessaloniki (Greece)Testing MOFScript Transformations with

HandyMOFInternational Conference on Model Transformations (ICMT) 2014, York (UK)

CommentsQuestions

Prototypes: www.onekin.org/content/jokin-garcia-0

[email protected]