vanderbilt university 23 july 2003 metamodel based model migration jonathan sprinkle dissertation...

23 July 2003

Vanderbilt University

Metamodel Based Model Migration

Jonathan Sprinkle

Dissertation Defense

Given toward satisfaction of the requirements for a PhD in Electrical Engineering at Vanderbilt University

23 July 2003

Overview

• Introduction• Backgrounds• Framework

justification• Framework

description• Domain Evolution

Tool• Example• Conclusions

23 July 2003

Metamodeling

• A systematic process to specify a domain-specific language

• Specifies– Ontology– Abstract syntax– Static semantics

• Domain-specific languages…– Have benefits with their targeted use– Immediately introduce their own set of

problems

23 July 2003

Life before metamodeling

• Computing languages are used to create implementations of computer systems

• Have 1. syntax 2. ontology 3. dynamic semantics 4. static semantics (constraints)

• Languages can be classified (roughly) as – General purpose (multi-use, domain-

independent)– Domain-specific

• Domain-specific languages not widespread– Still required the 4-definitions (above)– Why do all that work, if there will be no future

use for it?

23 July 2003

Life after metamodeling

• High-level, domain-specific language syntax, static semantics, and ontology, can be represented with metamodels

• Language prototypes relatively easy to create

• Languages simple to modify on user request

• Still require a compiler to be fully functional

• Metamodeling lessens the work required to produce a domain-specific language

23 July 2003

MIC

• Model-Integrated Computing (MIC)– A crucial ingredient of MIC is the building of formal

specifications of a system or family of systems– Aims at the following goal (the “Golden Rule”):

Small changes in the requirements

should be reflected

by small changes in the

implementation.

??

23 July 2003

Implementation?

• To the modeler– the implementation is the model of the system, not the

artifact– They don’t care what’s “under the hood”, because that

is all abstracted away

23 July 2003

Modeling and metamodeling

• Domain-specific modeling languages can be created using metamodels– Provides for rapid development of the ability to do modeling in the domain– Domain models are changed to propagate change to the application level

Model Builder

Model Interpreters

Models

MIPS Environment

ModelInterpretation

ApplicationDomain

App.1

App.2

App.3

Application Evolution

Meta-LevelTranslation

MetaprogrammingInterface

Formal Specifications

Domain Evolution

23 July 2003


• Application evolution– Changes are made to the models– Model interpretation updates the executable

system

Model Builder

Model Interpreters

Models

MIPS Environment

ModelInterpretation

ApplicationDomain

App.1

App.2

App.3





Domain Evolution

23 July 2003

Domain Evolution

• Domain evolution– Changes are made to the metamodels

• Model migration– Changes must be made to the models as a

consequence of the changes to the metamodels

Model Builder

Model Interpreters

Models

MIPS Environment

ModelInterpretation

ApplicationDomain

App.1

App.2

App.3





Domain Evolution

23 July 2003

The need

Model Builder

Model Interpreters

Models

MIPS Environment

ModelInterpretation

ApplicationDomain

App.1

App.2

App.3





Environment

Evolution

• Preservation of the data is important• The application domain is generated from the models, so

the models will be necessary after the domain has evolved• Changes in the formal specifications of the domain may

require changes to the models in order for them to be “correct”

23 July 2003

Example

• Specialization of type

• Old type (Port) is made abstract, and replaced by two objects (Input and Output) that belong in different contexts

23 July 2003

What is required...

• How do you maintain data appropriately throughout the evolution of a domain??

• How do you do it while following the golden rule??

23 July 2003

Thesis statement

A description of the change in semantics between and old and a new DSML is a sufficient specification to transform domain models such that they are correct in the new DSML.

Further, the pattern that specifies the proper model migration is driven by the semantic mapping between the two, and may be fully specified by a model composed of entities from the old and new metamodels along with an algorithmic description of their modification.

23 July 2003

MM : Scope

• Preconditions for model migration– Existence of abstract syntax– Dynamic and static semantics– Existing domain models– Modified abstract syntax– Modified dynamic or static semantics

• Failure to have any of these present means that model migration is not the solution to the problem

23 July 2003

Methods/Techniques for MM

• Model rebuilding– Looking at old models and rebuilding them by

hand

• Graph-rewriting– PROGRES, XSL, GReAT– Create subgraphs using rule-based pattern

matching of a host graph (source graph)– Eventually create a “whole” graph

• Model transformations– E.g., Milicev– Create new subgraphs using rules – Graph-rewriting using metamodels

23 July 2003

Current Disadvantages

• Model Migration not treated as a domain– Each of these methods get the job done, but none

designed specifically for domain evolution– Thus, the “golden rule” is not achieved, as MM

solutions want to minimize description of the change in domains

• Current solutions only loosely coupled with the domain– Why not just use a known language rather than learn

