Correctness of Generalisation and Customisation of Concurrent Model Synchronisation Based on Triple Graph Grammars

(1)

der Fakult ¨at IV – Elektrotechnik und Informatik

Correctness of Generalisation and Customisation

of Concurrent Model Synchronisation

Based on Triple Graph Grammars

Susann Gottmann, Frank Hermann, Nico Nachtigall, Benjamin Braatz,

Claudia Ermel, Hartmut Ehrig, and Thomas Engel

Bericht-Nr. 2013-08

ISSN 1436-9915

(2)

Concurrent Model Synchronisation Based on Triple Graph

Grammars

Susann Gottmann

Interdisciplinary Centre for Security, Reliability and Trust Universit´e du Luxembourg

Luxemburg

susann.gottmann@uni.lu

Frank Hermann

Luxemburg frank.hermann@uni.lu

Nico Nachtigall

Luxemburg

nico.nachtigall@uni.lu

Benjamin Braatz

Luxemburg

benjamin.braatz@uni.lu

Claudia Ermel

Technische Universit¨at Berlin Germany

claudia.ermel@tu-berlin.de

Hartmut Ehrig

Technische Universit¨at Berlin Germany

hartmut.ehrig@tu-berlin.de

Thomas Engel

Luxemburg thomas.engel@uni.lu

Triple graph grammars (TGGs) have been successfully applied to specify and analyse bidirectional model transformations. Recently, a formal approach to concurrent model synchronisation has been presented, where a source and a target modification have to be synchronised simultaneously. In this approach, conflicts between the given and propagated source or target model modifications are taken into account. A semi-automatic conflict resolution strategy is proposed, where a formal resolution strategy can be combined with a user-specific strategy. Up to now, our approach requires determinis-tic propagation operations.

In this paper, we want to relax this condition and also consider non-deterministic (conflicting) operations which might require backtracking. For optimisation, we propose to eliminate conflicts between the operational rules of a TGG using the concept of filter NACs. Nevertheless, concurrent synchronisation is non-deterministic from a user perspective: The user may choose between forward synchronisationand backward synchronisation. Moreover, the conflict resolution strategy may result in several solutions from which the user has to select the most adequate one. Hence, we discuss dif-ferent kinds of customisation of the synchronisation process and explain the impacts of the different strategies.

1 Introduction

Bidirectional model transformations have been successfully modelled and analysed using triple graph grammars (TGGs) [25, 26]. More recently, TGGs have also been applied in case studies for model integration and model synchronisation [20, 7, 9].

(3)

Model synchronisation aims to propagate updates between interrelated domains in order to derive updated models that are consistent with each other. Since model changes may occur concurrently in related domains and in a distributed way, model synchronisation has to cope with merging updates and resolving conflicts in the general case.

In order to perform model synchronisation of concurrent updates, we use the concurrent model syn-chronisation approach based on triple graph grammars [12]. In this approach, model synsyn-chronisation is performed by propagating the changes from one model of one domain to a corresponding model in another domain using forward and backward propagation operations. The propagated changes are compared with the given local updates. Possible conflicts are resolved in a semi-automated way. The op-erations are realised by model transformations based on TGGs [15, 18] and tentative merge constructions solving conflicts [6].

The synchronisation framework presented in [12] is based on deterministic propagation operations

fPpgandbPpg. In a more general setting with non-deterministic operations, the procedure would

re-quire backtracking and yield several possible results. In this paper, we also consider non-deterministic (conflicting) operations which might require backtracking. We propose to eliminate conflicts between the operational rules of a TGG using the concept of filter NACs that was already successfully applied in the area of model transformations [13]. For this purpose, we extend certain synchronisation oper-ations automatically with compatible NACs and show that these changes do not affect the correctness and completeness results for the derived synchronisation framework. This first main result of the pa-per ensures that concurrent model synchronisation can be pa-performed efficiently also in cases where the TGG operations are initially not deterministic, but become deterministic via the applied extension for optimisation.

Nevertheless, concurrent synchronisation might be non-deterministic from a user perspective: The user may choose between forward synchronisation (where the changes on the source domain are propa-gated to the target domain) and backward synchronisation (where target domain changes are propapropa-gated back to the source domain). Moreover, the conflict resolution strategy may result in several solutions from which the user has to select the most adequate one. User input is required to guide the synchronisa-tion process. Hence, in the second contribusynchronisa-tion in this paper, we discuss different kinds of customisasynchronisa-tion of the synchronisation process and explain the impacts of the different customisation strategies.

The paper is structured as follows: We present our running example in Sec. 2, a concurrent model synchronisation problem in the area of business modelling. Sec. 3 reviews the main concepts and results of the formal framework for concurrent model synchronisation [15, 12, 18]. In Sec. 4, we generalise the formal framework to non-deterministic forward and backward propagation operations and describe our new conflict elimination strategy based on filter NACs. Sec. 5 and Sec. 6 compare different customisation strategies to guide the user in obtaining a desired synchronisation result. After discussing related work in Sec. 7, we conclude the paper with an outlook to future work in Sec. 8.

2 Application Scenario

In this section, our running example will be introduced in presenting the concurrent model synchroniza-tion problem (Sec. 2.1). We will distinguish different kinds of model updates, which cause different effects during the synchronization process. The corresponding TGG used for the derivation of the corre-sponding synchronisation framework is provided in Sec. 3 thereafter.

(4)

Daniel Davis Base=3000 Bonus=3000 Freya Fisher Base=4000 Bonus=3000 Paul Page Base=2300 Bonus=1200 Tony Taylor Base=2500 Bonus=2000 Henry Hunter Base=3000 Bonus=2000 Lucy Lewis Base=3000 Bonus=600 Daniel Davis *1949-09-09 Salary=6000 M Freya Fisher *1965-12-05 Salary=7000 M Paul Page *1972-09-12 Salary=3500 M Henry Hunter *1954-03-30 Salary=5000 M Lucy Lewis *1990-01-31 Salary=3600 M K.-A. Knight *1961-05-07 Salary=5400 M Jack Judge *1975-10-25 Salary=4000 M Kai-Axl Knight Base=3400 Bonus=2000 Alex Archer Base=3000 Bonus=1500 Jack Judge Base=3000 Bonus=2000 Harrison Hunt Base=2500 Bonus=1000 Mia MacDonald Base=2500 Bonus=1500

Holly Jane Hill Base=3000 Bonus=2000 Henry Hunter Base=3000 Bonus=2000 Max McDonald Base=2500 Bonus=1500 Paul Page Base=2300 Bonus=1200 Max McDonald *1986-01-09 Salary=4000 M Molly Murphy *1971-12-24 Salary=5000 M Freya Fisher *1965-12-05 Salary=7000 D Henry Hunter *1954-03-30 Salary=5000 D Lucy Lewis *1990-01-31 Salary=3600 M M Holly Jane Hill *1981-07-18 Salary=5000 Mia McDonald *1987-08-18 Salary=4000 M K.-A. Knight *1961-05-07 Salary=5400 M M Alex Archer *1975-02-14 Salary=4050 M Tony Taylor *1983-11-20 Salary=4500 M Alex Archer *1975-02-14 Salary=4000 M Mia Miller *1987-08-18 Salary=4000 M Holly J. Hill *1981-07-18 Salary=5000 Holly J. Hill Base=3000 Bonus=2000 Mia Miller Base=2500 Bonus=1500 K.-A. Knight Base=3400 Bonus=2000 Alex Archer Base=3000 Bonus=1000 Jack Judge Base=2000 Bonus=2000

