Máster Oficial en Tecnología de la Información y Sistemas ...kybele.escet.urjc.es/mtisi/sisbm/documentacion/[mtisi.isbm-2010...02/03/2010 1 Classifying Model Transformation Approaches

02/03/2010

1

Classifying Model Transformation Approaches

Máster Oficial en Tecnología de la Información y Sistemas InformáticosIngeniería de Software Basada en Modelos

@Móstoles (MADRID) ─ 2 March, 2010

Verónica A. Bollati

Kybele Research Group

Rey Juan Carlos University (Madrid - Spain)

Classifying Model Transformation Approaches 2 march, 2009 @Móstoles (MADRID)2

Outline

Motivation

Model Transformation Approach

Case Study

Conclusions

02/03/2010

2


Outline

Motivation


Case Study

Conclusions


MotivationMDE - MDA

MDEprinciples

Role of models Automation

MDA

Standards to formalize MDE principles

Categorization of abstraction levels

XMI - QVT - OCL - SPEM - KMD

CIM

PIM

PSM

02/03/2010

3


MotivationMDA

PIM

PS

M

<<

map

pin

gs P

IM

-P

IM

>>

<<

map

pin

gs P

SM

-P

SM

>>

<<

map

pin

gs P

IM

-PS

M>

>

CIM


Model to Model TransformationVertical

Transformations

Horizontal

Transformations


MotivationMDA

PIM

PS

M

<<

map

pin

gs P

IM

-P

IM

>>

<<

map

pin

gs P

SM

-P

SM

>>

<<

map

pin

gs P

IM

-PS

M>

>

CIM

CODE


Model to TextTransformation

02/03/2010

4


MotivationMDA

PIM

PS

M

<<

map

pin

gs P

IM

-P

IM

>>

<<

map

pin

gs P

SM

-P

SM

>>

<<

map

pin

gs P

IM

-PS

M>

>

CIM

CODE


“...The transformation operation is the most important operation in model engineering...”

J. Bézivin


MotivationModel Transformation

What is the model transformation?“Model transformation is the process of converting one model to another model of the same system”

[MDA Guide – OMG, 2001]

“ Automated processes which take one or more source models as input and produce one or more target models as output, following a set of transformation rules ”

[Sendall, MT – the Heart and Soul of MDSD]

“ A Model Transformation is a program which mutates one model into another; in other works, something akin to a compiler ”

[Tratt, L. MT and tool integration]

“Automatic generation of the target model from a source model, which conforms to the transformation definition“

[Kleppe et. al, The MDA: Practice and Promise]

02/03/2010

5


MotivationModel Transformation

Model Transformations are the key to automate any model-driven development process

Meta-Meta-Model(MMM)

Meta-Model B(MMb)

Model Transformation language Meta-Model

(MtMM)

Meta-Model A(MMa)

Model Transformation (MMa2MMb)

Model A(Ma)

Model B(Mb)

source target

Model Trasnformation Engine

conforms touses


Outline

Motivation


Case Study

Conclusions

02/03/2010

6


Outline

Motivation


Case Study

Conclusions



Sendall, S. and Kozaczynski, W. Model Transformation: The

Heart and Soul of Model-Driven Software Development.IEEE Software. 20, 5 (Sep. 2003), 42-45.

K. Czarnecki and S. Helsen. Classification of model

transformation approaches.2nd Workshop on Generative Techniques in the context of Model Driven Architecture, October 2003.

Tratt, L. Model transformations and tool integration. Journal of Software and Systems Modelling (2004).

Jezequel, J.M. Model Transformation Techniques.(http://modelware.inria.fr/rubrique21.html), 2005.

T. Mens y P. Van Gorp, A Taxonomy of Model

Transformation.l Workshop on Graph and Model Transformation (GraMoT) 2005.

http://modelware.inria.fr/rubrique21.html

02/03/2010

7



Sendall, S. and Kozaczynski, W. Model Transformation:

The Heart and Soul of Model-Driven Software

Development.IEEE Software. 20, 5 (Sep. 2003), 42-45.









Sendall, S. and Kozaczynski, W. Model

Transformation: The Heart and Soul of Model-

Driven Software Development.

IEEE Software. 20, 5 (Sep. 2003), 42-45.

Classification of approaches to MT definition

Direct model manipulation

Intermediate representation

Transformation Languages

Desirable characteristics of MT languages


02/03/2010

8


Model Transformation ApproachSendall, S. and Kozaczynski

Direct model manipulation

Modeling tool used maintains a internal representation of

the models.

APIS to access and handle these internal representation.

A new representation of a given model can be generated

The application of this approach to define MT results quite

simple APIs are defined in GPL, like JAVA, so there is no previous learning

Define transformations in different contexts or implying

models at different abstraction levels could result too

complex Languages were not intended for direct model manipulation but for implementing

tasks over concrete platforms



Intermediate representation (typically, XML format)

To export the models to a common format

The transformation are defined using some language supporting this format

Use to be related with the XML technical space

Models are represented using the XMI standard

The transformations are defined using XSLT

Complex and non-interactive

The main problem of XML approaches to MT is

the hierarchical nature of XML, opposite to the

nature of models that can be shown as graphs

02/03/2010

9



Transformation Language support

The most suitable according to authors

Declarative, Procedural or a combination of both

Graph Transformations approach: GReAT & VMT

Rule rewriting: MAUDE

Nowadays this approach is commonly referred as

Domains Specific Languages (DSL) for MT.

Desirable characteristics for a MT language

Mechanism to define Preconditions

Definition of complex rule by composition of simple ones

Graphical representation to increase the usability












02/03/2010

10


Model Transformation ApproachK. Czarnecki and S. Helsen


transformation approaches.

2nd Workshop on Generative Techniques in the context of Model Driven Architecture,

October 2003.

The most commonly referenced classification of

MT approaches by MT developers

Provides with a set of new concepts that allow

distinguishing between different MT approaches,

and could be considered as a de-facto standard



A taxonomy (a feature model) for the classification

of MT approaches and the corresponding survey

Feature Model

• Variables

• Patterns

• Logic

• Deterministic

• Non Deterministic

• Interactive

• User-based

• Dedicated support

• New one

• Same

02/03/2010

11



Model TO Code approaches

Visitor-based: the code is written while the internal representation of the model is visited. (jamda)

Template-based: a transformation engine reads the model/s and forms the output based on a separate set of rules – in the form of code templates (ArcStyler, AndroMDA, Codagen Architect; open-source: Velocity, XDoclet)



Model TO Model approaches

Direct-Manipulation: based in the use of APIs to access the internal representation of models (JMI)

Relational: based on defining the relations that must be kept between the input and output artifacts.

Declarative approaches based on mathematical relations (QVT-Partners, Codagen QVT)

Graph Transformations: based on theorical work on GT + typed graphs (VIATRa, ATOM, GreAT, UMLX, BOTL)

02/03/2010

12



Model TO Model approaches Structure-Driven: (QVT Operational Mappings)

imperative transformations in the MT literature

1. Create the hierarchical structure of the target model

2. Sets the attributes and References

Hybrid: combine different techniques from the previous

categories

ATL: fully declarative/imperative or hybrid trans rules

XDE: OCL queries or Java callouts to select source elements

XML: suffering from the mentioned problems regarding

complexity, semantics loss and lack of user interaction



Satisfactory solutions for M2Code but not for M2M

Direct Manipulation becomes impractical (most low level)

Structure-driven are suitable for certain contexts

(UML2RDBMS)

GT-based are powerful and declarative but too complex

Practical experience

Just in the beginning of M2M transformations

Lack of controlled experiments

The need for a collection of benchmark problems

02/03/2010

13












Model Transformation ApproachTratt, L.

Tratt, L. Model transformations and tool integration.Journal of Software and Systems Modelling (2004).

Focus on transformation traceability as a way

towards tool integration

Proposes a method for MT to enforce tracing

information:1. Identify appropriate elements to transform

2. Transforming elements

3. Retaining tracing information

4. Detecting updates in one model and perform the corresponding

operations on the other one

In fact, just the first and second step are followed when applying

MT


02/03/2010

14



Classification of techniques to define MT.

Program Transformation

Unidirectional and stateless

XSLT

Tree structure of XML docs VS Graph structure of models

Graph Transformation

a particular category of rule-based transformation typically represented diagrammatically

Theorical properties + Models like graphs

Complexity and lack of change propagation support



Classification of techniques to define MT.

Others:

Defining MT as class diagrams: just for specification

Variations of OCL language

Use of MAUDE to execute and verify MT

QVT: seek a standard way of performing MT

TRL a rule-based imperative language

xMOF a declarative approach based on OCL

QVT-Partners declarative specifications and imperative implementations

ATL imperative bodies wrapped into declarative shells

02/03/2010

15



Conclusion:

The majority of the existing proposals at that time, follow a declarative approach since it results more suitable to support change propagation and maintaining the traceability

New proposal for MT definition:

CONVERGE: an imperative MT language attempt that has derived in the MT language

Provides with mechanisms to ensure the traceability maintenance automatically












02/03/2010

16


Model Transformation ApproachJezequel, J. M.

Jezequel, J.M. Model Transformation Techniques.

(http://modelware.inria.fr/rubrique21.html), 2005.

The less formal of the considered classifications

Much more intuitive that the rest of them and

collects ideas spread all along the previous

classifications

The most recent, it is also the most appropriate

according to the current reality.


Model Transformation ApproachJezequel, J.M.

Depending on the tools and approaches used:

General purpose programming languages

Generic transformation tools

CASE tools scripting languages

Dedicated model transformation tools

Meta-modeling tools


02/03/2010

17



General purpose programming languages

Any language with the correct library may be used to

code model transformations

Java, VB, C++, C#, Eiffel ...

Currently available in the tools via APIs

Rules and scheduling implemented from scratch using

the programming language

For example:

JMI (MOF-compliant Java Interface) JSR-000040 Java™

Metadata Interface



Generic transformation tools

XSLT / XML

More batch than interactive

Too verbose

Better for simple transformations

GT-based

Declarative, based on the theoretical work on GTs

Operates on typed, attributed, labeled graphs

Rule (LHS, RHS : Graph Pattern)

Non-deterministic scheduling and application strategy Require careful consideration of termination of the transformation process and the rule

application ordering

Well known technology, but hard to master

02/03/2010

18



CASE tools scripting languages

There are a lot of CASE tools that use their own scripting language:

Arcstyler from Interactive Objects MDA-Cartridge, JPython (Python & Java)

Objecteering from Objecteering Software J language

OptimalJ from Compuware TPL language

Fujaba (From UML to Java and Back Again)

Good level of maturity

Excellent integration with their CASE tool

Proprietary languages and/or tight coupling with the CASE

Often developed as a second thought, not central



Dedicated model transformation tools

Some kind of DSL for transformation (OMG QVT)

Simplify development and maintenance of MTs

Higher expression power

Enhanced structuration

Several approaches: GT-based, relational, structure-

driven, hybrid

Commercial Mia-Transformation (Mia-SW), PathMATE

Academic Tools ATL & MTL (INRIA), AndroMDA, BOTL, Coral, MOLA

Familiar with the prolog-like style of rules writing

Advantage of a dedicated explicit language vs. a general

purpose language

02/03/2010

19



Meta-modeling tools

This reflexive approach allow to:

Build (OO) Models of Transformations

Use MDE to run them

There is already several tools available.

Commercial tools:

• MetaEdit+ from MetaCase

• XMF-Mosaic from Xactium

Open-Source:

• KerMeta from INRIA



Transformations are assets apply sound SE

principles Modeling From requirements, analysis, design, to implementation, V&V, and

Configuration Management

Developing Model Transformations in-the-large is not

different from developing software Unclear Requirements, Bugs, Learning Curve (yet another language)…

A specific language does not help much to address

these generic SE issues Rely on proven techniques: OO languages, patterns, frameworks

We must use a Model-Driven Approach

to Model Transformation

02/03/2010

20












Model Transformation ApproachMens, T and Van Gorp P.



Propose a taxonomy of model transformation

Help a software developer choosing a particular MT

approach that is best suited for his needs

Help tool builders to assess the strengths and

weaknesses of their tools compared to other tools

Help scientists to identify limitations across tools or

technology that need to be overcome by improving the

underlying techniques and formalisms


02/03/2010

21



Taxonomy proposal

What needs to be transformed into what?

Number of source and target models:

• multiple source models and/or multiple target models

Technical space:

• determined by the metametamodel

Endogenous vs. exogenous transformations:

• Endogenous: same metamodel

• Exogenous: different metamodel

Horizontal vs. vertical transformations.

Syntactical vs. semantical transformations.



Taxonomy proposal

Level of automation

MT that can be automated

MT that need to be performed manually

Complexity of the transformation

Preservation

02/03/2010

22



Taxonomy proposal

Success criteria for a transformation language or

tool

Creating/Reading/Updating/Deleting transformations

(CRUD)

• Create a new transformation or upgrade an existing

transformation

Suggesting when to apply transformations

• dedicated tools can be built that suggest which MT might be

appropriate in a given context.

Customizing or reusing transformations

• use the inheritance mechanism to reuse the specifications of

MT



Taxonomy proposal


tool

Verifying and guaranteeing correctness of the

transformations

• Mechanism to check:

» syntactically correct and complete

» semantically correct

Testing and validating transformations

• Systematic testing and validation techniques to

transformations to ensure that they have the desired behavior

02/03/2010

23



Taxonomy proposal


tool

Dealing with incomplete or inconsistent models

• Detect and resolve inconsistencies in the transformations or in

the models transformed.

Grouping, composing and decomposing

transformations

• Compose existing transformations into new composite ones

» to increase the readability, modularity, maintainability and

scalability of a transformation language.



Taxonomy proposal


tool

Genericity of transformations

• higher-order transformations

Bidirectionality of transformations.

• transform the source model(s) into target model(s), and the

inverse transformation.

Supporting traceability and change propagation:

• link between the source and target models,

• consistency checking mechanism

• incremental update mechanism

02/03/2010

24



Taxonomy proposal

Quality requirements for a transformation

language or tool

Usability and usefulness

• Serve a practical purpose.

• Intuitive and efficient to use.

Verbosity vs. Conciseness

• Verbose, introducing extra syntactic sugar for frequently used

syntactic constructs

• Conciseness, the transformation language should have as few

syntactic constructs as possible.

Extensibility

• Easy to extend adding new functionality.



Taxonomy proposal

Quality requirements for a transformation

language or tool

Performance and scalability

• Large and complex transformations or transformations of large

and complex software models without sacrificing performance

Interoperability

• Easy to integrate with other tools.

Acceptability by user community

Standardization

• Compliant to all relevant standards (such as XML, MOF, UML)

02/03/2010

25



Taxonomy proposal

Which mechanisms can be used for model

transformation?

Techniques

• Declarative vs. Imperative

Languages

Methods


Model Transformation ApproachConclusions

Lessons learned from the existing classifications:

Focus on the technique used for defining the

transformation

Too complex

Based on theorical assertions

02/03/2010

26


Model Transformation ApproachOur Proposal

More simple classification

Nature of the input and

the output models

Use the lessons learned

(own experience)

Traditional benchmarks

for MT techniques

Classification Criteria

for a MT taxonomy

Makes easier the election of a MT technique

for a concrete problem



Traditional benchmarks for MT techniques

Expressiveness (Turing-complete)

Usability / Complexity

Consistency (transactional behavior)

Support for rule composition

Reversibility / Synchronizability / Updateability

Traceability

Graphical support

Tool support

02/03/2010

27



Classification Criteria for a MT taxonomy:

Direct / Reverse

AB

Vertical / Horizontal

PIM2PIM, PSM2PSM, Code2Code

PIM2PSM, PSM2Code

Transformation techniques for different domains

Technique will be more o less suitable depending on the domain

Transformation techniques for different aspects:

Behavior models need from more complex languages

Degree of Formality

PSM VS PIM



Classification Criteria for a MT taxonomy:

Semantic capabilities

Possible semantics loss derived by using a given MT approach

Source/Target model cardinality

1:1, 1:N, N:1 or N:M

Portability

Model In/Out

Paradigm (Declarative / Imperative / Hybrid)

MOF Complaint

QVT Complaint

OCL Syntaxes

02/03/2010

28


Outline

Introduction

Model Transformation

Case Study

Conclusions


Outline

Introduction


Case Study

Conclusions

02/03/2010

29


Case StudyFramework

XML

SchemaSQL

COMPORTAMIENTOHIPERTEXTOCONTENIDO

PIM

PS

M

Modelo de Dominio Modelo de Negocio

<<

mappin

gs P

IM-

PIM

>>

<<

mappin

gs P

SM

-PS

M>

>

<<

mappin

gs P

IM-P

SM

>>PI

M

PS

M

CODE

PSM

Conceptual Data Model

ORModel

XML Model

M2DAT/DB

MOFScript

MIDAS


Case StudyFramework

PIM

PSM

Conceptual Data Model

ORModel

XML Model RubyTL

QVT

02/03/2010

30


Case StudyModel Transformation

Meta-Meta-Model(MMM)

ORBD4ORA Meta-Model

Model Transformation language Meta-Model

(MtMM)

UML Meta-Model

Model Transformation (MMa2MMb)

UML Model

ORBD4ORA Model

source target

Model Trasnformation Engine

conforms touses


Case StudyATL

ATL

Component of the AMMA (Atlas Model

Management Architecture) platform

Developed over the Eclipse platform

IDE that incorporates facilities like dedicated editors,

debuggers, code completion, syntax highlighting,

metamodel registry

Developed as an EMF component

Hybrid (declarative style is recommend)

Based on the OCL specification

02/03/2010

31


Case StudyATL

ATL

Transformations are unidirectional

Source model read only

Target model write only

Very stable and mature and it is constantly

improved.

There is a huge amount of available

documentation in the form of manuals, usage

scenarios and user newsgroups


Case StudyQVT

QVT Standard

Family of languages for defining transformations

proposed by the OMG

QVT Core is a relational language (declarative).

• Set of basic constructions that allow defining source and

target patterns and variables binding.

• Forms the basis for the other two languages and is not really

meant to be directly used (as far as we understood it).

QVT-Relations is another declarative language defined

in top of QVT-Core.

• It supports complex expressions and a graphic notation.

QVT-Operational Mappings is an imperative language

that extends the previous.

02/03/2010

32


Case StudyQVT

QVT

Operational

Mappings

Relations

Core

RelationsToCore

TransformationBlack

Box


Case StudyQVT Engine

QVT engine

Developed by Open Canarias S. L

Based on the translation of supported transformation

languages to executable intermediate notation called

Atomic Transformation Code (ATC)

Operates as a byte-code

Implement Operational Mappings y Core

Developed on Eclipse and EMF.

Open-source

Available in: www.modelset.es/atc/atcdownload.html

02/03/2010

33


Case StudyQVTo

QVTo

Developed on Eclipse and EMF

Imperative paradigm

Based on the OCL specification

Transformations are unidirectional

Source model read only

Target model write only

Documentation is poor, almost reduced to the

QVT-Operational Mappings specification


Case StudyQVTo

QVTo

Metamodel

QVTo

Model

ATC

Metamodel

ATC Model

Conform to Conform to

QVTo2ATC

Transformation

VTE

Execution

02/03/2010

34


Case StudyQVT

QVT

Operational

Mappings

Relations

Core

RelationsToCore

TransformationBlack

Box


Case StudyMediniQVT

MediniQVT

Is a commercial product from ikv++

Integrated in Eclipse

Seems the more stable and mature

implementation of QVT-Relations.

It is freely available under Eclipse Public License

with non-commercial purposes

Includes tools for convenient development of

transformations

Graphical debugger and an editor with code

completion.

02/03/2010

35


Case StudyMediniQVT

MediniQVT

Supports bidirectional transformations

but suffers from some drawbacks

Works atop of EMF

It is distributed as an Eclipse plug-in.

Documentation is poor, almost reduced to the

QVT-Relations specification


Case StudyRubyTL

RubyTL

Transformation language defined as a DSL

embedded in Ruby

Influences its concrete syntax.

Provides an Eclipse-based IDE, called AGE

Includes a Ruby editor with syntax highlighting, code

templates and some code completion

Hybrid transformation

Declarative expressiveness is inappropriate for

complex transformations that can require an imperative

style.

02/03/2010

36


Case StudyRubyTL

RubyTL

Designed as a extensible language

Based on plugins to add new features to a basic core

Includes significant features such as the

organization of rules in phases

Is not based on OCL

Syntax is rather intuitive

Bidirectional transformations

Specified at the time of configuring the transformation

execution, one might modify the source model


Case StudyRubyTL

RubyTL

Transactional behaviour

If errors arise during the execution of the

transformation, the target model is not created

There are the lack of available documentation

and successful use cases showing its application

It does not plan any QVT alignment

Although it was not developed to run on top of

EMF, it works efficiently with Ecore models

02/03/2010

37


Case StudyVIATRA

VIATRA (VIsual Automated model

TRAnsformations)

Graph-based language

Mapping rules graph rewriting rules

ASM complex transformations

Provide a general-purpose support for the entire

life-cycle of engineering MT

Is include in Eclipse GMT EMP

Metamodelling language, based on algebraic

specifications: VPM


Case StudyVIATRA


TRAnsformations)

Features

Languages

• VTML: for capturing models and modeling

• VTCL: for specifying MT

• VTTL: for supporting template based code generation together

with a code formatter for splitting output of code generation

into multiple files

02/03/2010

38


Case StudyVIATRA


TRAnsformations)

Features

Core Engines

• A library for supporting the VPM metamodeling core

• A graph pattern matching engine

• An interpreter for executable ASM and GT specifications

• Extensible model importer and exporter framework

Graphical User interface for Eclipse

• Tree viewer and editor for the model space

• The Graphical User interface is not available.


Case StudyVIATRA


TRAnsformations)

