On-Site Synchronizers for Multi-View Applications · use a class diagram to show the static structure of the system and use a sequence diagram to show the dynamic behavior. In many

日本ソフトウェア科学会第 25回大会（2008年度）論文集 1

On-Site Synchronizers for Multi-View Applications∗

Yingfei Xiong1, Zhenjiang Hu1,3, Song Hui2, Masato Takeichi1, Haiyan Zhao2, Hong Mei2

1Department of Mathematical Informatics

University of Tokyo, Tokyo, Japan

[email protected]

{hu,takeichi}@mist.i.u-tokyo.ac.jp

2Key Laboratory of High Confidence

Software Technologies (Peking University)

Ministry of Education, Beijing, 100871, China

{songhui06,zhhy,meih}@sei.pku.edu.cn

3Information Systems Architecture Research Division / GRACE Center

National Institute of Informatics

Many applications use multiple editable views to represent data in different formats. When users modify

one view or change several views simultaneously, we need to synchronize the views by propagating these

changes across all views. Different from existing studies on off-site synchronization which synchronizes

data between applications, this kind of on-site synchronization has a strict requirement on response

time, and usually has no predefined propagation direction.

In this paper we propose a new approach to on-site synchronization, which takes modifications on

all data and produces new modifications to make them consistent. We deduce the propagation direction

from the modifications, and achieve incremental synchronization by only computing the modified part.

We have applied our approach to construct an EJB modeling tool and our experiments show that our

synchronizers are hundred times faster than existing off-site synchronizers.

1 Introduction

It is common that one software application uses dif-ferent views to represent its data. For example, aprogramming source code editor may show an out-line of the code and some features [AC06] of thecode as well as the code itself; a UML editor mayuse a class diagram to show the static structure ofthe system and use a sequence diagram to show thedynamic behavior.

In many cases, not only one view are editable.

∗The research was supported in part by a grant fromJapan Society for the Promotion of Science (JSPS) Grant-in-aid for Scientific Research (A) 19200002, the National Natu-ral Science Foundation of China under Grant No. 60528006and the National High Technology Research and Develop-ment Program of China (863 Program) under Grant No. of2006AA01Z156.

Since these views are representing shared informa-tion, when users modify one view, we need to trans-form and propagate the modification to other viewsto make all views consistent. Furthermore, multi-ple views may be modified at the same time, e.g.,a group of designers are working one UML designmodels and a group of programmers are working onthe implementing code simultaneously. In such sit-uations, we need to synchronize the modificationson different views and detect possible conflicts.

For a concrete example, let us consider a sim-ple Enterprise JavaBeans (EJBs) modeling tool, asshown in Figure 1. The tool provides two editableviews: The deployment view and the the persis-tent view. The deployment view shows three EJBs:


SignOnEJB, UserEJB, and DepartmentEJB, all ofwhich belong to a module SignOn. The persistentattributes of UserEJB and DepartmentEJB are true,and these persistent EJBs, called entity beans, arelisted in the persistent view. Some of the informa-tion is shared between the two views, such as themodule name and the EJB name, while some ofthe information is independently displayed on eachview, such as the module description just below themodule name and the primary keys of the entitybeans. When users modify an element related toshared information, for instance, the EJB name ofan entity bean on the persistent view, the systemshould dynamically modify the EJB name of thecorresponding EJB on the deployment view. Theprocess of propagating changes between data in dif-ferent formats is called heterogeneous synchroniza-tion and the software component to perform suchsynchronization is called synchronizers [ACar].

Figure 1. An EJB Modeling Tool

Existing synchronizers focus on off-site syn-chronization. That is, they synchronize data be-tween off-the-shelf applications where these appli-cations export their data in some intermediate for-mats like XML, and the synchronizers produce newXML files containing synchronized data. However,off-site synchronizers cannot well support synchro-nization in multi-view applications like the EJBmodeling tool, where the data are synchronized on-site within one application. Not only exporting andimporting the internal data requires extra program-ming work, but also the process takes too muchtime which is intolerable in most cases. We neednew synchronizers to support this kind of on-sitesynchronization.

Compared to off-site synchronization, on-site

synchronization imposes many new challenges.Here we highlight two challenges. The first one isresponse time. While off-site synchronization is of-ten not sensitive to response time, on-site synchro-nization has a strict requirement on response time.When users modify one view, they are expected tosee the modification of other views immediately.

The other one is about the direction of synchro-nization. Off-site synchronization often takes placebetween two applications, and the synchronizationare performed with an explicit direction, i.e., changethe data of one application according to the otheror vice versa. However, in on-site synchronizationthe data are often mutually related and it is dif-ficult to divide the data into two groups. For ex-ample, in the EJB application, when the attributesof an entity bean is modified by user, the applica-tion has to modify corresponding attributes of EJBsand modules. When a module is deleted by user,the application need to delete all EJBs and entitybeans belonging to that module. It is not possi-ble to divide the three types of objects into twogroups where synchronization only takes place be-tween groups but not inside a group.

In this paper, we made our first attempt ofdefining a set of on-site synchronizers to supporton-site synchronization. Our synchronizers are in-cremental, ensuring a short response time, and aresymmetric, treating every domain of data equallyand assuming no specific direction in modificationpropagation.

The key factor in our design is modifications.When users modify the application data, the ap-plication capture users’ modifications as an inputto our synchronizers and our synchronizers producenew modifications which can make all data consis-tent. As no specific propagation direction is defined,the synchronizers use modifications as an indicationand propagate the modification from modified partsto unmodified parts. Furthermore, because our syn-chronizers know users’ modification, the synchro-nizers can perform an incremental synchronizationwhere the modified part is treated carefully to avoidrecomputing on the unmodified parts, ensuring ashort response time.


EJBNameEqual = graph(ejb , entityBean) {

vars = name;

SGet <key="Name">(ejb , name);

SGet <key="EJBName">(entityBean , name);

}

Figure 2. ejb.Name = entityBean.EJBName

To give a first taste of on-site synchronizers, letus consider a simple synchronizer which relates thename attribute of an EJB and the EJB name at-tribute of an entity bean. The code for the syn-chronizer is listed in Figure 2.

The SGet<key="Name"> is a primitive synchro-nizer which synchronizes an object (the first ar-gument) and a value (the second argument), en-suring the Name attribute of the object is equalto the value. Similarly, SGet<key="EJBName"> en-sures the EJBName attribute of its first argument isequal to the second argument. The two primitivesynchronizers are combined into EJBNameEqual bya graph combinator which connects them throughvariables. The variables ejb and entityBean areexternal variables and name is an internal variable.The external variables are visible to the client of thesynchronizer while the internal variables are invisi-ble to the client. The Name attribute of ejb is en-sured to be equal to name and the EJBName attributeof entityBean is ensured to be equal to name.