d

S

d

1

d

T1

r

0 Lily Lee Base=500 Bonus=0 tr a in ee Willy Wilson Base=500 Bonus=0 tr a in ee Tony Taylor M *1983-11-19 Salary=4500 Lily Lee *1992-01-02 Salary=500 M Tony Taylor *1983-11-19 Salary=4500 Willy Wilson *1990-06-17 Salary=500 Willy Wilson *1990-06-17 Salary=500 M Willy Wilson Base=500 Bonus=0 D Lily Lee *1992-01-02 Salary=500 M Tony Taylor *1983-11-19 Salary=4500

(5)

2.1 Concurrent model synchronization problem

In the example shown in Fig. 1, we depict two models that are assumed to be in correspondence. As we may see, each model stores information about the employees of a company, where the information in

one model is slightly different from the information on the other model. Moreover, the source model (on

the left side of the visualization in Fig. 1) is assumed to include information only about the employees from the marketing department and the trainees of the company who do not belong to any department, while the employees in the target model (on the right side of the visualization in Fig. 1) may belong to any department or to no department, i.e., they are trainees. We assume that the source domain represents

the staff administration information available to the secretary of the marketing department whereas the

target domain contains information for the human resource manager or the administration department of the whole company, respectively.

The source model provides detailed salary information that is divided in the Base andBonusfor

each person. Furthermore in the source domain, the distinction between a trainee and an employee of the

marketing department is indicated by a flagisTrainee. If this flag is set to true, the person is a trainee,

if it is set to false, it is an employee of the marketing department. The type graph of the abstract syntax representation of the source model explicitly contains this flag and is described in detail in Sec. 3. In

Fig. 1, this distinction is illustrated by the bartraineeon the left side of the box containing the data of

the person. If the bartrainee is available, the person is a trainee, otherwise he is an employee of the

marketing department. Furthermore, the role icon for a trainee is wearing a hat and carrying book.

The target domain information regarding the complete staff of the company is available. It contains

information of the wholeSalaryand the date of birth of each employee. Furthermore, the membership

of each employee to a department is indicated. A person does not belong to any department, if he is a

trainee. In Fig. 1, all available departments in the target domain are indicated by different coloured boxes

including all employees of that department. In addition a small letter on the upper right corner of each box belonging to a person indicates the corresponding department and also a special role icon. In our example, the green box and letter “M” refers to employees of the marketing department. The blue box and the letter “D” denotes people employed at the development department. The role icon of employees of the development department shows a person carrying a pencil and working in front of a monitor. If a person is outside of any coloured box and if there is no letter available, the person is a trainee. In the target domain, the rule icon of a trainee is identical to the one in the source domain. E.g. in our example given in Fig. 1, Tony Taylor is an employee of the marketing department visualized by the letter “M” and because his data record is assigned to the marketing department, i.e., the green box. In contrast, Lily Lee is a trainee because she does not belong to any department visualized by a missing letter and her data record box is not part of any coloured box referring to any department.

Two model updates have to be synchronized concurrently: On the source side model update dS₁ and

on the target side model update dT₁ will be performed as shown in concrete syntax in Fig. 1. There

are different kinds of updates which can be performed on each side representing specific actions for

the corresponding administrative personnel. On both sides, a person can be removed because he/she

terminated his/her work in the company, e.g., because the person retires. The opposite, hiring a new

employee, i.e., adding a new person, is possible on each side. Furthermore, attributes of a data record can be changed, e.g., the name of a person, the salary, etc. and a person can be transferred from a department to another department or added to a department, i.e. a trainee can be hired by a department. These actions can be performed in parallel and on both sides of the model (source and target domain) so that conflicts might occur, e.g., because the same data record is changed differently on both sides. In our application scenario we perform various modifications concurrently. Consequently, conflicts might occur

(6)

which can sometimes be solved automatically, but in some cases conflict resolution requires a manual intervention by the user. In the following all modifications of our application scenario will be presented. In Sec. 5 the propagation of model updates from one domain into the other domain is presented and compared with the propagation into the opposite direction. We will recognise that a different order of the propagation will cause different results or different conflicts, respectively. We will investigate both kinds of conflict resolution: the automatic conflict resolution as well as the manual conflict resolution, in both possible propagation directions in Sec. 6.

All model updates on the source and target domain of the application scenario visualized in Fig. 1 can be divided into two kinds of model updates. Both model updates and the corresponding cases of our scenario are presented in detail in the following Sec. 2.1.1 and Sec. 2.1.2, respectively. The two kinds of model updates are:

1. Model updates on one domain only, which are presented in table 1. If a model update will be performed for a given data record in one domain only, the update will be directly propagated to the corresponding data record in the other domain, because no conflicts will occur.

2. Concurrent model updates, which are listed in table 2. If a model update on a data record will be performed on both domains concurrently, conflicts might occur that will prevent an automated propagation of the modifications into the other domain.

2.1.1 Model Updates on one Domain

In table 1 all model updates are enumerated that take place on one domain only of our scenario, which is illustrated in Fig. 1. We distinguish between the following kinds of model updates on one domain:

• If anAddition is performed on one domain of the model, a new complete data record of an

em-ployee or trainee, respectively, will be created or an existing data record will be extended by an attribute or a new connection from an existing trainee to a department will be created, i.e., a previ-ous trainee will be employed by a department.

• If a model update is aDeletion, complete data records, single attributes or the connection between

an employee and a specific department will be deleted.

• TheDeletion includes theAddition-Deletionupdate, which is presented in case 4, where a

con-nection between an employee and a department will be deleted but a new concon-nection from this employee to another department created, i.e., the employee will be redeployed by another depart-ment.

• The Attribute Modification includes all modifications of existing attributes, e.g., change name,

birth date, salary, base or bonus. This kind of model update does not include the modification of the corresponding department, because in this special case, the change of the department is a

Addition-Deletionupdate, as explained above.

Note that in table 1 and table 2 the abbreviated single types of model updates mean: “A” is Addition, “D” is Deletion, “M” is Attribute Modification, “DA” is Deletion-Addition and “-” is no changes. Example 2.1 (Case 1 - Appointment of Molly Murphy). In the target domain, Molly Murphy will be employed in the marketing department by the human resource manager of the whole company with

model update d₁T. Molly Murphy will not be employed by the marketing department itself, so that this

model update will not be carried out in the source domain, therefore it is not part of the modification dS₁.

(7)

Case Source Model Target Model

Addition 1 No changes. Add Molly Murphy to marketing

department.

-,A

2 Add Harrison Hunt. No changes.

A,-Deletion

3 No changes. Remove Paul Page. -,D

4 No changes. Redeploy Henry Hunter from

marketing department in develop-ment departdevelop-ment.

-,DA

5 Remove Lucy Lewis. No changes.

D,-Attribute Modification

6 Change name K.-A. Knight to

Kai-Axl Knight.

No changes.

M,-Table 1: Summary of the model updates on one domain only in our application scenario.

Example 2.2 (Case 2 - Appointment of Harrison Hunt). The marketing department itself employs Har-rison Hunt, but not the human resource manager of the company. Consequently, this model update is

reflected in the model updates d₁S in the source domain, but not in d₁T in the target domain. This case

represents a model update only in the source domain of the kindAddition.

Example 2.3 (Case 3 - Resignation of Paul Page). Paul Page wants to quit from his work at the marketing department. This update will be performed by the human resource manager on the target domain, but not by the administration of the marketing department. Consequently, this update is part of the modification

