Post on 16-Jan-2016
transcript
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
• 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
Application Evolution
Meta-LevelTranslation
MetaprogrammingInterface
Formal Specifications
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
Application Evolution
Meta-LevelTranslation
MetaprogrammingInterface
Formal Specifications
Domain Evolution
23 July 2003
The need
Model Builder
Model Interpreters
Models
MIPS Environment
ModelInterpretation
ApplicationDomain
App.1
App.2
App.3
Application Evolution
Meta-LevelTranslation
MetaprogrammingInterface
Formal Specifications
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
Domain Evolution Framework (DEF)
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 Domain Evolution Tool
GME Metamodel2
XSLScript
DEFDEF
M1M2 Domain Evolution Specification
(evolution tool layer)
(evolution specification layer)
(evolution framework layer)
(evolution tool layer)
template<meta-metamodel, graph-rewriting language>
Domain Evolution Framework (DEF)
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 Domain Evolution Tool
GME Metamodel2
XSLScript
DEFDEF
M1M2 Domain Evolution Specification
(evolution tool layer)
(evolution specification layer)
(evolution framework layer)
(evolution tool layer)
template<meta-metamodel, graph-rewriting language>
1
23 July 2003
Evolution Tool Layer
Domain Evolution Framework (DEF)
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 Domain Evolution Tool
GME Metamodel2
XSLScript
DEFDEF
M1M2 Domain Evolution Specification
(evolution tool layer)
(evolution specification layer)
(evolution framework layer)
(evolution tool layer)
template<meta-metamodel, graph-rewriting language>
Domain Evolution Framework (DEF)
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 Domain Evolution Tool
GME Metamodel2
XSLScript
DEFDEF
M1M2 Domain Evolution Specification
(evolution tool layer)
(evolution specification layer)
(evolution framework layer)
(evolution tool layer)
template<meta-metamodel, graph-rewriting language>
2
23 July 2003
Model
Domain Evolution Framework (DEF)
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 Domain Evolution Tool
GME Metamodel2
XSLScript
DEFDEF
M1M2 Domain Evolution Specification
(evolution tool layer)
(evolution specification layer)
(evolution framework layer)
(evolution tool layer)
template<meta-metamodel, graph-rewriting language>
Domain Evolution Framework (DEF)
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 Domain Evolution Tool
GME Metamodel2
XSLScript
DEFDEF
M1M2 Domain Evolution Specification
(evolution tool layer)
(evolution specification layer)
(evolution framework layer)
(evolution tool layer)
template<meta-metamodel, graph-rewriting language>
3
23 July 2003
3-Layer Framework/Tool
Domain Evolution Framework (DEF)
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 Domain Evolution Tool
GME Metamodel2
XSLScript
DEFDEF
M1M2 Domain Evolution Specification
(evolution tool layer)
(evolution specification layer)
(evolution framework layer)
(evolution tool layer)
template<meta-metamodel, graph-rewriting language>
Domain Evolution Framework (DEF)
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 Domain Evolution Tool
GME Metamodel2
XSLScript
DEFDEF
M1M2 Domain Evolution Specification
(evolution tool layer)
(evolution specification layer)
(evolution framework layer)
(evolution tool layer)
template<meta-metamodel, graph-rewriting language>
(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
+Attributes+Stereotype
«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
LegalPatternAssoc LegalConsequenceAssoc
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
LegalPatternAssoc LegalConsequenceAssoc
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
LegalPatternAssoc LegalConsequenceAssoc
FCO
+Attributes+Stereotype
«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']"><!-- template body -->
</xsl:template>+attributeName
«type»ClassName
<xsl:template match="type[@kind='ClassName']"><!-- template body -->
</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]"><!-- template body -->
</xsl:when><xsl:otherwise><!-- perform isomorphic transform -->
</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]"><!-- template body -->
</xsl:when><xsl:otherwise><!-- perform isomorphic transform -->
</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
Rule0.xsl Rule1.xsl Rule2.xsl
int0.xml int1.xml
input.xml output.xmlXML
XSL
XML
XSL
XML
XSL
XML
Rule0.xsl Rule1.xsl Rule2.xsl
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