ModelCVS A Semantic Infrastructure for Model-based Tool Integration

Transcription

1 ModelCVS A Semantic Infrastructure for Model-based Tool Integration G. Kappel, G. Kramler Business Informatics Group, Vienna University of Technology E. Kapsammer, T. Reiter, W. Retschitzegger Dept. of Information Systems, Johannes Kepler University Linz W. Schwinger Dept. of Telecooperation, Johannes Kepler University Linz Abstract With the rise of model-driven software development, more and more development tasks are being performed on models. A rich variety of modeling tools is available supporting different tasks, such as model creation, model simulation, model checking, and code generation. Seamless exchange of models among different modeling tools increasingly becomes a crucial prerequisite for effective software development processes. Due to lack of interoperability, however, it is often difficult to use tools in combination, thus the potential of model-driven software development cannot be fully utilized unless we find some scalable way of integration. We are aiming at providing a semantic infrastructure for model-based tool integration, enabling to facilitate any tool appropriate for the modeling task at hand. The key innovations provided are a set of scalable architectural model integration patterns supported by a highlevel metamodel integration language, thus going beyond existing low-level model transformation approaches. Ontology-based metamodel integration considerably lowers the manual effort required for tool integration, enabling a novel synergic use of technologies from the model engineering and ontology engineering domains. An open knowledge base for tool integration captures essential knowledge about modeling languages and tools in terms of ontologies, fostering reuse within and beyond the scope of this project. These innovations will be realized within the ModelCVS prototype and case study. The core of the system will be based on a versioning system such as CVS, thus providing a looselycoupled and well-proofed integration architecture. Transparent transformation of models between different tools languages and exchange formats, as well as versioning capabilities exploiting the rich syntax and semantics of models represent the key functionalities of ModelCVS. In this way, ModelCVS will serve as both, a research vehicle and testbed for exploring applications of semantic technologies in model-based tool integration and a prototype for a succeeding industrial product. 1 Introduction Motivation for model-based tool integration. Seamless exchange of models among different modeling tools becomes an important prerequisite for effective software development processes. With the rise of model-driven software development, more and more development tasks are being performed on models, to exploit the higher level of abstraction, the richness of visualization, and the power of expressiveness, as compared to general-purpose programming language code. A rich variety of tools is available supporting different tasks, such as model creation, model simulation, model checking, and code generation. Due to a lack of interoperability, however, it is often difficult to use tools in combination, thus the potential of model-driven software development cannot be fully exploited unless we find some way of integrating the variety of existing modeling tools. What we are looking for is model-based tool integration, enabling to facilitate any tool appropriate for the modeling task at hand. Although one could want complete tool integration, i.e., integration also addressing processes, user interfaces, etc., complete post- 1

2 hoc integration of modeling tools is very expensive in terms of effort and scalability compared to its benefits, and therefore out of scope of this project. Problems of model-based tool integration. Integration of modeling tools in terms of model exchange poses several difficult problems, resulting in high effort and costs. First, there is heterogeneity in textual representation, syntax, semantics, and scope of modeling languages and exchange formats used by different tools. Detecting and resolving these heterogeneities is a matter of both, size of modeling language and subtleties of syntactic and semantic differences. Second, implementation of an integration solution, i.e., basically a program that takes models in one tool s format and transforms it into another tool s format and vice versa, is a cumbersome and error-prone task. Although there are specific technologies emerging that can be used solving this task, e.g., in the context of OMG s model-driven architecture (MDA) 1 specific model transformation languages and tools are being developed, these are not tailored for the integration task, and furthermore require specific skills. Similarly, tools from the enterprise information/application integration (EII/EAI) markets [26] are not appropriate for handling data as complex as models typically are. Third, inconsistency in the handling of models becomes an issue when the development process proceeds in parallel branches such that different tools concurrently modify a model and model versions must be merged. Concurrent development arises in any development team and must be correctly dealt with. Finally, repetitive effort occurs when tools are updated by new versions or when tools similar to already known ones need to be integrated. Although during integration of a set of tools a huge amount of integration knowledge will build up, that knowledge is not captured explicitly in a form that facilitates re-use and automation support when integrating new tools or new tool versions. Semantic technologies for model-based tool integration. We believe that semantic technologies can improve model-based tool integration in multiple ways. Schema matching and ontology mapping solutions can be adapted to the modeling domain to tackle the heterogeneity problem. Research results from ontology mapping can serve as a basis for developing concepts and operators for specifying model transformations at a higher level of abstraction. Advanced model merging techniques can be developed based on semantically enriched descriptions of modeling languages. And finally, ontologies can be used to build a knowledge base capturing essential tool integration experience. Our approach ModelCVS. Therefore, we propose to build ModelCVS, a semantic infrastructure that serves as both a research vehicle and testbed for exploring applications of semantic technologies in model-based tool integration and a prototype for a succeeding industrial product. The core of the system will be based on a versioning system like the concurrent versioning system (CVS) 2, thus providing a loosely-coupled and well-proofed integration architecture. Transparent transformation of models between different tools languages and exchange formats, as well as versioning capabilities exploiting the rich syntax and semantics of models enhance the system s core. To keep the system evolvable, a scalable architecture for realizing tool integration is provided that minimizes the effort necessary for integrating new tools while maximizing reuse of integration knowledge. Integration is specified both at syntactic and semantic levels. The syntactic level deals with metamodels which define the structures and datatypes of models, whereas the semantic level uses ontologies which describe the semantics of modeling concepts. Semantic level integration and reuse of integration knowledge will be specifically supported through dedicated component of the semantic infrastructure that facilitates lifting metamodels to the semantic level, finding mappings between metamodels to be integrated, and finding semantic merge conflicts. Another dedicated component, the knowledge base, will comprise generic modeling concepts, selected important modeling domains, e.g., workflow, as well as reference examples

