8.4 Integrating Tools using Role Models
8.5.3 Data Migration
Our role-based tool integration approach, relies on the separation of interfaces of tools from the physical representation of the data they process. By composing role models, one can integrate a set of tools in different ways. The composition controls which data is shared across tools and how this is done.
An important questions that is raised by this procedure, is how existing data can be migrated when the role composition model is changed, for example, when a new tool enters an integration scenario. In such a case, one must distinguish between changes that modify the way role features are grounded, changes that apply to existing feature bindings, and changes the merely establish new feature bindings or groundings.
The first case is problematic, because the physical representation of data may be altered. The second one may also raise issues, because feature values are obtained from other sources. Thus, the views held by the involved tools can change. Only, the third case—adding new feature bindings or groundings—is more easy to handle. This case corresponds to adapting a new tool to an existing data representation. The existing
8 Role-based Round-Trip Engineering
bindings do not need to be changed here. However, to handle the first two cases— changing existing groundings and feature bindings—we see two options.
First, assuming that all views that are created by the definition of the role models, one could retrieve all stored data from the perspective of all tools individually. In our running example, the shape renderer, the graph analysis tool and the textual state machine editor would extract all data using their respective role model. The shape renderer would extract all shapes, the graph analysis tool all nodes and edges, and the state machine editor would retrieve all states and transitions. Then, the role composition can be replaced by a new one and all tools can put the extracted views into the system. The second option is to analyze the changes between the old role composition model and the new one. For some cases, one can probably derive the required steps to adjust existing data to the new grounding. Which of the two options is more feasible requires future investigations.
8.5.4 Technical Requirements
Our role-based tool integration approach puts very few technical requirements forward. From our perspective, these cannot be considered as blocking factors when applying the approach, but we want to mention the requirements if only for completeness reasons.
First, the definition of domain abstractions (i.e., tool data structures) requires a role modeling language. We have presented such a language that is based on EMOF. If the approach is applied to other platforms, a similar language is required.
Second, code generation must be employed to obtain an implementation of the domain models. This can be either obtained by mapping to an object-oriented modeling language or directly to an object-oriented implementation based on a GPL (e.g., Java). We have presented patterns to realize this mapping in Sect. 8.4.3. Alternatively, one can directly employ a programming language with support for roles (e.g., ObjectTeams [211]).
Similar to the derivation of code that implements the domain model, code generators are needed to realize role bindings and role groundings. Since the approach as such is not bound to a specific technical platform, no particular requirements apply to the target language of the code generation process.
8.6 Summary
Using role modeling in the context of RTE was motivated by the need to integrate tools in order to share data and to interact in unforeseen ways. In particular the fact that such flexible data sharing cannot be achieved using classical object-oriented meta- modeling languages, drove this work. Existing a priori integration approaches did not allow tools to be independent of each other and interferes with tool-specific abstractions. A posteriori tool integration using transformations does not support data sharing and
8.6 Summary
impedes multilateral tool interaction. In the latter case, interoperability was not antici- pated at all, while in the former it is anticipated only to a certain degree. This limited anticipation of tool interoperability at tool design time is one reason that renders RTE so difficult.
In this chapter we have shown how role-based metamodeling and role composition allow to handle arbitrary, unforeseen tool integration scenarios. We have used role models to capture the domain abstractions tools work on. Then, role composition programs are employed at integration time to bind domain abstractions to each other. A novel concept called grounding was used to specify which part of a role model is represented physically. All other role features need to be derived by examining role bindings.
While the idea of separating the data model required by tools from the physical repre- sentation of data is quite simple, explicitly providing modeling concepts to achieve this separation is not state-of-the-art. We have seen that roles and role composition are not only suitable to express such a separation, but furthermore allow to analyze the resulting tool integration. In particular the preservation of information is rendered possible by using a language dedicated to role composition.
The strength of our approach is that data models can be flexibly combined at tool integration time. One does no longer keep one (existing) data model fixed and adapt new ones to it. Both existing and newly added domain abstractions are treated equally. One important issue that we have discussed, but not fully addressed yet, is the mi- gration of existing data. Once a RTE scenario evolves (e.g., new tools are included), the grounding of data may change and existing data needs to be transferred to the new physical representation. To achieve such a migration an analysis of the changes made to the role bindings and grounding is needed.
The main limitation of our role-based metamodeling approach is that it needs to be applied during tool design time to prepare tools for interoperability. It cannot be applied as it is to integrate existing tools. Nonetheless, we strongly believe that the benefits gained at tool integration time outweigh enforcing tool developers to design their tools to allow for interaction. The fact that the proposed modeling approach allows to handle unanticipated future integration scenarios by construction relieves tool developers from anticipating unanticipated RTE scenarios.
9
Evaluation
This chapter contains the results of evaluating case studies for the different approaches to build RTE systems that have been presented in this thesis. Not all approaches were evaluated to the same degree. The most early approach underwent more investigations than the newer ones. Thus, the evaluation of the role-based and ontology-based syn- chronization approaches, being the approaches developed most recently, require further investigations (cf. Sect. 11.3). Nonetheless, we will try to highlight the positive and negative experiences that were gained while applying our approaches to practical syn- chronization problems in this chapter.
The backpropagation-based approach to RTE (cf. Chap. 6), being the first approach that was developed, is the most mature one and has been evaluated in different scenarios. In our initial publication [187], the approach was instantiated for the ISC technique and practically applied to synchronize both composed UML activity diagrams and Java programs. In later work that was performed within the research project MODELPLEX, the same ideas were evaluated on a composition system for UML and domain-specific security models. Details of this RTE system will be presented in Sect. 9.1. We selected this particular scenario, because it 1) has not been published before, 2) represents an industrial case study, and 3) outweighs the scenarios from [187] w.r.t. the complexity of the involved models.
Second, we evaluate a RTE system that employs backpropagation for a transformation that is not based on ISC. Namely, we apply our PREP approach to synchronize code and parameter models that are involved in template-based code generation. This is a particularly interesting scenario as it has high practical relevance. Using PREP to solve this problem will be presented in Sect. 9.2.
9 Evaluation
Third, we evaluate the ontology-based synchronization approach from Chap. 7 using a case study [212] that was previously performed using TGG rules (Sect. 9.3). We choose this scenario as it allows to validate whether the specification of synchronization rules in OWL and SWRL can handle mappings that are possible using the TGG formalism.
Our role-based tool integration approach (cf. Chap. 8) could not be applied to existing tools, because these do not employ role modeling. Thus, the evaluation of this approach was performed by building a new tool, which can benefit from the integration approach. More precisely, a refactoring tool was built and role models were employed to enable its applicability to arbitrary modeling languages. The initial results of this application have been published in [213] and will be recapitulated in Sect. 9.4.
All sections in this chapter follow the same outline. First, the context of the RTE scenario and an overview of the involved stakeholders and artifacts is given. Second, the application of our approach to build the RTE system is presented. Third, the pros and cons of the obtained system are discussed. The main focus of all evaluation sections is put on assessing more insights about the practical feasibility of our approaches rather than presenting all technical details that were required to accomplish the presented result.