how to use one of these new languages– None are tailored for MM needs (a -description)

• Current solutions not portable to similar problems

23 July 2003

Model Migration’s Domain

• Domain evolution is an archetypal problem found in all metamodeling tools

• There are common aspects found in the set of model migration tools

• Exists in general, not in terms of a particular implementation– independent of rewriting implementation machinery– may be integrated with any meta-metamodel

• The abstract, evolution language free of implementation details is termed the domain evolution framework (DEF)

• The evolution language tied to a rewriting implementation and a meta-metamodel is termed a domain evolution tool (DET)

23 July 2003

Why have a domain for MM?

• Use of ontology of the original and evolved metamodels during specification

• Domain concepts of MM used in specification– “becomes”, “delete on match”

• Ability to compare the two metamodels• Abstraction of the implementation

language

23 July 2003

Requirements for solution

• Distinguish models based on type• Consider models based on attribute

values or association roles• Provide unambiguous descriptions of the

implications of models that match the given criteria

• Simple metamodel changes should result in simple model migration specifications (golden rule)

23 July 2003

Requirements for solution

• Should be a variant of model transformation– Unmapped data preserved by default– Required specifications proportional to

change in semantics, not size of metamodels

• Operates more like a search/replace algorithm than a rebuild method

• Modulo the meta-metamodels and rewriting language implementation, all domain evolution tools can be the same!

23 July 2003

Domain Evolution Framework (DEF)

• The major contribution of the research• Is the abstract form and function of a

domain evolution tool (DET)• Contains hooks for specialization

– meta-metamodel, graph-rewriting engine, mapping functions, et al.

• Central method:– Maps from one domain to another using

Transform rules– Objects not mapped are copied directly– Has its own MoC for execution and control

flow

23 July 2003

MM: Layers of Usage


DEF

template<GME, XSL>

GME Domain Evolution Tool

M1M2 Domain Evolution Specification

GME Metamodel1

Rules

R1 R2

R4 R3

Sequence

R1 R2

R4 R3

DEF

template<GME, XSL>


GME Metamodel2

XSLScript

DEFDEF


(evolution tool layer)

(evolution specification layer)

(evolution framework layer)


template<meta-metamodel, graph-rewriting language>


DEF

template<GME, XSL>



GME Metamodel1

Rules

R1 R2

R4 R3

Sequence

R1 R2

R4 R3

DEF

template<GME, XSL>


GME Metamodel2

XSLScript

DEFDEF







1

23 July 2003

Evolution Tool Layer


DEF

template<GME, XSL>



GME Metamodel1

Rules

R1 R2

R4 R3

Sequence

R1 R2

R4 R3

DEF

template<GME, XSL>


GME Metamodel2

XSLScript

DEFDEF








DEF

template<GME, XSL>



GME Metamodel1

Rules

R1 R2

R4 R3

Sequence

R1 R2

R4 R3

DEF

template<GME, XSL>


GME Metamodel2

XSLScript

DEFDEF







2

23 July 2003

Model


DEF

template<GME, XSL>



GME Metamodel1

Rules

R1 R2

R4 R3

Sequence

R1 R2

R4 R3

DEF

template<GME, XSL>


GME Metamodel2

XSLScript

DEFDEF








DEF

template<GME, XSL>



GME Metamodel1

Rules

R1 R2

R4 R3

Sequence

R1 R2

R4 R3

DEF

template<GME, XSL>


GME Metamodel2

XSLScript

DEFDEF







3

23 July 2003

3-Layer Framework/Tool


DEF

template<GME, XSL>



GME Metamodel1

Rules

R1 R2

R4 R3

Sequence

R1 R2

R4 R3

DEF

template<GME, XSL>


GME Metamodel2

XSLScript

DEFDEF








DEF

template<GME, XSL>



GME Metamodel1

Rules

R1 R2

R4 R3

Sequence

R1 R2

R4 R3

DEF

template<GME, XSL>


GME Metamodel2

XSLScript

DEFDEF







(abstraction)

(specialization)

(use)

23 July 2003

Pieces of the framework

1) Old metamodel2) New metamodel3) Set of sequenced transforms4) Transform specifications (i.e., patterns and maps)

Transformation

NewClassDiagram

OldClassDiagram

Transform

+Delete

PatternItem

+CreateNew

ConsequenceItem*

*

Sequenced

*

Mapping

**

*

(3) (4)

(1)

(2)

23 July 2003

Metamodels (1) & (2)

• Give context to primitives used in matching• Lend paradigm attributes for the transform• Transform may need to distinguish between

objects from old or new metamodels

OldClassDiagram

Transformation

NewClassDiagram

1

1

23 July 2003

Transformation Layout (3)

• The contents of the Transformation algorithm• View of Transform components (hiding their contents)• Gives sequence to the Transforms (if necessary)