3 Example Overview of the case study. To exemplify the complexity of model-based tool integration and to point out the specific challenges we want to tackle, we consider a real-world scenario 3 that deals with the integration of three tools, the CASE tool AllFusion Gen (Gen for short) 4, the UML tool Rational Software Modeler 5, and the Oracle BPEL Process Manager 6. In this scenario, Gen is a legacy tool under which many existing applications have been developed. UML should be employed for new projects, to link up with current technologies. And BPEL (Business Process Execution Language for Web Services) 7 is required for developing certain web-enabled workflow applications. The UML and BPEL tools are stand-alone tools, with integration support restricted to file exchange using some particular file format, i.e., XMI (XML Metadata Interchange) 8 for UML and XML for BPEL. Gen is actually a well integrated suite of tools covering a wide range of tasks, following a common modeling paradigm. The integration capabilities of Gen, however, are not open for external tools. Without proper infrastructure support, integration of these tools poses severe problems as introduced above, which are very costly to solve. Different format, representation, scope, syntax, and semantics. First of all, the model exchange formats of these tools are quite different. The differences in representation textual data by Gen, XMI by the UML tool, and XML by the BPEL tool are the least problem, since there are tools to cope with that. A big problem, however, is difference in scope. Gen supports a variety of modeling domains, ranging from database via GUI to definition of functions. UML also has a rather broad scope, which is a subset of Gen s. BPEL, in contrary, has a very limited scope focusing on process modeling, which is related to Gen s process model and UML s activity diagram. Therefore, it is not possible to simply take a Gen model and translate it to UML or BPEL as only parts of it can be translated. Conversely, to allow for a translation back to Gen, precautions need to be taken to enable reassembly of any changed parts with the overall Gen model. No less of a problem are the differences in syntax and semantics. E.g., the control flow primitives of UML activity diagrams and BPEL are somewhat different, although they express the same concepts, e.g., parallelism. In some cases, however, there are also differences in expressiveness that cannot be translated. An integration infrastructure has to deal with that, too. Large and complex metamodels. The metamodels especially of Gen and UML are very large and complex. For instance, Gen s metamodel comprises more that 800 classes and the metamodel of UML2 more than 260 classes. Even if specific implementation technology for model transformations is used, e.g., the forthcoming QVT (Query/Views/Transformations)-standard [48], it is clear that implementing a transformation for Gen and UML will require a lot of effort and not least due to the overall complexity will be a very error-prone process. Part of the problem is here, that existing implementation technologies such as object-oriented programming languages but also emerging model transformation languages are not optimized for the problem at hand. The problem is not just to implement a single translation, but to also deal with the scalability problem. If BPEL is added to the tool chain, two new translations have to be implemented. If even more tools need to be integrated, simple point-to-point integration quickly comes to its limits and the need for more powerful architectures arises. Conflicting modifications. When, in the course of concurrent development, changes to a model are merged, much care has to be taken to keep the model consistent. As we have seen above, if a model is translated from Gen to BPEL, only some part of it can be translated, thus the BPEL developer may not be aware of all implications that any changes to the BPEL-relevant part may have on the overall model. The situation is even exacerbated when models are modified concurrently. Since we want to enable collaborative development 3 This scenario is envisioned as case study to evaluate the results of this project. The tools have been selected according to the requirements of the demonstrator of our project and to cover a broad range of integration issues

