Organizational and Informational Perspectives on Synchronization

can be described more specifically. Consistency of two models a and b which conform to metamodels Mand N, respectively, means thatha,bi is an element of a consistency relation CMN ⊆M×N, where M,N are the sets of all possible models that conform to MandN, respectively. Thus, a consistency condition for a heterogeneous set of models can be defined by a set of binary consistency relations.

Theorem 1. Let S = {m, n, o...} be a set of models which conform to at least two different metamodels in a set MM = {M,N,O...}. Let C = {CMN,CMO,CN O, ...} be a set of binary consistency relations. A consistency condition c over S can be defined by c = ∀ x,z ∈ S : P(x,z) with P being defined either directly as P(x,z) ≡ hx,zi ∈ CXZ, where x conforms to a metamodel Xand z conforms to a metamodel Z, or transitively, e.g., with P(x,z) ≡ hx,yi ∈ CXY ∧ hy,zi ∈ CYZ. In general, c can be defined using the transitive closure of the union of all consistency relations: c =∀ x,z ∈ S : P(x,z) ≡ hx,zi ∈(S

C)⁺. The number of required consistency relations |C| depends on the number of different metamodels|MM|: it is at most ^{|MM|·(|MM|−1)}

2 (all directly related) and at least

|MM| −1 (most transitive relations).

So now that we know how to describe consistency, how can we enforce consistency – i.e., realize synchronization – by means of model transformation? A unidirectional model transformation can be seen as a function on models. It describes a binary relation of source and target models. If a (unidirectional or bidirectional) model transformation implements a consistency relation, the transformation can be used to establish consistency.

Definition 3.2 (binary heterogeneous model synchronization, binary synchronization).

Let hx,yi be a pair of inconsistent models which conform to metamodelsX,Y, respec-tively, where consistency is defined by a consistency condition c which is defined by a binary consistency relationCXY. Thenbinary heterogeneous model synchronization is an operation which alters one or both models, so that they are consistent with respect toc. The simplest case of synchronizing two inconsistent models is to choose one of them – the one whose changes are to be preserved – and use a unidirectional model transfor-mation which implements the consistency relation to create a (by definition) consistent model. The originally inconsistent model is then replaced with the newly created model, discarding all information in the original model. Thus, any model transformation can be considered as a model synchronization.

When synchronizing a pair of models, we can distinguish different general situations which we callsynchronization types. Two concepts that are helpful for categorizing binary synchronization scenarios are explained in the following subsection.

3.2.3 Organizational and Informational Perspectives on Synchronization

In this section, we consider two basic features of binary model synchronization scenarios:

organizational symmetry (org-symmetry) and informational symmetry(info-symmetry),

60 Chapter 3. Model Synchronization in a Domain-Specific Workbench and then discuss their orthogonality and the 2D-plane formed by their combination.

Org-symmetry is fundamental for model synchronization but, to our knowledge, has not been discussed in the literature in technical or formal terms. Org-symmetry captures the idea of one model being more authoritative than the other. Info-symmetry charac-terizes “equality” of informational contents of models. This feature, and its phrasing in terms of symmetry, is well known in the literature on algebraic models of bidirectional transformations (Diskin et al., 2011b,a; Hofmann et al., 2011).

Organizational Symmetry

Suppose that two models to be synchronized, a andb, are given together with a consis-tency relation between them. Assume that a₁ and b₁ are two inconsistent states of the models, and one of the models, or both, are to be changed to restore consistency. There may be different policies for such changes. As we discussed before, a simple one is when one of the models (say,a), is considered entirely dominating the other modelb. That way, consistency restoration is realized by changing b₁ to b₂ which is then consistent witha₁. This situation is common when a low-level model b (e.g., bytecode) is generated from a high-level model a (Java program). Generating Java code (this time model b) from a UML model a is similar, if round-tripping is not assumed. The low-level model b is not supposed to be modified manually. When the high-level modelais changed, the original low-level model is discarded and a new model is regenerated from scratch. In all such cases, we say that model aorganizationally dominates b, and writea>orgb. Equivalently, we say that b is dominated by a and write b<orga. We will also refer to these cases as organizational asymmetry.