When users modify, say, the Name attributeof the ejb object to "UserEJB", an input of〈{Name->"UserEJB"}, nomod〉 will be passedto EJBNameEqual. The first component de-scribes the modification on ejb while the secondcomponent nomod indicates entityBean is notmodified. EJBNameEqual will notice that ejb

is modified, and will invoke SGet<key="Name">

with 〈{Name->"UserEJB"}, nomod〉 where thesecond nomod indicates name is not modified.SGet<key="Name"> will propagate modificationsfrom modified part to unmodified part, and pro-duce 〈{Name->"UserEJB"}, "UserEJB"〉. ThenEJBNameEqual will notice that name is modifiedand invoke SGet<key="EJBName"> to further prop-agate a modification {EJBName->"UserEJB"}

to entityBean. Finally, EJBNameEqual

will produce the synchronized modifications〈{Name->"UserEJB"}, {EJBName->"UserEJB"}〉on ejb and entityBean.

If users modify the EJBName attribute of theentityBean object, the modification will be prop-agated in the reverse direction. If both objectsare modified, the synchronizer will check if the twomodifications are consistent, and report a failure ifthey conflict.

We start our definition of on-site synchronizersby giving a precise requirement for on-site synchro-nization (Section 2). A fundamental difficulty of de-signing synchronizers concerns the balance betweenexpressiveness and robustness [FGM+07, Ste07]. Inthis work we choose to stick to only a reason-able subset of robustness properties to gain theexpressiveness for most common synchronizationtasks. Specifically, our on-site synchronizers sat-isfy the stability, preservation, propagation proper-ties [XLH+07] – they are ensured to produce consis-tent result and make no unnecessary modifications– but not total [FGM+07] – on-site synchronizersare not ensured to find out all possible solutions fora specific input. We hope our work could serve asa foundation upon which others can build domain-specific synchronization language that is total.

We then proceed to the definition of concretesynchronizers. To simplify and generalize our def-initions, we use a small set of data types to rep-resent in-memory objects and define modificationtypes on the data types (Section 3). Based on thedata types and modification types we define a setof primitive synchronizers and a set of combinators(Section 4), where the combinators are used to com-bine primitive synchronizers into bigger synchroniz-ers for more complex consistency relations, such asthe graph combinator we have seen.

We have applied our work to actually constructthe EJB modeling tool to see how our synchronizerwork in practice (Section 5). The result is satis-factory and moreover, we also discovered an extrabenefit of using on-site synchronizers: we can getrid of the key attributes used in off-site synchroniza-tions. In off-site synchronization, users often needto designate some key attributes [Obj05, FGM+07]


which uniquely identify each data item. However,based on our experience, many application data donot have a suitable candidate to be a key attribute[YKW+08]. Because on-site synchronizer is tightlyintegrated into the application, we can make use ofin-memory addresses to identify items and get ridof key attributes.

We evaluate the performance of our synchroniz-ers through a set of experiments (Section 6). Theresult shows that our synchronizers are hundredstimes faster than medini QVT [ikv], an implemen-tation of an off-site synchronization language. Wealso compare our work with a variety of related work(Section 7). Finally, we discuss the remaining prob-lems of current work and point out possible futuredirections (Section 8).

2 On-site Synchronization

Before defining concrete synchronizers, we discussgenerally about on-site synchronization withouttargeting any particular data types. Later we willdefine specific data types and define synchronizerson those data types. We use ~v to denote a n-tuple〈v1, v2, . . . , vn〉. We assume no nested structure intuples, that is, 〈v1, 〈v2, v3〉〉 = 〈v1, v2, v3〉.

We assume a data type is collection of values. Amodification defined on the data type D is a idem-potent function where m ∈ D → D and m◦m = m.The idempotent property of a synchronizer can beused to check whether a modification has been ap-plied or not. If we apply a modification to a dataitem and we get the same data item, the modifica-tion has been applied to the data item. A specialmodification nomod is used to denote that the dataitem is not modified, where nomod(d) = d.

Users usually do not apply only one modifica-tion on the data, but a sequence of modifications.In many cases, a sequence of modifications has thesame effect of one modification. To avoid a com-plex model involving both single modifications andsequences, we introduce the concept of modifica-tion set. A modification set M defined on the datatype D is a set of modification operation closed oncomposition, that is, for any m1,m2 ∈ M we havem1 ◦m2 ∈ M . To be simple, we assume each data

type D has a corresponding modification set, de-noted by MD, and nomod ∈MD.

If two modification operations affect differentparts of an artifact, we say the two operations aredistinct. Formally, we say m1,m2 are distinct if andonly if they are commutative: m1 ◦m2 = m2 ◦m1.We write m1m2 if m1 and m2 are distinct. If twomodifications are not distinct, we say they conflictwith each other.

Another important relation over modificationsis the sub modification relation, which indicates onemodification is included in another modification. Ifm1 ◦m2 = m2, we say m1 is a sub modification ofm2, denoted by m1 v m2.

A synchronizer synchronizes n data items thatare defined in data types D1, D2, . . . , Dn is denotedas s ∈ D1 ↔ D2 ↔ · · · ↔ Dn. We write s ∈↔ D1

when n = 1. A synchronizer consists of four com-ponents. The first one is a consistency relations.R ⊆ D1 ×D2 × · · · ×Dn which the synchronizertries to establish over the data items. The secondcomponent is a state set s.Θ. To perform incre-mental synchronization, a synchronizer may needto keep some information like trace information,and update the information after synchronization.This kind of information is called states of the syn-chronizer and is defined by s.Θ. The third com-ponent is an incremental synchronization functions.sync ∈ MD1 × · · · ×MDn × s.Θ → MD1 × · · · ×MDn×s.Θ. This function takes a sequence of mod-ifications on the data items, produces a new se-quence of modifications, and updates the state ofthe synchronizer at the same time. The forth com-ponent is a non-incremental synchronization func-tion s.sync ∈MD1 × · · · ×MDn ×D1 × · · · ×Dn →MD1 × · · · ×MDn × s.Θ. This function is used atthe initial stage when we do not have a state ofthe synchronizer, and it takes a sequence of dataitems instead of the state and constructs a state af-ter synchronization. If the input modifications areconflicting or the synchronizer has failed to synchro-nize with the modifications, the s.sync and s.resyncwill return ⊥.