4 <XML> <tag1> <tag2> <XML> <tag1> </tag1> <tag2> <XML> <tag2> <tag1> </tag1> <tag2>... <tag2> </XML> </tag1>. <tag2> </XML>. </XML> and flexible working processes, we have to deal with the facts that experts working on some specific part, e.g., the BPEL part, use very specific tools and that development in related parts may proceed concurrently. Although the task of merging concurrent modifications is not genuine to model-based tool integration and is addressed by existing versioning tools, in our case we cannot rely on individual tools to help detecting and resolving potential inconsistencies, since a change performed in one tool may propagate to parts of the model that are outside that tool s scope. Therefore, appropriate infrastructure support is required. Different versions of metamodels. Finally, let s consider the process of updating a tool to a new version with an updated metamodel. If not already supported by the tool, the update process involves implementing translators for migrating existing models to the new version and possibly back again. Less obviously, also all of the existing integration specifications need to be updated to the new version, and the tool will certainly not support this task. Lot of repetitive effort will be required unless it is possible to automatically migrate existing integration specifications. A similar situation and potential of re-use occurs when tools supporting equal modeling languages have to be integrated. Typically these tools, although supporting the same modeling language, interpret and realize the associated metamodels in different ways, in case that the semantics of the metamodel is not clearly defined (which is, e.g., a major concern in the current UML 2.0 standard). Also in this case, reuse could be supported through higher-level integration knowledge, thus reducing the manual integration effort to validation, precision, and completion. 2 Research Goals The main research goal that has to be achieved in the proposed project is the finding of novel methods and the development of new technologies for a model-based approach to tool integration. The innovation in our approach is clearly the employment of semantic technologies in the form of ontologies to facilitate tool integration. Apart from the basic requirement of providing interoperability between tools, our focus on model driven development rises new requirements, in the form of providing model integration capabilities supported by semantic technologies for scalability reasons, advanced versioning mechanisms for practical applicability, and the construction of a tool integration specific knowledge base for the effective reuse of concept semantics for modeling languages. The unique character of the proposed project stems from being rooted in several traditionally disparate research fields such as ontology engineering, model driven development, versioning, and tool integration in general. Thus, the specific research goals associated with the proposed project as listed below, are expected to contribute to various research areas. Motivated by this overall research focus, three specific research goals can be derived, which are followed in this project (cf. Figure 1-1). (3) Open Knowledge Base for Tool Integration Tool B (e.g. Oracle BPEL (2) ProcessManager) Innovative Technologies for Ontology-Based Metamodel Integration (1) New Language for Scalable Model-basedTool Integration Tool A (e.g. AllFusionGen) Figure 1-1: Research Goals of ModelCVS Tool C (e.g. Rational Software Modeler) 4

5 (1) New Language for Scalable Model-Based Tool Integration Metamodel bridging. Model-based tool integration comprises creating so-called metamodel bridges between the different tool metamodels (i.e., the metamodels of the modeling languages supported by the tools). These metamodel bridges define the model transformations facilitating transparent model translation. The main problems in creating such bridges arise due to metamodel heterogeneity in various aspects and due to the fact that existing implementation technologies are not exactly appropriate for the metamodel bridging task. While we do not attempt to fully solve metamodel heterogeneity in any case for certain reasons heterogeneity is actually considered a necessity we aim at providing improved technologies for dealing with metamodel heterogeneity in more efficient and evolvable ways. Existing approaches. As already discussed, there exist specific languages for defining model transformations as required in the area of model-driven development. Requirements for such languages are, e.g., to transform complex high-level models into platform-specific models and ultimately into code. Although model transformation capabilities form the base of a model-based tool integration solution, generic model transformation languages operate at a very low level of abstraction, such that the specifics of tool integration are not explicitly supported (cf. Section 1.2). There also exist a wide range of EII/EAI tools, that support, e.g., conversions between different data formats (cf. Sections 5.2 and 5.4). These tools, however, do not focus, as already mentioned, on model-based tool integration and therefore are not able to deal with the complexities of metamodel bridging as envisioned in our approach. Integration patterns and bridging operators. For these reasons, we aim at defining a language specifically tailored to metamodel bridging. We will identify architectural model integration patterns (integration patterns for short) that ensure openness, scalability, and evolvability of a tool integration solution. These will serve as basis to define specific bridging tasks and to develop appropriate bridging operators forming a metamodel bridging language that supports the identified integration patterns. Concerning these integration patterns and bridging operators, our research can build on a few closely related approaches in the areas of model management (e.g., [39]) and model integration (e.g., [6]) as well as in the area of aspect-oriented modeling (e.g., [54]) which can be used as a first starting point (for a detailed overview, cf. Section 1.2). An initial set of integration patterns is proposed in Section 1.4, namely translation (i.e., bridging syntactic and semantic heterogeneity between largely overlapping tool metamodels), alignment (i.e., bridging cross-cutting concerns of partly overlapping tool metamodels), modularization (i.e., decomposing monolithic tool metamodels as a prerequisite for scalable bridging), and versioning (i.e., semantic-based migration of different versions of tool metamodels). (2) Innovative Technologies for Ontology-Based Metamodel Integration Ontologies for metamodel integration. The proposed project makes extensive use of semantic technologies for the integration of tool metamodels as well as for the realization of semantically aware model versioning mechanisms. We assume that addressing the integration problem at the semantic level using ontologies improves the quality of automation support that can be achieved. Given the fact that a huge amount of work already exists in the area of ontology integration, the question arises as how these research results can be employed for ontology-based metamodel integration. The essential difference between metamodels and ontologies is that metamodels define the concepts of a modeling language in terms of their syntax, whereas ontologies focus on the semantics of concepts, disregarding syntactical concerns. Therefore, in order to harness the potential of ontologies for metamodel integration and semantic versioning, the difference in abstraction level and semantic expressiveness between metamodels and ontologies needs to be dealt with. Metamodel lifting. In this respect, we aim to enable transitioning from the mostly syntactic metamodel level to the semantic ontology level in terms of a translation and subsequent 5

