Transcript Supporting Parallel Updates with Bidirectional Model

Supporting Parallel Updates with
Bidirectional
Model Transformations
Yingfei Xiong and Masato Takeichi
University of Tokyo, Japan
Song Hui
Peking University, China
Zhenjiang Hu
National Institute of Informatics, Japan
Background: Bidirectional
Transformation
• Bidirectional transformation maintains the
consistency between two models
Class
name = Book
persistent= true
Class
name = Person
persistent= true
Class
name = Purchase
persistent= false
Table
name = Book
owner= admin
Table
name = Person
owner= xiong
Forward Transformation
Class
name = Publication
persistent= true
Table
name = Book
owner= xiong
forward
Table
name = Publication
owner= xiong
A forward transformation updates the target model
according to the updated source
Backward Transformation
Class
name = Book
persistent= true
Table
name = Publication
owner= xiong
backward
Class
name = Publication
persistent= true
A backward transformation updates the source model
according to the updated target
Bidirectional Languages
relation ClassAndTable {
String name;
enforce domain uml c:Class{
name=name;
persistent=true;
A QVT Program }
enforce domain dbms t:Table{
name=name;
owner=“admin”;
}
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 = Publication
persistent= true
Class
name = Person
persistent= true
Class
name = Purchase
persistent= false
Table
name = Book
owner= Song
Table
name = User
owner= xiong
Parallel Updates
• Parallel updates may conflict
Class
name = Publication
persistent= true
Class
name = Person
persistent= true
Class
name = Purchase
persistent= false
Table
name = Volume
owner= admin
Table
name = Person
owner= 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
Original
Models
Class
name = Book
persistent= true
Table
name = Book
owner= admin
Updated
Models
Class
name = Publication
persistent= true
Table
name = Book
owner= xiong
sync
Synchronized
Models
Class
name = Publication
persistent= true
Table
name = Publication
owner= xiong
Properties of Synchronizing Parallel
Updates: Consistency
Class
name = Book
persistent= true
Table
name = Book
owner= admin
Class
name = Publication
persistent= true
Table
name = Book
owner= xiong
sync
Class
name = Publication
persistent= true
Consistent
Table
name = Publication
owner= xiong
Output models should be consistent according to the
consistency relation R.
Properties of Synchronizing Parallel
Updates: Stability
Equal
Class
name = Book
persistent= true
Table
name = Book
owner= admin
Class
name = Book
persistent= true
Table
name = Book
owner= admin
sync
Class
name = Book
persistent= true
Table
name = Book
owner= admin
If no model is changed by users, no model should be
changed by the synchronization.
Equal
Properties of Synchronizing Parallel
Updates: Preservation
Class
name = Book
persistent= true
Table
name = Book
owner= admin
Class
name = Book
persistent= true
Table
name = Publication
owner= admin
Preserve
sync
Class
name
= Publication
name
= Book
persistent= true
Table
name
name
= Publication
= Book
owner= admin
The output model should preserve the user update.
How to Define Update Preservation
• Different updates may lead to the same result
Class
name = Book
persistent= true
rename
Class
name = Volume
persistent= true
Class
name = Book
persistent= true
delete
Class
insert
name = Volume
persistent= true
• Need to specify what updates we consider
• Need to specify how to relate models to the
updates
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 nonconflicting 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
Class
name = Book
ma
persistent= true
rename diff(m , m )
a
b
Class
mb
name = Volume
persistent= true
change
Class persistent
name = Volume
persistent= false
δ
m
How to Synchronize Parallel Update
m
n
m’
n’
backward
temp_m
merge
forward
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
Violating Preservation
Class
name = Book
persistent= true
Table
name = Book
owner= admin
Class
name = Book
persistent= false
Table
name = Book
owner= xiong
backward
Class
name = Book
persistent= true
merge
forward
Class
name = Book
persistent= false
no element!
Synchronization Algorithm
m
n
m’
n’
backward
temp_m
test
preservation
merge
forward
m’’
n’’
Relation between Properties
• Bidirectional transformation properties
[Stevens07] lead to synchronization properties
Synchronizer
forward
forward
backward
backward
Correctness
Consistency
Hippocraticness
Stability
Preservation
19
Case Study: Runtime Management
Framework
High-Level Interface
Synchronizer
Beanbag-based Update
Representation and
QVT Program
Difference
Running System
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