dT₁, but not of dS₁. This case represents a model update only in the target domain of the kindDeletion.

Example 2.4 (Case 4 - Transfer of Henry Hunter). Henry Hunter will leave the marketing department because he will switch to the development department. This redeployment will be entered by the human

resource manager into the target domain, which is included in the modification dT₁. Modification d₁S does

not reflect this update, because the administration of the marketing department will not enter this model

update. This case represents a model update only in the target domain of the kindAddition-Deletion.

Example 2.5 (Case 5 - Resignation of Lucy Lewis). Lucy Lewis wants to leave the company. This

change is included in the modification d₁S because it will be entered by the administration of the

market-ing department in the source domain. In contrast, on the target domain, this model update will not be

performed so that d₁T will not include this specific update. This case represents a model update only in

the source domain of the kindDeletion.

Example 2.6 (Case 6 - Renaming of K.-A. Knight). The employee K.-A. Knight is currently registered in both domains with the abbreviated first name K.-A.. The marketing department detects this mistake

and corrects his first name to Kai-Axl, which is reflected in the modification d₁S. In contrast, this change

will not be performed on the target side by modification dT₁. This case represents a model update only in

the source domain of the kindAttribute Modification.

2.1.2 Concurrent Model Updates on Both Domains

table 2 enumerates all cases of our scenario where concurrent model updates on both domains are per-formed. We can distinguish between the following kinds of model updates on both domains, which are also considered in table 2:

• Addition vs. Addition: A concurrent addition on both domains of the model means that the same data record or attribute or edge indicating the membership to a department, respectively, will be

(8)

added concurrently. Even if the addition of the same data on both sides will not produce any

conflicts, it can lead to an undesirable side effect: A model update adding the same thing on both

domains will result in the creation of the same thing twice after applying the propagation operation. E.g. if a new employee is added on the source and on the target side, concurrently, the employee will be added twice (c.f. case 7).

• Deletion vs. Deletion: On both domains, the same data record, attribute or membership to a certain department, respectively, can be deleted concurrently that will always produce delete-delete

conflicts. This kind of concurrent model update can also containDeletion vs. Addition-Deletion.

Then an element will be removed in one domain but modified in the other domain, which lead to delete-use conflicts.

• Attribute Modification vs. Attribute Modification: Attributes belonging to the same person (i.e., employee or trainee, respectively) are modified in both domains. When, in addition, the

modifi-cations dT₁ and dS₁ change attributes on source and target domain which correspond to each other,

delete-delete conflicts will occur.

• Deletion vs. Attribute Modification: The next kind of model update deletes an object in one domain but modifies an attribute of the corresponding object in the other domain. This type of model update might provoke delete-use conflicts.

• Addition vs. Deletion or Attribute Modification: The last kind of model update consists of two similar types of model updates: Adding attributes or creating a membership to a department in one domain, whereas the data record will be deleted in the other domain and adding attributes or creating a membership to a department in one domain, whereas an attribute of the same object will be modified in the other domain. Depending on the correspondences between the elements

affected by the addition in one domain and the deletion or attribute modification, respectively, in

the other domain, conflicts might occur.

Example 2.7 (Case 7 - Appointment of Max McDonald). Max McDonald will be hired as new employee of the marketing department. This model update will be performed on both sides, on the source domain by the administration of the marketing department and on the target side by the human resource manager,

which will be reflected in both modifications dS₁ and dT₁. This case represents a concurrent model update

of the kindAddition vs. Addition.

Example 2.8 (Case 8 - Retirement of Daniel Davis). Daniel Davis was employed at the marketing department. Due to reaching the retirement age, he will leave the company. The deletion of Daniel Davis will is performed concurrently in both domains at the same time. Consequently, the deletion of

Daniel Davis is part of the modification dS₁ but also of dT₁. This case represents a concurrent model

update of the kindDeletion vs. Deletion.

Example 2.9 (Case 9 - Transfer of Freya Fisher). Freya Fisher is currently employed at the marketing department but will be transferred to the development department. This change is entered on both sides of the model. In the source domain, Freya Fisher will be deleted because the source model only depicts employees of the marketing department or trainees, respectively. In contrast, in the target domain, the connection from Freya Fisher to the marketing department will be deleted, first, in order to create a new connection from Freya Fisher to the development department characterizing the new membership

to the development department. This case represents a concurrent model update of the kindDeletion

vs. Deletion-Addition. In this case of our example, theDeletiontakes place in the source domain in dS₁,

(9)

Case Source Model Target Model

Addition 7 Add Max McDonald. Add Max McDonald to marketing

department.

A,A

Deletion 8 Remove Daniel Davis. Remove Daniel Davis. D,D

9 Remove Freya Fisher. Redeploy Freya Fisher from

mar-keting department in development department.

D,DA

Attribute Modification

10 Change name Holly J. Hill to

Holly Jane Hill.

Change name Holly J. Hill to Holly Jane Hill.

M,M

11 Change name Mia Miller to Mia

MacDonald.

Change name Mia Miller to Mia McDonald.

M,M

12 Increase bonus of Alex Archer

from 1000 to 1500.

Increase salary of Alex Archer from 4000 to 4050. M,M Deletion vs. Attribute Modification or Addition

13 Increase base of Jack Judge from

2000 to 3000.

Remove Jack Judge. M,D

14 Remove Tony Taylor. Increase salary of Tony Taylor

from 4500 to 5000. D,M Addition vs. Deletion or Attribute Modification

15 Remove trainee Lily Lee. Employ Lily Lee at Development

department.

D,A

16 Employ Willy Wilson at

Market-ing department.

Employ Willy Wilson at Market-ing department.

M,A

Table 2: Summary of model updates on both domains in our application scenario (concurrent changes).

Example 2.10 (Case 10 - Renaming of Holly J. Hill). Holly J. Hill intimates her full first name. The change of the first name from Holly J. to Holly Jane will be entered on both domains and therefore will

be reflected in the model updates dS₁ and dT₁. This case represents a concurrent model update of the kind

Attribute Modification vs. Attribute Modification.

Example 2.11 (Case 11 - Renaming of Mia Miller). Due to marriage, the last name of Mia Miller changed to McDonald. In the target domain, this change is entered correctly, which is reflected in

dT₁. However, the administration of the marketing department enters this update with a typing error:

In the source domain, the new last name is modified from Miller to MacDonald, which is reflected in

modification d₁S. This case represents a concurrent model update of the kindAttribute Modification vs.

Attribute Modification.

Example 2.12 (Case 12 - Changing the salary and bonus of Alex Archer). TheBonusof Alex Archer will

be increased from 1000 to 1500 by the marketing department, because he was performing well during

the last years. This update of Alex Archers’Bonus is entered by the administration of the marketing

department on the source domain, which is part of model update d₁S. Furthermore, theSalaryof Alex

Archer will be increased from 4000 to 4050 by the human resource manager of the whole company in the

target domain in order to compensate the inflationary adjustment, which is reflected in modification dT₁.

Both model updates are independent from each other, therefore, they both should be carried out leading

to a new total salary of 4550 and a new Base= 3050 and a new Bonus = 1500, respectively. In Ex. 5.12

and Ex. 6.12 we will see that the model update regarding case 12 will produce delete-delete conflicts and will propose different possible results from the desired one. This case represents a concurrent model

(10)

