McGill UniversitySchool of Computer Science

Ph.D. Candidate in the Modelling, Simulation, and Design Lab

Eugene Syriani

OUTLINE

Model Transformation Languages (MTLs)

Uses & Applications of Model Transformation

Features of Model Transformation Languages

Essence of Model Transformation Languages

Common Basis

A Product Line of MTLs

Explicitly Modelling MTLs

Syntax, Semantics, and All That Stuff

Challenges

2

WHAT IS MODEL TRANSFORMATION?

“The process of converting one model to another model of the same system.” [1]

“The automatic generation of a target model from a source model,according to a transformation definition.” [2]

“A manipulation of a model with a specific intention.” [3]

3

[1] OMG. MDA Guide version 1.0.1, 2003. OMG Document: omg/2003-06-12.[2] Kleppe, A. G.; Warmer, J. & Bast, W. MDA Explained. The Model Driven Architecture: Practice And Promise. Addison-Wesley, 2003.[3] Syriani, E. Model Transformation. Summer School on Domain-Specific Modelling: Theory & Practice (DSM-TP’10). Lisbon, 2010.

TERMINOLOGY

• The transformation is defined at the meta-model level

• The execution of the transformation is applied on the models to automatically transform them

• Model-to-Model Transformation– Same meta-models

– Same model

– Multiple source/target models4

TargetMeta-model

TargetMeta-model

Transformation

Transformation

TransformationDefinition

TransformationDefinition

TargetModelTargetModel

SourceModelSourceModel

SourceMeta-model

SourceMeta-model

reads outputs

refers to refers to

TYPES OF TRANSFORMATIONS

• Simple operations on a model:– AddAdd an element to the model;

– RemoveRemove an element from the model;

– UpdateUpdate an element’s properties;

– AccessAccess an element or its properties.

• These primitive operations are know as the CRUD operations (Create, Read, Update, Delete)

Access/Modify operations

5

TYPES OF TRANSFORMATIONS

Operation that requests some informationinformation about a system

• This operation takes as input the model M and outputs a viewview of M• A view is a projectionprojection of (a sub-set of) the properties of M• A query is a transformation since it is a projection, obtained by CRUD

operations on the properties of M

• Restrictive viewRestrictive view: Reveal a subset of the properties of M (all, none, some)– Retrieve all cycles in a causal block diagram

– Show only classes/associations of a class diagram

• Aggregated viewAggregated view: Restriction of M modifying some of its properties– Get the average of all costs per catalogue product in a relational database schema

– In a hierarchical model, show top-level elements only, with an extra attribute denoting the number of sub-elements

Query

6

TYPES OF TRANSFORMATIONS

Transform from a higher level specification to a lower level description

• Design models translated into source code

• DSM compiled into an executable implementation

Synthesis

7

PhoneApps to Statecharts [5]

[5] Mannadiar, R. & Vangheluwe H. Modular Synthesis of Mobile Device Applications from Domain-Specific Models. in 7th Model-based Methodologies for Pervasive and Embedded Software workshop, 2010.

TYPES OF TRANSFORMATIONS

• Formalism’s semantic mapping function defined by a transformation

• Formalism's semantic domain is a modelling language

Translational Semantics

8[4] Kühne, T.; Mezei, G.; Syriani, E.; Vangheluwe, H. & Wimmer, M. Explicit Transformation Modeling. MODELS 2009 Workshops,LNCS: 6002, pp. 240-255, Springer. Denver (USA) 2010.

Finite State Automata to Petri-Net [4]

TYPES OF TRANSFORMATIONS

Inverse of synthesis: extract higher-level specifications from lower-level ones

Reverse Engineering

9

TYPES OF TRANSFORMATIONS

• Update the state of the system modelled

• Target model is an “updated” version of the source model

• Operational semantics

Simulation

10

Finite State Automata Simulator

TYPES OF TRANSFORMATIONS

• Automatically generate random models that conform to the language

Meta-model instance generation

11

Class diagram meta-model

TYPES OF TRANSFORMATIONS

Transform from a software model written in one language or framework into another, but keeping the same level of abstraction

• Evolution to new version

Migration

12

Enterprise Java Beans 2.0 to 3.0