6 syntax abstraction and semantic enrichment, furtheron called metamodel lifting. The lifting process should result in a mapping between metamodel level and ontology level such that both levels can be used synergically. Regarding utilization of the expressiveness and reasoning capabilities of the semantic level, we aim in particular at supporting the various integration tasks as outlined in goal (1). Therefore, existing work on lifting data sources to ontologies (e.g., [59]), integration of ontologies (e.g., [41]) as well as modularization (e.g., [56]), and versioning of ontologies (e.g., [32]) has to be considered and adapted to the specific requirements of metamodel integration in terms of integration patterns and bridging operators. (3) Open Knowledge Base for Tool Integration Reuse capabilities. The basic idea behind the semantic infrastructure in ModelCVS is to enrich metamodels with specific semantics. As suggested above, this can be achieved by deriving tool ontologies from tool metamodels, which provide proper semantics for modeling languages. The entailment of specific semantics through an enrichment of tool ontologies, however, shall be possible with reasonable effort. Therefore, a key requirement is to provide reuse capabilities for the process of defining specific semantics for a tool ontology. Tool integration knowledge base. Hence, our research aims at constructing a tool integration knowledge base that, similar to a library, provides reusable concepts for the enrichment of individual tool ontologies. The knowledge base should enable semantic support for ontology-based metamodel bridging as discussed in goal (2), as well as improved detection of versioning conflicts as motivated by the introductory example. The knowledge base should furthermore be open for usage outside the scope of ModelCVS. Content of the knowledge base. Specific research tasks comprise, first, identification of generic, reusable concepts and development of a structure to organize the contents of the knowledge base and to enable efficient reuse. Second, devising a set of reference examples, which will be the result of our case study, to populate the tool integration knowledge base with, to be used to enhance ModelCVS matching and reuse capabilities. Third, defining knowledge about semantic merging conflicts as required for enhanced model versioning capabilities, i.e., automated identification and subsequent resolution of such conflicts. Fourth, establishment of a public platform enabling Internet-wide access and contributions to the knowledge base as to maximize reuse effects. 3 State of the Art In the following, the state of the art is described with respect to our research goals outlined in Section 1.1. For this, in a first step, a brief overview on tool integration in general is given, followed by a discussion of more closely related approaches in the area of model-based tool integration and concluded finally, by a review of ontology research for integration purposes. 3.1 State of the Art in Tool Integration Research in tool integration has been a hot topic since the Stoneman Model 9 was proposed at the end of the 70's and summarized by Brown [8] in two categories, the conceptual level ( what is integration? ) and the mechanical level ( how do we provide integration? ). Conceptual level of integration. In general, commercial of the shelf (COTS) tools are meant to be integrated if they function coherently and effectively in an environment as a whole, as is the case in an integrated development environment (IDE). Wasserman [60] is regarded as the first author who has suggested a categorization to describe the integration of tools from a functional point of view comprising integration in terms of platforms, GUIs, data, control, and processes. Other categorizations used for characterizing tool integration 9 6