Transformation

Transform

Mappable

AreSequenced

Case Test

Rule

InitialTransition

Transition

Sequence

0..*

0..*

0..1

0..*

0..1

0..*

dst

src

InitialSequence

dst

src

0..*

0..1

0..*

0..*

0..1

0..*

23 July 2003

Types of Transforms

• Rule– Has side effects and is sequenced

• Test– Is sequenced, but without side effects– Contains Cases (as ports) to allow

conditional processing

• Case– Has side effects, but not sequenced

• Directs execution (to a sequenced object) if matched

• Terminates execution (on this exec. path) if not matched

23 July 2003

+Attributes+Stereotype

Class


«proxy»ClassCopy

+Cardinality+ChildRole+ParentRole

Composition+srcCardinality+dstCardinality+srcRole+dstRole

Association

+Delete

PatternItem

+CreateNew

ConsequenceItem

LegalPatternAssoc LegalConsequenceAssoc

Legal Items (4)

• Contents of Transform objects

• The patterns and mappings from one domain to another

• Abstract objects that are specialized in the domain evolution tool

+Delete

PatternItem

+CreateNew

ConsequenceItem


23 July 2003

Legal Items (4) (c’d)

• Legal items are mapped from one domain (pattern) to another (consequence)

• Mappings are specified as– CreateNew, CreateWithin, Becomes, Delete– Extendible, if necessary, by the DET

Mappable

Mapping

+Delete

PatternItem

+CreateNew

ConsequenceItem


0..* 0..*

0..*

0..*

src dst

0..*

23 July 2003

<xsl:template name="PortBecomesInput_62081432"> <xsl:element name="atom"> <xsl:apply-templates select="@*"/> <xsl:attribute name="kind">Input</xsl:attribute> <xsl:attribute name="role">Input</xsl:attribute> <xsl:comment>transformed using template 'PortBecomesInput_62081432'</xsl:comment> <xsl:apply-templates select="node()"/> </xsl:element></xsl:template><xsl:template name="PortBecomesInput_62081992"> <xsl:element name="atom"> <xsl:apply-templates select="@*"/> <xsl:attribute name="kind">Input</xsl:attribute> <xsl:attribute name="role">Input</xsl:attribute> <xsl:comment>transformed using template 'PortBecomesInput_62081992'</xsl:comment> <xsl:apply-templates select="node()"/> </xsl:element></xsl:template>

23 July 2003

Model of Computation

• Execution order– Execution order is guaranteed only if a

sequence is given in the Transformation– Sequence path is terminated when no output

sequence is specified from the sequenced object

– Recursive calls placed on a stack (user responsible to determine termination of the recursion call)

– Execution continues while • unsequenced nodes have not been executed, and• current execution path has not been terminated, and• no more paths exist on the execution stack

23 July 2003

Model of Computation

• Control Flow– Managed using Test objects

• Acts similar to a “switch” statement in C• Cases are contained

– Cases are not necessarily mutually exclusive– Cases operate as ports to direct execution

order– Default execution always followed, specified as

a sequence from the Test to the next object– Failure to match a Case terminates execution

along that path (at runtime) regardless of future contents of the execution path

23 July 2003

Example Transformation

1. Transform all Ports that will become Input ports connected to other Input ports

2. Transform all Ports that will become Output ports connected to other Output ports

3. Transform all remaining Ports that will become Input ports

4. Transform all remaining Ports that will become Output ports

23 July 2003

Domain Evolution Tool(DET)

• The DEF is specialized to create a DET• Two axes of specialization

– Metamodeling language (meta-metamodel)– Rewriting implementation (e.g., XSL)

• There would usually be a many-to-1 mapping between meta-metamodel and rewriting impl.– Unless different types of transformations

benefit from different implementations

• The type of rewriting implementation should be chosen to reflect the storage medium of the domain models

23 July 2003

DET for GME,XSLT

• A DET for the MetaGME metamodeling language has been implemented using XSLT as its rewriting language

• MetaGME – metamodeling language used to configure GME as a DSME

• XSL – w3c standardized functional language– Performs operations on nodes of an XML tree

that satisfy certain ‘match’ criteria– Chosen because GME has XML persistence

format

23 July 2003

Specializing the visual language

OldClassDiagram

Transformation

NewClassDiagram

1

1

ParadigmSheet

23 July 2003

Specializing the visual language

+Delete

PatternItem

+CreateNew

ConsequenceItem


FCO


«proxy»ProxyBase

+Cardinality+ChildRole+IsPort

Composition

+dstRole+srcRole+dstCardinality+srcCardinality

Connector

Atom Model Reference Set Connection

«proxy»AttributeProxy

«proxy»EnumAttrRef

«proxy»BooleanAttrRef

«proxy»FieldAttrRef