TYPES OF TRANSFORMATIONS

Improve certain operational qualities of the model while preserving its semantics

• Typically used on architecture or design models

Optimization

13

SSheet

+ addRow() : void+ addColumn() : void+ getCell(Coordinate) : SSheetCell+ getCellValue(Coordinate) : CellValue+ setCellValue(SSheetCell, CellValue) : void

Dictionary

Mapping

SSheetCell

- coordinate: Coordinate

+ getValue() : CellValue+ setValue(CellValue) : void

«struct»Coordinate

- row: int- column: int

+ set(int, int) : void+ row() : int+ col() : int

1

+cells

1 *

+key 1 +value *

SSheet

+ addRow() : void+ addColumn() : void+ getCell(Coordinate) : SSheetCell+ getCellValue(Coordinate) : CellValue+ setCellValue(SSheetCell, CellValue) : void

2DArray 2DItem

- index: int

SSheetCell

- coordinate: Coordinate

+ getValue() : CellValue+ setValue(CellValue) : void

«struct»Coordinate

- row: int- column: int

+ set(int, int) : void+ row() : int+ col() : int

ArrayItem

- index: int

+items

*1

+cells

1

+value 1

+items

*

+value

1

List to Table Optimization

TYPES OF TRANSFORMATIONS

Change the internal structure of the model to improve certain quality characteristics without changing its observable behaviour(Understandability, modifiability, reusability, modularity, adaptability)

• Typically used on architecture or design models

• Refactoring

Restructuring

14

Pull Up Method refactoring

TYPES OF TRANSFORMATIONS

Decrease syntactic complexity• DesugaringDesugaring

Translate complex language constructs (syntactic sugar) into more primitive language constructs

• SimplificationSimplification Transform all uses of a language construct in a normal or canonical form

• Map the concrete syntax back to the abstract syntax

Normalization

15

H H

H

H

C

H

H

C OCH3 CH2 OH

TYPES OF TRANSFORMATIONS

Integrate models that have been produced in isolation into a compound model

Composition

16

Model Merging

Model Weaving

TYPES OF TRANSFORMATIONS

Integrate models that have evolved in isolation but that are subject to global consistency constraints

• In contrast with composition, synchronization requires that changes are propagated to the models that are being integrated

• Source model changes are propagated to corresponding target model changes:Incremental Incremental / Change-drivenChange-driven transformation

Synchronization

17

RepositoryRepository

• Synchronization must be ensured in both directions: multi-directional transformation

• InconsistencyInconsistency managementmanagement

TYPES OF TRANSFORMATIONSClassification

18

Endogenous Exogenous Either

In-place Access/Modify, Simulation XX XX

Out-place Restrictive query, SimplificationAggregate query, Synthesis,

Reverse engineering, Migration, Desugaring

Composition, Synchronization

Either Optimization, Restructuring XX XX

Endogenous Exogenous Either

Horizontal Access/Modify, Simulation, API migration Language migration Composition

Vertical

Formal refinement, Restructuring,

Restrictive query, Optimization, Simplification

Aggregate query, Synthesis, Reverse engineering,

DesugaringXX

Syntactical Query Synthesis ReverseEngineering Simplification Desugaring - -

Semantical Access /Modify Simulation Migration Optimization Restructuring Composition Synchronization

CHARACTERISTICS OF MTLS

• Feature model [6]

19[6] Czarnecki, K. & Helsen, S. Feature-Based Survey of Model Transformation Approaches. IBM Systems Journal, special issue on Model-Driven Software Development, 45, no. 3, pp. 621-645, July 2006.

• SpecificationPre/post condition on the transformation:• Function between source & target models• Relation may be executable or not

• Transformation RulesSmallest transformation unit, used to specify a transformation• Rule-based transformationsRule-based transformations: pre-condition & post-condition for rewriting• Transformation units defined as functions• Templates

• IncrementalityAbility to update existing target models based on

changes in the source models

• Source-Target Relationship• In-place• Out-place

• Rule OrganizationGeneral structuring issues of rules• Modularization• Composition• Re-use

• DirectionalityTransformation executed in one direction or in multiple directions

(uni-/multi-directional transformation)

