Towards Automatic Model Synchronization from Model Transformation Yingfei

Towards Automatic Model Synchronization from Model Transformation Yingfei Xiong, 2007

ASE Work

The Problem of Data Interchange l l Suppose we have a software modeling system We want to write a code generating system that generates code from the models in the modeling system Modeling System Code Generator Models ----------------------Code

Difficulties l l The format how the models are stored is unknown Even if the format is known, there are many trivial details to deal with l l l Byte encoding: high bit first? Low bit first? Char encoding: GB 2312? UTF-8? …

Solution l Standards l l l W 3 C XML OMG MOF Standards for data interchange that l l Provide a generic data structure to describe data ü XML: tree ü MOF: graph Provide means to define the format of data ü XML: DTD, Schema ü MOF: meta model Define how the data are stored into and loaded from files ü XML: part of the basic XML standard ü MOF: XMI Provide a set of general APIs to operate data

The resulting system l The modeling system produces data in MOF models for data interchange. Modeling System MOF Models Code Generator ----------------------Code

A More General Situation l l The code generating system wants to support more modeling system The system proposes a meta model and supports input of models in the meta model Modeling System A Models in Metamodel C Code Generator Modeling System B Models in Metamodel B

Solution l Provide specific languages for converting model formats between meta models Modeling System A Models in Metamodel A Transform A 2 C m Modeling System B Models in Metamodel B ran T for s Models in Metamodel C C B 2 Code Generator

Walk a little further l Software development yields artifacts in different formats l l l Requirement documents Design models Code … If we can provide transformations between these artifacts, we can automate software development

Model-Driven Development l MDD l l l MDA l l An model-based approach to software development Developing software by transforming models The set of standards by OMG for realizing MDD Model Transformation Languages l l ATL [F. Jouault and I. Kurtev. 2005] QVT [OMG, 2006]

A UML 2 Java Transformation in ATL module UML 2 Java ; create OUT : Java from IN : UML ; rule Class 2 Class { from u : UML ! Class to j : Java ! Class ( name <- u. name , fields <- u. attrs ) } rule Attribute 2 Field { from a : UML ! Attribute to f : Java ! Field ( name <- ’_’ + a. name , type <- a. type ) }

An Example of Executing UML 2 Java UML!Class name = “Book” description = “a demo class” UML!Attribute name = “title” type = “String” UML!Attribute name = “price” type = “Double”

The Transformation Result UML!Class name = “Book” description = “a demo class” UML!Attribute name = “title” type = “String” Java!Class name = “Book” comment = “” Java!Field name = “_title” type = “String” UML!Attribute name = “price” type = “Double” Java!Field name = “_price” type = “Double”

Modifications UML!Class name = “Book” description = “a demo class” UML!Attribute name = “title” type = “String” UML!Attribute name = “authors” type = “String” Java!Class name = “Book” comment = “_book. Title cannot be null” Java!Field_book. Title name = “_title” type = “String” UML!Attribute name = “price” type = “Double” Java!Field name = “_price” type = “Double”

Model Synchronization l Model synchronization is a process that propagates modifications across different models, making the models consistent with each other.

Model Synchronization Src 0 Transform Modify Tar 0 Modify Src 1 Tar 1 Synchronize Src 2 Tar 2

Existing Approaches l General Frameworks l l Multi-view synchronization [J. Grundy et al. 1998] Rely on users to write code to handle each type of modifications in each side It is users who should ensure the consistency of the code Specific Languages l l FSML [M. Antkiewicz and et al. 2006] Feature model to code synchronization

Our Contributions l A clear semantics of model synchronization l l An automatic model synchronization approach l l Four properties Using the existing unidirectional ATL byte code program Requiring no extra code Satisfying the four properties A prototype tool for synchronizing EMF models

Our Contributions l A clear semantics of model synchronization l l An automatic model synchronization approach l l Four properties Using the existing unidirectional ATL byte code program Requiring no extra code Satisfying the four properties A prototype tool for synchronizing EMF models

Our Contributions l A clear semantics of model synchronization l l An automatic model synchronization approach l l Four properties Using the existing unidirectional ATL byte code program Requiring no extra code Satisfying the four properties A prototype tool for synchronizing EMF models

The ATL Transformation System ATL Program QVT Program Compile ATL Byte-code

Our Contributions l A clear semantics of model synchronization l l An automatic model synchronization approach l l Four properties Using the existing unidirectional ATL byte code program Requiring no extra code Satisfying the four properties A prototype tool for synchronizing EMF models

The ATL Transformation System Original Source Models ATL Virtual Machine Original Target Models Modified Source Models Modified Target Models ATL Byte-code Meta. Models

Our System Original Source Models Modified Source Models ATL Byte-code Synchronized Source Models Modified Target Models Our System Meta. Models Synchronized Target Models

Our Contributions l A clear semantics of model synchronization l l An automatic model synchronization approach l l Four properties Using the existing unidirectional ATL byte code program Requiring no extra code Satisfying the four properties A prototype tool for synchronizing EMF models

Review the example UML!Class name = “Book” description = “a demo class” UML!Attribute name = “title” type = “String” UML!Attribute name = “authors” type = “String” Java!Class name = “Book” comment = “_book. Title cannot be null” Java!Field_book. Title name = “_title” type = “String” UML!Attribute name = “price” type = “Double” Java!Field name = “_price” type = “Double”

The Synchronized Result UML!Class name = “Book” description = “a demo class” UML!Attribute book. Title name = “title” type = “String” UML!Attribute name = “authors” type = “String” UML!Attribute name = “price” type = “Double” Java!Class name = “Book” comment = “_book. Title cannot be null” Java!Field_book. Title name = “_title” type = “String” Java!Field name = “_authors” type = “String” Java!Field name = “_price” type = “Double”