Example 2.13 (Case 13 - Resignation and changing the base salary of Jack Judge). After being a long-time employee of the marketing department, Jack Judge wants to leave the company next month. This model update is entered by the human resource manager of the company in the target domain and will

be executed as part of modification dT₁. A rule that is specific to the marketing department states that the

base salary will be increased every two years. Jack Judge has now reached this time so that hisBasewill

be increased from 2000 to 3000 by the marketing department. This change is entered by the marketing

department itself in the source domain (model update dS₁). Both model updates are completely opposed

to each other so that conflicts will occur requiring a manual resolution by the user. This case represents

a concurrent model update of the kindAttribute Modification vs. Deletion.

Example 2.14 (Case 14 - Resignation and changing the birth date of Tony Taylor). Tony Taylor, who has been an employee of the marketing department, will leave the company next month. The administration of the marketing department enters this change in the source domain, which will be reflected by

modifi-cation dS₁. In addition, another Tony Taylor will be hired for the marketing department. This leads to a

misunderstanding by the human resource manager of the whole company, who modifies the data record of the old Tony Taylor in the target domain by mistakenly changing the birth date instead of adding a

the new employee. The change in the target domain is included in modification dT₁. In propagating both

model updates dS₁ and dT₁, conflicts will occur, which will be discussed later in Ex. 5.14 and Ex. 6.14.

This case represents a concurrent model update of the kindDeletion vs. Attribute Modification.

Example 2.15 (Case 15 - Transfer of Lily Lee). Lily Lee has been a trainee at the company and was hired for a permanent position by the development department. The change of her position will be entered concurrently in both domains. Her data record will be deleted in the source domain, because it only reflects information about employees of the marketing department or of trainees. In the target domain, the membership of Lily Lee to the development department is added. This case represents a

concurrent model update of the kindDeletion vs. Addition.

Example 2.16 (Case 16 - Switch of Willy Wilson to a permanent position). Willy Wilson has been a trainee at the marketing department was performing well so that he gets hired by the marketing depart-ment for a permanent position. This model update is entered on both domains. In the source domain,

the attribute value ofisTraineeis changed fromtruetofalse. In the target domain, the membership of

Willy Wilson to the marketing department is added. This case represents a concurrent model update of

the kindAttribute Modification vs. Addition.

Note, even if we address each modification separately as one case, all modifications on source and

target side are combined to one model update d1= d₁S∪ d₁T, i.e., they are executed concurrently. We only

address the cases separately for better clarity.

After performing updates d₂S and dT₂, a “consistently integrated model” (see below) should be derived

that reflects as many changes as possible from the original updates dS

1 and d

T

1 in both domains and

resolves inconsistencies. E.g. in case 8, the deletion of Daniel Davis is entered in both domains of the model, which will cause a delete-delete conflict. But, we may notice that this conflict can be considered not a real conflict, but an apparent one, because the deletion can be propagated automatically. In contrast,

in case 12, theSalary(in the target domain) and theBonus(in the source domain) of Alex Archer will

be increased, which will lead to a delete-delete conflict, too. But in this case, a manual intervention by the user is necessary in order to receive the desired results.

To solve conflicts like the ones mentioned in this section (Sec. 2.1.2), an adequate conflict resolution strategy must be integrated in the concurrent model synchronization process.

(11)

2.1.3 Expected Results

In Fig. 2 the desired optimal results of our scenario are illustrated. In Sec. 5 and Sec. 6, we will investigate the possible derivations of solutions for each single case in detail and also for the whole scenario in connection. At the end we will see, if we can derive the desired results in a consistently integrated model after performing the model updates dS₂ and dT₂.

In the following, we would like to present the desired results for each case, separately, without taking into account that the consistently integrated model can only be derived in propagating all changes from

source to target model, first (fSync), or the other way round (bSync). Depending on the synchronization

direction chosen, i.e., iffSyncshould be performed orbSync, different results will emerge. Therefore,

the desired results illustrated in Fig. 2 possibly might not be achieved (c.f. Sec. 5 and Sec. 6).

Kai-Axl Knight Base=3400 Bonus=2000 Alex Archer Base=3050 Bonus=1500 Harrison Hunt Base=2500 Bonus=1000 Mia McDonald Base=2500 Bonus=1500

Holly Jane Hill Base=3000 Bonus=2000 Max McDonald Base=2500 Bonus=1500 Max McDonald *1986-01-09 Salary=4000 M Molly Murphy *1971-12-24 Salary=5000 M Freya Fisher *1965-12-05 Salary=7000 D Henry Hunter *1954-03-30 Salary=5000 D M Holly Jane Hill *1981-07-18 Salary=5000 M Mia McDonald *1987-08-18 Salary=4000 Kai-Axl Knight *1961-05-07 Salary=5400 M M Alex Archer *1975-02-14 Salary=4550 Harrison Hunt *1956-04-28 Salary=3500 M Molly Murphy Base=2500 Bonus=2500 M Tony Taylor *1983-11-19 Salary=4500 D Lily Lee *1992-01-02 Salary=500 M Tony Taylor *1983-11-19 Salary=5000 M Tony Taylor *1983-11-19 Salary=4500 M Willy Wilson *1990-06-17 Salary=500 Willy Wilson Base=500 Bonus=0

Figure 2: Concurrent model synchronization: desired result of compact example

Example 2.17 (Case 1 - Appointment of Molly Murphy). Molly Murphy is employed at the marketing

department by the human resource manager. After applying the model updates dS₂ and dT₂, her data

record should be available at both domains. Because no information is known about the split of her

Salary(target domain) intoBaseandBonus(source domain), her givenSalaryof 5000 will be divided into Salary/ 2 = Base = Bonus. The correct division of the Salaryhave to be entered later by the administration of the marketing department.

Example 2.18 (Case 2 - Appointment of Harrison Hunt). The appointment of Harrison Hunt at the marketing department was entered by the marketing department only. On the source domain of our

(12)

model, no possibility for entering the birth date is given, because it only reflects detailed information

about theBaseandBonussalary. Nevertheless, his birth date is known, so that a possibility of manually

adding the birth date during the propagation of the changes from source to target domain should be given, so that his data records will be complete on both domains of the model.

Example 2.19 (Case 3 - Resignation of Paul Page). The data record of Paul Page should be deleted in the resulting model, because he resigned his work at the marketing department.

Example 2.20 (Case 4 - Transfer of Henry Hunter). Henry Hunter is transferred from the marketing department to the development department. Consequently, he should be deleted from the marketing department on both domains, but added to the development department in the target domain.

Example 2.21 (Case 5 - Resignation of Lucy Lewis). The resignation of Lucy Lewis is entered on the source domain. The resulting model should propagate this deletion also to the target model.

Example 2.22 (Case 6 - Renaming of K.-A. Knight). The resulting model should contain the corrected first name Kai-Axl of employee K.-A. Knight in both domains.

Example 2.23 (Case 7 - Appointment of Max McDonald). Max McDonald gets employed by the mar-keting department. Even though this change is entered in both domains, this modifications involves only one person, therefore Max McDonald should be added only one time to the system in the source and in

the target domain and the connection between hisSalaryin the target domain and hisBaseandBonus

in the source domain should beSalary= 4000 =Base+Bonus= 2500 + 1500 whereBase= 2500 and

Bonus= 1500.

Example 2.24 (Case 8 - Retirement of Daniel Davis). The data record of Daniel Davis shall be deleted from the source and target domain in the resulting model because Daniel Davis has retired.