• TracingMechanisms for recording different aspects of transformation

execution:• Create & maintain trace links between source & target model elements

• Rule Application Control• Where is a rule applied on the model• In what order are the rules executed

CHARACTERISTICS OF MTLS

• Smallest transformation element

• A transformation is mainly specified in terms of rules– Pre-condition on the input model

– Post-condition on the output model

Transformation Unit

20

:

:

CHARACTERISTICS OF MTLS

• LogicHow computations & constraints are specified on model elements

Transformation Unit

21

Imperative Declarative

Executable Java API for MOF models OCL query

Non-executable XX QVT-R relation

operation transform(source:PackageHierarchy): DataBase is doresult := DataBase.newtrace.initStep(“uml2db”)source.hierarchy.each{ pkg |

var scm: Schema init Schema.newscm.name := String.clone(pkg.name)result.schema.add(scm)trace.addlink(“uml2db”, “package2schema", pkg, scm)

}end

operation transform(source:PackageHierarchy): DataBase is doresult := DataBase.newtrace.initStep(“uml2db”)source.hierarchy.each{ pkg |

var scm: Schema init Schema.newscm.name := String.clone(pkg.name)result.schema.add(scm)trace.addlink(“uml2db”, “package2schema", pkg, scm)

}end

top relation PackageToSchema {domain uml p:Package{name=pn}domain rdbms s:Schema{name=pn}

}

top relation PackageToSchema {domain uml p:Package{name=pn}domain rdbms s:Schema{name=pn}

}

QVT-Relations rule [7] Kermeta operation [8]

[7] OMG. Meta Object Facility 2.0 Query/View/Transformation Specification. April 2008.[8] Falleri, J-R.; Huchard, M. & Nebut, C. Towards a Traceability Framework for Model Transformations in Kermeta. ECMDA-TW'06, pp. 31-40, HAL-CCSd-CNRS. Bilbao (Spain), July 2006.

CHARACTERISTICS OF MTLS

• Syntactic separation

Transformation Unit

22

module Person2Contact;create OUT: MMb from IN: MMa {

rule Start {form p: MMa!Person(

p.function = ‘Boss’)to c: MMb!Contact(

name <- p.first_name + p.last_name)}

module Person2Contact;create OUT: MMb from IN: MMa {

rule Start {form p: MMa!Person(

p.function = ‘Boss’)to c: MMb!Contact(

name <- p.first_name + p.last_name)}

ATL [11] rule

[9] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In: Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC Press. Boca Raton (USA), 2009.[10] Fischer, T.; Niere, J.; Turunski, L. & Zündorf, A. Story diagrams: A new graph rewrite language based on the Unified Modelling Language and Java. Theory and Application of Graph Transformations, LNCS: 1764, pp. 296-309, Springer-Verlag. Paderborn (Germany), 2000.[11] Jouault, F.; Allilaire, F.; Bézivin, J. & Kurtev, I. ATL: A model transformation tool. Science of Computer Programming (special issue), 72, no. 1-2, pp. 31-39, June 2008.

MoTif [9] graph transformation rule

FUJABA [10] rule: compact notation

CHARACTERISTICS OF MTLS

• ParameterizationExchange control parameters: pre-defined binding of some model elements

Transformation Unit

23

GReAT [12] pivot passing

[12] Agrawal, A.; Karsai, G.; Kalmar, Z.; Neema, S.; Shi, F. & Vizhanyo, A. The Design of a Language for Model Transformations. SoSym, 5, no. 3, pp. 261-288, September 2006.[13] Zündorf, A. Graph Pattern Matching in PROGRES. Graph Grammars and Their Application to Computer Science, LNCS: 1073, pp. 454-468, Springer-Verlag. Williamsburg (USA), November 1994.

ProGreS [13] in/out parameters

CHARACTERISTICS OF MTLS

• Unidirectional Unidirectional transformation:create (or update) the target model only

• Multi-directionalMulti-directional transformation :can be executed in any direction

• OperationalOperational rules have a functional character:given an input model, produce a target model– CausalityCausality from source to target model

• DeclarativeDeclarative rules:gives a relation between both models that must be satisfied– AcausalAcausal relationship between the models

Directionality

24

top relation PackageToSchema {domain uml p:Package {name = n}domain rdbms s:Schema {name = n}

}

top relation PackageToSchema {domain uml p:Package {name = n}domain rdbms s:Schema {name = n}

}

[14] Syriani, E. & Vangheluwe, H. Discrete-Event Modeling and Simulation: Theory and Applications. In: Wainer, G. A. & Mosterman, P. J. (ed.) DEVS as a Semantic Domain for Programmed Graph Transformation, CRC Press. Boca Raton (USA), 2009.

Triple Graph Grammar [11] rule

QVT-R relation

CHARACTERISTICS OF MTLSDirectionality

25

TGG rule

One TGG rule generates 7 TGG operational rules:•Every new element in a model has a correspondence in the other [x2]•When an element is removed from a model, its correspondent element(s) is (are) deleted appropriately [x2]•Enforce the consistency relations between attributes [x2]•Create a correspondence between unmapped elements of the two models [x1]

TGG operational rules

CHARACTERISTICS OF MTLS

• Strategy for determining the application locations of a rule

Location Determination

26

Model:

Rule:

CHARACTERISTICS OF MTLS

Implicit• Unordered

One rule that is applicable is selected to be applied non-deterministically at each iteration

• Grammar Unordered with start model and terminal states (generation or recognition)

Rule Scheduling

27

Model:

Rules: ,

CHARACTERISTICS OF MTLS

Explicit internalA rule may invoke other rules

• In ATL, a matched rule (implicitly scheduled) may invoke a called rule in its imperative part. Lazy rules

• In QVT, the when/where clauses of a rule may have a reference to other rules.When: the former will be applied after the latter. Where: the latter will be applied after the former.

Rule Scheduling

28

top relation ClassToTable {domain uml c:Class {package = p:Package{},isPersistent = true,name = cn

}domain rdbms t:Table {

schema = s:Schema{},name = cn,cols = cl:Column {

name = cn + ‘_tid’,type = ‘NUMBER’},

pkey = cl}when {

PackageToSchema (p, s);}where {

AttributeToColumn (c, t);}

}

top relation ClassToTable {domain uml c:Class {package = p:Package{},isPersistent = true,name = cn

}domain rdbms t:Table {

schema = s:Schema{},name = cn,cols = cl:Column {

name = cn + ‘_tid’,type = ‘NUMBER’},

pkey = cl}when {

PackageToSchema (p, s);}where {

AttributeToColumn (c, t);}

}

QVT-R relation

CHARACTERISTICS OF MTLS

Explicit externalClear separation between the rules and the scheduling logic.Use a control structure to define rule scheduling

• OrderedPriority, layer/phased, explicit workflow structure, …

• Event-drivenRule execution is triggered by external events

Rule Scheduling

29

CHARACTERISTICS OF MTLSRule Scheduling

30

• Priority-based: AToM3 [15]

[15] de Lara, J. & Vangheluwe, H. AToM3: A Tool for Multi-formalism and Meta-Modelling. FASE'02, LNCS: 2306, pp. 174-188 , Springer-Verlag. Grenoble (France), April 2002.

CHARACTERISTICS OF MTLSRule Scheduling

31

• Layered/Phased: AGG [16]

[16] Taentzer, G. AGG: A Graph Transformation Environment for Modeling and Validation of Software. AGTIVE'03, LNCS: 3062, pp. 446-453, Springer-Verlag, 2004.

CHARACTERISTICS OF MTLSRule Scheduling

32

• Explicit workflow:

FUJABA story diagram

GReAT data flow

CHARACTERISTICS OF MTLSRule Scheduling: Feature Matrix [17]

33

PRoGReS FUJABA VIATRA AToM3 GReAT VMTS MoTif

Control structure

Imperative language

Story Diagram

Abstract state

machine

Priority ordering Data flow Activity

diagram DEVS

Atomicity transaction, rule Rule gtrule Rule Expression Step ARule

Sequencing & Yes seq Implicit Yes Yes Yes

Branching choose...else Branch activity if-then-else No Test / Case Decision

step, OCL Query

Looping loop For-all pattern iterate, forall Implicit Yes Self loop FRule, SRule,

LRule

Non-determinism and, or No random Within layer 1−n

connection No Selector pattern

Recursion Yes No Yes No Yes Yes Yes

Parallelism No Optional No Optional No Fork, Join Synchronizer pattern

Back-tracking Implicit No choose

(implicit) No No No XRule

Hierarchy Modularisation Nested state Yes No Block,

ForBlockHigh-level

step CRule

[17] Syriani, E. & Vangheluwe, H. Matters of model transformation. McGill University, SOCS-TR-2009.2, School of Computer Science, March 2009

CHARACTERISTICS OF MTLS

What these languages/tools have in common:

• Graph transformation (GT) paradigm with explicit external scheduling

• Not complete list:– AGG: layered graph transformation

– MOLA [18]: structured flowchart

– T-Core [19]: primitive graph transformation operators combined with Python

– ...

• Non GT languages with explicit control structure:QVT-Operational Mappings, Kermeta

Rule Scheduling: Feature Matrix

34

[18] Kalnins, A.; Barzdins, J. & Celms, E. Model Transformation Language MOLA. ECMDA-FA'05, LNCS: 3599, pp. 62-76, Springer. Nuremberg (Germany), November 2005.[19] Syriani, E. & Vangheluwe, H. De-/Re-constructing Model Transformation Languages. ECEASST, no. 29 (GT-VMT'10), Paphos (Cyprus), March 2010.

FAMILY OF TRANSFORMATION LANGUAGES

• Model Transformation has many applications:– GenerateGenerate PSMs form PIMs and reverse engineeringreverse engineering

– MapMap and synchronizesynchronize among models at the same or different level of abstraction

– Create viewsviews of a system

– Model evolutionevolution tasks

• Since the applications are very different in nature, it is not optimal to have a single model transformation language that supports all of the above.

• Instead, it is more appropriate to have dedicated transformation languages tailored to specific transformation problems.

35

ESSENCE OF MODEL TRANSFORMATION LANGUAGES

What is common to the different rule-based transformation approaches?

• Pre-/Post- condition patternspatterns

• MatchingMatching

• RewritingRewriting

• ValidationValidation of consistent rule application

• Matches manipulation– IterationIteration

– Roll-backRoll-back

• Control flow– ChoiceChoice

– ConcurrencyConcurrency

• CompositionComposition

36

T-COREPrimitive Transformation Operations

37

• Pattern representation

• Matches processed structure

• 8 primitive transformation operators

T-Core Module

T-CORE

• Dissociate pre- from post-condition patterns– Query vs. Rule

– Embedded inside Matcher & Rewriter

Patterns

38

T-COREPacket Data-Structure

39

• Packet– Host graph

• MatchSet– Matches for a given pattern

• Match– Sub-model of interest

• Pivot– Node binding (across match sets)

– Parameterized rule

• All messages exchanged

T-CORECore Operators

40

• Dissociate Match from Rewrite:– match-rewrite- match-rewrite– match-match-match– match-match-rewrite-rewrite

• Matcher– Find one, max, all (parameter)– Store matches in packet

• Rewriter– Apply rewriting phase– Consume matches

• Resolver– Conservative check of conflicts among match sets– Customizable resolution function

[20] Rensink, A. and Kuperus, J.-H. (2009) Repotting the geraniums: On nested graph transformation rules. GT-VMT’09, EASST: 18, March 2009.

Amalgamated Rules [20]

T-COREMatch Manipulation

41

• Iterator– Randomly choose a match in a match set

– Number of iterations

• Rollbacker– Ensure transactional behaviour

– Restore packet when all matches exhausted

– Number of iterations

• Combine to handle multiple matches

FUJABA loops

T-COREControl Flow

42

• Selector– Can store packets

– Select one on demand

• Synchronizer– Can store packets

– Merge packets on demand

– Customizable merge function

Priorities in AToM3

T-COREComposition

43

• Meaningfully compose its sub-primitives

• User-defined composition

• Common interface

T-CORE IS...• A minimal collection of model transformation primitives

– De-construct to optimal granularity

• Not restricted to any form of specification of transformation unit– Rule-based, Constraint-based, Function-based– Bidirectional, Functional– Query, Transformation

• Modularly encapsulates combinations of primitives– Composition– Re-use– Interface

• Executable– Self-contained– Easily integrable

44

TRANSFORMATION LANGUAGE PRODUCT LINE

Primitive transformation operators(sub-set of) T-Core module

+Scheduling language

• Programming language (Python, Java)• Modelling language (UML Activity diagram, Petri-Net, DSL for scheduling)

Transformation Language

45

GENERAL PURPOSE VS. PROBLEM-SPECIFIC TRANSFORMATIONS

• There are manymany transformation languages and tools out there

– Very good at what they do

• Most of them tend to provide a genericgeneric tool to solve any kind of model transformation problem

– They must therefore be very expressiveexpressive

– AnalysisAnalysis of transformation models built using these general purpose transformation is very hard

• One can use T-Core primitives to restrict a transformation language for one specific purpose

– The expressiveness then depends on the glue language used and the primitive operators chosen

46

PROBLEM-SPECIFIC MTLS WITH T-CORE

47

48[10] Fischer, T., et. al., (2000) Story diagrams: A new graph rewrite language based on the UML and Java. In Ehrig, H., et al., (eds.), Theory and Application of Graph Transformations, LNCS, 1764, pp. 296–309. Springer-Verlag.

FUJABA: FOR-ALL PATTERN [10]

FUJABA: FOR-ALL PATTERN

49

FUJABA: FOR-ALL PATTERN

50

AMALGAMATION RULES:REPOTTING THE GERANIUMS [20]

“Repot all flowering geraniums whose pots have cracked”

51[20] Rensink, A. and Kuperus, J.-H. (2009) Repotting the geraniums: On nested graph transformation rules. In Margaria, T., Padberg, J., and Taentzer, G. (eds.), GT-VMT’09, EASST.

PY-CORE

52

Combine T-Core with a programming language: Python

PY-COREQuery

53

PY-COREAtomic Rule

54

PY-CORERule applied as long as possible

55

PY-CORECombining rules with Python

56

MTLS BASED ON T-CORE

• T-Core seems well fit to describe a common basis for transformation engines.

• How can we build a transformation language?– Meta-Model

Abstract Syntax: depends on the problem the MTL should solve Concrete Syntax: how user-friendly should it be (depends on the target users)

– Semantics Semantic Domain:

– Formal (theoretical) formalism to analyse the MTL– T-Core to execute the transformation

Semantic Mapping function– Link between the abstract syntax and to the language of the semantic domain– Embed (sub-set of) T-Core in an “executable meta-model”

57

MODELS, META-MODELS, AND TRANSFORMATIONS

• T: operation that transforms the model M1 into M2.• MT: model of a transformation that transforms any model of MM1 into a

model of MM2.• MMT: meta-model of all transformations that transform any meta-model.• MMM: meta-model of the language used to describe meta-models.

58

conforms to

is modelled by

transformed to

M M’

T

MM1 MM2MMT

MMM

MT

MODELS, META-MODELS, AND TRANSFORMATIONS

• MMTU: meta-model of the transformation units (rules, primitive operators, ...)

• MMSC: meta-model of the scheduling language

• MMPL: meta-model of the pattern language59

M M’

T

MM1 MM2MMT

MMM

MT

MOTIF-CORE [20]

60

DEVS [21]T-Core

[20] Eugene Syriani and Hans Vangheluwe. A Modular Timed Model Transformation Language. School of Computer Science, McGill University, SOCS-TR-2010.4, March (2010). [21] Zeigler, B. P. Multifacetted Modelling and Discrete Event Simulation. Academic Press (1984).

MOTIF-CORE

61

DEVST-Core

MoTif-Core

MOTIF-CORE: ASYNCHRONY

• Asynchrony

• Parallelism

GReAT Test/Case block [12]

62[12] Agrawal, A., Karsai, G., Kalmar, Z., Neema, S., Shi, F., and Vizhanyo, A. (2006) The design of a language for model transformations. SoSym, 5, 261–288.

MOTIF-CORE: VISUAL REPRESENTATIONMore Readable: Repotting the geraniums

63

IS MOTIF-CORE OPTIMAL?

• Soundness of MoTif-Core can be proven (based on DEVS)– Needed because of asynchronous behaviour

• MoTif-Core is a meta-modelled language– Closed system

– Open for extension

• Timed formalism– Simulation

– Real-Time

• MoTif-Core is very expressive– BUT it requires expertise in DEVS

– Not trivial to use

64

MOTIF FRAMEWORK

65

MOTIF META-MODEL

66

MMSC

MMTU

PRECISE MODELLING OF TRANSFORMATIONS [21]

What about MMPL?

Unlike the transformation units and scheduling sub-languages, the pattern language depends on other languages: the domains of the transformation

1. Generic pattern language+ Most economic solution - Generic concrete syntax (MOF-like) - Allow to specify patterns that will never occur

2. Customized pattern language+ Concrete syntax adapted to the source/target languages (DSL)+ Exclude patterns that do not have a chance to match - More work for the tool builder

67[21] Kühne, T.; Mezei, G.; Syriani, E.; Vangheluwe, H. & Wimmer, M. Systematic Transformation Development. Journal of the ECEASST: 21, Multi-Paradigm Modeling (best paper), Denver (2009).

DOMAIN-SPECIFIC PATTERN LANGUAGESRAM Process: (quasi-)Automatically generated environment for pattern language

68

Input Meta-Model Output Meta-Model

Relax Augment ModifyRelax Augment Modify

Customized Pattern Meta-Model

DOMAIN-SPECIFIC PATTERN LANGUAGES

RelaxationRelaxation:• Concretize abstract entities

• Reduce minimal multiplicity constraint

• Constraints (automatic?)

– Free form: no constraints

– Valid elements: ensure typing

– Valid multiplicities: enforce (relaxed) multiplicities

– Valid constraints: enforce (a subset of) meta-model constraints

RAM Process: generate pre-/post-condition patterns meta-models

69

DOMAIN-SPECIFIC PATTERN LANGUAGES

AugmentationAugmentation:• Type all meta-model entities to MT(pre/post)_Element

• Add model transformation specific properties

– Labels

– Parameter passing (pivots)

– Allow abstract rules*

– Other (e.g., isProcessed)

• Generic elements

• Trace elements

RAM Process: generate pre-/post-condition patterns meta-models

70

DOMAIN-SPECIFIC PATTERN LANGUAGES

ModificationModification:• Pre-condition pattern

– Attributes are of type constraintconstraint

• Post-condition pattern

– Attributes are of type actionaction

• Concrete syntax– Abstract classes

– Association ends

– Other (e.g., replace topological visual syntax constraints)

RAM Process: generate pre-/post-condition patterns meta-models

71

DOMAIN-SPECIFIC PATTERN LANGUAGESRAM Process: Generate the MMPL for Finite State Automata

72

Relax Augment Modify

MOTIF IN ACTION

73

CONCLUSION

• Realized there are many uses and applications where model transformation is needed

• Motivated need to have transformation tailored to the specific problem to solve

• Presented a framework that allows to build a product line of transformation languages

– SBL + T-Core

– Py-Core

– MoTif

74

CHALLENGES FOR INDUSTRIAL ADOPTION

• ScalabilityScalability– Size of source model

How big of a model can be handled: 103, 105, 106 elements?

– Size of transformation Size of the total sequence of rules applied Number of rules evaluated at a given point

• ExpressivenessExpressiveness– Pattern language

– Scheduling language

• Reversibility / BidirectionalityReversibility / Bidirectionality– Handle arbitrarily complex attribute constraints

75

CHALLENGES FOR INDUSTRIAL ADOPTION

• AnalysisAnalysis– Model Checking

Input & output model Transformation model

– Verification Transformation: correct application, property satisfaction Rules: parallel independence

• TestingTesting– Adequate test input

How to assess quality of models?

– Adequate design of oracle Generic? Domain specific? Transformation specific?

76

CHALLENGES FOR INDUSTRIAL ADOPTION

• DebuggingDebugging– Transformation

Appropriate support for user to determine origin of failure

– Generated Artefacts Debug in terms of output model (or input model)

• TraceabilityTraceability– Trace back to origin of error

– Trace back to which element the created/modified element originated form

• EvolutionEvolution– Of the languages

– Of the transformations

77