Attribute

ReferTo

+dstRole+Cardinality

Dst

+srcRole+Cardinality

Src

AttributeContainment

23 July 2003

Generating the XSL

• Isomorphism– applied if no matches are found for an object– recursively copies the object, attributes, and any children

• XSL MoC– Will match an object only one time (unless recursion

specified)– Matches the most ‘complex’ scenario when more than one– Wildcards (such as isomorphism) are least complex of all

<xsl:template match="@* | node()"> <xsl:copy> <xsl:apply-templates select="@* | node()"/> </xsl:copy></xsl:template>

23 July 2003

Basic XSL matches

<xsl:template match="type[@kind='ClassName']">

</xsl:template>+attributeName

«type»ClassName

<xsl:template match="type[@kind='ClassName']">

</xsl:template>+attributeName

«type»ClassName

<xsl:template match="FCO[@kind='B']"><xsl:variable name="B4_A"

select="parent::model[@kind='A']"/><xsl:variable name="B4_focus_B"

select="current()"/><xsl:choose><xsl:when test="current()[$B4_focus_B][$B4_A]">

</xsl:when><xsl:otherwise>

</xsl:otherwise></xsl:choose>

</xsl:template>

+attributeName

«model»A

+attributeName

«FCO»B

<xsl:template match="FCO[@kind='B']"><xsl:variable name="B4_A"

select="parent::model[@kind='A']"/><xsl:variable name="B4_focus_B"

select="current()"/><xsl:choose><xsl:when test="current()[$B4_focus_B][$B4_A]">

</xsl:when><xsl:otherwise>

</xsl:otherwise></xsl:choose>

</xsl:template>

+attributeName

«model»A

+attributeName

«FCO»B

23 July 2003

Mapping with XSL

<xsl:template match="model[@kind='B']"><xsl:variable name="Becomes_focus_B" select="current()"/><xsl:choose><xsl:when test="current()[$Becomes_focus_B]"><xsl:call-template name="BBecomesD_2"/></xsl:when><xsl:otherwise><xsl:copy><xsl:apply-templates select="@*|node()"/></xsl:copy></xsl:otherwise></xsl:choose></xsl:template>

<xsl:template name="BBecomesD_2"><xsl:element name="atom"><xsl:apply-templates select="@*"/><xsl:attribute name="kind">D</xsl:attribute><xsl:comment>transformed using template 'BBecomesD_2'</xsl:comment><xsl:apply-templates select="node()"/></xsl:element></xsl:template>

23 July 2003

Mapping to XSL MoC

XML

XSL

XML

XSL

XML

XSL

XML

Rule0.xsl Rule1.xsl Rule2.xsl

int0.xml int1.xml

input.xml output.xmlXML

XSL

XML

XSL

XML

XSL

XML


int0.xml int1.xml

input.xml output.xmlXML

XSL

XML

XSL

XML

XSL

XML


int0.xml int1.xml

input.xml output.xml

23 July 2003

Code Reuse in DET Implementations

• Much of the MoC of the DEF is captured in abstract classes that can be extended for DET implementation

• Classes for each DEF concept exist, and contain information independent of the DET

• DET implementations must provide visitors for each class that use a common interface

23 July 2003

Wildcards

• When no source/destination is specified for a connection, then no source/destination is attempted for a match

• Thus, wildcards are specified by being less specific in the XSL match

23 July 2003

Before/After

Befoooooore

Afffter

23 July 2003

Results

1. Language framework for model migration, with the following integral parts• Pattern and mapping specifications• Source and destination domain definitions• Meta-metamodel based primitives• Sequencing and decision support for ordering of

transform steps

2. Interpreter/compiler for the language3. Proof of concept

• DSME for use of the language• Visual language for more than one meta-

metamodel (but compiler for only one)• Simple and complex examples of MM

23 July 2003

Conclusions

• Metamodel based model migration schemes had not previously been formalized

• This research provides a framework with this capability, along with directions (and one sample implementation) for how to implement such a scheme

• Examples show how transformations can be created to enact the evolutionary changes to the domain models in an evolutionary fashion, leaning on domain concepts rather than implementation languages

23 July 2003

Other comments

• The MM language is aimed at modelers who are knowledgeable of metamodeling and perform environment evolution

• The framework supports revolutionary changes to metamodels, but is designed for evolutionary changes to the metamodels

23 July 2003

“Well HAL, I’m damned if I can find anything wrong with it.”“Yes. It’s puzzling. I don’t think I’ve ever seen anything quite like this before.”

-- 2001: A Space Odyssey

Questions

vanderbilt university 23 july 2003 metamodel based model migration jonathan sprinkle dissertation...

Documents

domaindomain models

small changes

new dsml

dynamic semantics

golden rule

new metamodels

modelerthe implementation

proper model migration