7 comprises depth of integration, varying from exchanging byte streams to semanticspreserving integration, and the universal applicability of the integration approach. Mechanical level of integration. The research efforts at the mechanical level of tool integration include (1) a series of standardization efforts and middleware services like CAIS [45], PCTE [2], CDIF [20], CORBA 10, and OMG s recent RFP OTIF 11 (open tool integration framework) to support tool interoperability, (2) architecture models, infrastructures, and tool suites like the ECMA toaster model [17], the ToolBus architecture [5], and finally (3) basic tool integration mechanisms such as data sharing, data linkage, data interchange, and message passing [52]. Some of these efforts were often grounded in large initiatives but have not been widely accepted. The European standardization effort PCTE, e.g., supporting data integration by providing tools with a common repository and services to store, retrieve, and manipulate data was not widely adopted in industry, not least because of its heavyweight architecture and high usage costs. Another example, CDIF, a standard for model exchange has been in the meanwhile replaced by MOF and XMI (cf. Section 1.2.2). Regarding, e.g., tool suites, they are often incomplete with respect to the various development activities requiring tool support, and most often do not allow to select between best of class tools (apart from promising exceptions like Eclipse 12 ) [52]. Despite of all these important efforts, tool integration is still a challenging task, leading most often to hand-crafted bilateral integration solutions [52]. These solutions suffer from high maintenance overheads not least in case of evolutions of the underlying data or tools themselves, are often strongly technology-dependent and, most importantly, do not scale. With the advent of model-driven development (MDD) and in particular the introduction of MDA, new possibilities have been opened up to cope with these challenges. 3.2 State of the Art Relevant for Model-Based Tool Integration Model-driven development. The key idea of MDA is to focus on models instead of code as the major artefact in software development. This allows modeling tools to be integrated on basis of the metamodels of modeling languages supported by the tools (i.e., the tool metamodels), thus paving the way for another generation of (meta)model-based tool integration approaches and providing a basis to overcome the above mentioned limitations of existing integration approaches. For this, MDA includes a set of interrelated standards 13, comprising a language for metamodel definition (Meta Object Facility MOF), and the MOFcompliant languages for constraint specification (Object Constraint Language OCL), model transformation (QVT), and metadata interchange (XML Metadata Interchange XMI). Model transformation as key technology Model transformation languages. Model transformation is one of the major building blocks in the context of model-based tool integration and a very active research area. Existing approaches in this area having been either submitted to OMG s QVT request for proposals or being already part of existing MDA tools range from algorithmic and imperative approaches, via graph-transformation-based approaches to template rule-driven, and hybrid approaches [14]. Tratt et al. [57], e.g., provide an extensible, imperative model transformation language with some rule-based elements for pattern matching purposes, whereas Becker et al. [4] use purely rule-based mechanisms based on graphtransformations and generates wrapper for tool integration following a kind of programmingby-example approach. Highly relevant for our approach seems to be transformation languages such as BOTL 14, which allows the definition of modular, rule-based transformations, with independent rules for sets of metamodel elements a property important for realizing the versioning interaction pattern as introduced in Section

8 Infrastructures based on transformation languages. Based on these several kinds of QVT-like transformation language proposals, infrastructures and frameworks have been built for tool integration (cf. the special issue of SoSym on model-based tool integration [52]). For example, WOTIF (Web-based open tool integration framework) 15 uses a graphtransformation mechanism and realises different tool integration patterns (e.g., direct tool integration and integration via a common metamodel), but requires that every tool to be integrated supports certain APIs for installing plugins which is in contrast to our approach. GeneralStore [50] being in fact a MOF-based repository, allows bi-directional transformations between models, but uses XSLT or ad-hoc approaches for model transformation, only. Finally, MDDi, (Model-driven Development Integration Project of Eclipse) 16, although providing some interesting ideas for model integration in terms of a bus architecture similar to AMMA (cf. below) is still in its draft proposal phase. Deficiencies of pure model transformations. Although, QVT-like model transformation languages are a cornerstone also for our project, existing proposals are too generic and lack appropriate abstraction mechanisms for different kinds of model integration patterns, which are highly needed in practice and well-known from other research areas such as federated and multi database systems [53], megaprogramming [61] and web service composition [35]. Such integration patterns (cf. Section 1.4) would require a series of basic model transformations which will simply not scale up when manually specified for complex models. Beyond pure model transformation integration patterns and bridging operators There are only few closely related approaches providing abstraction mechanisms in terms of, e.g., high-level bridging operators or modularisation techniques in the areas of model management and model integration as well as in the area of aspect-oriented modeling which are described in the following in more detail. Rondo. Having a similar intent in mind, the generic model management initiative from Bernstein et al. [39] provides a prototypical implementation called Rondo, which aims at keeping the matching of large XML schemata scalable. An approach to matching is introduced that operates on fragments of a large schema to lower the complexity of matching tasks. Besides this modularisation, model management operators on relational and XML schemata are provided, comprising, e.g., the automatic derivation of semantic correspondences or differences, the merging of models, and the derivation of a mapping from other mappings. Although set in the context of relational and XML schema matching, this idea seems to be transferable to tool metamodels. Nevertheless our approach is not only aimed at finding semantic correspondences between metadata, but also to support certain model integration patterns, keeping a later code-generation step in mind in terms of deriving appropriate model transformation programs thereof. Another difference is that our focus goes beyond integrating XML and database schemata, by allowing the integration of arbitrary MOFmodels in the sense of MDA. AMMA / AMW. The ATLAS Model Weaver (AMW) which is part of the AMMA model engineering platform (soon to be released under the Eclipse GMT project 17 ) proposed by Bézivin et al. [6], allows to perform a weaving operation in terms of establishing semantic correspondences between two metamodels, which are stored in a weaving model. Model weaving seems to be different to Rondo a manual operation, requiring an explicit specification of appropriate semantics for correspondences. Our approach, in contrast, aims at both, inferring semantics of correspondences from ontological knowledge and providing a predefined set of higher-level bridging operators. In addition, ModelCVS extends the notion of weaving from an activity that solely establishes correspondences between metamodels, to a mechanism that interprets operators specified between metamodel elements and carries out transformation programs accordingly