Example 2.25 (Case 9 - Transfer of Freya Fisher). Freya Fisher was formerly employed at the marketing department and has changed to the development department. This model update should result in the deletion of Freya Fisher’s data record in the source domain, whereas in the target domain, she will be part of the development department.

Example 2.26 (Case 10 - Renaming of Holly J. Hill). The resulting model should reflect the change of the abbreviated second name J. to Jane in Holly Jane Hill’s data set in both domains.

Example 2.27 (Case 11 - Renaming of Mia Miller). Mia Miller has married and therefore her last name changed from Miller to McDonald. This model update is entered in both domains, but in the source domain, a typing error occurred. Consequently, in the resulting model the correct last name

McDonaldshould be obtained in both domains, whereas the typing error should be rejected. The decision

of choosing the correct last name has to be done manually.

Example 2.28 (Case 12 - Changing the salary and bonus of Alex Archer). The marketing department

increases theBonusof Alex Archer by 500 due to a great performance in his job, which was entered at

the source domain. At the same time, hisSalaryis increased by the company in order to compensate the

inflationary adjustment, which was entered in the target domain. The raise of Alex ArchersSalaryand

Bonustake place because of different reasons, thus both types of increase shall be paid to Alex Archer.

The desired new values illustrated in Fig. 2 for theBaseis 3050, which contains the compensation of the

inflationary adjustment. The newBonusshall be 1500 including the increase of theBonusby 500. The

resultingSalaryin the target domain should be 4550. In order to achieve this desired result, a manual

(13)

Example 2.29 (Case 13 - Resignation and changing the base salary of Jack Judge). In the resulting model the data record of Jack Judge should be deleted in both domains, because he resigns from the company. The increase of the salary is a procedure, which will be executed by the administration of the marketing department in a nearly automatic way, but, in this case, it is an incorrect update. To solve the occurring conflict, a manual intervention will be necessary.

Example 2.30 (Case 14 - Resignation and changing the birth date of Tony Taylor). Tony Taylor quits

his work at the company, whereas a new staff member with the same name will be employed by the

marketing department. This leads to a misunderstanding of the administrative staff in the target domain, who modifies the birth date of the data record of the former employee instead of adding a new one. The resulting model should reflect the correct change, i.e., the existing data record of Tony Taylor should be deleted in both domains.

Example 2.31 (Case 15 - Transfer of Lily Lee). The former trainee Lily Lee is employed by the devel-opment department. The resulting model should reflect this modification in both domains, i.e., Lily Lee is deleted in the source domain, and in the target domain, she is member of the development department. Example 2.32 (Case 16 - Switch of Willy Wilson to a permanent position). Willy Wilson has been a trainee at the company and is now hired as employee at the marketing department. In the resulting model, Willy Wilson should be part of the marketing department, both in the source domain, as well as in the target domain.

3 Non-Deterministic Concurrent Synchronisation Framework

In this section, we generalise the formal framework for concurrent model synchronisation presented in [15, 12, 18]. The main task of concurrent model synchronisation is to take a given integrated model together with concurrently performed model updates in the source and target domains and to derive a con-sistent integrated model together with corresponding updates on both domains. Triple graph grammars (TGGs) are a suitable formal approach for defining a language of consistently integrated models [25, 4]. They have been applied successfully for (concurrent) model synchronization [7, 15, 12, 18] using the generated operations for bidirectional model transformations [26, 13]. In the framework of TGGs, an

integrated model is represented by a triple graph G consisting of graphs GS_{, G}C_{, and G}T_{, called source,}

correspondence, and target graphs, together with two mappings (graph morphisms) sG: GC→ GS and

tG: GC→ GT for specifying the correspondence links. Attribute values of nodes and edges are defined

as links to actual values according to [5]. The two mappings in G specify a correspondence r : GS↔ GT,

which relates elements of GS with corresponding elements of GT and vice versa.

