UNIVERSIDADE TECNICA DE LISBOA INSTITUTO SUPERIOR TECNICO

MYNK: Model sYNchronization frameworK

Users Guide

Document produced by PhD Student: Joo de Sousa Saraiva (jppmssaraiva@gmail.com) (author) a PhD Supervisor: Alberto Silva (alberto.silva@acm.org)

November 2011

Contents

List of Figures

ii

Listings

iii

Chapter 1 Introduction
Although there are many modeling languages nowadays, addressing the modeling needs of their target audiences, there is still the need for a mechanism that (1) supports the obtainment of models from other models (possibly in dierent languages), and (2) ensures both kinds of model are kept consistent with one another. A lack of such a mechanism would mean that models in dierent languages would have to be manually synchronized, which would have the drawbacks of: (1) requiring additional eort to perform that manual synchronization task; and (2) becoming an error-prone task, because of its repetitive nature. Although most model transformation languages can support the modication of a model B1 to become equivalent to a model A, this typically implies that some changes made to B1 (especially changes to elements that have also been changed in A) may be lost. Figure ?? provides a tentative illustration of this problem.

Figure 1.1: Typical model transformations may lose changes. This documents presents the Model sYNchronization frameworK (MYNK) language, which allows not only the obtainment of a model MA from another model MB (and vice 1

versa, as per typical model transformation mechanisms), but also ensures that changes to one of the models or even to both models will be propagated to the other one, in order to maintain consistency between the two. MYNK addresses the following objectives: (1) ensuring that two models are semantically equivalent to one another; and (2) ensuring that this semantic equivalence relationship is maintained throughout model changes, regardless of those changes being applied to one or both models. Furthermore, MYNK considers a model to be not just a simplied representation of a certain reality in its latest state, but rather a sum of its history (i.e., the various changes that it suered until it got to the current state). Of course, this does not hinder the denition of model snapshots (at specic points in the models lifecycle), that can be used by someone to understand the reality being modeled. It is important to note beforehand that MYNK is not intended to enable round-trip engineering scenarios, an overview of which is illustrated in Figure ??: (1) considering a model A1 (specied in a certain language A), a model B1 is obtained via some mechanism (e.g., a model transformation TAB , from A1 to B1 ); (2) likewise, by using a model transformation TBA , a model A2 is obtained from B1 . If the transformations TAB and TBA are exactly symmetrical (i.e., they are the opposite of one another), then A1 and A2 should be semantically equivalent (in the sense that they should have the same meaning. However, this kind of scenario presents the caveat of requiring that both languages have the same level of expressiveness, as otherwise information would be lost between the various transformations (and so TAB could never be symmetrical to TBA , and vice versa). Instead, MYNK aims at enabling scenarios like the one depicted in Figure ??. This scenario starts with two semantically equivalent models, M L1 and IL1 , respectively modeled with the languages M L and IL. After changes are made (marked CM L1 in the gure) to M L1 , in order to obtain a dierent model M L2 , the model synchronization mechanism will receive those changes and generate the corresponding set of changes (marked CIL1 ) in the IL language. CIL1 is then applied to IL1 , originating a dierent model IL2 that is intended to be semantically equivalent to M L2 . However, in practice it is not certain that two models will be in sync after just a single change propagation (in fact, it is most unlikely). This is because there may still be changes to be applied to a model, derived from (1) changes made to the other model or (2) changes that are implied by the initial change propagation operation (which is illustrated in Figure ??). More specically, the model synchronization operation should consist of a IL M L = M L IL cycle (not illustrated in Figure ?? for simplicity), 2

(a) Round-trip engineering.

(b) Synchronizing model changes.

Figure 1.2: Possible synchronization scenarios. which should be performed until a xed-point is reached (i.e., the application of a set of changes to a certain model results in that same model). The way in which MYNK operates can be considered analogous to a variety of tools and practices, of which we highlight some illustrative examples in the following paragraphs. The notion of capture-replay testing consists of recording events and applying them again, at a later point in time. These tests are often used in automated software testing scenarios (particularly in regression and UI testing), and are done by (1) recording a sequence of events and their expected results, (2) simulating the occurrence of those recorded events, and (3) evaluating whether the results are equivalent to the ones expected. An analogy can be found in MYNK, when considering such events to be model changes. MYNKs change propagation process is also very similar to what happens in a Revision Control System (RCS) such as Subversion or Mercurial: the only information that goes to or comes from the developers working copy is a set of deltas (i.e., dierences) between the most recent version of the artifact and the version that is on the developers working copy. A developer can (1) make changes to her own working copy, and (2) merge changes from other developers working copies with her own, in order to keep synchronized with the rest of the development team. Another adequate metaphor for this process is the pantograph, a tool that links two pens so that any movement to one of the pens is automatically reproduced (possibly with a dierent scale) by the other pen. This metaphor is particularly interesting, as MYNK operates much like a pantograph, by taking changes to one model and automatically reproducing them on another model. 3

1.1. CONVENTIONS USED

1.1

Conventions Used

The following conventions are assumed through the remainder of this Users Guide. MYNKs abstract syntax is described in this document using UML, because: (1) although the language does not use UML as a metamodel, it is nevertheless possible to use UML to illustrate MYNKs concepts; and (2) it is expected that most readers are familiar with UMLs class diagrams, due to its widespread use nowadays. When the text mentions a name with uppercase initials, it is referring to a MYNK concept, while a name with lowercase initials refers to a generic term. As an example, the term Operation is used to refer to the MYNK Operation concept in particular, while the term operation is used according to its traditional interpretation (i.e., to refer to an activity to be performed).

Chapter 2 The ReMMM Metamodel

TODO ReMMM shares s notion that a model consists only of a set of Model Elements which are linked among themselves. In fact, ReMMM and are similar to each other, as the former mostly consists of extensions to the latter. The most noteworthy dierences between them are the following: The relationship is represented by Instantiation, a Relationship that establishes ontological links between two Model Elements; The explicit denition of Data Type, which represents a kind of value that an Attribute can assume. The Data Type element is abstract, and is specialized by Enumeration and Primitive Data Type (explained next); One specialization of Data Type, Enumeration, contains Enumeration Values and represents sets of possible values that Attributes can assume (much like enumerations in UML or in typical programming languages); In addition to Enumerations, Primitive Data Types are used to represent simple kinds of values (such as string or integer). These can be assumed to be present in all (because of ReMMMs reexiveness, explained further down this section), in order for an Attribute to be associated with that Data Type without that association crossing any metalevel boundaries; The Association Relationship, used to allow designers to specify their own kinds of links between Model Elements, can now assign names to its Association Ends, in order to identify each Model Elements role in that Association; The Association can also be of one of three types (Normal, Aggregation, or Composition), which have the same semantics as their UML-homonyms; The Concept element is dened to represent concepts (i.e., metaclasses that have some meaning and representation, which is specied by a language designer). The 5

reason why Model Element is not abstract (considering all of its specializations) is that it is also used to represent elements that (1) are only instances of another Model Element and (2) are not themselves metaclasses for other Model Elements; and The Attribute can hold multiple values of its type. Regarding Attributes link to Model Element (its type), we opted to maintain this link unaltered (as opposed to linking Attribute to Data Type, which is the case in UML), in order not to curtail the expressiveness of this metamodel (e.g., by preventing scenarios in which an Attribute references a specic Model Element instance). Nevertheless, we do not take advantage of this feature in ReMMM-based , so that we can use UMLs as-is and facilitate the readers interpretation of those . Its -based heritage notwithstanding, ReMMM could also be considered as being dened using (or even UML), although in this case ReMMM as a metamodel would bring no added-value (regarding expressiveness) in relation to its own (meta-)metamodel. Finally, ReMMM shares s trait of being reexive (i.e., ReMMM can be used to describe itself). We take advantage of this fact, as the for the CMS-ML and CMS-IL languages were dened using ReMMM as their . More specically, we take advantage of (1) the reexiveness of ReMMM and (2) the explicit denition of the Instantiation concept to dene these languages using multiple . The MYNK model synchronization language also assumes that the of the models being synchronized can be themselves specied using ReMMM (a fact that we expect to be true for most existing modeling languages, because of ReMMMs simplicity and high degree of expressiveness); this is because MYNK needs to have a common ground that allows it to receive and manipulate many kinds of models. TODO

Chapter 3 MYNK Elements

The MYNK language, although not very complex (regarding the number of concepts that it denes), divides its concepts into a set of modules, according to the principle of separation of concerns1 . These modules are: Model, which denes the basic concepts to which MYNK-compatible languages must comply; Traceability, which establishes the concepts for traceability between model elements; Changes, which species the possible changes (or deltas) that can occur on MYNK-compatible models, and which are the foundation for MYNKs change propagation mechanism; and MYNK, which uses the other modules to establish a coherent model synchronization mechanism. Figure ?? illustrates the relationship between these modules, which will be further explained in the remainder of this chapter.

Figure 3.1: Overview of the MYNK language.

We do not call these views, because MYNK synchronization developers will use all of these concepts at the same time. However, this division makes it easier to explain and understand the MYNK language.

3.1. MODEL

3.1

Model

The Model module is the fundamental building block for the MYNK language, as it denes the MYNK Artifact concept that (1) is used in every other MYNK module and (2) determines the set of characteristics to which languages must comply if they are meant to be MYNK-compatible. Furthermore, this module also establishes the connection between the MYNK language and the ReMMM metamodel. Figure ?? depicts the abstract syntax for this module.

Figure 3.2: Abstract syntax for the Model module. The aforementioned MYNK Artifact (or just Artifact, for brevity) is used to represent something (e.g., a model element, or even the model itself) that MYNK synchronizations can handle, and over which they will operate. When considering that MYNK assumes models to be specied using the ReMMM metamodel, it follows that MYNK Artifact and ReMMMs Model Element should be related. In fact, the relationship between them is that any Model Element instance should be classiable as a MYNK Artifact (i.e., the former should exhibit a set of characteristics that would also allow it to be considered as an Artifact). However, from a practical perspective, MYNK synchronization developers only need to be aware that each Artifact instance corresponds to a specic Model Element instance. Each Artifact instance is also uniquely identiable by an ID of type string; this ID can be anything, such as a name which must be unique within the model or a UUID (Universally Unique Identier), as long as it unambiguously identies a specic Model Element. TODO

3.2. TRACEABILITY

3.2

Traceability

The Traceability module, although relatively simple, is responsible for establishing trace relationships (also called trace links, or just traces) between MYNK Artifacts. Figure ?? presents the abstract syntax for this module.

Figure 3.3: Abstract syntax for the Traceability module. The most important concept in this module is the Trace, which is what eectively establishes a correspondence between two (or more) MYNK Artifacts in dierent models. To do so, a Trace contains a set of Trace References, which are named references to MYNK Artifacts. TODO

3.3

Changes

The Changes module is responsible for dening the concepts that are necessary to represent changes to MYNK Artifacts (regardless of the metalevel in which those Artifacts are located). These concepts, in turn, are a cornerstone of MYNKs change propagation (and processing) mechanism. Figure ?? illustrates this modules abstract syntax.

Figure 3.4: Abstract syntax for the Changes module. 9

3.3. CHANGES Like the Traceability module, the Changes module is relatively simple, as it denes a small set of concepts. The most relevant concept is Change, which represents a change in one or more model elements. A Change contains a set of Change Elements, which are references to the model elements that are involved in the change being modeled. It should be noted that the Change concept is abstract (otherwise, this concept would not be expressive enough for a computer to be able to answer the question What was the change?). More specically, it is rened by the following concepts: Change Attribute Value, indicating a change in the value of a property (called Attribute in the ReMMM metamodel), for which it references (1) the metamodel element that represents the property itself, and (2) the instance of the model element that contains the property. Furthermore, it also contains not only the new value, but also the old value; Create Model Element, representing the creation of a new instance of a certain Model Element (e.g., UMLs Class, or even ReMMMs Instantiation); Establish Relationship, which references a certain metamodel element R (e.g., UMLs Association) that represents a relationship between Model Elements, and establishes a new instance of R between two other instances in the model; and Delete Element, which represents the removal of a certain instance (of either Model Element or Relationship) from the model. MYNK denes this set of change concepts (and no additional ones) because these are the minimum necessary to specify any changes to a model, as long as it and its metamodel conforms to the ReMMM metamodel. It should be noted that these Change concepts also provide the information that is necessary to determine whether a conict is present. Specically, a conict occurs whenever a certain change is to be applied to a model, but that model contains information that is inconsistent with the intended change. An example of this could be a change to an attributes value (by using Attribute Value Change): (1) consider a change C that is to be applied to a certain attribute A; (2) C is meant to change As value from V1 to V2 (i.e., its Old Value and New Value properties assume the values V1 and V2 , respectively), and so it expects that As value is initially V1 ; (3) however, if As value is not V1 , then there is a conict, and C cannot be applied to A. The topic of conict resolution will not be further explored in this version of the document, as there are many possible approaches to address this issue. Furthermore, and unlike other MYNK modules, Change instances are not meant to be specied by the MYNK synchronization developer, but rather by a modeling tool for a MYNK-compatible language. The MYNK synchronization process will then try to match 10

3.4. MYNK these Changes with Operation specications (explained in Section ??), in order to obtain a set of corresponding Changes to be applied to the corresponding model. TODO

3.4

MYNK

The MYNK module is responsible for using the concepts that were specied in the Changes and Traceability modules, and dening the concepts that support the MYNK languages purpose (the denition of model synchronization operations). Figure ?? provides a simplied illustration of the abstract syntax for the MYNK module.

Figure 3.5: Abstract syntax for the MYNK module. The underlying idea to these concepts is that MYNK will work by: (1) analyzing a set of Changes; (2) determining which synchronization rules contain condition operations that 11

3.4. MYNK match with some of the provided Changes; (3) obtain templates for the set of Changes that should result from the provided Changes; and (4) based on a provided set of Traces, convert those templates into Changes to be applied to the models being synchronized. This workow will be elaborated on further down this chapter. We start this modules description by the Synchronization Spec (or just Sync Spec, for brevity), which is a container for all the other concepts dened in this module. When dening a new model synchronization, the designer starts by specifying a Synchronization Spec element, within the context of which other MYNK elements will be dened. A Synchronization Spec contains a set of Sync Rules, which (as the concepts name suggests) are rules that guide the model synchronization process. More specically, there are two types of Sync Rules, Simple Sync Rules and Bidirectional Sync Rules, which perform synchronization in dierent manners (these will be explained further down this section). A Sync Rule can also be characterized by a Name, which is an optional string that can be used to indicate the purpose of the rule. In addition to the Sync Spec and Sync Rule concepts, this module also denes another fundamental concept, Operation. An Operation can be considered as something to be done. MYNK provides dierent kinds of Operation, which are derived from the concepts dened in the Changes and Traceability modules: Trace Operations and Change Operations. A Trace Operation consists simply of an instruction to fetch a Trace element, create a new Trace element, or remove an existing one. On the other hand, a Change Operation can be considered as a template or a possible match for a Change, which is why the available concrete Change Operations are dened in a way very similar to the concrete Changes in the Changes module. Operations are grouped into Operation Sets, which can then be considered as expected sets of Changes (eventually combined with tracing instructions) to be matched when performing model synchronizations. Operation Sets are important because Sync Rules also contain such Sets. However, the kind of Sync Rule also determines how these Operation Sets are interpreted: A Bidirectional Sync Rule contains only a list of two (or more) Operation Sets. Each of those Sets can act as the condition for applying the Sync Rule, and the result of rule is provided by combining all of the remaining Operation Sets. It should be noted that there is a caveat regarding the Set that acts as the condition, as the New Trace and Delete Trace Operations are ignored when determining whether the Operation Set is a match for the provided Changes; On the other hand, a Simple Sync Rule contains only one Operation Set, which is the result of the rule. The rules condition is instead specied by the Condition 12

3.4. MYNK concept, which can be of one of the following types: (1) a Boolean Condition, which contains other Conditions and combines them using boolean operators (and, or, or not); (2) a Query Condition, which contains a Query (a simple SQL-like string) that can be performed over input models and returns a value of true or false; or (3) a Change Condition, which contains an ordered set of Operations that must be successfully matched to a set of Changes. The New Trace and Delete Trace Operations cannot be used in the context of Change Conditions. In turn, the matching of Operations to Changes leads to the Change Condition concept having a set of properties that determine the manner in which such matching should occur: (1) the In Exact Order property species whether the corresponding Operations must be matched in the exact same order in which they are specied ; and (2) the Consumes Changes property (used only in case of a successful match) determines whether the matched Changes will still be available for matching by other Sync Rules, or if they will be removed from the set of Changes so that no other rules can match Operations with them. It is also possible to manually specify the existence of conicts that can occur. This is captured by the Conict concept, which is a particular kind of Operation Set that signals the need for a conict resolution mechanism (explained further down this chapter). However, there are some restrictions to dening Conflicts, as they (1) cannot contain Operations, and (2) cannot be matched with any Changes. The rationale for these constraints is that it would make no sense for a Conflict to be used in such cases. Finally, at runtime, a Synchronization Spec receives: (1) a Change Set, which is a container for an ordered set of Change elements; (2) a Trace Set, which is also a container, but now for a set of Trace elements; and (3) a set of (ReMMM-based) models. These elements are depicted in Figure ?? as being related to the Synchronization Spec concept by means of UML dependencies. TODO

13

Chapter 4 Examples
TODO

4.1
TODO

CMS-ML and CMS-IL

4.2
TODO

CMS-ML and UML

14

Chapter 5 Conclusion
In this manual, we have presented the MYNK model synchronization language. The ReMMM metamodel and MYNK itself have been explained in great detail, and their concepts have been dened. Finally, we have presented small examples of synchronizations between: (1) the CMS-ML and CMS-IL languages; and (2) the CMS-ML and UML languages.

15