9 Aspect-orientation. The research efforts associated with aspect-orientation also deal with modularization in terms of factoring out cross cutting concerns into modules called aspects. This idea manifests in aspect-oriented programming languages [33], but also in aspectoriented modeling, which allows to modularize cross-cutting-concerns in an implementation independent manner (cf. the approaches below). Our approach focuses on tool integration, meaning that metamodels are, e.g., decomposed according to certain concerns they cover. Weaving as in aspect-orientation can be compared in our approach to the re-assemblage of models after modularization. In a tool integration setting, one can assume modularization to take place by detecting join points, e.g., in the form of meta-associations and point-cuts, e.g., in the form of links between model elements, to offer automatic support for a future re-assemblage. Most of the following approaches more or less use ideas from aspect-orientation for model integration purposes. Model Composition Semantics. Clarke [12] introduces a composition mechanism for UML class diagrams, representing different separated concerns. Overlapping concepts are identified in these models and thus merged as specified by a composition relationship, following so-called merge and override strategies. Based on this basic integration behavior, composition patterns [11] are introduced as an extension to UML templates. This approach focuses on UML models, only, and does not allow, e.g., the deletion of obsolete model elements after an integration is performed, as required for our approach. In addition, we focus on the derivation of model transformation programs during the integration stage, which are capable of automatically performing, e.g., the merging of models. Model Composition Directives. Based on [12], Straw et al. [54] propose so called composition directives for composing UML class diagrams. These basically include name rewriting, adding, and deleting of model elements, change of references, and control of execution order. Inspired by aspect-oriented programming, so-called primary models are composed with aspect models, which represent a crosscutting concern to be interwoven. Although composition directives are comparable to our envisioned model bridging operators, their primary focus seems to be on model weaving but not on meta-model weaving. We believe that our metamodel bridging operators could in turn be transformed into composition directives at the model level. Since we avoid an ad-hoc integration of models, with our approach, licit integrated models can be generated, only. GME. The Generic Modeling Environment (GME) proposed by Karsai et al. [31] is a modeling and metamodeling toolkit based on UML notation and a GME specific meta metamodel. GME allows for the composition of metamodels similar to our approach. The composition mechanisms comprise an equivalence operator creating a union of two model elements, similar to the merge semantics in [12] and two different inheritance operators, realizing implementation inheritance and interface inheritance. Differerent to our approach is that GME is not based on the MOF standard. Furthermore, our approach goes beyond the functionalities for metamodel composition in GME by supporting different model integration patterns, not just composition of metamodels. C-SAW. C-SAW, developed as a plug-in for GME by Gray et al. [23] is a so called crosscutting-concern weaver. Aspects are specified using the Embedded Constraint Language (ECL), a OCL superset, additionally providing imperative constructs for model manipulation. The transformation capabilities of ECL are, however, limited to models of the same metamodel, it lacks support for abstract integration mechanisms and is, instead of MOF, based on a meta-metamodel specific to GME, making the approach not applicable for us. Domain Composition Approach. Estublier et al. [18] propose a UML profile allowing the composition of separately designed domain models, as required when facing the federation of immutable components off the shelf. UML associations and association classes are specialized by stereotypes to express feature correspondence and concept overlapping. In principle, this approach is similar to our envisioned alignment interaction pattern, but does not support other interaction patterns as targeted in our project. In addition, only UML models are supported instead of arbitrary MOF-models. 9

