Vanderbilt University 23 July 2003 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 Model Interpretation Application Domain App. 1 App. 2 App. 3 Application Evolution Meta-Level Translation Metaprogramming Interface 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 Model Interpretation Application Domain App. 1 App. 2 App. 3 Application Evolution Meta-Level Translation Metaprogramming Interface 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 Model Interpretation Application Domain App. 1 App. 2 App. 3 Application Evolution Meta-Level Translation Metaprogramming Interface Formal Specifications Domain Evolution

23 July 2003 The need Model Builder Model Interpreters Models MIPS Environment Model Interpretation Application Domain App. 1 App. 2 App. 3 Application Evolution Meta-Level Translation Metaprogramming Interface 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 1

23 July 2003 Evolution Tool Layer 2

23 July 2003 Model 3

23 July Layer Framework/Tool (abstraction) (specialization) (use)

23 July 2003 Pieces of the framework 1)Old metamodel 2)New metamodel 3)Set of sequenced transforms 4)Transform specifications (i.e., patterns and maps)

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

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)

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 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

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

23 July 2003 Input transformed using template 'PortBecomesInput_ ' Input transformed using template 'PortBecomesInput_ '

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

23 July 2003 Specializing the visual language

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

23 July 2003 Basic XSL matches

23 July 2003 Mapping with XSL D transformed using template 'BBecomesD_2'

23 July 2003 Mapping to XSL MoC

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 language 3.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.” : A Space Odyssey Questions