To ensure synchronizers behave in a sen-sible way, researchers have proposed different


kinds of properties to constrain the behavior ofsynchronizers. Here we adopt three propertieswe proposed in our previous work for off-sitesynchronization[XLH+07] and adapt them for on-site synchronization.

Suppose s is a synchronizer of the type s ∈D1 ↔ D2 ↔ · · · ↔ Dn. The first property, stabil-ity, is to prevent synchronizers making unnecessarymodifications. It requires that when users modifyno data items, the synchronizer will also modify nodata items.

Property 1 (Stability) ∀θ ∈ s.Θ :s.sync(nomod, . . . , nomod, θ)= 〈nomod, . . . , nomod, θ〉

The second property, preservation, requires alluser modifications should be kept. Each input mod-ification should be a sub modification of the cor-responding output. Here we write ~v.i for the ithcomponent of the tuple ~v.

Property 2 (Preservation) s.sync(~m, θ) =〈~m′, θ′〉 =⇒ ∀i ∈ {1, 2, . . . , n} : ~m.i ◦ ~m′.i = ~m′.i

The third property, propagation, requires thatthe synchronizer should correctly propagate themodification to make all data consistent. Suppose~m1 and ~m2 are two tuples of modifications, we write~m1◦~m2 for 〈~m1.1◦~m2.1, . . . , ~m1.n◦~m2.n〉. Similarly,we write ~m(~d) for a tuple constructed by applyingeach item of the modification tuple ~m to each itemof the data sequence ~d.

Property 3 (Propagation) For any sequence ofinvocations:s.resync(~m0, ~d) = 〈~m′0, θ0〉,s.sync(~m1, θ0) = 〈~m′1, θ1〉,

· · ·s.sync(~mn, θn−1) = 〈~m′n, θn〉;

we have:∀i ∈ {0, . . . , n} : (~m′i ◦ ~m′i−1 ◦ · · · ◦ ~m′0)(~d) ∈ s.R.

3 Data and Modification Types

To simplify our definition of synchronizers, in thissection we define a small set of data types. We tryto make this set of data types general so that otherdata types can be mapped to our data type and

be synchronized by our synchronizers. When f isa partial function, we write f(a) = ⊥ to mean f isundefined on a.

We treat booleans, integers, strings and ⊥ asunstructured primitive values, denoted by Prim.For modifications on Prim, we consider only replac-ing a value by a new value. If v ∈ Prim, we write !vfor a modification on Prim, where !v(a) = v. Themodification set on Prim is MPrim = {nomod}∪{!v |v ∈ Prim}. We sometimes ignore the ! symbol if noconfusion will be caused.

The only structured data type we consider isdictionaries. A dictionary in type Dict < T > mapskeys in Prim to values in T , where T can be prim-itive values or other dictionary types. If we usea universal type Object to denote all primitive val-ues and dictionaries, the typing rule for a dictionarytype is as follows.

T ⊆ U, f ∈ Prim→ T and the domain of f is finite

f ∈ Dict < T >

The modifications on dictionaries are also struc-tured. A dictionary modification on dictionary ap-plies different modifications to values mapped bydifferent keys. Formally, if ω ∈ Prim → MT is afunction mapping keys to modifications, a dictio-nary modification &ω is defined as: &ω(d) = d′

where ∀k ∈ Prim : d′(k) = ω(k)(d(k)) The modi-fication set on a dictionary type Dict < T > is de-fined as MDict<T> = {nomod} ∪ {&ω | ω ∈ Prim →MT }. We sometimes ignore the & symbol if no con-fusion will be caused.

A lot of other data structures can be mappedto this dictionary-based data types. For example,a set can be mapped to a dictionary by giving eachvalue a random key or using the in-memory ad-dress of each value as its key. A sequence canbe mapped to a dictionary by using the index askey, that is, 〈"a", "b", "c"〉 can be represented as{1->"a", 2->"b", 3->"c"}.

For the in-memory objects, we can also mapthem to the data types. For all instance of a class,we represent them as a dictionary mapping fromthe in-memory addresses to the instances. Eachinstance object is represented as a dictionary map-ping from attribute names to attribute values. If


the attribute value is a primitive value, we use theprimitive value. If the attribute value is a referenceto another object, we use the corresponding key ofthe referenced object.

As an example, the deployment view of the EJBtool can be represented by the following two dictio-naries. In a practical system, the keys of the dictio-naries can be replaced by in-memory addresses.

{1->{Name ->"SignOnEJB",

Persistent ->false ,

Module ->1},

2->{Name ->"UserEJB",

Persistent ->true ,

Module ->1},

3->{Name ->"DepartmentEJB",

Persistent ->true ,

Module ->1}

},