10 Summary. Summarizing, although there are already few approaches targeting model-based tool integration from a meta-modeling point of view and providing some basic abstraction mechanisms in terms of modularization techniques and bridging operators, each of them suffers from certain deficiencies with respect to the focus of our project as outlined above. Nevertheless, several ideas and concepts of these approaches could be of high value for ModelCVS, which has to be investigated in-depth in the course of the project. It has to be noted however, to the best of our knowledge, none of these approaches uses ontologies to facilitate the semantic aspect of model-based tool integration, as done in our approach. 3.3 State of the Art Relevant for Ontology-Based Metamodel Integration History of semantic integration. The research field mainly relevant for ontology-based metamodel integration is the broad area of semantic integration. The history of semantic integration goes back to the early 1980s, where Brodie et al. [7] addressed semantic relativism in data modeling, leading to a comprehensive taxonomy of semantic heterogeneities introduced by Shet et al. [53] in the early 1990s and an in-depth survey of automatic schema matching approaches in 2001, published by Rahm et al. [49]. Although the problem of semantic integration is tackled in various ways by different communities, as could be seen at the remarkable Dagstuhl workshop on semantic interoperability and integration in , in recent years, ontologies became very popular to facilitate various semantic integration tasks. This is not least since, in comparison to other techniques, integration based on ontologies can rely heavily on the high expressive power of ontology languages and on appropriate reasoning techniques. As already stated in Section 1.1, our approach will utilize ontologies as a base mechanism to semantically enrich tool metamodels, thus facilitating tool metamodel integration. In this respect related work in the area of lifting metadata to ontologies, issues of integrating ontologies, and the usage of integration patterns for ontologies is highly relevant for our approach, as discussed in the following. Lifting Metamodels to Ontologies A basic question to be investigated is the derivation of ontologies from the tool metamodels, often referred to as lifting. Few existing work, although approaching the lifting problem from somewhat different angles, could be used as starting point to resolve this research question. OntoLIFT. Lifting is, e.g., dealt with in the WonderWeb project in terms of the OntoLIFT prototype [59], which helps to semi-automatically create ontologies from database schemata by using syntactical patterns as employed for mapping database schemata to ER models. Although these ontologies have to be further refined to infer specific semantics, OntoLIFT provides a useful entry point for the establishment of ontologies. Ferdinand et al. Another approach from Ferdinand at al. [19] proposes an automatic mechanism to lift XML Schema to the Web Ontology Language (OWL) 19 via RDF and provide according mapping rules. Although both approaches deal with the derivation of ontologies from structured sources, methods applied in these two approaches cannot be immediately reused, since ModelCVS requires the derivation of ontologies from metamodels. Further research has to be put into the question of how to facilitate the creation of ontologies from MOF-based metamodels. ODM. A way to bridge between model engineering and ontology engineering could be the Ontology Definition Metamodel (ODM) 20, an upcoming OMG standard for the definition of ontologies in terms of MOF models. Guizzardi et al. [24] provide an evaluation framework to estimate the appropriateness and the comprehensibility of a modeling language for describing concepts in terms of domain knowledge captured in an ontology. Such considerations are relevant in the context of

11 ModelCVS to define ontologies for modeling languages or to estimate to what extent existing ontologies can be reused. Basics of Integrating Ontologies As ModelCVS is able to perform tool metamodel integration on basis of semantics covered by tool ontologies, these individual tool ontologies have to be integrated. The central burden making ontology integration a rather comprehensive challenge are heterogeneity issues that have to be coped with [34], which are similar to heterogeneities in database research [53]. Thus, our approach has to deal with different forms of heterogeneity, establish a certain ontology integration architecture, and provide appropriate mechanisms for mapping discovery, representation and reasoning [44]. Although having different goals in mind since we use ontologies as a basic vehicle for the integration of tool metamodels, we can benefit from a large body of literature which may provide useful input for our approach. For a comprehensive overview about this active research area compare, e.g., [1], [30], and [44]. Ontology integration architecture. Concerning the architecture for ontology integration, one can basically distinguish three alternatives (cf. e.g., [44]): (1) a direct mapping between ontologies, (2) an indirect mapping via a common, shared ontology further on called upper ontology (sometimes also referred to as toplevel, or reference ontology), e.g., the Standard Upper Merged Ontology (SUMO) [42] and DOLCE [21] and (3) a mapping based on a library of already mapped ontologies [58]. This is again similar to database integration research, where peer-to-peer database systems are similar to the direct mapping approach, and federated database systems relying on a global schema are similar to the indirect mapping approach with the difference that an upper ontology is usually more general since it needs to encompass the top level for ontologies yet to be developed [44]. We intend to use a hybrid approach, involving all three architectures in order to ensure a balance between reuse capabilities, provided by upper ontologies as well as ontology libraries, and overhead induced, which can be reduced by using direct mappings for special, non-recurring mappings. For this, existing approaches as mentioned above can provide a valuable input, although they have to be adapted in order to deal with our special focus of deriving appropriate metamodel bridges. Mapping discovery. Based on a certain ontology integration architecture, mappings between ontologies have to be established, i.e., similar concepts have to be related to each other. Mapping discovery techniques deal with finding such correspondences (also called matches) between ontologies. This can be done either in a fully manual way or by utilizing heuristic-based or machine learning techniques that use various characteristics of ontologies, such as their schemata (schema-based matching), their instances (instancebased matching) as well as lexical reference systems [49], [15], [44]. It has to be emphasized, that it is not the intent of this project to develop yet another mapping discovery technique. Rather, it is foreseen to either use a single existing technique or a combination thereof which can be easily adapted to best fit our requirements. A selection of some of these approaches which may be (partly) useful for our purposes are sketched out in the following. Chimaera. Chimaera [38] provides support for ontology merging by interactively relating concepts that are identical or related by subsumption or instance relationships. Further, it supports to manipulate the ontologies as to improve alignment by suggesting modifications. PROMPT. PROMPT [43] supports interactive, guided ontology merging, starting from linguistic and structural similarity matches. Merge operations can be performed, and based on the results and potential conflicts arising from the merge (e.g., name conflicts, dangling references, or redundancies in class hierarchies), further operations are proposed. KRAFT. KRAFT [47] supports the finding of mappings by special mediator agents which can be customized with respect to support particular ontologies as well as ontology languages. Although the approach provides great flexibility in supporting various mappings, the user is able to specify arbitrary mappings since the semantic of concepts is not regarded, thus risking wrong and even conflicting mappings. Within our approach it is of major importance 11