(GS mS G oo sG GC mC tG // GT) mT (HS H m HC sH oo tH //HT) Triple graphs are related by triple graph morphisms m : G →

H [25, 4] consisting of three graph morphisms that preserve the

as-sociated correspondences (i.e., the diagrams on the right commute). Triple graphs are typed over a triple type graph TG by a triple graph

morphism typeG: G → TG, such that TG plays the role of a meta-model. Morphisms between typed

triple graphs preserve the typing. For a triple type graph TG= (TGS ← TGC→ TGT), we use VL(T G),

VL(T GS), and VL(T GT) to denote the classes (visual languages) of all graphs typed over TG, TGS, and

TGT, respectively.

Example 3.1 (Triple Type Graph). The triple type graph is illustrated in Fig. 3 in compact notation and in Fig. 4 in E-Graph notation. E-Graphs are the underlying formal representation of attributed graphs.

(14)

dep TGS TGC TGT PP Department name: String Person FirstName: String LastName: String Birth: String Salary: Real Person FirstName: String LastName: String Base: Real Bonus: Real IsTrainee: Boolean

Figure 3: Triple Type Graph: Compact Notation

dep TGS TGC TGT PP Department Person String name FirstName LastName Birth Person String FirstName LastName Real Salary Bonus Real Base Boolean IsTrainee

Figure 4: Triple Type Graph: E-Graph Notation

They define attributes as links from attributed elements (nodes and edges) to the actual values (c.f. [5]). According to the triple type graph, models in the source domain contain persons with their first and last name, their detailed salary information divided into base and bonus salary and their state of employment, i.e., it is given, if the person is a trainee or a permanent employee. Models in the target domain contain the first name, last name and birth date of the person and the full salary. The salary is given by an attribute without any detailed information about base and bonus salary. The membership to a department is provided by a direct link to the department. Trainees have no link to any department.

A triple graph grammar TGG= (TG,S,TR) consists of a triple type graph TG, a triple start graph

S and a set TR of triple rules, and generates the triple graph language of consistently integrated

mod-els VL(TGG) ⊆ VL(TG) with consistent source and target languages VLS = {GS | (GS ← GC → GT) ∈

VL(TGG)} and VLT= {GT | (GS ← GC→ GT) ∈ VL(TGG)}. A model update d : G → G0is specified as a

graph modification d= (G ←i1

−

− I −−→ Gi2 0) with inclusions i1: I ,→ G and i2: I ,→ G0. Intuitively, all elements

in G \ I are deleted and all the elements in G0\ I are added by d.

L m tr _// R n (PO) G t //H

A triple rule tr= (trS,trC,trT) is an inclusion of triple graph L (left hand side) in

triple graph R (right hand side), represented by tr : L ,→ R. It specifies how a given consistent integrated model can be extended simultaneously on all three components yielding again a consistent integrated model. In particular, this means that triple rules

are non-deleting. This is sufficient, because triple rules are not used for editing in the source and target domains. A triple rule is applied to a triple graph G by matching L to some subtriple graph of G via a match morphism m : L → G. The result of this application is the triple graph H, where L is replaced by R in G. Technically, the result of the transformation is defined by a pushout diagram, as depicted on

the right. This triple graph transformation (TGT) step is denoted by G=tr,m==⇒ H. Moreover, triple rules

can be extended by negative application conditions (NACs) for restricting their application to specific matches [13].

Example 3.2 (Triple Graph Grammar). The TGG of our scenario is given by the triple type graph shown in Fig. 3, the empty start graph and the set of triple rules illustrated in compact notation in Fig. 5. All

elements (nodes, edges or attributes) that are marked with ++ (green border) are added by the triple

rule. Parts marked with a rectangle containing the labelNAC(red border) describe negative application

conditions [13]. The trainee status of the person is specified by attributeIsTrainee(T(true) orF(false))

in the source domain and only full employees are linked to a department in the target domain.

The first triple rulePerson2FirstMarketinginserts a new department called “Marketing” into the

(15)

:PP :Person Salary=base+bonus ++ :Person Base = base Bonus = bonus ++ ++ 6:DetailedSalary2Salary(base:Real,bonus:Real) :PP :Person LastName = n ++ :Person LastName = n ++ 4:LName2LName(n:String) 1:Department name=n ++ ++ NAC 7:Empty2OtherDepartment(n:String) :Department name=n ++ NAC1 n=“Marketing“:String NAC2 :Department name=n 1:Person2FirstMarketingP() :PP ++ ++ _:Person ++ :dep ++ ++ ++ NAC :Department name=“Marketing“ ++ ++ :Department name=“Marketing“ :Person IsTrainee = False :PP ++ ++ 2:Person2NextMarketingP() :Person ++ :dep ++ ++ ++ :Department name=“Marketing“ :Person IsTrainee = False :PP 9:Trainee2Trainee() ++ :Person IsTrainee = True ++ ++ :Person ++ ++ ++ 1:Department :dep NAC ++ 1:Department name=“Marketing“ 8:Empty2OtherP(nF:String,nL:String,b:String,s:Real) :Person FirstName = nF LastName = nL Birth = b Salary = s ++ ++ ++ ++ ++ Person :PP :Person Birth = b ++ 5:Empty2Birth(b:String) :Person 3:FName2FName(n:String) :PP :Person FirstName = n ++ :Person FirstName = n ++

Figure 5: Triple rules

(NAC) ensures, that a department named “Marketing” will not be created twice. In addition, this rule creates a person in the target domain that is directly linked to the marketing department, which is

indi-cated by the edgedep, in order to specify the membership of the person to the marketing department. In

the source domain, the same person will be created and linked to the corresponding person in the target

domain. The attributeIsTraineeis set toFalse, because this person is no trainee. The second triple rule

Person2NextMarketingPwill be applied, if in the target domain a marketing department is already cre-ated. It extends the model by a new person employed at the marketing department. For that, a person will be created in the source and target model with correspondences between them and a link of the person in the target model to the marketing department. The person is no trainee, consequently, the attribute

IsTraineeis set toFalse. Triple ruleFName2FNamegets a string as input. It sets the input value as first name of a person in the source domain and of the corresponding person in the target domain. Similar to

the third rule, triple ruleLName2LNamegets a string input and sets this as last name of a person in the

source domain and of the same person in the target domain. Empty2Birth assigns the birth date given

as input to the person in the target domain, because the birth date is only reflected in the target domain

of the model. The salary of a person is added by the next triple ruleDetailedSalary2Salary. This triple

rule expects two input parameters indicating the base and bonus salary of the person, which will be both added as attributes to the person in the source model. In the target domain, the full salary of the corre-sponding person will be added as attribute, whose value will be the sum of the base and bonus salary.

(16)

Triple ruleEmpty2OtherDepartmentis empty in the source and correspondence domain. It extends the target model by a new department, but only if no other department is named equally and only if the name of the new department is not “Marketing”, which is ensured by both NACs. As already mentioned before, the source model only contains employees of the marketing department or trainees, whereas trainees do

not belong to any department at all. Therefore, triple rule Empty2OtherP only adds a person in the

target domain which is directly linked to a department which is not named “Marketing”. Furthermore, all necessary attributes (first name, last name, birth date and salary) are added, which are provided by input parameters. This person is no trainee, because the person is employed at a department. This rule is empty in the source and correspondence domain, because the newly added person is no trainee and does

not belong to the marketing department. With the last ruleTrainee2Trainee, a trainee will be added in

the source and in the target domain and connected by a correspondence. The traineeship of the person is

indicated by setting the attributeIsTraineeto True in the source domain and by creating no link between

the corresponding person and any department in the target domain.

The concurrent synchronisation problem is formalised in the left of Fig. 6. Given an integrated model G0= (GS₀ ↔ GT₀) and two model updates d₁S = (G₀S → GS₁) and dT₁ = (GT₀ → GT₁), we need to find

source update dS

2 = (G S

1 → G

S

2) and target update d

T 2 = (G

T

1 → G

T

2) together with a new integrated model

G2= (GS₂ ↔ GT₂) [12]. The solution for this problem is the concurrent synchronisation operationCSync,

which is in general non-deterministic, i.e., it may require backtracking and it may yield different results

for the same input.

Signature Laws GS₁ dS₂ GS₀ dS₁ oo oor0// :CSync GT₀ d T 1// GT₁ d₂T GS₂ oo _r 2 //_GT 2 GS₁ dS₂ ⇓_:CSync GS₀ oor0// dS 1 oo _GT 0 dT₁ //_GT 1 dT 2 GS₂ oo r2:VL(TGG) //_GT 2 (a) ∀ c ∈ VL(TGG) : GS 1 ⇓:CSync GS 1 oo ooc_// GT 1//GT 1 GS oo _c //GT (b) Figure 6: Signature and laws for correct concurrent synchronisation frameworks

Correctness of a concurrent synchronisation operation CSynch (right of Fig. 6) ensures that any

resulting integrated model G2= (GS₂ ↔ GT₂) is consistent (law (a)), i.e., G2∈ VL(TGG). Furthermore, if

the given input is initially consistent and the updates do not change anything, then one of the possible

outputs of operationCSyncis identical to the input itself (law (b)). Completeness means that CSynch

yields at least one possible output for any input.

Definition 3.3 (Non-Deterministic Concurrent Synchronisation Problem and Framework). Given a triple type graph TG, the concurrent synchronisation problem is to construct a non-deterministic operation

CSync leading to the signature diagram in Fig. 6 with concurrent synchronisation operationCSync.

Given a triple graph grammar TGG= (TG,TR) and a concurrent synchronisation operationCSync, the

non-deterministic concurrent synchronisation framework CSynch(TGG,CSync) is called correct, if laws

(a) and (b) in Fig. 6 are satisfied and it is called complete, if operationCSyncis a left total relation.

In order to review the construction of the concurrent synchronisation operationCSync, we need to

recall the general notions for bidirectional model transformations based on TGGs. The corresponding

operational rulesfor executing bidirectional model transformations are derived from the given TGG. In

particular, TRS and TRF denote the sets of all source and forward rules derived from TR as shown below.

(17)

rules TRBare derived analogously and the extended construction for triple rules with negative application conditions is presented in [3]. (LS trS L oo sL LC trC tL // LT) trT (RS R tr RC sR oo tR //_RT₎ triple rule tr (LS trS ∅ oo //_∅) (RS oo ∅ //∅) source rule trS (RS id LC trS_◦s L oo trC tL // LT) trT (RS oo sR RC tR //RT) forward rule trF (∅ ∅ oo //LT) trT (∅oo ∅ //RT) target rule trT (LS trS LC sL oo trC trT_◦t L // RT) id (RS oo sR RC tR //RT) backward rule trB

Figure 7: Operational rules of a TGG for bidirectional model transformations

Figure 8: Derived source and forward rules

Example 3.4 (Operational Rules). The rules in Fig. 8 are the derived source and forward rules of the

triple ruleFName2FNamein Fig. 5.

As presented in [3], the derived operational rules provide the basis to define model transformations based on source consistent forward transformation sequences. Source consistency of a forward sequence (G0=

tr∗_F

==⇒ Gn) via TRF requires that there is a corresponding source sequence (∅=

tr∗ S

==⇒ G0) via TRS, such

that matches of corresponding source and forward steps are compatible. The source sequence is obtained by parsing the given source model in order to guide the forward transformation. As presented in [3, 13], source and forward sequences can be constructed simultaneously and backtracking can be reduced in

order to derive efficient executions of model transformations. Given a source model GS_{, then a model}

transformation sequencefor GS _{is given by (G}S_{, G}

0= tr∗_F

==⇒ Gn,GT), where GT is the resulting target model

derived from the source consistent forward sequence G0=

tr∗_F

==⇒ Gnis a source-consistent forward sequence

with G0= (GS ← ∅ → ∅) and Gn= (GS ← GC→ GT).

Model transformations based on forward rules using the control condition “source consistency” are

syntactically correct and complete as shown in [3]. Correctness means that for each source model GS that

is transformed into a target model GTthere is an integrated model G= (GS ← GC→ GT) in the language

of integrated models VL(TGG) generated by the TGG. Completeness ensures that for each valid source model there is always a forward transformation sequence that transforms it into a valid target model.

In order to efficiently execute model transformations based on TGGs, the concept of translation

attributes was introduced in [13] that automatically ensures source consistency during execution. We review the main technical concepts based on translation attributes used for the construction and extension of the operational rules.

Given an attributed graph AG and a family of subsets M ⊆ AG for nodes and edges, we call AG0 a

graph with translation attributes over AG if it extends AG with one Boolean-valued attribute tr x for each element x (node or edge) in M and one Boolean-valued attribute tr x a for each attribute associated to such an element x in M. The family M together with all these additional translation attributes is denoted

(18)

by AttM. Note that we use the attribution concept of E-graphs as presented in [5], where attributes are

possible for nodes and edges. An E-graph EG extends a directed graph G= (V, E,(s,t : E → V)) by a set

of attribute value nodes VDtogether with sets of attribution edges ENA and EEA for assigning attribute

values to structural graph nodes V and edges E. An attributed graph AG= (G, D) is given by an E-graph

Gtogether with a data algebra D, such that the attribute values VDare given by the disjoint union of the

carrier sets of D.

Definition 3.5 (Family with Translation Attributes). Given an attributed graph AG= (G, D) we denote

by |AG|= (V_GG,V_GD, EG_G, E_GNA, E_GEA) the underlying family of sets containing all nodes and edges. Let M ⊆ |AG|with (VG_M,V_MD, EG_M, ENA_M , EEA_M), then a family with translation attributes for (AG, M) extends M by additional translation attributes and is given by AttM= (VG_M,V_MD, EG_M, ENA, EEA) with:

• ENA_{= E}NA M ∪ {tr x | x ∈ V· G M} ·∪ {tr x a | a ∈ E NA M ,src NA G (a)= x ∈ V G G}, • EEA= EEA_M ∪ {tr x | x ∈ E· G_M} ·∪ {tr x a | a ∈ EEA_M,src_GEA(a)= x ∈ E_GG}. Definition 3.6 (Graph with Translation Attributes). Given an attributed graph

M_{_} // (PO)

AttM

|AG| // |AG0|

AG= (G, D) and a family of subsets M ⊆ |AG| with {T,F} ⊆ VD_M and let AttM be

a family with translation attributes for (G, M) according to Def. 3.5. Then, AG0=

(G0, D) is a graph with translation attributes over AG, where the domains |AG0| of

AG0 are given by the gluing via pushout of |AG| and AttM over M and the source

and target functions of G0are defined as follows:

• srcG_G0= srcG_G, trgG_G0= trgG_G,

• srcX

G0(z)=

(

src_GX(z) z ∈ E_GX

x z= tr x or z = tr x a for X ∈ {NA, EA},

• trg_GX0(z)=

(

trg_GX(z) z ∈ E_GX

T or F z= tr x or z = tr x a for X ∈ {NA, EA}.

Attv_M, where v= T or v = F, denotes a family with translation attributes where all attributes are set

to v. Moreover, we denote by AG ⊕ AttM that AG is extended by the translation attributes in AttM, i.e.

AG ⊕ AttM = (G0, D) for AG0= (G0, D) as defined above. We use the notion AG ⊕ Attv_M for translation

attributes with value v and we use the short notion Attv(AG) := AG ⊕ Attv_|AG|.

As shown in [13], the construction of forward and backward translation rules allows for the efficient implementation and analysis of model transformations. In combination with the generation consistency creating rules, the sets of operational translation rules provide the basis for concurrent model synchro-nisation [18]. The consistency creating rules are used to partially parse a given triple model G, where

partial parsing means finding a maximal consistent submodel G0⊆ G.

Definition 3.7 (Operational Translation Rules). Given a triple rule tr= (L → R) and its derived source

rule trS = (LS → RS), target rule trT = (LT → RT), forward rule trF = (LF → RF) and backward rule

trB= (LB→ RB), the derived translation rules of tr are given by consistency creating rule trCC= (LCC←

lCC

−−−

KCC−

rCC

−−→ RCC), forward translation rule trFT= (LFT ←

lFT

−−− KFT − rFT

−−→ RFT), and backward translation rule

trBT = (LBT ←

lBT

−−− KBT − rBT

−−→ RBT) defined in Fig. 9 using the notation based on translation attributes. By

TRCC, TRFT, TRBT we denote the sets of all derived consistency creating, forward translation and

(19)

main components new NAC for each n: L → N of tr trCC LCC ? _ KCC lCC oo rCC // RCC (R ⊕ AttT_L⊕ AttF R\L) (R ⊕ Att T L) (R ⊕ AttTL⊕ AttTR\L) NCC= (LCC+LN) ⊕AttT_N\L trFT LFT ? _ KFT lFT oo rFT // RFT (LF⊕ AttT_L S⊕ Att F RS\LS) (LF⊕ Att T LS) (RF⊕ Att T LS ⊕ Att T RS\LS) NFT= (LFT+LN) ⊕AttT_N S\LS trBT LBT ? _ KBT lBT oo rBT // RBT (LB⊕ AttT_L_T⊕ AttF_R T\LT) (LB⊕ Att T LT) (RB⊕ Att T LT⊕ Att T RT\LT) NBT= (LBT+LN) ⊕AttT NT\LT

Figure 9: Components of derived operational translation rules

Remark 3.8 (Construction of Operational Rules). Note that in Fig. 9 (B+AC) is the union of B and C

with shared A, such that for instance (LFT+LN) is the union of LFT and N with shared L. Also, G ⊕ AttT_M

denotes adding to the graph G translation attributes for all the elements and attributes included in M ⊆ G,

and moreover all these attributes are set to T. Similarly, G ⊕ AttF_Mdenotes adding to G all these attributes,

but this time they are set to F.

Due to the modification of the translation attributes, the rules are deleting, which means that, techni-cally, the rules cannot be denoted by inclusions L ,→ R. As a consequence, from a formal point of view, triple transformations are not defined as a pushout, but in terms of the classical double pushout (DPO) approach [5].

According to Def. 3.7, the consistency creating rule does not modify the structure of a triple graph, but modifies the translation attributes only. It is used for marking consistent substructures of a given triple graph, i.e., of a given integrated model. By applying all derived consistency creating rules as long as possible to a given triple G graph with all translation attributes set to “F”, a maximal consistent triple graph that is contained in G is computed. Intuitively, for each element x ∈ R (node, edge, or attribute)

of a triple rule tr= (L → R) a separate translation attribute (tr or tr x) is added for the consistency

creating rule trCC. If an element x ∈ R is preserved by the triple rule tr (x ∈ L), then the consistency

creating rule preserves it as well and the translation attribute has value T. Otherwise, if x ∈ R is created

by tr (x ∈ R \ L), then it becomes a preserved element in the consistency creating rule trCC and the

corresponding translation attribute is changed from F to T. In visual notation, this means that all plus signs are replaced by additional translation attributes whose values are changed from F to T and we

denote such a modification by [F⇒T].

A forward translation rule trFT, introduced in [19], extends the forward rule trFby additional Boolean

valued translation attributes, which are markers for elements in the source model and specify whether the

elements have been translated already. Each forward translation rule trFTturns the markers of the source

elements that are translated by this rule from F to T (i.e., the elements that are created by trS). This

way, we can ensure that each element in the source graph is not translated twice, but exactly once. The backward translation rules are dual to the case of forward translation rules and used for the translation of target models into their corresponding source models. Thus, they do only modify translation attributes

(20)

on the target component.

Example 3.9 (Derived Sets of Operational Translation Rules). Figure 16 concerns the original triple rule Trainee2Traineeand shows the derived consistency creating ruleTrainee2TraineeCC, the derived

backard translation ruleTrainee2TraineeBT (left part of the figure) and the extended versions of both

rules containing additional filter NACs (right part of the figure).

Remark 3.10 (Interdependencies between Operational Rules). The consistency creating rules (TRCC)

are used in Sec. 3 for marking the already consistent parts of a given integrated model in the second phase of the synchronization. The forward and backward translation rules are used for the third sub-phase. This third sub-phase can be interpreted as a completion of the computed sequence of the second sub-phase. Since we consider non-deterministic sets of operational rules in general, this completion may fail leading to backtracking some steps of the first sequence.

We recall the definition of model transformations based on forward translation rules according to [13]. A model transformation sequence starts with a triple graph that consists only of the given source graph, i.e., the target and the connection graphs are the empty graphs. At the beginning, the source graph is completely marked with F-valued translation attributes indicating that no element from the graph has been translated yet. Then, we apply a sequence of forward translation transformation steps leading to a graph whose source part is completely marked with T meaning that all the elements from the given source graph have been translated. These transformation sequences are called complete forward translation sequences.

Definition 3.11 (Complete Forward Translation Sequence). A forward translation sequence G0 =

tr∗_FT

==⇒

Gn with almost injective matches is called complete if Gn is completely translated, i.e., all translation

attributes of Gnare set to true (“T”).

A model transformation based on forward translation rules transforms models from the source do-main into models of the target dodo-main by executing complete forward translation sequences. Given a concrete source model, then the resulting target model of the model transformation is obtained by re-stricting the resulting triple graph of the forward translation sequence to the target component. We have shown in [13] that model transformation sequences based on forward rules and those based on forward translation rules, respectively, are equivalent. This ensures that the derived model transformation rela-tions are the same.

Definition 3.12 (Model Transformation Based on Forward Translation Rules). A model transformation sequence(GS, G0₀=tr

∗ FT

==⇒ G0

n,GT) based on forward translation rules TRFT consists of a source graph GS,

a target graph GT, and a complete TGT-sequence G0₀=tr

∗ FT ==⇒ G0 n typed over TG 0_{= TG ⊕ Att}F |TGS_|⊕ Att T |TGS_|

based on TRFTwith G0₀= (AttF(GS) ← ∅ → ∅) and G0n= (AttT(GS) ← GC→ GT).

A model transformation MT : VL(TGS) V VL(TGT) based on TRFT is defined by all model

trans-formation sequences as above with GS ∈ VL(TGS) and GT ∈ VL(TGT). All the corresponding pairs

(GS,GT) define the model transformation relation MTRFT ⊆ VL(TGS) × VL(TGT) based on TRFT. The

model transformation is terminating if there are no infinite TGT-sequences via TRFT starting with

G0₀= (AttF(GS) ← ∅ → ∅) for some source graph GS ∈ VL(TGS).

Consistency creating sequences as defined in Def. 3.13 below, are used for computing a maximal

consistent part of a given triple graph, which is used for the auxiliary operationDelin Sec. 3. A

consis-tency creating sequence starts at a triple graph G0₀= AttF(G), i.e., at a triple graph where all elements are

(21)

intermediate triple graph G0_i from F to T and preserves the structural part G contained in G0_i. Therefore,

the resulting triple graph G0n extends G with translation attributes only, i.e., some are set to T and the

remaining ones to F.

Definition 3.13 (Consistency Creating Sequence). Given a triple graph grammar TGG= (TG,∅,TR), a

triple graph G typed over TG and let TRCCbe the set of consistency creating rules of TR. A consistency

creating sequence s= (G,G0₀=tr ∗ CC ===⇒ G0 n,Gn) is given by a TGT sequence G0₀= tr∗_CC ===⇒ G0 n via TRCC with

G0₀= AttF(G) and G0n= G ⊕ AttTGn⊕ Att F

G\Gn, where Gnis the subgraph of G derived from G

0 0=

tr∗_CC

===⇒ G0

nby

restricting G0nto all T-marked elements. Consistency creating sequence s is called terminated, if there is

no rule in TRCC which is applicable to the result graph G0n. In this case, the triple graph G0nis called a

maximal consistency marking of G. A triple graph G0is called completely T-marked, if G0= AttT(G) for

a given triple graph G, i.e., all translation attributes in G0are “T”.

Remark 3.14 (Termination). It is quite easy to show that, unless the given TGG includes a trivial iden-tical rule L ,→ L, every consistency creating sequence terminates. The reason is that the application of each rule switches some translation predicates from F to T. Since the number of these predicates in a given triple graph is finite, only a finite number of rule applications is possible.

The case of forward and backward translation sequences is different. In particular, if a triple rule

tr= L ,→ R is source identic, meaning that it does not change the source part, i.e., LS = RS or equivalently

trs= id, its associated forward translation rule will not switch any translation predicate from F to T. This

implies that this rule could be applied infinitely many often in a forward translation sequence. Something similar happens with backward translation rules.

In this sense, according to whether rules modify or not the source or target part of a rule, we classify rules as shown below. In particular, this notation is used in the following section. Let TR be a set of triple rules. We distinguish the following subsets.

• The set of source creating rules TR+s= {tr ∈ TR | trS , id},

• The set of source identic rules TR1s= {tr ∈ TR | trS = id},

• The set of target creating rules TR+t= {tr ∈ TR | trT

, id},

• The set of target identic rules TR1t= {tr ∈ TR | trT= id}, and

• The set of identic rules TR1= {tr ∈ TR | tr = id}.

In order to ensure termination for forward translation sequences, if the given TGG includes source identic triple rules, we propose a general strategy based on an automated analysis using the tool AGG. The main idea is the following. If we can show that none of the remaining triple rules depends on the source identic triple rules, we can actually omit the source identic ones. The reason is that for each forward transformation sequence, we can shift the steps along source identic rules to the end and obtain an equivalent sequence. Since all steps along source identic triple rules do not change the marking of the source model, we further derive that these steps can be removed yielding still a complete forward translation sequence. GS oo r // a _u:fPpg GT b G0S oo r0 //_G0T GS oo r // a _w:bPpg GT b G0S oo r0 //_G0T