There is available documentation.

The syntax is not very intuitive.

There is no way of defining auxiliary functions in

VIATRA.

The whole transformation must be coded inside the

rules.

Problems at the time of importing the UML-Ecore

metamodel and conforming models

02/03/2010

39


Case StudyConclusions

ATL QVTo MediniQVT RubyTL Viatra

Tra

dit

iona

l

Benc

hm

arks

Expressiveness High High Medium High Medium

Usability/

ComplexityMedium Medium Medium Semi-Complex Complex

Consistency Medium Medium Medium High Low

Support for rule

compositionHigh High High High High

Traceability CompleteSemi-complete

(QVT-R)Semi-complete No No

Graphical Support No No No NoUnder

development

Cri

teri

afo

rM

T

taxon

omy

Direct / Reverse Uni Uni Bid Bid Uni

Vertical/Horizontal V/H V/H V/H V/H V/H

Semantic Capabilities High High High High Medium

Input/Output

CardinalityN – 1 N – 1 N - 1 1 - 1 N-N

Portability High High High High Low*

Model InOut No No No Yes * Yes

Paradigm Hyb Imp Dec Hyb Based-graph

MOF-based Yes Yes Yes Yes Yes

OCL-based Yes Yes Yes No Yes


Outline

Introduction


Case Study