12 to guide the user and prevent useless mappings exploiting the provided semantics. PUZZLE. The goal of PUZZLE [29] is to construct a consensus ontology, i.e., a common, shared ontology, from independently designed ontologies. Both, linguistic as well as contextual features of ontology concepts are considered, there is no need for a previous agreement on the semantics of the used terminology and WordNet is used to support, e.g., synonyms and homonyms. Reasoning rules are based on the relationships subclass, superclass, equivalentclass, and sibling, and on property lists of ontology concepts to find new relationships among concepts. Representation of mappings. Having found appropriate mappings, they have to be properly represented in order to facilitate reasoning on mappings. Concerning the representation of mappings several approaches can be found in literature [44]. Note that also combinations thereof are possible. First, similar to traditional data integration, views can be used to describe mappings, e.g., between upper ontology and local ontologies, either using the global-as-view (GAV) or the local-as-view (LAV) approach, well known from database integration research [25] and used, e.g., within the OIS framework [9]. Second, mappings can be represented in terms of bridging axioms in first-order logic to express transformation rules, relating classes and properties of two ontologies, as it is done in the OntoMerge system [16]. Finally, mappings can be represented as instances in an ontology of mappings. The mapping ontology usually provides different ways of linking concepts from the source ontology to the target ontology, transformation rules to specify how values should be changed, and conditions and effects of such rules. Examples are the Semantic Bridge Ontology of the MAFRA framework [37] or the mapping ontology [13]. Within our project we will have to investigate the proposed alternatives to find an appropriate one, whereby specific mapping ontologies seem to provide a great potential for mapping representation as well as reasoning. Reasoning with mappings. In general, reasoning aims at drawing a conclusion, e.g. to perform semantic integration tasks. In ModelCVS reasoning over ontology mappings is required to facilitate metamodel integration. Reasoning hardly depends on the underlying representation form [44]. In the OIS framework [9] mappings are expressed on basis of a GAV/LAV approach, using description logics and therefore a special description logics reasoner. PROMPT [43] takes a mapping ontology and automatically merges the corresponding ontologies based on the specified mapping. In case that we utilize a mapping ontology, corresponding existing approaches will be taken as base and adapted for our special purposes. Model Integration Patterns and Ontologies As our approach provides different model integration patterns such as alignment and modularization to allow metamodel integration in a scalable way, also the tool ontologies have to support these model integration patterns. Klein, e.g., [34], suggests several kinds of integration, applied to ontologies as a whole, which are comparable to our integration patterns. In the Onion system [41], an algebra for ontology composition is proposed, supporting several operators, e.g., filter, extract, union, intersection, and difference. There already exist approaches in the field of ontology modularization, e.g., [55], [56] and [22], aiming at modularizing ontologies for the purposes of efficient reasoning, distribution, and maintainability. In our approach, however, not an ontology is the target of integration patterns, but the tool metamodel it is associated with and as a consequence to that, finding ways for dealing with ontologies in the same semantics preserving way. Therefore, the approaches described above are not immediately reusable in our context, but could provide a useful starting point. To support ontology versioning, Kauppinen et al. [32] define a so-called change bridge ontology that enables reasoning about an evolved ontology. The goal is not interoperability, as with ontology mapping in general, but rather to align the revisions of a single ontology in time. Important in our context are also maintenance and evolution techniques for mappings, as proposed, e.g., by Maedche et al. [36], providing a reusable ontology of semantic bridges. 12