model-driven development of model transformations

““Model-Driven Development of Model-Driven Development of Model Transformations”Model Transformations”

Pieter Van GorpPieter Van GorpProefschrift ingediend tot het behalen van de graad vanDoctor in de Wetenschappen

Model EverythingModel Everything

The System (part of the real world)

Model of the external structure

Model of the internal structure

Model of the electricity

models

models

modelsOmit detailsSupport a purpose

Java 1

CORBABPEL.XML

EJBJMS, JCA,

WSIF, …

CORBA CORBABPEL.XML

BPEL.XML

Language Evolution in Software DevelopmentLanguage Evolution in Software Development

VB C++VB.NET C#

Bla 1

Bla 3Bla 2

The next best thing

The next best thing

The next best thing

?

??

Escaping from Language evolution & extinction?Escaping from Language evolution & extinction?

1954 - FORTRAN 1958 - LISP 1958 - ALGOL 58 1959 - COBOL 1962 - APL 1962 - Simula 1964 - BASIC 1964 - PL/I 1970 - Pascal 1970 - Forth 1972 - C 1972 - Smalltalk 1972 - Prolog 1973 - ML 1978 - SQL 1983 - Ada 1983 - C++ 1985 - Eiffel 1987 - Perl 1989 - FL (Backus) 1990 - Haskell 1990 - Python 1991 - Java 1993 - Ruby 1995 - PHP 2000 - C# …

Java RMIJDBCJMSEJB 1HibernateEJB 2Generics…

OO Modeling

UMLDataSetsNHibernateODXGentle.NETUbikPersist.NET...

Keep it stable “Human

Friendly”

Modeling LanguageModeling Language: : Keep it StableKeep it Stable

specifyconforms-to UMLUML

conforms-to JavaJava

conforms-to C++C++Programmer

interpret

specifyspecify…

Modeling Languages & ToolsModeling Languages & Tools:: Human FriendlyHuman Friendly

• Example: Decompose complex models into Views- Association View

- Inheritance View

- Any other task-specific view- Always keep track of the big picture

- Automatic Consistency Maintenance• Mainstream: several industrial tools

modelsmodels

One Step Further:One Step Further:Multiple Software Models, Multiple Levels of AbstractionMultiple Software Models, Multiple Levels of Abstraction

Purpose of Analysis model: conceptual data modeling

Purpose of Design model: Choosing datatypes (linkedlist etc.) Optimizing performance (bidirectional references or not...) Evaluating architecture (MVC, ...)

Clean separation between models iterative development

Transformations in Conventional Software DevelopmentTransformations in Conventional Software Development

DrawbacksDrawbacksManual

!

Doing the transformations by hand is

expensive and error-prone!

If only we couldautomatically transform

those models intowhatever the machine

requires!

Anno 2000Anno 2000

... and we do them

over and over for each project...

Transformations in Model-Driven Software DevelopmentTransformations in Model-Driven Software DevelopmentRien ne se perd, rien ne se crée,

tout se transforme!

Thesis GoalsThesis Goals• Model the Model Transformations

- Evaluate the UML• Reuse expertise from the Application Modeling• Specialize for Transformation modeling

» Similar to specializing UML for specific application domains (BPM, DM, ...)

- State-of-the-art • Start

» Taxonomy: compare existing approaches, identify weaknesses» Graph Transformation Languages

• Improve» BUT: Maintain UML’s interoperability

- General Applicability: » Refactoring, » Synthesis, » Synchronization

• Derive Implementation Automatically: - Translate the Transformation Models automatically into an implementation

Model-Driven Development of Model TransformationsModel-Driven Development of Model Transformations

Principles of TranslationPrinciples of Translation

conforms-to

conforms-to

conforms-to

HieroglyphicHieroglyphicmodels

DemoticDemotic

Ancient GreekAncient Greek

models

......models

describing the repealing of various taxes and instructions to erect statues in temples