Conclusions

02/03/2010

40


Outline

Introduction


Case Study

Conclusions


Conclusions

MDE changed the role of models in the

prospect of software engineering

First class entities conducting thread in the

development process

Development set of M2M transformations until

the working code is generated

The transformation operation is one of

the most important task in MDE

02/03/2010

41


Conclusions

To support the need of defining MT

A vast amount of MT proposals emerged

New MDE methodologies or in adopting their

previous ones to the new paradigm.

Which one is the most suitable MT approach

to apply to their particular situations?

Classification of MT approaches to allow select

the most convenient approach


Conclusions

Our proposal

Traditional benchmarks for transformation

techniques

MT taxonomy focused on the nature of the input

and output models.

Have applied different MT approaches in real

case studies in the frame of MIDAS

02/03/2010

42


Conclusions

Future works

Apply the classification in others MT approach

Apply MDE to Model Transformations

Transformation Model

• Raise to abstraction level

• Automatically generate the model transformation from a high-

level specification

Metametamodel for the specification of

high level model transformations

Meta-tool


Conclusions

Independent of the model transformation engine

selected

Defining the transformation in a transformation

model

High-level specification into a lower level

transformation completely operative for any

transformation engine

Portability

Automatization

Meta-tool

02/03/2010

43


Conclusions

Meta-Meta-Model

Transformation

Meta-Model

RubyTL

Meta-Model

MediniQVT

Meta-Model

QVTo

Meta-Model

ATL

Meta-Model

Viatra

MT

RubyTL

MT

MediniQVT

MT

QVTo

MT

ATL

MT

Viatra

Model

Transformation

MeTAGeM

PIT

PST

Code ATL Code MediniQVT Code Viatra Code RubyTLCode QVTo


Conclusions

02/03/2010

44

Master Oficial en Tecnológia de la Información y Sistemas InformáticosIngeniería de Software Basada en Modelos

@Móstoles (MADRID) ─ 3 March, 2010

Verónica A. Bollati

Kybele Research Group

Rey Juan Carlos University (Madrid - Spain)

Documents

Máster Oficial en Tecnología de la Información y Sistemas ...kybele.escet.urjc.es/mtisi/sisbm/documentacion/[mtisi.isbm-2010...02/03/2010 1 Classifying Model Transformation Approaches