{1->{Name ->"SignOn",

Description ->"This module is for ..."

}

4 Synchronizers

Based on the data and modification types, we areready to define some concrete synchronizers andcombinators. For the sake of brevity, we will onlygive the formal definitions of some synchronizers,and introduce the rest synchronizers and combina-tors informally. For all formal definitions, pleaserefer to [XHT+08].

4.1 Basic Synchronizers

Identity We start from a simple synchronizerId<v1OverV2=true> ∈ Object ↔ Object thatkeeps two data items identical. This synchronizeris parameterized on a boolean parameter v1OverV2,where a different assignment to the parameter leadsto a different synchronization behavior. The valuetrue after the equal sign is a default assignmentto the parameter. Here the parameter v1OverV2

defines the behavior of the resync function, and isexplained below.

The Id synchronizer keeps no information in itsstate. Its sync function composites the two inputmodifications, and produce a pair of the compos-ite result when the two input modifications are dis-tinct. When the two inputs conflict, the functionwill fail (returning ⊥). The resync acts accord-

ing to the parameter v1OverV2. When two differ-ent values with no modification are inputted to theresync function, Id has to modify one data itemaccording to the value of the other. The param-eter v1OverV2 determines whether we modify thesecond according to the first (v1 is over v2) or wemodify the first according to the second (v2 is overv1). When v1OverV2=true, the function first applythe input modifications on the first data item, anduse a function findmod to find the smallest modi-fication that can change the second data item intothe first. The result of findmod is composited withthe original modifications and is returned. Whenv1OverV2=false, resync will try to modify the sec-ond data item into the first instead.

Id<v1OverV2=opt> ∈ Object↔ Object

R = {〈a, b〉 | a = b}Θ = {ε}sync(m1,m2, ε) =

{〈m1 ◦m2,m1 ◦m2, ε〉 m1 m2

⊥ else

resync(m1,m2, v1, v2) =

{〈m,m, ε〉 m1 m2

⊥ else

where m ={findmod(v2, (m1 ◦m2)(v1)) ◦m1 ◦m2 opt = true

findmod(v1, (m1 ◦m2)(v2)) ◦m1 ◦m2 opt = false

SetMember, Equality and NotNull The sec-ond synchronizer SetMember<tester, default>

∈↔ Object is used to ensure a data item is be-longing to a specific set or not. The first parameteris a function tester ∈ Object → Boolean whichdefines the set. If a data item is in the set, testerreturns true, otherwise tester returns false. Thesecond parameter default is a value in the set,which is used to produce a value in resync whenthe input value is not in the set.

The SetMember synchronizer keeps the currentvalue of the data item in its state. Its sync functionapplies the modification to its state, and report afailure if the new state is not in the set. Its resyncfunction tries to modify the input value to the de-fault if the input is not in the set, and report afailure when the modification found conflicts withthe input. The definition of SetMember is as follows.


SetMember<tester=f, default=v0> ∈↔ Object

R = {a | f(a) = true}Θ = Object

sync(m, v) =

{〈m,m(v)〉 f(m(v)) = true⊥ else

resync(m, v) =

〈m,m(v)〉 f(m(v)) = true

〈findmod(v, v0) ◦m, v0〉 f(m(v)) = false∧findmod(v, v0)m

⊥ else

By using SetMember, we can construct severaluseful synchronizers. For example, if we define afunction equal<v> as

equal < v >(a) =

{true a = v

false else,

We can define a synchronizer Equal that ensures adata item is equal to a specific value.

Equal <v>=

SetMember <tester=equal <v>, default=v>

Similarly, we can define a NotNull synchronizerthat ensures a data item is not null.

notNull(a) =

{true a 6= null

false else

NotNull <default >=

SetMember <tester=notNull , default=default >

4.2 Synchronizers on Dictionaries

We define two primitive synchronizers on dictio-naries. The two synchronizers both synchronize adictionary and a data item, and ensure the dataitem is equal to the value mapped by a key in thedictionary. The difference is that the key of thestatic get synchronizer is statically determined atprogramming time and the key of the dynamic getsynchronizer is dynamically obtained from a thirddata item.

Static Get The static get synchro-nizer SGet<key, dictOverValue=true>∈Dict < T > ↔ T synchronizes a dictionarywith a data item and ensures the data item is equalto the value mapped by key in the dictionary. Thesecond parameter dictOverValue is similar tov1OverV2 in Id: in the resync function, whetherthe synchronizer try to modify the dictionaryaccording to the data item or try to modify thedata item according to the dictionary.

The implementation of SGet is similar to ID,except that it synchronizes an item in a dictionarywith the other item. Because the modification ondictionaries is a function mapping keys to modifi-cations, we can get the inner modification mappedby key and proceed as Id.

Dynamic Get The dynamic get synchronizerDGet<dictOverValue=true, changeKey=false,

keyFactory=null>∈ Prim ↔ Dict < T > ↔ T

ensures the third data item is equal to the valuemapped by the first data item in the seconddata item, a dictionary. The first parameterdictOverValue has the same meaning as thedictOverValue parameter of the static get syn-chronizer: whether we modify dictionary accordingto the third data item or we modify the data itemaccording to the dictionary.

The parameter changeKey is also a booleanvalue. If changeKey=false, then the dynamic getsynchronizer will act the same behavior as the staticget dictionary. Suppose the current values of thethree data items are 〈1, {1->"a", 2->"b"}, "a"〉and the input modifications are 〈nomod, nomod,

"b"〉, the synchronizer will produce 〈{1->"b"},nomod, "b"〉.

If changeKey=true and the first modification isnomod, the dynamic get synchronizer will first ap-ply the input modifications to the dictionary andthe data item, and then try to find a value inthe changed dictionary whose value is equal to thechanged data item. If there is such a value, the dy-namic get will change the first data item to the keymapping to the value. If there is no such a valueand keyFactory=null, or if the first modification isnot nomod, the synchronzier acts the same behavioras changeKey=false.

For example, if the current values of the dataitems and the input modifications are the same asthe above, but changeKey=true, the result will be〈nomod, 2, "b"〉.

The third parameter keyFactory is effectiveonly when changeKey=true. It is a functionkeyFactoyr ∈ Dict < T > → Prim used to gener-ate a new key that is different from all existing keysin the dictionary. When keyFactory is not null,


the synchronizer will create a new key if it cannotfind a proper value in the dictionary. This parame-ter is useful when the dictionary is a set of objectsand sometimes we want to create new objects fromother modifications.

4.3 Combinators

We have seen a set of primitive synchronizers.In practice, the consistency relationship over dataare often much more complex than the primi-tive synchronizers can cover. To specify these re-lationships, we adopt the compositional methodused in many off-site synchronization approaches[FGM+07, LHT07]. These approaches define a setof combinators where a combinator can combinesynchronizers into new a synchronizer to synchro-nize artifacts according to a new relation that iscombined from the consistency relations of the in-ner synchronizers. In this way users can combinethe consistency relationships as they needed.

Graph Combinator We have seen graph com-binator in the introduction. The synchronizerin Figure 2 ensures the Name attribute of ejb isequal to the EJBName attribute of entityBean.The graph combinator combines synchronizers us-ing a graph. The nodes of the graph are vari-ables (ejb, entitybean, and name), and the edgesof the graph are synchronizers (the two SGet

synchronizers). For example, the statement ofSGet<key="Name">(ejb, name) connects the SGet

synchronizer to the variable ejb and the variablename, enforcing the consistency relationship SGet.R

over ejb and name. Variables are further classifiedinto external variables and internal variables. Onlyexternal variables are expose to the synchronizersoutside the graph. Input/output modifications areassumed to be applied on the external variables inthe same order where the external variables appear.

The sync function of the graph combinator firstputs the input modifications on the external vari-ables, and invokes the inner synchronizers connect-ing to the external variables whose modificationsare not nomod. Once an inner synchronizer is in-voked, the output modification of the inner syn-

chronizer will be put on the variables, and the syncfunction further invokes all synchronizers connect-ing to a variable whose modification is changed af-ter the invocation. The resync function is similarto the sync function, except that sync invokes thesync function of inner synchronizers, while resyncinvokes the resync function of inner synchronizers.

It is possible that more than one inner synchro-nizers can be invoked at the same time. For ex-ample, a changed external variable is connected tomore than one synchronizers. In such situations,the graph combinator will invoke the inner synchro-nizers in the order that they appear in the declara-tion of the synchronizer. For example, if both ejb

and entityBean are changed, EJBNameEqual willinvoke SGet<key="Name"> first.

Switch Combinator The switch combinatorrepresents the union of relations. The follow-ing code shows a synchronizer constructed using aswitch combinator:switch {

graph{moduleRef , modules }{

var=module;

DGet(moduleRef , modules , module );

NotNull <defaultValue =0>( module );

};

graph(moduleRef , modules ){

Equal <value=null >( moduleRef );

};

}

This synchronizer ensures a reference to a mod-ule being valid. It contains two inner synchronizers,both of which are constructed using the graph com-binator. The first synchronizer ensures that if wequery the dictionary modules with moduleRef, weare ensured to get a module object which is notnull. The second synchronizer ensures moduleRef

is null. The union of the two synchronize ensuresthe reference moduleRef is always valid, that is,either moduleRef is null or moduleRef exists inmodules.

The switch combinator works by invoking theinner synchronizers one by one. The state of theswitch synchronizer includes the current values ofthe data items and the index of the synchronizerinvoked the last time. The sync function of theswitch combinator first find the synchronizer usedin the last time and invokes its sync function. If


the function succeeds, the switch combinator re-turns. Otherwise it will invoke the resync functionsof the other inner synchronizers in the order theyappear in the declaration, and return the result ofthe first succeeded function. If all inner synchro-nizer fails, the function returns ⊥ to report a fail-ure. The resync function of the switch combinatorjust invokes the resync functions of the inner syn-chronizers one by one and return the result of thefirst succeeded function.

For example, suppose the current value ofmoduleRef is 1, and the input modification is〈nomod, {1->null}, nomod〉. That is, the refer-ence is no longer in the dictionary and is invalid.The switch combinator first invokes sync functionof the first inner synchronizer, which is the syn-chronizer used in the last synchronization. This in-ner synchronizer first invokes DGet to propagate a!null modification to module, and then fails be-cause NotNull fails. After that, the resync func-tion of the second inner synchronizer is invoked, andmoduleRef is set to null.

In MOF [OMG02] there is a special referencecalled containment reference, which indicates oneobject is contained in another object respect to thereference. When the referenced object is deleted, weshould also delete the contained object. This kindof reference can be simulated using the followingsynchronizer.

ContainmentReference <attribute > = switch {

graph(childObj , parentObjs) {

var=ref , parentObj;

SGet <key=attribute >(childObj , ref);

DGet(ref , parentObjs , parentObj );

NotNull <default =0>( parentObj );

};

graph(childObj , parentObjs) {

Equal <value=null >( childObj );

};

}

Map Combinators The combinators we haveseen so far are static, which means the data itemsto be synchronized by inner synchronizers are stat-ically determined. Sometimes we need to dynam-ically synchronize newly created data items or re-move existing items according to modifications onthe data items. For instance, we may want to syn-chronize two dictionaries by using an inner synchro-

nizer s to synchronize every two items in the twodictionaries. We introduce two map combinatorsfor this task.

The two map combinators synchronize a se-quence of dictionaries both by matching the itemsin the dictionaries and synchronizing the matchedtuple with an inner synchronizer. The differenceis how they match the items. The emap combina-tor matches items by key. Items are matched onlyif they are mapped by the same key in the dictio-naries. This is suitable for dictionaries whose keyscontaining significant information, like sequences.The smap combinator matches two dictionaries bythe inner synchronizer s. Two items are matchedif they are successfully synchronized by s. This issuitable for dictionaries whose keys containing in-significant information, like sets.

For example, the following code construct syn-chronizers using emap and smap, respectively.

s1=emap <sync=Id, dicts=2>

s2=smap <sync=Id, factories =[f1, f2]>

The inner synchronizers for both combinators areId. The combinator emap also takes a parameterto specify the number of dictionaries to synchronize.The combinator smap also takes a list of key facto-ries in case that it need to create new keys when asuitable match cannot be found for some keys. Thecombinator emap does not need a factory list be-cause it just copies keys from one dictionary to theother and does not create new keys.

Suppose the current values for thetwo dictionaries are both empty dictio-naries. With an input modifications of{1->"a"}, {2->"a", 3->"b"}, synchronizers1 will produce {1->"a", 2->"a", 3->"b"},

{1->"a", 2->"a", 3->"b"} where the valuemapped by the same key are made identical.Synchronizer s2 will produce {1->"a", 2->"b"},

{2->"a", 3->"b"}, where the keys 1 and 2 arematched because they are modified to the samevalue, and a new key 2 is created in the firstdictionary because no proper match can be foundfor the key 3 in the second dictionary.

Sometimes the inner synchronizer may needsome shared data items that cannot be obtained


from the two dictionaries. For example, when weare synchronizing an EJB and an entity bean, weneed the module dictionary to obtain informationfor the moduleName attribute. In this case, weresynchronize all data items whenever the shareddata items are modified by an inner synchroniza-tion, so that all items in the dictionaries are consis-tent with the shared data item.

For example, the following synchronizer main-tains a containment reference between two dictio-naries using the ContainmentReference synchro-nizer we have created:

ReferenceMaintainer <attribute > = emap {

sync = ContainmentReference

<attribute=attribute >;

dicts = 1;

}

The dicts parameter is set to 1, whichmeans the first data item synchronized byContainmentReference is a dictionary to beiterated and the second data item is a shared dataitem. All objects in the first dictionary shouldhave a valid containment reference, or the objectsis deleted from the dictionary by being set to null.

4.4 The Synchronizer for the EJB Model-

ing Tool

Now we have seen all the primitive synchronizersand the combinators. Let us construct the synchro-nizer for the EJB Modeling Tool. The code for thesynchronizer is shown in Figure 3.

The final synchronizer is Main, which synchro-nizes the three dictionaries of EJBs, modules andentity beans using three inner synchronizers. Thefirst inner synchronizer ModulesAndNames mappedthe modules dictionary into a dictionary of modulenames to be used by TwoViewMaintainer. Thesecond inner synchronizer ReferenceMaintainer

maintains the containment reference Module

of the EJB objects. The last synchronizerTwoViewMaintainer maintains the mappingsbetween the two views. This synchronizer mapsbetween the EJB dictionary and the entity beandictionary while the module name dictionary isused as a shared item. The inner synchronizer isfurther a switch between three synchronizers.

Persistent deals with persistent EJBs. ThePersistent attribute of the EJB object is re-quired to be true while other attributes are mappedbetween the EJB object and the entity bean.NonPersistent deals with non-persistent EJBs.The Persistent attribute of the EJB object isensured to be false while the entity bean is en-sured to be null. That is, no entity bean is cre-ated for non-persistent EJBs. Deletion deals withdeleted objects. Both the EJB object and the en-tity bean are ensured to be equal to null. Notein the switch synchronizer NonPersistent appearsbefore Deletion, which means when an entity beanis deleted, we first try to change the EJB into a non-persistent one, rather than deleting the EJB.

The synchronization behavior can be easilychanged by changing the composition of synchro-nizers and the parameters on synchronizers. Forexample, if we want the synchronizer to deletean EJB when an entity bean is deleted, we justput Deletion before NonPersistent in the switch

combinator. For another example, when userschange the ModuleName attribute of an entity bean,the current synchronizer will try to find a modulewhose name is equal to the modified name and movethe corresponding EJB to that module. If we wantthe synchronizer instead to change the name of theoriginal module, we can just set the changeKey pa-rameter of the DGet synchronizer to false.

5 Case Study

As we have constructed the synchronizer for theEJB modeling tool, we would like to see how thesynchronizer works in actions. In this section, weuse Eclipse Graphics Modeling Framework (GMF)and on-site synchronizers to actually construct theEJB modeling tool. The result interface of the ed-itor has been shown in Figure 1. Besides the twoviews in Figure 1 there is also a “synchronize” but-ton. When users press the button, the modificationson the two views are synchronized.

GMF is a framework for generating graphicaleditors. In GMF, users define a meta model and aset of shapes, together with a mapping between ele-ments of the meta model and the shapes, and GMF


Persistent = graph(ejb , entitybean , modules) {

var = moduleRef , ejbName , moduleName , persistent;

SGet <key="Persistent", dictOverValue=false >(ejb , persistent );

Equal <value=true >( persistent );

SGet <key="Name">(ejb , ejbName );

SGet <key="EJBName", dictOverValue=false >(entitybean , ejbName );

SGet <key="ModuleName", dictOverValue=false >(entitybean , moduleName );

SGet <key="Module" >(ejb , moduleRef );

DGet <changeKey=true , dictOverValue=false , keyFactory=MaxInteger >

(moduleRef , modules , moduleName );

}

NonPersistent = graph(ejb , entitybean , modules) {

var = persistent;

SGet <key="Persistent", dictOverValue=false >(ejb , persistent );

Equal <value=false >( persistent );

Equal <value=null >( entitybean );

}

Deletion = graph(ejb , entitybean , modules) {

Equal <value=null >(ejb);

Equal <value=null >( entitybean );

}

TwoViewMaintainer = smap <

sync = switch{

Persistent;

NonPersistent;

Deletion;

},

factories = [MaxInteger , MaxInteger]

>

ModulesAndNames = emap <

sync = switch {

SGet <key = "Name", dictOverVal=dictOverVal >;

graph(a, b){Equal <value=null >(a);Equal <value=null >(b);};

},

dicts = 2

>

Main = graph(ejbs , modules , entitybeans) {

var = modulenames;

ModulesAndNames(modules , modulenames );

ReferenceMaintainer <attribute="Module" >(ejbs , modules );

TwoViewMaintainer(ejbs , entitybeans , modulenames );

}

Figure 3. The Synchronizer for the EJB Modeling Tool


generates a graphical editor that uses the shapes toedit models defined by the meta model. A simpli-fied structure of GMF-generated editors is shown inFigure 4. The model is responsible for maintainingthe data defined by the meta model and the viewis responsible for displaying the data using the pre-defined shapes. When users make modifications onthe view, the view modifies the model, and whenmodel is modified, it updates the view.

M o d e l

V i e w

u p d a t e m o d i f y

Figure 4. The Structure of a GMF Editor

GMF requires the mappings between metamodel elements and shapes to be of one-to-one map-ping, that is, the graphical view and the model can-not be heterogeneous. As a result, although we cangenerate multiple heterogeneous views using GMF,the data of these views cannot be synchronized.

We fill the missing synchronization part usingon-site synchronizers, and the structure of our edi-tor is shown in Figure 5. We define different mod-els for different views, and uses GMF to generatemultiple independently running single-view appli-cations. The synchronization part is shared amongall these applications. When a view is modifyingits model, the modification is captured by a modellistener. This can be achieved through the notifi-cation mechanism provided by GMF. When userspress the “synchronize” button, the modificationsrecorded in the model listener will be inputted intothe synchronizer, and the synchronizer will producethe synchronized modifications. Finally, the syn-chronized modifications are applied to the modelsthrough a modification applier.

As mentioned in Section 1, the synchronizationpart can directly use the internal addresses of ob-jects to interact with other part, rather than defin-ing key attributes for objects. Here we have twochoices to convert objects into dictionaries. Thefirst one is that we directly use the addresses of

M o d e l 1

V i e w 1

u p d a t e

m o d i f y

M o d e l 2

V i e w 2

u p d a t e

m o d i f y

M o d e l L i s t e n e r

S y n c h r o n i z e r

M o d i f i c a t i o n A p p l i e r

[ m o d i f i c a t i o n s ]

[ s y n c h r o n i z e d m o d i f i c a t i o n s ]

a p p l ya p p l y

Figure 5. Synchronizing Multiple Views in GMFEditors

objects as keys of the objects in the dictionaries.The second one is that we use integers as the keysfor objects, and keep a bijective mapping betweenthe integers and the addresses of objects. The firstmethod is more efficient, but it requires the objectsand the states of synchronizers be serialized in thesame way when we save the file. Because GMF usesXMI to store objects, we choose the second methodin our construction of the EJB tool.

The EJB editor is constructed using the struc-ture in Figure 5. A deployment view editor and apersistent view editor are generated from two sets ofdefinitions using GMF. The synchronizer betweenthe two views is constructed using the code in Fig-ure 3, and the model listener and the modificationapplier are manually constructed from 340 lines ofJava code. The whole development takes no morethan ten hours.

To test our synchronizers work correctly, wehave performed dozens of experiments on the ed-itor, and all experiments gave desirable results. Inthe following we describe a few experiments relatedto the important properties of on-site synchronizers.

In the first experiment, we created an entitybean on the persistent view with EJBName="User"

and ModuleName="SignOn". After synchroniza-tion, an EJB named "User" and a module named"SignOn" was added to the deployment view. TheEJB belongs to the module and its Persistent at-tribute is set to "true". The two views are nowconsistent, embodying the propagation property.

In the second experiment, we pressed the syn-chronization button without modifying anything.


The two views remained the same, satisfying thestability property.

In the third experiment, we modified the de-scription text of the SignOn module. After syn-chronization, the modified text, together with otherparts of the views, remained the same, satisfying thepreservation property.

In the forth experiment we tested the abilityof handling conflicting modifications. We modifiedthe EJBName attribute of the entity bean to "x" andrenamed the EJB to "y". When we synchronized,we got a message saying that there were conflictingmodifications. We solved the conflict by renamingthe EJB to "x", and synchronized again. This timethe synchronization passed without errors.

6 Performance Evaluation

We evaluate the performance of our approach by ex-perimenting with the synchronizer for the EJB de-sign tool. We also compare our results with an off-site incremental synchronizer, medini QVT v1.1.2[ikv], which is a state-of-art implementation of themodel transformation standard [Obj05]. Our ex-periments are carried out on a laptop with an 1.70GHz Intel(R) Pentium(R) M processor and 1.25 GBRAM.

Before carrying out the experiments, we preparesome common data. We first construct a large num-ber of EJBs and modules, where every 100 EJBs be-long to a module and the attributes are randomlyassigned. Then we synchronize to get a consistentset of entity beans.

In the first set of experiments we randomlychoose a set of EJBs, set their Name attributes tonew values, and record the synchronization time.The result is shown in Table 1. The third columnshows the time our tool takes and the forth columnshows the time medini QVT takes. To be fair, weexclude the time during which medini QVT loadsand saves XMI files, and only use the in-memoryevaluation time reported by medini QVT.

From the table we can see, the synchronizationtime of our tool is a linear function of the modi-fication size. The time remains constant when weincrease the number of EJBs and increases linearly

Table 1. Modifying the Name AttributeMod.Size

Numberof EJBs

Time(ms)(Synchronizers)

Time(ms)(QVT)

500 1000 20 901500 2000 20 2083500 3000 20 6048500 4000 20 10155500 5000 20 16594500 6000 20 237851000 6000 40 238941500 6000 60 247062000 6000 90 245752500 6000 130 25427

when we increase the size of modifications.The time of medini QVT is much longer than

our approach and is mainly related to the numberof EJBs. This is probably because QVT works off-site. When synchronizing, medini QVT has to re-check whether all applied rules are still valid andthe number of rules is related to the number of EJBobjects.

However, the synchronization time cannot al-ways be a linear function of modification opera-tions. In the second set of experiments we firstchanges the changeKey parameter of the DGet syn-chronizer to false, that is, when we modify theModuleName attribute of an entity bean, the nameof the corresponding module will be changed. Thenwe randomly choose an entity bean object and mod-ify its ModuleName attribute to a new value. Be-cause more than one entity bean can belong to thesame module, to synchronize we have to iterate allEntityBean objects to find the objects in the samemodule for modifying their ModuleName attributes,and the time of the iteration is related to the num-ber of objects. The result of the experiment isshown in Table 2. Note medini QVT cannot syn-chronize this modification because it does not prop-agate modifications within one model.

Table 2. Modifying the ModuleName Attribute

Number of EJB objects Time(ms)

1000 502000 803000 1014000 1905000 250

From the table we can see that the synchroniza-


tion time increases as the number of EJB objectsincreases. Nevertheless, the synchronization time isstill short and we believe that it is efficient enoughto support real applications.

7 Related Work

The mainstream work of off-site synchronizationis work on bidirectional transformation [FGM+07,KH06, KW07, LHT07, Obj05]. In these ap-proaches, a bidirectional language is used to de-scribe a consistency relation R between two arti-facts a ∈ A, b ∈ B, a forward function f : A×B →B and a backward function g : A × B → A atthe same time [Ste07]. Bidirectional transformationcannot directly support modifying the two artifactsat the same time. Benjamin and et al. [PSG03] pro-posed a framework, Harmony, to support this withbidirectional transformation by designing a com-mon artifact and use a reconciler to reconcile dif-ferent versions of the common artifact.

Some bidirectional transformation approachesalso target at synchronizing data in software ap-plications. Two among them are Triple GraphGrammars (TGGs) [KW07], a model transforma-tion approach applying early work in graph gram-mars to modeling environments [NNZ00, AKRS06],and QVT relations [Obj05], the standard of modeltransformation. The two approaches have beenproved structurally similar by Greenyer and Kindler[GK07]. They are both rule-based, and can supportincremental synchronization by re-checking appliedrules. Part of our design of on-site synchronizers,like the smap combinator, is inspired by TGGs. Onthe other hand, we try to stay less declarative thanTGGs, so that we can provide finer control oversynchronization behavior to users.

Some researchers focus on the on-site mainte-nance of view consistency, which is a typical ap-plication of on-site synchronization. Amor and etal. [AHM95] design a declarative language which fo-cuses on bijective mappings between views and pro-vides powerful support to expressions. Some otherwork [GHM98, FGH+94] provides general frame-works for view consistency, where users write codefor identifying and handling inconsistency. Com-

pared to these frameworks, our approach only re-quires users to composite synchronizers once andusers automatically get the ability of handling in-consistency.

Our work started from our previous attempt[XLH+07] on synchronizing models from a forwardtransformation program. However, later we foundthat it is difficult to fully present the semantics ofsynchronization just in a forward program, and thenwe designed synchronizers, to provide a precise andflexible foundation for synchronization.

8 Discussion and Future Work

In this paper we have defined several on-site syn-chronizers and combinators, and have used them toconstruct an EJB modeling application. However,several issues still need attention before on-site syn-chronizers can be widely used. Here we discuss fourof these issues.

Memory Consumption To achieve an efficientsynchronization of application data, on-site syn-chronizers keep some information as their internalstates. Keeping these states requires extra memory.Currently, to synchronize 6000 EJBs, we need about110m memory, which is about twenty times higherthan just keeping the objects without synchroniz-ers. The memory consumption may be reduced bysharing of data. The current states of synchronizersare mainly the copies of data they synchronize. Ifwe just keep references to the original data insteadof keeping duplicated copies, a lot of memory canbe saved. We leave this engineering task for futurework.

Totality The current synchronizers are not to-tal, which means, synchronizers may fail even ifthere is no conflicts among modifications. To seehow this happens, consider the following synchro-nizer.

graph(k, d, v) {

vars=k0;

DGet <changeKey=true >(k0, d, v);

Id(k, k0);

}

Suppose the input modifications are 〈2, nomod,"newV"〉. Since both inner synchronizers are con-


nected to modifications, they are invoked in the or-der they appear in the declaration. When DGet isinvoked, it will try to find a new key for the changedvalue. However, if the new key is different from 2,the synchronization will fail when the Id is invoked.

This failure can be avoided by changing the or-der of Id and DGet. As a result, the current synchro-nizers require programmers to carefully consider thesynchronization behavior when they define synchro-nizers, and sometimes the synchronization behavioris not easy to analyze.

We plan to overcome this problem by designingsome high level languages that is total, so that userscan program synchronizers by considering only theconsistency relations over application data.

Termination The current synchronizers are notalways ensured to terminate. Suppose AddOne is asynchronizer over two integers a and b, and ensuresa + 1 = b. One example of a non-terminating syn-chronizer is as follows.

graph{d1 , d2}{

map <sync=AddOne , dicts=2>(d1, d2);

map <sync=AddOne , dicts=2>(d2, d1);

}

When users add a new integer x to d1, the firstmap will insert a new integer x+ 1 to d2, and thenthe second map will be invoked and insert x + 2 tod1 and x − 1 to d2. After that, the first map willbe invoked again, and will insert two more items tothe dictionaries. This process will repeat and willnot stop.

Termination is a more fundamental problem toprogramming, and non-terminating programs canalso be constructed in other synchronization ap-proaches [KW07, Obj05] and common program-ming languages. If we want to keep synchronizersalways terminating, we may have to greatly reducethe expressiveness of synchronizers, which conflictswith our original goal. Therefore we choose not toensure the termination of all synchronizers, and relyon programmers to create terminating synchroniz-ers.

Conflicts Reporting The current synchroniz-ers only report the existence of conflicts. A morepreferable way is to report the locations of conflicts

so that users know where to solve the conflicts. Thiscan be possibly achieved by extending a modifica-tion with a source location, which records the orig-inal location of the modification. When a synchro-nizer propagates a modification from one data itemto another data item, it also copies the source lo-cation part to the new modification. However, forcomplex synchronizers it is sometimes difficult totell where the modification is propagated from. Forexample, for a DGet synchronizer, when the key andthe dictionary are both modified, it is difficult tosay the modification propagated to the third dataitem is from the key or from the dictionary. Weplan to further investigate this issue and design analgorithm for propagating the source locations ofmodifications.

References[AC06] Michal Antkiewicz and Krzysztof Czarnecki.

Framework-specific modeling languages withround-trip engineering. In Proc. 9th MoD-ELS, pages 692–706, 2006.

[ACar] Michal Antkiewicz and Krzysztof Czarnecki.Design space of heterogeneous synchroniza-tion. In Proc. 2nd GTTSE, to appear.

[AHM95] Robert Amor, John Hosking, and WarwickMugridge. A declarative approach to inter-schema mappings. In Modelling of Build-ings Through Their Life-Cycle: Proc CIBW78/TG10 Conference, 1995.

[AKRS06] C. Amelunxen, A. Konigs, T. Rotschke, andA. Schurr. MOFLON: A standard-compliantmetamodeling framework with graph trans-formations. In Proc. 2nd ECMDA, pages361–375, 2006.

[FGH+94] A. C. W. Finkelstein, D. Gabbay, A. Hunter,J. Kramer, and B. Nuseibeh. Inconsistencyhandling in multiperspective specifications.IEEE Trans. Softw. Eng., 20(8):569–578,1994.

[FGM+07] J. Nathan Foster, Michael B. Greenwald,Jonathan T. Moore, Benjamin C. Pierce,and Alan Schmitt. Combinators for bidirec-tional tree transformations: A linguistic ap-proach to the view-update problem. ACMTrans. Program. Lang. Syst., 29(3):17, 2007.

[GHM98] John Grundy, John Hosking, and War-wick B. Mugridge. Inconsistency manage-ment for multiple-view software develop-ment environments. IEEE Trans. Softw.Eng., 24(11):960–981, 1998.


[GK07] Joel Greenyer and Ekkart Kindler. Recon-ciling TGGs with QVT. In Proc. 10th MoD-ELS, pages 16–30, 2007.

[ikv] ikv++ technologies. medini QVT homepage.http://www.ikv.de/index.php?option=

com content&task=view&id=75&Itemid=77.

[KH06] Shinya Kawanaka and Haruo Hosoya. biXid:a bidirectional transformation language forXML. In Proc. 11th ICFP, pages 201–214,2006.

[KW07] Ekkart Kindler and Robert Wagner. Triplegraph grammars: Concepts, extensions, im-plementations, and application scenarios.Technical Report tr-ri-07-284, University ofPaderborn, June 2007.

[LHT07] Dongxi Liu, Zhenjiang Hu, and MasatoTakeichi. Bidirectional interpretation ofXQuery. In Proc. PEPM, pages 21–30, 2007.

[NNZ00] Ulrich Nickel, Jorg Niere, and AlbertZundorf. The FUJABA environment. In InProc. 22nd ICSE, pages 742–745, 2000.

[Obj05] Object Management Group. MOFQVT final adopted specification.http://www.omg.org/docs/ptc/05-11-01.pdf, 2005.

[OMG02] OMG. MetaObject Facility specifica-tion. http://www.omg.org/docs/formal/02-04-03.pdf, 2002.

[PSG03] Benjamin C. Pierce, Alan Schmitt, andMichael B. Greenwald. Bringing Harmony tooptimism: A synchronization framework forheterogeneous tree-structured data. Tech-nical Report MS-CIS-03-42, University ofPennsylvania, 2003.

[Ste07] Perdita Stevens. Bidirectional model trans-formations in QVT: Semantic issues andopen questions. In Proc. 10th MoDELS,pages 1–15, 2007.

[XHT+08] Yingfei Xiong, Zhenjiang Hu, Masato Take-ichi, Haiyan Zhao, and Hong Mei. On-sitesynchronization of software artifacts. Tech-nical Report Report METR 2008-21, De-partment of Mathematical Informatics, Uni-versity of Tokyo, April 2008.

[XLH+07] Yingfei Xiong, Dongxi Liu, Zhenjiang Hu,Haiyan Zhao, Masato Takeichi, and HongMei. Towards automatic model synchroniza-tion from model transformations. In Proc.22nd ASE, pages 164–173, 2007.

[YKW+08] Yijun Yu, Haruhiko Kaiya, HironoriWashizaki, Yingfei Xiong, and ZhenjiangHu. Enforcing a security pattern in stake-holder goal models. In Proc. 4th QoP Work-shop, 2008.

Documents

On-Site Synchronizers for Multi-View Applications · use a class diagram to show the static structure of the system and use a sequence diagram to show the dynamic behavior. In many