We have an entirely different synchronization type for code generation with round-tripping. Suppose that a UML model a₀, and a Java program b₀ which was generated froma₀, were initially consistent, but later model awas changed to state a₁ inconsistent with b₀. Then program b₀ must be changed to b₁ which is consistent with a₁. We say that update a₀ → a₁ on the a-side is propagated to the b-side. Conversely, if model b₀ (code) was changed to b₁ inconsistent with a₀, then model a must be changed to restore consistency, and we say that update b₀ → b₁ was propagated to a. Thus, in contrast to organizational dominance, propagation can go in either direction based on the history: the freshly updated model dominates irrespectively to whether this freshly updated model is eitheraorb. We say that neither model organizationally dominates the other, writea≥≤_orgb, and call this situationorganizational symmetry. The basic question characterizing the organizational dimension is the following:In what direction are updates propagated? Are they propagated only fromatob, only frombtoa, or in either direction?

There are also important synchronization cases in-between the strict asymmetry and strict symmetry considered above. A model can bepartially dominatedin the sense that some (but not all) updates on this model are allowed to propagate to the other side depending on the type of the update. Consider, for example, the outline view ofEclipse JDT. The outline view is regenerated every time the Java code changes. Thus, there seems to be an organizational dominance of the Java code over the outline view. However, the JDT outline view allows the user to make some selected operations in the outline view,

3.2. A Taxonomic Space for Increasingly Symmetric Model Synchronization 61 e.g., renaming elements, or moving elements within the hierarchy. These updates are then propagated to the code. So, whereas all updates from the code (modelb) are propagated to the abstract outline view a, only selected updates on a are allowed, and thus can be propagated, from the outline a to the code b. We call this situation organizational semi-symmetry and writea≤_orgb(note the difference from a<orgbdenoting asymmetry).

A similar semi-symmetric variant of code generation from UML models could be also constructed. In contrast to the strict asymmetry version discussed above (no changes from code b are propagated to model a, a>orgb), some code updates – for example, changes in method heads – are allowed to be propagated to the model. We will therefore sometimes refer to organizational semi-symmetry aspartial round-tripping.

Organizational semi-symmetry also includes a setting, in which both models are par-tially dominated, i.e., both update propagation directions are sensitive for the update type. Consider, for example, a system model consisting of a UML class diagram and a UML sequence diagram with the following synchronization policy. If a class name is changed in the class diagram, this change has to be reflected in the sequence diagram, but class name changes are not allowed in the sequence diagram. Dually, if a method signature is changed in the sequence diagram, this change has to be reflected in the class diagram, but the latter is not allowed to change method signatures. Thus, to completely characterize the organizational dimension, one has to ask: Which updates (if any) are propagated in what direction?

Informational Symmetry

The notion of informational symmetry is based on inter-model consistency. The latter can be modeled as a binary relation C ⊂ M×N, where M and N denote the sets of all models which conform to metamodelsMandN, respectively. In general, the consistency relation is of type many-to-many. For example, if M is a set of UML models, and N a space of Java programs, a given UML modela∈Mcan be correctly implemented by many Java programsb∈N; differences between thesebs are usually termed as “implementation details”. On the other hand,a normally contains some information not relevant for code generation, such as layout of boxes and arrows, timestamps, etc. Hence, the same Java program can be a correct implementation of, generally speaking, different UML models.

Thus, each of the models has some privateinformation not needed for the other model, and they both share somepublicinformation important for the other model, but represent it differently. We then writea≥≤_infband term the case asinfo-symmetry.

We have an essentially different synchronization situation between code and its outline view in a typical IDE, e.g., the JDT outline mentioned above. The outline only shows parts of the information that is presented in the code, or, more generally, an abstract view of the code so that only one outline modelais consistent with a given piece of code b. Of course, the same outline model a may be consistent with many implementations b, so that the consistency relation is of the one-to-many type. We then writea≤_infband term the case asinfo-asymmetry(below we will explain why we use ≤_infrather than<inf).

So far, we used the term ‘view’ informally to describe common GUI elements of domain-specific workbenches that display only selected information of a bigger model. With the