describing the repealing of various taxes and instructions to erect statues in temples

describing the repealing of various taxes and instructions to erect statues in temples

Principles of TranslationPrinciples of Translation

HieroglyphicHieroglyphicmodels

DemoticDemoticmodels

Thomas Young (1818): • Demotic Alphabet• Translation to Ancient Greek

Jean-François Champollion (1824): • Hieroglyphic Alphabet & Grammar• Translation Rules to Demotic

Noun, Verb, ...

Substantif,

Verbe, ...

Alphabet, Grammar,

Normalization,Translation Rules

Need to describe: 1) Structure of Demotic

& Hieroglyphic languages

2) Translation process

a “Metamodel” = a Model of a Language

Translation Process =Application of Transformations

TranslationTranslation

Normalization“Switch position of Subject and

Verb”Translation“LV PV O maps to …”`

Translation“LV PV O maps to …”

UML2CSP: 1. first normalize, 2. then translate!

A language for Modeling Translations...A language for Modeling Translations...

1. Metamodel• Structural model of the translation program

• Model of the input/output Languages• The language in which the input models are expressed

• Can be model of UML, BPML, YourOwnThing, ...

• Mainstream syntax: UML (MOF) Class Diagrams

• Standardized

2. Translation Rules• Behavioral model of the translation program

• Magnitude of new languages...

• Needs standardization...

• Without re-inventing the wheel!>> Align with (1)

>> Link to Class Diagrams

Standard Syntax for MetamodelingStandard Syntax for MetamodelingExample: UML MetamodelExample: UML Metamodel

UML MetaModel

(of UML)

UML MetaModel

(of UML)

UML Model (of racing game)UML Model (of racing game)

Standard Syntax for MetamodelingStandard Syntax for MetamodelingExample: UML MetamodelExample: UML Metamodel

UML MetaModel

(of UML)

UML MetaModel

(of UML)

UML Model (of racing game)UML Model (of racing game)

Standard Syntax for MetamodelingStandard Syntax for MetamodelingExample: UML MetamodelExample: UML Metamodel

UML MetaModel

(of UML)

UML MetaModel

(of UML)

UML Model (of racing game)UML Model (of racing game)

A language for Modeling Translations...A language for Modeling Translations...

1. Metamodel• Structural model of the translation program• Model of the input/output Languages

• The language in which the input models are expressed• Can be model of UML, BPML, YourOwnThing, ...

• Mainstream syntax: Class Diagrams = Object-Oriented Structural Modeling

• Standardized

2. Translation Rules• Behavioral model of the translation program• Magnitude of new languages...• Needs standardization...• Without re-inventing the wheel!

EXISTING

N E W

Related Software Models: Related Software Models:

Correspondences in DetailCorrespondences in Detail

AnalysisModel

DesignModel

INPUT model OUTPUT model

Modeling Transformation RulesModeling Transformation Rules

INPUT metamodel OUTPUT metamodel

Match, Create, Destroy, Copy

in terms of the metamodels

Class Diagrams too!Class

Diagrams

conforms toconforms to conforms toconforms to

Copying fragments of

models iscomplex!

» Example

IN/OUT metamodel

conforms toconforms to conforms toconforms to

OUTPUT modelINPUT model

processed byprocessed by processed byprocessed by

IN-to-OUT Transformation

readread writewrite

Modeling a Modeling a CopyCopy Operation OperationDerivationDerivation

Modeling a Modeling a CopyCopy Operation OperationDerivationDerivation

IN/OUT metamodel

OUTPUT modelINPUT model

<<copy>>

IN-to-OUT Transformation

readread writewrite

Modeling a Modeling a CopyCopy Operation OperationSummarySummary

Transformation Modeling Language:

(extension of) so-called“Story Diagrams”, in Standard UML syntax

Cognitive EvaluationCognitive Evaluation (of Transformation Modeling Language) (of Transformation Modeling Language)

Closeness of Mapping(syntax ~ metamodeling)

Juxtaposition(embedding… native Fujaba)

Role-Expressiveness(edges: relation to whole)

Progressive Evaluation(tool issue?)

Secondary Notation(2D layout, color, …)

Diffuseness (however: issue of input/output metamodels!)

Consistency(able to infer <<onCopy>> <<destroy>>)

+ -

T. R. G. Green. Cognitive dimensions of notations. In Alistair Sutcliffe and Linda Macaulay, editors, People and Computers V, pages 443–460, New York, NY, USA,1989. Cambridge University Press.

GeneralityGenerality ((of Transformation Modeling Language)of Transformation Modeling Language)

Synthesis

Refactoring

SynthesisSynthesis

RefactoringRefactoring

UML2CSPCM2RMCopy2GT

UML2CSPCM2RMCopy2GT

Pull Up MethodExtract InterfacePush Down Method

Pull Up MethodExtract InterfacePush Down Method

Model Synchronization

Model SynchronizationModel Synchronization

OperationalDeclarative, Hybrid:

>> outline for future work

OperationalDeclarative, Hybrid:

>> outline for future work

Normalization

NormalizationNormalization

UML2CSPUML2CSP

Chaining

ChainingChaining

UML2CSPUML2CSP

Thesis GoalsThesis Goals• Model the Model Transformations

- Evaluate the UML• Reuse expertise from the Application Modeling• Specialize for Transformation modeling

» Similar to specializing UML for specific application domains (BPM, DM, ...)

- State-of-the-art • Start

» Taxonomy: compare existing approaches, identify weaknesses» Graph Transformation Languages

• Improve» BUT: Maintain UML’s interoperability

- General Applicability: » Refactoring, » Synthesis, » Synchronization

• Derive Implementation Automatically: - Translate the Transformation Models automatically into an implementation

Model-Driven Development of Model TransformationsModel-Driven Development of Model Transformations

Towards Transformation Code…Towards Transformation Code…

HigherOrder

TransformationsCase Studies:1. Story Diagrams2. Copying

1. From Story Diagrams to JMI Transformation Code

2. From the Copy language to plain Story Diagrams

Higher Order TransformationsHigher Order Transformations

ModelTransformer.ftlTransFlow.ftlTransPrimitive.ftl

<<success>>,

<<failure>>,

<<each time>>

<<success>>,

<<failure>>,

<<each time>>

<<create>>,

<<destroy>>

<<copy>>,

<<create>>,

<<destroy>>

<<success>>,

<<failure>>,

<<each time>>

<<create>>,

<<destroy>>

Again as Story

Diagrams!

Eat your own

dogfood

getClasses(): FCollectio

n

remove(),

add(LinkedList l),

…MDA Standardizationof the state-of-the-art

(Fujaba 3)

Improvement of the state-of-the-art

(Graph Transformation,QVT)

Independent of the modeling platform!

ConclusionsConclusionsModel-Driven Development of Model TransformationsModel-Driven Development of Model Transformations

• Modeling of Model Transformations - Evaluation of UML

• Class & Activity diagrams sufficient for challenging transformation problems» Most popular diagram types!

• Profiles are good for language prototyping

- State-of-the-art • Start

» Taxonomy: compare existing approaches, identify weaknesses» Graph Transformation Language (Story Diagrams)

• Standardize» Interoperability (UML, XMI, JMI, MOF)» Views on Transformation Models

• Improve» Copy Operator» Maintain interoperability: language extensions should be considered more!

- General Applicability: » Refactoring, » Synthesis, » Synchronization

• Transformation of Model Transformations

• Final Conclusion- Transformations do not require fundamentally different modeling techniques!- Model & Transform Everything... but leverage mature languages and tools!

• Future Work- Hybrid Modeling Languages

» Scheduling, Directionality, Change Propagation, Versatility» Control flow