The technical requirements connected to our approach, have already been briefly men- tioned in Sect. 6.4.2. PREP requires an infrastructure that allows to isolate models. That is, one must be able to create independent versions of models to perform model transformations in isolation. Each propagation alternative yields a new version of the source models. Executing the transformation on these versions (i.e., performing the re- play step) creates additional versions of the target models. All these versions need to be kept in isolation to avoid interference with other activities. Typically, this is not a very severe restriction, since versioning of models and executing the same transformation on different input models are typical requirements in MDSD.
In addition, if model editors do not support change tracking, an algorithm to compute differences between models is required. Since we operate on EMOF models, such algo- rithms are readily available (cf. [198]). If one wants to port the PREP process to other modeling paradigms, the same kind of differencing mechanism is required.
In addition to model isolation and change tracking, establishing traceability is required to employ PREP. One needs to have information about the concrete relations between source and target models available to provide accurate backpropagation options. For example, we keep track of all copies that are created from elements of source models in the state machine composition example. Without such fine-grained and precise tracing information, propagating changes becomes difficult or even impossible.
6.6 Summary
In this chapter, a generic approach to RTE was presented that can be applied uniformly to our example scenarios in Sect. 9.1 and 9.2. The approach is based on the idea that individual changes that are applied to target models can be propagated to source models. Thus, no inverse transformations are required, which makes the approach particularly applicable to scenarios where no such inverse transformations do exist.
Depending on the transformation operators that are employed in the forward transfor- mation a specific relation between source and target model elements is established—the traceability relation. When changes need to be propagated the semantics of this relation determines whether and how target changes correspond to source changes. This is in
6 Backpropagation-based Round-Trip Engineering
M1
Replay
Model A
Model B
Propagate
Consistency Constraints Skeleton Clothing Model elementFigure 6.10: Model partitioning for backpropagation-based RTE.
contrast to [156], where traceability relations and basic transformation operators are not explicitly considered.
Sometimes, multiple valid options to propagate a change exist, which demands for a decision. To formalize this decision process, we have presented the PREP procedure that propagates each option individually and replays the transformation to obtain the resulting target models. Based on these target models, the usefulness of each option is evaluated using two functions—the consistency fitness function and the conservation fitness function. According to the design of both functions, PREP can be customized.
If we express PREP in terms of our conceptual framework, backpropagation-based RTE can be depicted as shown in Fig. 6.10. Here, the forward transformation is used to define when target models are consistent with source models. Since PREP requires that all target changes can be propagated to source models, the whole target model forms the skeleton. This is in contrast to the source model where parts can be irrelevant w.r.t. the forward transformation. These parts form the clothing of source models.
If target models shall contain information that cannot be propagated to source models, they need to be partitioned. Parts that are not reflected in source models (i.e., target model clothing) must be stored in separate model fragments and composed with the target skeleton to obtain complete target models. This composition is a separate RTE scenario. Our basic example—the composition of state machines—did not require addi- tional partitioning. We will show more complex examples in the evaluation Sects. 9.1 and 9.2. For the former case study we will discuss such a partitioning of target models. We have analyzed limitations and drawbacks of PREP and can clearly say that PREP is not a universal solution to all RTE scenarios. However, it allows for substantial improvement, at least for our set of scenarios. In addition, the support for non-invertible transformations renders PREP superior in comparison to approaches that target bijective functions. As such, PREP delivers a feasible approach for important scenarios in MDSD (e.g., model composition and template-based code generation).
7
Ontology-based Round-Trip Engineering
When models are synchronized manually, humans determine inconsistencies and resolve them step by step. To do so, they use special knowledge about the involved modeling languages. This knowledge includes the structure and semantics of the languages, con- straints that might apply, and most importantly, the relationship between languages and their elements. Thus, to understand the process of model synchronization, it is crucial to grasp the relations between the involved modeling languages and the associated seman- tics. Moreover, relations within a single modeling language need to be considered when changes are made. Reestablishing a synchronous state among different related models can therefore be seen as propagating changes according to the semantics of all involved model relations—both within and across modeling languages.
Ontologies and DL, have been intensively studied as means to represent knowledge in a precise and formal way (cf. [55] for a comprehensive introduction). As such, on- tologies seem a suitable candidate to formalize the manual synchronization process and thereby shift to a more automated synchronization approach. The challenge stated above (i.e., formally capturing model relations and their meaning) strongly suggests a closer investigation to clarify whether DL can be employed in this context.
This chapter is based on our paper “Ontology-based Model Synchronisation” [199] and further pursues this investigations. We will first motivate the use of ontologies and DL for RTE (Sect. 7.1). Secondly, we give an overview of our approach in Sect. 7.2, followed by a small example in Sect. 7.3, which will be used subsequently. Then, we will present how to specify inter-model relations using ontologies (Sect. 7.4) and how synchronization is performed (Sect. 7.5). We will carry out a discussion of the properties of the approach in Sect. 7.6 and conclude with a summary at the end of this chapter (Sect. 7.7).
7 Ontology-based Round-Trip Engineering
Main contributions of this chapter are
C7-1 a novel approach to RTE based on semantically founded models,
C7-2 an analysis of ontologies (and OWL) w.r.t. their feasibility in creating synchro- nization specifications.
7.1 Motivation
When comparing the approach of knowledge representation taken in object-oriented modeling and ontologies, certain similarities can be observed. First, both share the concepts of classes and individuals (or objects, respectively). Here, the former describes a set of things, while the latter exactly refers to one of these things. Secondly, models and ontologies share the notion of generalization and specialization, which are subsumed by the term inheritance. Both representational styles use relations to describe semantic connections between concepts (or classes, respectively).
But, in contrast to models, ontologies (and DL being their foundation) provide a formal grounding that can be beneficial in the context of model synchronization. Ontologies allow to formally represent both knowledge about the subject of the synchronization and the rules that are used by humans during manual synchronization. The computational complexity of many of the underlying classes of logic is well understood. The derivation of implicit knowledge can be performed. All these properties make ontologies appear to be useful in the context of RTE, which motivated the subsequent investigations.
Moreover, various approaches to combine ontologies and metamodeling [13, 181, 200, 201] have emerged recently. These do explicitly target the formal description of model semantics. If such a description is available, the synchronization of models could be eased. In particular, there is hope that writing synchronization specifications could require less effort, if relations between metamodels can already be determined by the information about their semantics.
The previous chapter was motivated by the fact that some RTE scenarios require non- injective transformations and provides an alternative procedure to synchronize models. This chapter is focused on using ontology tools to synchronize models. Thus, it provides another alternative to classical bidirectional transformation languages. But, in contrast to our backpropagation-based approach, we do not aim to eliminate the need for inverse transformations, rather we want to investigate on the pros and cons of combining the formal grounding of ontologies with the practical feasibility of software models.
Within the PREP procedure, the synchronization fitness functions were designed to decide which set of models most appropriately reflects the change applied by a user while still preserving global consistency across the involved models. During this chapter, we will not see such functions, because the ontology-based approach to RTE uses predicates
7.2 Overview