62 Chapter 3. Model Synchronization in a Domain-Specific Workbench concepts of organizational and informational asymmetry, we can define the concept of a view. In order to distinguish the GUI element from the general informational concept, we will – when it is not clear – refer to the latter as the ‘view model’ to make clear that we only refer to the underlying information which is displayed by a GUI view.

Definition 3.3 (view model). A view is a role of a model in a model synchronization context. A view v can always be uniquely extracted from another models, which in this scenario is referred to as thesource model (or just the source). Viewv is informationally dominated,v≤_infs, so that several source modelss1,s2, etc. can match the samev, whereas v cannot have private information. If v is allowed to be modified, the view role implies that updates made tovare supposed to be propagated back to the sources immediately.

Thus, vacts as an interface for modifyings. In this case, we callv anactive view. Ifvis not allowed to be modified, i.e., if there is v≤_infs combined with v<orgs so that v’s only purpose is to present some of the information ofs, we call v apassive view.

Note that info-asymmetry appears in the case of code generation, if we consider UML models up to their code-relevant context. That is, we consider two UML models equiva-lent, if they only differ in their concrete syntax and layout, and ignore all attributes not needed for code generation (like authorship and timestamps). Then consistency becomes a one-to-many relationship, and we have a≤_infb (UML modela is an active view). This conceptual simplification of code generation is a useful model of the situation.

An important characteristic of info-asymmetry is that the computational nature of update propagation essentially depends on the direction. Propagating updates from the sourcebto the viewais a relatively simple computational procedure. In contrast, propa-gating updates from the view to the source is non-trivial because some missing informa-tion on the source side is to be restored (see Foster et al., 2007; Diskin et al., 2011b). For the info-symmetric case, both update propagation directions need restoration of missing information and both are non-trivial.

A special case of info-symmetry is when the consistency relation is of the one-to-one type and determines a bijection between two model spaces: now neither of the two models has private information, i.e., both models are just different representations of the same information. We write a=infbfor info-bijectivity. An example of such bijective situation is synchronizing a wiki article described in a lightweight markup language like MediaWiki with the equivalent HTML description of the article. Although bijectivity is symmetric, it is convenient to consider it as a special case of info-asymmetry: each of the two models can be uniquely extracted from the other and update propagation is simple in both directions. To show that bijectivity is included into the info-asymmetry, we writea≤_infbrather thana<infb. The latter can be used to explicitly exclude bijectivity and denote strict info-asymmetry wherebmust have a private part whileamust have no private part.

Organizational and Informational Symmetries Together

Recall two cases of info-asymmetry,a≤_infb. The first is whenais the outline view of code b. The second is whenais a UML model whose syntactical peculiarities (i.e., those which

3.2. A Taxonomic Space for Increasingly Symmetric Model Synchronization 63 do not affect code generation) are ignored for synchronization, and bis generated code.

Despite the same info-asymmetry relationship between the models, their synchronization situations (we also say synchronization types) are different. Indeed, in the former case, the view is mostly a passive receiver of the source updates, and we havea<orgb(ora≤_orgb, if some updates can be propagated from the view to the source). In the latter case, the view is active and generates the source which passively receives the view updates,a>orgb. What determines the synchronization type of the case is a combination of two parame-ters indexing the organizational and the informational symmetry, respectively. Clearly, these two parameters are independent, and hence can be considered as two orthogonal coordinates forming the plane shown in 3.15.

The vertical axis has two points corresponding to the two possibilities of the info-symmetry: a≤_infb (y=0) and a≥≤_infb (y=1). The horizontal axis has three basic points corresponding to the three possibilities of org-symmetry considered in Sec. 3.2.3:a<orgb (x=0),a≤_orgb(x=¹₂), and a≥≤_orgb(x=1).

Figure 3.15: Plane of organizational and informational symmetries

However, when we consider real synchronization types, i.e., pairs (xy) on the plane, each of the types (00) and (¹₂0) splits into two subtypes depending on whether two dominant models coincide or not. We will denote these subtypes by (xy)⁻(even less symmetry, since the same model is “suppressed” in both relations), or (xy)⁺(more symmetry as one model dominates in one relation, while the other model in the other relation). Thus, the plane comprises eight synchronization types. Each case considered above obtains its unique synchronization type, and each type in the plane can be interpreted by a practically interesting situation along the lines described in the section.