Our Contributions l A clear semantics of model synchronization l l An automatic model synchronization approach l l Four properties Using the existing unidirectional ATL byte code program Requiring no extra code Satisfying the four properties A prototype tool for synchronizing EMF models

Content l l l Background and Motivation Outline of our work Details of our work l l l A clear semantics An automated approach A prototype tool

Properties of Synchronization l l To ensure the synchronization process exhibits reasonable behavior, we need to define clear semantics to model synchronization Our semantics includes four important properties: l l Stability Preservation Propagation Composibility

Stability If no model is modified, the synchronized models are not modified. UML!Class name = “book” description = “demo” Transform UML!Class name = “book” description = “demo” Java!Class name = “book” comment = “” Synchronize UML!Class name = “book” description = “demo” Java!Class name = “book” comment = “”

Preservation Modifications on both sides should be kept. UML!Class name = “book” description = “demo” Transform UML!Class name = “book” description = “demo” Java!Class name = “book” comment = “persistent” Synchronize UML!Class name = “book” description = “demo” Java!Class name = “book” comment = “persistent”

Propagation The modifications should be propagated to the other side if necessary. UML!Class name = “book” description = “demo” Transform UML!Class name = “book” description = “demo” Java!Class name = “book” comment = “” Java!Classpublication name = “book” comment = “” Synchronize UML!Class publication name = “book” description = “demo” Java!Classpublication name = “book” comment = “”

Composibility – Step 1 A series of modifications have the same effect regardless of whether is applied once or is applied incrementally UML!Class name = “book” description = “demo” Transform UML!Class publication name = “book” description = “demo” Java!Class name = “book” comment = “” Synchronize UML!Class publication name = “book” description = “demo” Java!Classpublication name = “book” comment = “”

Composibility – Step 2 A series of modifications have the same effect regardless of whether is applied once or is applied incrementally UML!Class publication name = “book” description = “demo” Java!Class publication name = “book” comment = “” Java!Class name = “book” comment = “persistent” Synchronize UML!Class publication name = “book” description = “demo” Java!Class publication name = “book” comment = “persistent”

Composibility - Composed A series of modifications have the same effect regardless of whether is applied once or is applied incrementally UML!Class name = “book” description = “demo” Transform UML!Class publication name = “book” description = “demo” Java!Class name = “book” comment = “persistent” Synchronize UML!Class publication name = “book” description = “demo” Java!Class publication name = “book” comment = “persistent”

Content l l l Background and Motivation Outline of our work Details of our work l l A clear semantics An automated approach A prototype tool Conclusion

Backward Modification Propagation l l To put back modifications from target to source, we need to know which source items are related to a target item Bidirectional ATL Virtual Machine l Record trace information when performing the transformation ü Trace the sources of items ü Trace how items are transformed

Examples of Tracing l l to f : Java ! Field ( name <- ’_’ + a. name , type <- a. type ) The f. name is created from a. name by prefixing an underscore When f. name is modified, we modify a. name by removing the prefixed underscore

Propagate Modifications UML!Class name = “Book” description = “a demo class” I am from here! When I am deleted, delete the source class and all its attributes Java!Class name = “Book” comment = “” ere! UML!Attribute name = “title” type = “String” I am from h ged, When I am chan g attribute find correspondin ute back and set that attrib UML!Attribute name = “price” type = “Double” Java!Field name = “_title” type = “String” I am from here! When I am changed, remove the leading ‘-’ and copy me back! Java!Field name = “_price” type = “Double”

Synchronization Algorithm Src. Modifications Src 0 Transform Tar 0 Tar. Modifications Shared Modifications Difference Src 1 Tar 1 Difference Tagged Tar Tagged Src Source Merging Inter. Src Backward Propagate Inter. Tar Supplementray Merging Transform Src 2 Tar 2

Content l l l Background and Motivation Outline of our work Details of our work l l A clear semantics An automated approach A prototype tool Conclusion

Implementation l A prototype tool l l Synchronizing EMF models Using an ATL byte-code program Requiring no extra code Available at: l http: //www. ipl. t. utokyo. ac. jp/~xiong/model. Synchronization. html

Content l l l Background and Motivation Outline of our work Details of our work l l l A clear semantics An automated approach A prototype tool

Ongoing Work

Problem in the ASE work l l Cannot deal with insertions Lack of well-defined semantics for references l l Synchronization is slow l l My recent study shows that in our ASE work, properties may be violated when there are complex reference operations Some applications require instant updating of models ü Eclipse. UML ü Synchronization of document and view in MVC applications Cannot apply to data that is not XMI files l Other data includes: XML files, in-memory structures

My Current Work: Objectives l Provide a general framework for implementing synchronization applications l l To support all kinds of modifications To support incremental synchronization ü Finding out what modification operations should be taken to make models consistent from some initial modification operations To allow users to define new data structures Can easily correspond to a unidirectional imperative program

My Current Work: Approach l l l Provide a framework to allow users to construct execution graphs Execution graphs can be analyzed from imperative programs Execution graphs can be invoked when there are modifications on values

An Execution Graph source int a, b; target int x, y; x = a + 1; y = a + b; a +1 b a+b x y

Forward Transformation a=1 b=2 a=1 Mod +1 Mod b=2 a+b x y

Forward Transformation a=1 b=2 a=1 Mod +1 Mod b=2 a+b x=2 Mod y=2

Incremental Synchronization a => 5 y => 10 a=5 Mod b=2 +1 a+b x=2 Mod y = 10

Incremental Synchronization a => 5 y => 10 a=5 Mod +1 Mod b=5 a+b x=6 Mod y = 10

The Next Step in My Plan l Automatically derive execution graphs from ATL programs