supporting parallel updates with bidirectional model transformations yingfei xiong and masato...

Post on 04-Jan-2016

215 Views

Category:

Documents

1 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Supporting Parallel Updates with BidirectionalModel Transformations

Yingfei Xiong and Masato TakeichiUniversity of Tokyo, Japan

Song HuiPeking University, China

Zhenjiang HuNational Institute of Informatics, Japan

Background: Bidirectional Transformation

• Bidirectional transformation maintains the consistency between two models

Classname = Book

persistent= trueTable

name = Bookowner= adminClass

name = Personpersistent= true

Classname = Purchasepersistent= false

Tablename = Personowner= xiong

Forward Transformation

Classname = Publication

persistent= true

Tablename = Publication

owner= xiong

A forward transformation updates the target model according to the updated source

Tablename = Bookowner= xiong

forward

Backward Transformation

Classname = Book

persistent= true

Tablename = Publication

owner= xiong

Classname = Publication

persistent= true

A backward transformation updates the source model according to the updated target

backward

Bidirectional Languagesrelation ClassAndTable {String name;enforce domain uml c:Class{

name=name;persistent=true;

}enforce domain dbms t:Table{

name=name;owner=“admin”;

}

A QVT Program

Forward Transformation Backward Transformation

Parallel Updates

• Both models may be updated before any transformation can be applied

• Can we handle this using bidirectional transformation?Class

name = Publicationpersistent= true Table

name = Bookowner= SongClass

name = Personpersistent= true

Classname = Purchasepersistent= false

Tablename = Userowner= xiong

Parallel Updates

• Parallel updates may conflict

Classname = Publication

persistent= trueTable

name = Volumeowner= adminClass

name = Personpersistent= true

Classname = Purchasepersistent= false

Tablename = Personowner= xiong

How to Synchronize Parallel Updates

• In this talk, I will introduce – formal requirements of synchronizing parallel

updates– an approach that synchronizes parallel updates

using bidirectional transformation

with the help of model update representation and model difference approaches

Synchronizing Parallel Updates

Classname = Publication

persistent= true

Tablename = Bookowner= xiong

Classname = Book

persistent= true

Tablename = Book

owner= admin

Classname = Publication

persistent= true

Tablename = Publication

owner= xiong

Original Models

UpdatedModels

SynchronizedModels

sync

Properties of Synchronizing Parallel Updates: Consistency

Classname = Publication

persistent= true

Tablename = Bookowner= xiong

Classname = Book

persistent= true

Tablename = Book

owner= admin

Classname = Publication

persistent= true

Tablename = Publication

owner= xiong

Output models should be consistent according to the consistency relation R.

sync

Consistent

Properties of Synchronizing Parallel Updates: Stability

Classname = Book

persistent= true

Tablename = Book

owner= admin

Classname = Book

persistent= true

Tablename = Book

owner= admin

Classname = Book

persistent= true

Tablename = Book

owner= admin

Equal Equal

If no model is changed by users, no model should be changed by the synchronization.

sync

Properties of Synchronizing Parallel Updates: Preservation

Classname = Book

persistent= truename = Publication

owner= admin

Table

Classname = Book

persistent= true

Tablename = Book

owner= admin

Classname = Book

persistent= true

Tablename = Book

owner= admin

Tablename = Publication

owner= admin

Preserve

name = Publicationpersistent= true

The output model should preserve the user update.

sync

How to Define Update Preservation

• Different updates may lead to the same result

• Need to specify what updates we consider• Need to specify how to relate models to the

updates

Classname = Volumepersistent= true

Classname = Book

persistent= truerename

Classname = Volumepersistent= true

Classname = Book

persistent= truedelete

insert

Update Representation and Difference

• Model Update Representation [Cicchetti08]– A space of updates– An operation to test whether two updates conflict– An operation compose to compose two non-

conflicting updates on the same model• Model Difference [Alanen03,Abi06]– An operation diff to find update by comparing

two models

Defining Update Preservation

• We say that m preserves the update from ma to mb iff exists an update δ where– δ and diff(ma, mb) do not

conflict– compose(δ, diff(ma, mb))

(ma)=m

Classname = Volumepersistent= true

Classname = Book

persistent= truerename

Classname = Volumepersistent= false

change persistent δ

diff(ma, mb)

m

ma

mb

How to Synchronize Parallel Update

m n

m’ n’

temp_m

merge

m’’ n’’

merge(m, m’, m’’) = compose(diff(m, m’), diff(m, temp_m))(m)reports an error when diff(m, m’) and diff(m, temp_m) conflict

forward

backward

Violating PreservationClass

name = Bookpersistent= true

Tablename = Book

owner= admin

Classname = Book

persistent= false

Tablename = Bookowner= xiong

Classname = Book

persistent= true

merge

Classname = Book

persistent= falseno element!

backward

forward

Synchronization Algorithm

m n

m’ n’

temp_m

merge

m’’ n’’

testpreservation

backward

forward

Relation between Properties

• Bidirectional transformation properties [Stevens07] lead to synchronization properties

Synchronizer

Correctness

Hippocraticness

Consistency

Stability

Preservation19

forward forward

backward backward

Case Study: Runtime Management Framework

Running System

High-Level Interface

Synchronizer

QVT ProgramBeanbag-based Update

Representation and Difference

Available at: http://sei.pku.edu.cn/~songhui06/tool-case/rsa/case.html

Conclusion

• The requirement of synchronizing parallel updates can be defined through three properties– Consistency– Stability– Preservation

• Using existing bidirectional transformations and update representation / model difference approaches, we can construct a synchronizer satisfying the three properties

• A case study shows the feasibility of the approach

top related