Hugo Brunelière
email: hugo.bruneliere@inria.fr

Jordi Cabot
email: jordi.cabot@inria.fr

Cauê Clasen
email: caue.avilaclasen@inria.fr

Frédéric Jouault
email: frederic.jouault@inria.fr

Jean Bézivin
email: jean.bezivin@inria.fr

Towards Model Driven Tool Interoperability: Bridging Eclipse and Microsoft Modeling Tools

Successful application of model-driven engineering approaches requires interchanging a lot of relevant data among the tool ecosystem employed by an engineering team (e.g., requirements elicitation tools, several kinds of modeling tools, reverse engineering tools, development platforms and so on). Unfortunately, this is not a trivial task. Poor tool interoperability makes data interchange a challenge even among tools with a similar scope. This paper presents a model-based solution to overcome such interoperability issues. With our approach, the internal schema/s (i.e., metamodel/s) of each tool are explicited and used as basis for solving syntactic and semantic differences between the tools. Once the corresponding metamodels are aligned, model-to-model transformations are (semi)automatically derived and executed to perform the actual data interchange. We illustrate our approach by bridging the Eclipse and Microsoft (DSL Tools and SQL Server Modeling) modeling tools.

Introduction

Development of a software system involves the collaboration of many developers with different roles (managers, analysts, designers, programmers,...) employing various tools (from project management tools, as Microsoft Project, to tools for requirements elicitation, as DOORS or even Excel, modeling tools as EMF and Microsoft DSL Tools, and development IDEs among many others).

Clearly, a key aspect for this collaboration is proper interoperability in the tool ecosystem. Interoperability is the ability of two (or several) tools to exchange information and thus to use the exchanged information [START_REF] Geraci | [END_REF] [START_REF] Thomas | Definitions of tool integration for environments[END_REF]. Interoperability is required in several scenarios: forward engineering, reverse and round-trip engineering, tool and language evolution (to address backward compatibility with previous versions) and, for instance, collaborative development, where several subteams may work on separate views of the system using different tools (e.g., modeling tools) that must be later merged.

Unfortunately, interoperability is also a challenging problem that requires addressing both syntactic and semantic issues since each tool may use a different syntactic format to store its information but, more importantly, use its own internal schema to represent and manipulate such information, most likely different from the one expected by other tools. Therefore, trying a manual solution is P r e l i m i n a r y V e r s i o n error-prone and very time-consuming, and it is hardly reusable even when using a similar set of tools. Instead of ad-hoc solutions, a generic set of bridges between the tools should be provided. Each bridge should ensure data-level interoperability (i.e., metadata/data interchange) and operational-level interoperability (i.e., behavior interchange) for two or more tools, independently of the specific project/context in which the tools are used.

In this sense, we propose a model-driven solution for tool interoperability. In general, model-driven interoperability approaches work by first making explicit the internal schema (i.e., metamodel) of each tool. Metamodels are then aligned by matching the related concepts. Finally, model-to-model transformations exploit this matching information to export data (i.e., models from our point of view) created with the first tool to data conforming to the second tool's internal schema. In this paper, we focus on a more general scenario in which tools that need to interoperate are able to manipulate data conforming to different metadata specifications. In this situation, data interoperability needs to interchange not only the data but also the metadata between the tools so that the target tool can correctly interpret the imported information. Therefore, in this case, alignment is not done at the metamodel level but at the metametamodel level. Note that tools that support arbitrary metadata specification necessarily represent metadata using a specific format, or structure, and cannot have fully hard-coded metadata. This format is what we refer to as the metametamodel of the tool, whether it is called a metametamodel in the tool terminology or not, and whether it is explicit in the tool or not. Also note that, in contrast to other approaches, changes on the internal schema/s used by one of the tools do not require updating the bridge.

We believe this more generic approach is required to deal with the complexity of current model-driven engineering (MDE) approaches. As an example, consider the Eclipse Modeling Framework (EMF [START_REF]Eclipse Modeling Framework (EMF[END_REF]). When modeling a system with EMF, designers can use several domain-specific languages, each one represented by its corresponding metamodel, to specify different views of the system. When exporting this specification to another tool we need to export both the models and the metamodels the designers have used. We will use this scenario to illustrate our interoperability approach. In particular, we will provide a set of bridges between the Eclipse (EMF) and Microsoft (SQL Server modeling [START_REF]Microsoft SQL Server Modeling Technologies[END_REF] and DSL Tools [START_REF]Microsoft Domain-Specific Language (DSL) Tools[END_REF]) modeling technologies. The bridges will allow to automatically open and manipulate in Microsoft tools any model and metamodel defined in EMF and vice-versa.

As we will see, our model-based solution offers several advantages: it is generic (it can be applied to any metamodel and model independent of the domain), reusable (all tools using the same underlying framework/platform, e.g., all tools based on EMF, can reuse the bridges) and extensible (it can be easily adapted to cover new environments and formats since it addresses separately the syntactic and semantic issues). Besides, our approach is easier to integrate with current trends towards the use of modeling in many aspects of the development process.

P r e l i m i n a r y V e r s i o n

The rest of the paper is structured as follows. Next section characterizes the problem context for our method and comments the current state of the art in this field. Section 3 introduces the Eclipse-Modeling example. Then, Section 4 presents our approach for data-level interoperability and applies it to create the Eclipse-DSL Tools bridge. Section 5 repeats the process for the Eclipse-SQL Server Modeling bridge highlighting how both bridges are built following the same generic architecture. Operational-level interoperability is commented in Section 6. Finally, we explain the tool support in Section 7 and the conclusions and further work in Section 8.

Problem Definition

The interoperability problem has been widely addressed in the literature (see [START_REF] Wicks | Controversy corner: A new research agenda for tool integration[END_REF][START_REF] Ossher | Software engineering tools and environments: a roadmap[END_REF] for existing surveys) but it is still far from being solved. For instance, the OMG has recently created the Architecture Ecosystem Special Interest Group to discuss this same problem.

Previous approaches tried to handle this problem by connecting the tools' APIs (e.g., [START_REF] Sim | Next generation data interchange: Tool-to-tool application program interfaces[END_REF]) or interfaces (e.g., [START_REF] Bao | A new approach to software tool interoperability[END_REF]). Approaches of this kind, operating at the API-level, may notably make use of the facade pattern. However, this lowlevel view of tools was too limited to achieve real data interoperability. With the advent of MDE, new proposals have realized about the benefits of looking at the interoperability problem at a higher abstraction level [START_REF] Elvester | Towards an interoperability framework for model-driven development of software systems[END_REF] and now follow a model-based approach in which interoperability is specified at the (meta)model level: the internal metamodels of both tools are explicited and aligned and this information is used to drive the interchange of information between them.

Nevertheless, most of these approaches (including our previous experiments in this area) focus on an ad hoc solutions for two concrete tools [START_REF] Kern | Integration of microsoft visio and eclipse modeling framework using m3-level-based bridges[END_REF][START_REF] Del Fabro | Model-driven tool interoperability: An application in bug tracking[END_REF][START_REF] Moalla | Model-Driven Architecture to enhance interoperability between product applications[END_REF][START_REF] Sun | A model engineering approach to tool interoperability[END_REF][START_REF] Kern | Model interchange between aris and eclipse emf[END_REF][START_REF] Zhang | An mde-based method for bridging different design notations[END_REF]. The exceptions are [START_REF] Kramler | Towards a semantic infrastructure supporting model-based tool integration[END_REF] that proposes some generic patterns that facilitate a (manual) metamodel alignment based on the use of ontologies (under the assumption that integration of ontology-annotated metamodels is easier) and [START_REF] Blanc | Model bus: Towards the interoperability of modelling tools[END_REF] and [START_REF]Open tool Integration Framework[END_REF] that focus on the interoperability of modeling tools through the use of a bus that provides several predefined data interchange and conversion services.

Moreover, all these approaches assume that tools have a fixed metamodel (e.g., UML modeling tools only accept models conforming to the UML metamodel). This is not the case anymore. With the rise of MDE, more and more development tasks involve manipulating models conforming to different metamodels and created using generic tools able to handle several metamodels at the same time. Typical examples are the Eclipse and Microsoft modeling tools. As part of the definition of the working environment, the designer can define the metamodel to work with and then create models conforming to that metamodel. Therefore, data interchange for these tools involves bridging both the models and the metamodels at the same time.

In this sense, our approach provides a more general solution to the tool interoperability problem by allowing data interchange between tools with variable metamodels. Once the bridge has been built, metamodels and models can be P r e l i m i n a r y V e r s i o n automatically interchanged between the tools. Adding new metamodels does not require extending the bridge. Besides, as we will see our approch is fully model-driven and separates in different steps the processing of the syntactic and semantic aspects of the bridge. Instead many existing approaches mix both transformations which impairs the reusability of the bridge. In addition to this, many of the interoperability scenarios cited above could be expressed as a specific instance of our approach (where the variable metamodels would be just the specific metamodel of the tool) and benefit from (parts of) it.

Motivating Example

As a concrete example of the problem previously detailed in Section 2, we consider in this paper bridging the Eclipse Modeling Framework (EMF) [START_REF]Eclipse Modeling Framework (EMF[END_REF] with two different Microsoft modeling environments: Microsoft DSL Tools [START_REF]Microsoft Domain-Specific Language (DSL) Tools[END_REF] and Microsoft SQL Server Modeling [START_REF]Microsoft SQL Server Modeling Technologies[END_REF]. This is actually a quite common interoperability scenario: these three modeling environments overlap in many aspects, in terms of both concepts and capabilities, and are becoming increasingly popular. Therefore, it is likely that many projects need to import/export metamodels (i.e., metadata) and corresponding models (i.e., raw data) from one environment to the other. This can occur for instance when the base platform has to be changed and the related legacy (meta)models must be reused. A collaborative work, in which both environments are being used at the same time and some specified models need to be merged accordingly, is another potential situation where such interoperability is required. More pragmatically, the goal of our bridges is to allow metamodels and models built or generated in EMF to be manipulated in both Microsoft modeling environments and vice-versa. We provide here short descriptions of these three different environments.

The Eclipse Modeling Framework [START_REF]Eclipse Modeling Framework (EMF[END_REF] is the well-known reference modeling infrastructure when developing under and for the Eclipse platform. It provides an explicit metametamodel, named Ecore, as well as the corresponding standard runtime, serialization and code generation features for the designed metamodels and models to be exploited. See, for instance, the PetriNet metamodel along with a sample model conforming to that metamodel created using EMF (cf. Fig. 1). All the Eclipse modeling tools are based on EMF such as model-to-model (M2M) transformation tools (e.g., ATL [START_REF] Jouault | Transforming Models with ATL[END_REF] used to implement the bridges), model-to-text (M2T) transformation tools, graphical or textual model editors, etc.

The Microsoft DSL Tools [START_REF]Microsoft Domain-Specific Language (DSL) Tools[END_REF] are part of the Visual Studio SDK dedicated to the customization of the Visual Studio platform (largely based on the .NET framework) for specific needs or domains. DSL Tools aim more particularly at providing facilities for building graphical Domain-Specific Languages (DSLs) and corresponding editors, i.e., modeling tools. Contrary to EMF, this environment is based on an implicit metametamodel which is somehow internally hard-coded P r e l i m i n a r y V e r s i o n by APIs and corresponding serialization XML Schema. It also comes with code generation capabilities from the designed models.

Microsoft SQL Server Modeling (SSM) [START_REF]Microsoft SQL Server Modeling Technologies[END_REF], formerly "Oslo", is the latest modeling environment developed by Microsoft and targets the building of datadriven tools. This environment is based on the 'M" modeling language whose MSchema part is a declarative language to design domain models (or metamodels). The other parts of this language allow defining corresponding textual concrete syntaxes for DSLs as well as concrete data models (models). SSM also features a customizable tool, named "Quadrant", allowing to interact between the available models and the actual data (i.e., the databases).

In the remainder of this paper, we will focus on the possible bridges between EMF and these two Microsoft environments. Bridging the Eclipse and Microsoft worlds opens the door to import/export into/from Microsoft all (meta)models specified with any modeling tool built on top of EMF: interoperability is thus possible between many different tools at the same time. We will see the results of porting our PetriNet metamodel and sample model as an example of the application of our method.

Approach Presentation

This section introduces our model-driven approach for tool interoperability. First, we present the high-level architecture of the method. Then, we clarify and describe in detail each individual step, showing how to apply the method to build the bridge between Eclipse Modeling Framework and Microsoft DSL Tools.

P r e l i m i n a r y V e r s i o n With each tool, a given metamodel (e.g., M M X on the figure) may be expressed in terms of the metametamodel of that particular environment. Then, models (e.g., M 1) may be expressed in terms of M M X . The objective of the bridge is therefore twofold:

1. At metamodel-level, the bridge must enable the transformation of any metamodel conforming to metametamodel A into an equivalent metamodel conforming to metametamodel B, and vice versa. For instance, if M M X is initially expressed in terms of metametamodel A, then the bridge must automatically create the version of M M X that conforms to metametamodel B. 2. At model-level, the bridge must enable the transformation of any model defined with Tool A into an equivalent model defined with Tool B, and vice versa. The metamodel of the original model and that of its derived equivalent are themselves equivalent.

The bridge is bidirectional and allows the interchange of models and metamodels in both directions. However, the implementation of the bridge itself must take place inside one of the two environments (in Fig. 2, this bridge is implemented using the environment A) 1 . The main selection criteria is that the selected environment must provide a transformation technology to perform the required adaptations. However, the capabilities of the bridge are independent from the chosen implementation environment.

As seen in Fig. 2, there are four main steps (plus an optional one) involved in the process of creating such a bridge. Each step is represented as a circled number. These steps are:

x (Optional) Metametamodel discovery. All variable-metamodel tools necessarily have a metametamodel, in terms of which metamodels are defined. However, this metametamodel may not be explicitly available. In such a case, it is necessary to discover that metametamodel from the tool API, its storage schema, etc. For instance, metamodels defined with the tool can be analyzed in order to identify the set of concepts and relationships used to express them. These constitute the metametamodel of the tool. When the metametamodel is readily available (e.g., as is the case for EMF and SSM), this step can be skipped. 1 We could also use a third environment as a pivot but presenting the approach in that way adds unnecessary complexity.

P r e l i m i n a r y V e r s i o n conformsTo Legend:

Projection Transformation Metametamodel A Metametamodel B M3 1 MM X MM X Metametamodel B M2 2 4 3 M1 M1 MM X M1 5 A B
Fig. 2. General bridging approach (overview).

y Transcription. This step consists in expressing metametamodel B in terms of metametamodel A (in environment A). This has first to be done manually. However, as a metametamodel conforms to itself, the approach may be bootstrapped and this may be re-generated using the bridge once established.

z Syntactic translation. At this step, the syntactic differences between Tool A and Tool B are solved by transcribing the elements of B within the same technical space of A, i.e., by switching from environment B to A in order to use the same kind of concrete syntax. As seen in Fig. 2, the metamodel in Tool B is re-expressed as an instance of the metametamodel B rewritten within Tool A. Therefore, this is a purely syntactic re-expression we call projection, since the structure of elements of B has not changed.

{ Semantic alignment. At this step, we cannot yet import models of Tool B in Tool A (and vice-versa) since we cannot have more modeling levels in A, according to the OMG metamodeling architecture. Therefore, we need first to express the metamodel of Tool B as a native metamodel in environment A, which conforms to the corresponding metametamodel of A. This implies a semantic adaptation between the metametamodels of A and B, which is actually realized by transformations. These transformations allow to import/export any metamodel between A and B. This step may be realized with the assistance of matching tools or not.

| Data interchange. Once this is done, the previous (semantic alignment) information is used as well to generate the transformations that actually imports models from B to A and vice-versa. Note that complementary projections similar to those of the Syntactic Translation step are also required to allow exchanging models between A and B. This bridge is generic: even if Tool B changes its metamodel, there is no need to modify the bridge since the mappings will automatically support importing B models (with the new metamodel) into Tool A.

P r e l i m i n a r y V e r s i o n

The important characteristics behind the proposed approach are its genericity, extensibility and reusability:

-Genericity because it can be applied on any metamodel and model, independently of the selected environment and considered domain or field of application; -Extensibility because the built transformations and projections can be directly extended in order to target other environments or any software in general, specially given the separation of the syntactic and semantic alignment steps. -Reusability because 1 -these transformations, projections (or at least parts of them) and metamodels can be directly reused as they are for other purposes and 2 -the bridge can be reused by all tools based on the same metametamodel.

Fig. 3 shows the application of this method to our motivating EMF-DSL Tools interoperability example. In this case, the environment A is EMF and the environment B is DSL Tools. EMF has been chosen as the implementation environment because of the several evolved transformation technologies available, such as ATL [START_REF] Jouault | Transforming Models with ATL[END_REF] for model-to-model transformation. Fig. 3 also shows that EMF has an explicit metametamodel named Ecore while DSL Tools has an implicit one we arbitrarly name DSLMeta. As an example, consider a PetriNet modeling tool in EMF (Tool A) and its equivalent in DSL Tools (Tool B). Each of these two tools is based on an explicit PetriNet metamodel, which conforms to its corresponding metametamodel. The goal is to be able to automatically exchange PetriNet models between the PetriNet EMF modeling tool and the similar DSL Tools one. In the next subsections, we provide more details on the step-by-step application of our MDE approach to this concrete example. As we will see, for some steps, it is useful to split them into substeps that improve the modularity of our approach and reduce the complexity of each single step. This depends on the P r e l i m i n a r y V e r s i o n syntactic and semantic distance between the tools to be bridged and it is optional since it is always possible to built the bridge in just the five steps described above.

Metametamodel Discovery

In our scenario, this optional step is required as the metametamodel of DSL Tools is not explicitly specified. There are currently no fully automated solutions for discovering it. Thus, this has to be performed manually by using the metamodel examples we can find, but also the available documentation and APIs.

Transcription

In our case, this step requires defining metametamodel DSLMeta as a metamodel which conforms to metametamodel Ecore in EMF, as shown on Fig. 3. This is a manual step but usually a simple one since many metametamodels share the same basic conceptual elements.

Ecore DSLMeta M3 MM X MM X DSLMeta M2 KM3 XML M1 M1 MM X M1 MM X MM X

EMF DSL Tools

Fig. 4. EMF-DSL Tools metamodel-level bridge (overview).

Syntactic Translation

Then, we need to be able to express our PetriNet metamodel from DSL Tools as a model conforming to this newly defined DSLMeta metamodel in EMF. As shown in Fig. 4 (right), this has been implemented using an intermediate substep to simplify the process. Because the serialization format used by the DSL Tools is XML, we can first automatically inject the content of the XML document storing the PetriNet metamodel (in DSL Tools) into a model which conforms to a standard structural XML metamodel (note that the inverse operation is of course also possible). At this point, our DSL metamodel is already expressed as a EMF model but conforming to the XML metamodel. Therefore, the second step is to define the model transformation that generates the corresponding version of the model that conforms to the DSLMeta metametamodel in EMF created in the previous step. Using XML as a pivot metamodel simplifies the projection of the PetriNet metamodel in EMF.

P r e l i m i n a r y V e r s i o n

Semantic Alignment

The previously projected PetriNet metamodel can be considered as the precise representation of the initial PetriNet metamodel in DSL Tools. However, this metamodel is not yet conforming to Ecore, i.e., it is not a real metamodel from an EMF point of view (in fact, for EMF, this metamodel is regarded as a simple terminal model, an instance of the DSL Tools EMF metamodel) and cannot be used by metamodeling tools using EMF. The objective of this step is to be able to get a native PetriNet metamodel in Ecore from this model and vice-versa, as shown in Fig. 4 (left). Again, this step uses an intermediate representation to reduce the semantic gap. First, this DSLMeta PetriNet metamodel is transformed into a model which conforms to the KM3 metamodel. Aligning DSL Tools and KM3 is easier than directly aligning DSL Tools and EMF. Furthermore, we already have existing KM3-Ecore converters that take the KM3 model and re-expresses it as a native Ecore metamodel, and vice versa.

At the end of this step, we have a metamodel-level bridge that may now be automatically reused to any metamodel specified in DSL Tools in EMF and the other way round.

Data Interchange

Now that we have our PetriNet metamodel available in both the EMF and DSL Tools environments, we want the two associated PetriNet modeling tools to be able to interoperate exchanging PetriNet models. Fig. 5 presents how this has been concretely realized. Similarily to the metamodel-level bridge (i.e., because the serialization format used by the DSL Tools is XML at both levels), the PetriNet sample models in DSL Tools are converted as first XML and then DSLModel models in EMF and vice-versa. The DSLModel metamodel is introduced in order to decouple P r e l i m i n a r y V e r s i o n concrete syntax (i.e., XML), and metamodel-independant abstract syntax. This metamodel represents the graph structure used in DSL Tools independently of any metamodel. This corresponds to the projection phase between the two different environments.

The transformation phase itself is separated into two distinct parts, which makes it fully generic (i.e., independent from the used metamodel). First, the transformation itself is (semi)automatically generated from the alignment information used in the previous step. Then, the transformation is added to the overall transformation chain for effectively building the output terminal model from the source one. Only parts of the transformation that are metamodel-dependant are automatically generated. Metamodel-independant parts are written by a developer once for each bridge. They are then reused for every metamodel to which the bridge is applied. Generated and manually written transformation parts are typically composed by chaining them.

This way, we can apply the generated PetriNet-DSLModel mapping transformations in order to finalize the bridge and interchange PetriNet models (coming from either EMF or DSL Tools).

In this section, our generic MDE approach for tool interoperability has been introduced and directly used on our first motivating example. The next section demonstrates the genericity and applicability of our solution by considering a second example: bridging EMF and SQL Server Modeling.

Bridging Eclipse and SQL Server Modeling

The generic interoperability method presented in the previous section (cf. Section 4) can be applied to make interoperate many different platforms and their corresponding tools. As a second example, we briefly describe in this section how we can use our method to build an EMF-SQL Server Modeling bridge. To do so, we follow again the same steps we considered for the creation of the EMF-DSL Tools bridge. P r e l i m i n a r y V e r s i o n Fig. 6 presents the abstract view of this bridge in this specific case. We consider here MSchema, i.e., the part of the "M" language dedicated to metamodeling (cf. Section 3), as the SSM metametamodel. As the situation is roughly equivalent to the EMF-DSL Tools bridge one, as shown from Fig. 3, we do not provide more insights on this overall view. Fig. 7 gives more concrete details on the metamodel-level bridge. Again, the architecture is roughly the same as in the EMF-DSL Tools bridge: KM3 is used as a pivot metamodel which allows directly reusing the available Ecore-KM3 converters, while the actual mapping between the two metametamodels is realized by the KM3-to-MSchema transformation. The only difference is that, for this bridge, we are not using XML for metamodel/model serialization since the format used by SSM is not XML-based but text-based. The use of the XML metamodel as an intermediate step is thus not required: a textual modeling tool can be directly applied to switch between a textual file and the corresponding metamodel/model, and vice versa. For this purpose, we use the TCS [START_REF] Jouault | TCS: a DSL for the Specification of Textual Concrete Syntaxes in Model Engineering[END_REF] (Textual Concrete Syntax) tool.

Ecore MSchema M3 MM X MM X MSchema M2 KM3 M1 M1 MM X M1 MM X

EMF SSM

Fig. 7. EMF-SSM metamodel-level bridge (overview).

Operational-Level Interoperability

So far, we have focused on the data-interoperability problem. The bridges presented in the previous section enable sharing models among the tools, including the interchange of transformation models, i.e., models that define model transformations between source and target (meta)models. However, the simple exchange of a transformation model is a necessary but not sufficient condition to achieve operational-level interoperability. The additional requirement is that the target tool includes a transformation engine able to process the information contained in the transformation model and execute the corresponding transformation.

In our scenario, operational-level interoperability between Eclipse and Microsoft modeling tools requires creating a new version of the ATL virtual machine (component in charge of executing model-to-model transformations defined us-P r e l i m i n a r y V e r s i o n ing the well-known ATL transformation language [START_REF] Jouault | Transforming Models with ATL[END_REF]) adapted to the Microsoft modeling tools. The ATL virtual machine is currently written in Java and only accepts (meta)models defined using EMF, KMF [START_REF] Jouault | Towards an advanced model-driven engineering toolbox[END_REF] or MDR as modeling frameworks. Therefore, porting the ATL virtual machine implies two different steps:

1. Migrating ATL VM to the .NET platform to facilitate its execution from within the Microsoft tools. It would be possible to directly call the Java ATL VM from .NET but this solution loses in efficiency and elegance, requiring the use of both Java and .NET Framework virtual machines (and exchanging data between them) at the same time. 2. Integrating support for the SSM and DSL Tools frameworks.

The first step has been already completed. Regarding the second step, the virtual machine has been built from the beginning in a layered structure (see Fig. 8) to facilitate its portability. The model adaptation layer decouples the virtual machine's core from the modeling framework used to define the (meta)models. This allows the virtual machine to run on top of new modeling frameworks providing that an adapter for the framework is available. Therefore, adding support for SSM and DSL Tools only requires to create the corresponding adaptors.

Tool Support

Several of the bridges described in the previous sections have been actually implemented (see Fig. 9) and are available from [START_REF]Eclipse-Microsoft Bridges Implementations[END_REF]. As can be seen in the figure, in some cases, bridges concern both the metamodel and model levels, or just one of these two categories. We are working on completing the full set of bridges.

However, we would like to remark that, in fact, it is not necessary to implement all bridges to achieve full interoperability between each pair of tools. Existing bridges can be used, by transitivity, to connect two tools with no direct bridge between them. For instance, even if the corresponding bridge is not implemented, we can interchange metamodels and models between DSL Tools and P r e l i m i n a r y V e r s i o n SSM using EMF as a pivot tool. This is similar to using a metamodel as a pivot between two other metamodels. However, in this case, we use it for bridges, not single transformations. As an example of the use of the bridges, Fig. 10 shows the result of automatically generating, for the DSL Tools, the metamodel and sample model from our PetriNet EMF example (Fig. 1).

Note that this same PetriNet metamodel is also available in SSM format. However, the SSM equivalent sample model (in "M") has not been produced since the direct bridge has not been yet implemented at the model-level. But, as commented before, it could be obtained by transtivity of the other bridges.

P r e l i m i n a r y V e r s i o n

As part of our tool support, we have also released a first version of the ATL Virtual Machine for .NET [START_REF] Amma | NET[END_REF] that allows direct execution of model transformations within the .NET environment.

Conclusions and Future Work

We have presented our approach for tool interoperability, focusing on the most general scenario: interoperability among tools able to handle data (i.e., models) conforming to different metadata (i.e., metamodels). Our method follows a model-driven approach in which the (meta)metamodels of the tools are explicited, aligned and used to (semi)automatically generate the model-to-model transformations that effectively bridge the tools.

Our model-driven view of the problem facilitates the reusability, genericity and extensibility of the bridges in order to cope with the increasing complexity of tool ecosystems. This model-driven view is also especially useful under the current model-driven engineering paradigm where most of the tools already use (meta)models as first-class entities.

There are several directions in which we plan to continue this work. First, we plan to improve our proof of concept by completing the implementation of all bridges between Eclipse and Microsoft modeling tools (including a bridge between the two Microsoft tools themselves) and extending them with full support for operational-level interoperability as well. Second, we would like to improve the automation of the interoperability process by advancing, for instance, in the automatic discovery of metamodels from tool APIs for those tools with no explicit metamodel. Finally, we plan to study different "instantiations" of our generic architecture to see how it can be optimized depending on the specific pair of technical spaces (e.g., XML, grammar-based, modeling-based) of the two tools to bridge.

Fig. 1 .

 1 Fig. 1. Simple PetriNet metamodel in Ecore and corresponding sample model (EMF)

Fig. 3 .

 3 Fig. 3. EMF-DSL Tools conceptual bridge (overview).

Fig. 5 .

 5 Fig. 5. EMF-DSL Tools model-level bridge (overview).

Fig. 6 .

 6 Fig. 6. EMF-SSM theoretical bridge (overview).

Fig. 8 .

 8 Fig. 8. ATL VM structure (overview).

Fig. 9 .

 9 Fig. 9. Existing bridges (overview).

Fig. 10 .

 10 Fig. 10. PetriNet metamodel and sample model in DSL Tools format.

Acknowledgments. The present work has been supported by the IST-FP6 MODELPLEX and the ITEA2 OPEES European projects.


Jean Bézivin

Hugo Brunelière

Jordi Cabot

Guillaume Doux

Frédéric Jouault

Jean-Sébastien Sottet

Model Driven Tool Interoperability in Practice

Keywords: MDE, Tool Interoperability, Metamodel, Model Transformation

Model Driven Engineering (MDE) advocates the use of models, metamodels and model transformations to revisit some of the classical operations in software engineering. MDE has been mostly used with success in forward and reverse engineering (for software development and better maintenance, respectively). Supporting system interoperability is a third important area of applicability for MDE. The particular case of tool interoperability is currently receiving a lot of interest. In this paper, we describe some experiments in this area that have been performed in the context of open source modeling efforts. Taking stock of these achievements, we propose a general framework where various tools are associated to implicit or explicit metamodels. One of the interesting properties of such an organization is that it allows designers starting some software engineering activity with an informal light-weight tool and carrying it out later on in a more complete or formal context. We analyze such situations and discuss the advantages of using MDE to build a general tool interoperability framework.

Introduction

The practices for producing and maintaining software systems are highly dependent on the toolset used. Software engineering is highly tool oriented. Tools are ubiquitous in this context. They implement methods. They can make a conceptual approach concrete. They are the support for roles. They can be called by human or automated actors, possibly from other tools. They can also be incorporated in other tools, allowing transitioning from simple tools to composite tools. They implement services. They define access API's and may encode part of the know-how and good practices.

In the different perspectives that may be taken on the software and development landscape, the tool-centric one is certainly not the less important.

As an example, one old but still popular toolbox is the UNIX system. It is mainly composed of a set of elementary tools named commands. These tools can be P r e l i m i n a r y V e r s i o n chained together and can be composed to build composite tools. Some of these tools have a certain degree of redundancy since the same goal may be achieved with the help of different tools. The UNIX toolbox contains elementary tools like ls, awk or sort as well as sophisticated ones like sccs utilities. Many users use their own knowhow to develop new tools adapted to their concrete software practices.

Similarly, software engineering started by building software in development tools like assemblers, disassemblers, compilers, etc. Since then, the progresses of methodology and technology are paved with successive generations of tools, testifying the various steps of practice innovation. This paper discusses some new possibilities of model-based tools, i.e. tools at least partially based on Model Driven Engineering (MDE) [START_REF] Bézivin | On the Unification Power of Models[END_REF], to improve current tool interoperability challenges. One of the characteristics of these tools is that they usually make use of explicit metamodels. This paper is organized as follows. Section 2 presents the notions of metamodels and tools, and relates them. The issues of tool interoperability are presented in Section 3 while Section 4 discusses lessons learnt, related and forthcoming work. Finally, concluding remarks are given in Section 5.

METAMODELS and TOOLS

Metamodels

A metamodel is a simplified ontology. It is a graph of concepts and relations between these concepts. This is close to a grammar or to an XML schema or to a database schema. A metamodel may be used to discuss with precision a number of situations.

There are a number of languages to write metamodels like MOF, ECORE or KM3. All metamodels expressed in the same language may be easily compared, merged or jointly used in a number of abstract operations. They can also be transformed, including from one language representation to another one.

Each metamodel encodes a consensual agreement. There are standard metamodels like the ones defined by OMG (UML, KDM, SysML, BPMN, etc.). There is also a high number of non standard metamodels, sometimes in open source libraries like the AtlanMod zoos [START_REF]AtlanMod AtlanMod MegaModel Manager[END_REF] containing more than 300 different metamodels in nearly 15 different notations. Some metamodels have a general purpose while others target a specific knowledge domain or software activity.

Tools

A tool is an entity that interfaces between two or more domains; facilitating more effective action of one domain upon the other. The screwdriver, invented in Germany in the late fifteenth century, typically interfaces between the operator's hand and the screw the operator wishes to tighten or untighten. Basic tools are simple machines.

There is a very rich literature on tools and how the sophistication of these tools has accompanied and influenced the evolution of mankind. Usually, the use of a tool P r e l i m i n a r y V e r s i o n supposes some know-how. For example, the operator needs to learn how to apply torque by rotating the handle of the screwdriver with correct positioning of the tip on the screw. Tools are constantly improved to make their usage easier and more efficient, for example electric motor screwdrivers.

A tool may share key functional attributes with one or more other tools. In this case, some tools can substitute for other tools. The Swiss knife is often taken as the symbol of a hypothetical universal tool. Sentences like "One tool does it all" or "All tools can be used as hammers." emphasizes the issues of exchangeability or specialization of tools.

Software Tools

A software tool is a software device run by a computer system and intended to be used by an actor to achieve a given goal in a given context. Any domain of human activity may use software tools, for example house building, airline design, payroll management, differential equation solving, etc. The actor may be a human or an automated agent. Examples of software tools are Catia, Microsoft Excel or Word, Simulink, Modelica, etc.

We may consider most applications found in what is commonly called AppStores to be a reservoir of hundreds of thousands of software tools for different purposes. Smartphones are often considered as containers for a large library of such software tools for agenda scheduling, road finding, music composition, and much more.

Software Development Tools

One particular case of a software tool is a programming tool or a software development tool. Related to that, one may also mention the Software Development Toolkit (SDK) that may be defined as a set of software development tools. A typical software development tool is a compiler, but a general software tool like a text editor may be used non-exclusively for software development.

Modeling and Model-based Tools

Some software development tools are modeling tools [1], i.e., tools specifically intended to produce or manage models. The ATL model transformation language support system or the Rational Rose tool fit in this category. However, we are interested in a different category called model-based tools, i.e., tools that are implemented using MDE principles. There is obviously the possibility of having a model-based modeling tool, and the ATL tool is an interesting example. On the contrary, many modeling tools are completely implemented in Java, without any use of MDE principles, and this does not mean that they are not useful. Of course, an important category of tools are model-based tools that are not modeling tools and sometimes not even software development tools.

P r e l i m i n a r y V e r s i o n From this plain raw list to a map of all the relations between these tools and of the various roles and actors that use them there is a significant distance. However this could show many of the characteristics of the process followed by the team. But the interest of such a brainstorming exercise is to show the diversity and the difficulty to organize these tools in well defined categories. More than that, a list of real world tools like above illustrates the need to cope with a high number of different scenarios, many of them presenting challenging interoperability problems.

An Ideal Model-based Tool

The tool interoperability goal becomes clearer when considering a hypothetical ideal tool and using it as a comparative basis. Even if such a tool does not exist, or even if it is impossible to build, this may be a very useful comparative benchmark. This will allow in particular separating the discussion in two threads: (1) how do ideal tools interoperate and (2) how to interoperate an ideal tool with a common tool. We thus consider an ideal metamodel-based software tool having the following properties:

• It is strongly associated to one or more metamodels (e.g., data, event, state)

• It has been built with the direct use of these metamodels. This means that the metamodel has not been loosely interpreted by humans and then converted in software code. Instead, the metamodel was used as a parameter in the direct generation of the tool. • It is delivered together with the metamodels

• It is delivered with model injectors and extractors

Its various versions are delivered with a metamodel difference P r e l i m i n a r y V e r s i o n 3 Tool Interoperability

General Interoperability

Interoperability to the ability of two or more systems to exchange information and to use the information that has been exchanged [START_REF]IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries[END_REF]. These systems usually have been independently defined or designed. According to the nature of these systems, we have different kinds of interoperability. Typical examples are enterprises, information systems, software component, computer network, software application, combined hardware/software system, digital libraries and many more. The subject of this paper is tool interoperability. Dealing with this subject at an abstract level means that many of the conclusions may also apply to different system interoperability situations like enterprise interoperability.

Tool Interoperability

The "one engineer uses one tool" approach has been quite usual in computer science. It followed the hard specialization of tasks in the software development cycle. The typical example is the programmer using a compiler as his/her main tool. This is quite an interesting example because of the narrow interface of compilers (source input, code output, error output). Of course the programmer has to prepare/modify source programs with a text editor, but the interface between the text editor and the compiler is rather simple. A compiler is usually grammar-based and not metamodel-based, but this makes no major difference conceptually. Some compilers are directly generated from the grammar. But the simple grammar is obviously not sufficient for total generation of the tool. Finally, many different tools may use the same grammar. This generates an obvious interoperability opportunity by using the common grammar as a way to interoperate between different compilers for the same language.

Many additional tasks have been identified for the programmer and these could be supported by different tools. The notion of Integrated Development Environment (IDE) may be considered as a composite tool.

Illustrative projects

This section presents some illustrative projects on Tool interoperability solved by using a model-based tool approach. Lessons learnt when developing these examples are the focus of the next section.

UML to MS Project

One of the initial examples of model transformation was to manipulate UML activity diagrams with the Microsoft Project tool [START_REF] Bezivin | Applying The Basic Principles of Model Engineering to The Field of Process Engineering Upgrade[END_REF]. On the source side, the metamodel used was the relevant part of the official OMG UML metamodel. On the target side, one metamodel had to be defined for the MS Project tool. The input consisted in XMI serialized activity diagrams, while the XMI output of the transformation had to be P r e l i m i n a r y V e r s i o n converted into the XML import format of MS Project. This additional transformation from to MSP/XML is typical of the injectors/extractors used in such situations.

Most of the experiments we have done use unidirectional transformations between Tool A and Tool B . However, once we have such a transformation, the inverse transformation from Tool A to Tool B is generally quite easy to implement. The metamodels can be reused as is, and usually the injectors/extractors and transformations are not complex to adapt manually. One of the authors has implemented the transformation from MS Project to UML activity diagrams in a couple of hours. This allows one to start the blueprint of a process model with MS Project, to tune it, and later if needed, to transform it into a UML activity diagram for insertion in a more stable project.

Version management

The particular case of making two versions of the same tool collaborate is important in theory and practice. Both tools work on similar domains and synchronizing them should not be difficult. However, in practice this is not always so simple. In an experiment [START_REF] Vara | Model Weaving Support for Migrating Software Artifacts from AUTOSAR 2.0 to AUTOSAR 2[END_REF], we considered the AutoSar industrial metamodel (about 5,000 elements), considering that this metamodel could be used by an industrial tool. The problem was to deal with legacy models conforming to the AutoSar 2.0 version and to use them in another tool working with the later defined AutoSar 2.x metamodel. The first step was to perform a matching operation to get a difference of the two metamodels. The difference is the set of additions, deletions and modifications to the first metamodel. This difference, expressed as a model could then be input to a higher order transformation which would generate another concrete transformation that will do the conversion from one version to the next one. This experiment shows how MDE can help making tools versions interoperate in a very regular pattern, when the metamodels of these tools are explicitly available. Of course, if the version difference between models is provided by the tools providers and has not to be computed, this is an important improvement.

Bugzilla to Mantis

The domain of software bug tracking or bug tracing tools is very interesting to study. Only as open source, there are nearly fifty tools that could be used for similar purposes. This is a real problem since many organizations have to use different tools. The experiment has been done in different phases. First metamodels of two typical tools (Bugzilla and Mantis) were defined. Then transformations between these tools were implemented. It then became clear that a pivot metamodel between these two metamodels could be most useful. Looking at the practical usage of bug tracking, we noticed that some companies were using ad-hoc tools like Excel to record and report bugs. We then added a bridge to/from this simple tool to Mantis/Bugzilla through the pivot metamodel. These experiments are reported in [START_REF] Bézivin | Model Engineering Support for Tool Interoperability In[END_REF]. But one additional issue became more apparent: the lack of exact correspondences between some concepts of the different tool domains. The strict transformation approach is not able to provide P r e l i m i n a r y V e r s i o n sufficient flexibility to handle such situations. In [START_REF] Vara | Model Weaving Support for Migrating Software Artifacts from AUTOSAR 2.0 to AUTOSAR 2[END_REF] show how we can establish more abstract correspondences through model weaving to address these issues.

Other examples

Many other experiments have been conducted in model-driven tool interoperability.

Bridges have been established with Office or Open Office tools, for handling general services. Graphical visualization has been implemented by bridges to SVG, to DOT/GraphViz, to GraphML/Prefuse, etc. Very often, when such a bridge is built, it is rapidly reused and sometimes improved. The tabular output was initially handled separately for Excel and HTML. Rapidly a pivot tabular metamodel was however built, allowing submitting tabular presentation data not only to the two aforementioned tools but to other ones as well. We can see the tabular pivot as the definition of an abstract data presentation virtual tool.

A more extensive one year study in an industrial context has been performed in the domain of BRMS (Business Rules Management Systems). The ILOG Rule language and similar tools have been successfully bridged with a number of metamodels, projectors and ATL transformations [START_REF] Del Fabro | Industrial-strenght Rule Interoperability using Model Driven Engineering INRIA research report[END_REF].

One example of tools that have been often targeted is constraint solving engines [START_REF] Chenouard | Rewriting Constraint Models with Metamodels[END_REF]. Long chains of transformations going from various problem statements to these engines have demonstrated the practicality of the approach, and the interest of using pivot metamodels to handle the different fine possibilities of these various types of solvers. Some bridges between model transformation tools are also described in [START_REF] Jouault | On the Architectural Alignment of ATL and QVT[END_REF].

Discussion

Lessons learnt

Methodology for interoperability

One important conclusion that comes out of our preliminary work is the need to develop a methodology supporting tool interoperability. In presence of two tools that need to interoperate, we suggest first to define the data metamodel of each tool, then to build injectors/extractors for the tools, and finally to write the transformations. Each of these steps may be quite complex, and space does not allow for a detailed description in this paper. For the first step, for example, the metamodel may be manually defined from the tool user manual 1 . If there is an XML import/export scheme, this may be used to guide semi-automatically the building of the metamodel.

In some cases the tool may use a concrete textual syntax and the metamodel can be 1 We have successfully experimented "pair modeling" here, a practice similar to "pair programming".

P r e l i m i n a r y V e r s i o n built from the grammar of the language. It is also quite frequent that tool is based on some DB layer like MySQL and the corresponding internal data schema may be used as a first sketch of the metamodel. Sometimes several solutions may be followed and different metamodels may have to be aligned to produce a suitable solution.

Flexible modeling

As discussed in the FlexTools workshops [START_REF]Flexitools2010 ICSE Workshop on Flexible Modeling Tools[END_REF], a common problem is interfacing formal modeling tools and more informal but flexible free-form approaches. Practitioners throughout the software lifecycle are currently forced to choose between them. Whichever they choose, they lose the advantages of the other, with possible frustration, loss of productivity and sometimes of traceability and even quality. In the list of ATL model transformation use cases [START_REF]AtlanMod AtlanMod MegaModel Manager[END_REF], several examples fall in this category. Therefore, we believe our model-based strategy can help in this matter.

Tool services interoperability

Metamodel based tool interoperability can be used in many different situations to build conversion bridges. The first situation is when we have to link two versions of the same tool (AutoSar example). The second situation is when we have two different tools within the same application domain (Bugzilla/Mantis example). But a very important number of cases concern tools that are not in the same domain, and that just provide general service reusability. Two examples of services are data entry and data display. A tool like Excel, for example, may be used for tabular data entry and tabular data display. When we need to have graph visualization (a common practice in MDE), we may use tools like DOT or GraphViz. According to the type of visualization needed, a wide spectrum of services may be implemented by open source or proprietary tools.

Global tool maps

Ideally, in a given context, it should be possible to build a relationship map with all the available tools and all the conversion paths between these tools. The brainstorming list given in section Erreur ! Source du renvoi introuvable. may give an idea of the basis of such a list. We may see a future facility as showing the various possible connections between all the tools used in a given group, and managing the conversions between them. Note that we may get indirect conversion paths between tools by transitivity through a pivot intermediate tool.

Related work

Tool interoperability has been a subject of research for a long time. The dream of being able to plug together tools to achieve interoperability between them has motivated many efforts, based on the fact that these tools have not initially been designed to cooperate. The recognition that the number of tools was high led many investigations to consider a hub or more often a bus to avoid O(N 2 ) point to point

P r e l i m i n a r y V e r s i o n connections between N separate tools. PCTE [START_REF] Del Fabro | Applying generic model management to data mapping[END_REF] is ECMA standard framework for software tools developed in the Esprit programme and defining the way they may access a common hub. Another well known effort is the AD/Cycle lead by IBM in the late 80's [START_REF]IBM AD/Cycle strategy and architecture[END_REF]. These efforts are characteristic of the tool-bus vision. The CDIF (Case Data Interchange Format [START_REF] Bézivin | Model Engineering with CDIF OOPSLA'98[END_REF]) initiative was also very successful in the 90's and many of these ideas were later reused in OMG MOF-based standards. Many efforts in defining graph-based interchange formats for various tools may also be mentioned [START_REF] Sim | ICSE Workshop on Standard Exchange Format (WoSEF)[END_REF]. The work on format interchange is obviously complemented by the work on semantic interoperability [START_REF] Heiler | Semantic interoperability[END_REF].

The notion of virtual tool has been presented in [START_REF] Jouault | Integration by Model-driven Virtual Tools[END_REF]. This work is related and complementary to the present one. The issue addressed in this proposal is to build a virtual tool from a set of concrete tools. The goal is achieved by precise operations on the metamodels associated to the different tools.

Further work

In the 80's, one main argument to support object technology was reusability. Nowadays different other ways to look for reusability are being explored. By opposition to implementation reusability offered by object technology, service technology is providing some form of functionality reusability. This is also one objective of this work. We do not have usually access to the implementation of a tool, but we can have access to the services it exposes, and we can reuse these services, possibly by combining several of them. Our conviction is that to build this reusability on a broad scale, we need to use precise metamodels.

We are planning to develop new experiments in tool interoperability in order to gain understanding on the possibilities and challenges.

Many ideas concerning tool interoperability equally apply to more general situations of system interoperability. For example enterprise interoperability is currently a field were similar techniques could be developed.

Only some characteristics of model driven tool integration have been presented in this position paper. The state of the art in tool integration has yet to be expanded. Previous achievements of bus-based and service-based tool integration have to be more completely analyzed. The additional advantages brought by MDE should also be more thoroughly assessed. Among the key techniques used to achieve tool interoperability, one finds various forms of metamodel alignment. The conditions for this need to be investigated and suggestions made for the proposed approach to scale up.

We have mainly focused this paper on loosely coupled tools, with the help of data metamodels. This study needs to be completed by the study of state and event metamodels for more tightly coupled tools.

One important issue that has not been mentioned here is the need for a practical support to transformation chaining. As has been seen in several occasions, the interchange between two tools may use several intermediary or pivot metamodels.

P r e l i m i n a r y V e r s i o n

This in turn may need some support for transformation typing, but these issues much beyond the scope of the current paper.

Conclusion

We have presented here some pragmatic issues about the possibility to use MDE in tool interoperability situations. We all agree on the importance of tools in the software development landscape. However, we do not yet understand all the characteristics of a tool. Until now tool interconnection has been traditionally handled within the classical "tool bus" vision. The "service vision" may help improving these solutions. The arguments developed in this paper in favor of the "metamodel vision" may still seem a bit premature, but we have checked their relevance and potential on a number of cases. More importantly, this approach seems economically feasible if there are a number of open source libraries of modeling artifacts (metamodels, transformations, projectors) that may be easily reused. The current AtlanMod zoos [START_REF]AtlanMod AtlanMod MegaModel Manager[END_REF] show how this could be implemented in practice.

Acknowledgments

This work has been supported by the IDM++, Lambda and CESAR projects that all contributed different solutions to the tool interoperability experiments. We acknowledge the help of all past and present members of the AtlanMod team. We acknowledge also many discussions with Antonio Vallecillo. The ideas presented here are similar to his "village metaphor" proposal [17].


Vincent Mahé

Hugo Brunelière

Frédéric Jouault

Jean Bézivin

Jean-Pierre Talpin
email: vincent.mahe|jean-pierre.talpin@inria.fr

Model-Driven Interoperability of Dependencies Visualizations

Software tools and corresponding knowledge tend to be collected and packaged into platforms like Eclipse, MathLab or KDE. Their success and usefulness combined with their growing size and complexity rise issues about management of dependencies between their components and between the platform and other applications which rely on its plug-in system and/or provided functionalities. Such problems imply need for dependencies management tools in which visualization is a core feature. As dependencies are also a concern in domains like Object-Oriented Programming or Operating System packaging, we may expect to reuse corresponding works in visualization. But each domain and its related dependencies problem have induced their own hard-coded viewing and browsing tools. In this article we present how we have reuse existing visualization tools for our platform cartography together with our own displays using a Model-Driven Interoperability approach to easily realize bindings btween visualization tools.

Introduction

[CfP keywords]: Visualisation in software engineering (e.g. UML diagrams), Integration of software visualization tools and IDEs, Visualization of software evolution Platforms are a widely used concept we may encounter in domains as distinct as hardware industry, engineering environments or web services. They satisfy same needs: defining an interface to extra pieces, embedding selected services, etc. But their success together with their growing size and complexity rise management issues we try to deal with through a visualization approach. Despite their complexity, those platforms share main features and corresponding issues (e.g. dependencies management) we would like to reach once for all. We should rely on the numerous researchs done on these visualization issues to solve our platform problems. But each existing tool is built onto a specific domain in an independent way using its own data format or even a monolithic P r e l i m i n a r y V e r s i o n application doing reverse engineering, computation and visualization in the same execution thread. We propose models paradigm and tools as a gateway between platforms specific needs and visualization tools. As an additional result, our generic dependency management gives easy binding to dependency tools for any domain which could need them out of platforms world. This paper presents our initial motivation in the section 2. The section 3 presents our visualization tool and its main properties. Our attempts to plug our platform model into existing tools is then explained with the experiments we have done in the section 4. The section 5 discusses about interests and needs of generic visualization tools. We conclude in section 6.

Motivation

In year 2000 the Object Management Group standardization organisation presented its Model Driven Architecture (MDA) initiative [START_REF] Soley | Model Driven Architecture[END_REF], which promotes a separation of software engineering process artifacts between Platform Independent Models (PIM) and Platform Specific Models (PSM) enriched from the previous ones by (automated) inclusion of platform dedicated stuff. They understood platforms as middleware but did not explore the underlying world; platforms were an issue they tried to escape from by modeling applications at a higher (platform-free) level. Since this initiative, the multiplication of platforms has spread and blurred the concept: hardware platforms (as processors: x86, ARM; as all-in-one computers: smartphones, internet appliances), software platforms (as OSes: Windows, MacOSX; as frameworks: Java, Eclipse, OSGi), as sets of tools (Eclipse Modeling, Topcased, MathLab). The large use of platform concept emphasizes its usefulness and gathers needs like handling of components. As actual platforms are larger and larger, platform builders and users need a way to manage them in-the-large. The cartography of platforms and the management it enables are needed for many different platforms (Eclipse, Linux, web services) which do not fit well together. So our works rose some issues we managed on the fly. One of our main needs was a visualization tool for dependencies management.

Once our need was identified we expected to find existing tools for visualization of dependencies because this question has been investigated in many works. As a matter of fact we found plural tools about dependencies with an embedded viewer:

-DepAn [START_REF]DEPendency vizualization and ANalysis tool[END_REF] is a tool for Dependency Analysis of Java programs. It inspects a .jar file and offers many views on the generated data file. -CAP [START_REF]Code Analysis Plugin[END_REF] is a Code Analysis Plug-in for Eclipse. It analysis algorithm is based on Martin works [START_REF] Martin | OO design quality metrics. An analysis of dependencies[END_REF].

-BARRIO [START_REF] Dietrich | Cluster analysis of Java dependency graphs[END_REF] is a cluster analyser for object-oriented programs.

-GUESS [START_REF]The Graph Exploration System[END_REF] is a generic graphs visualizer which accepts GraphML XML format files as input data.

-SHriMP [START_REF] Lintern | Plugging-in visualization: experiences integrating a visualization tool with Eclipse[END_REF] stands for Simple Hierarchical Multi-Perspective. It is both a technique and a software application for exploring software.

-SIV [START_REF] Harel | Visualizing inter-dependencies between scenarios[END_REF] stands for Scenario Inter-dependency Visualization.

-SolidFX [START_REF] Telea | An interactive reverse engineering environment for large-scale C++ code[END_REF] is an integrated reverse-engineering environment for C and C++ code (not tested).

P r e l i m i n a r y V e r s i o n

-STAN is an Eclipse-based STructure ANalysis tool for Java.

-X-Ray [START_REF] Malnati | X-ray-an eclipse plug-in for software visualization[END_REF] is a software visualization plug-in for Eclipse.

But those tools suffer some lacks and rigidities that disqualify them for our purpose relying on platforms instead of OO source code: some visualization tools target a specific domain like Java packages or Object-oriented typing and inheritance. Another big issue is about their hard-coded relation to their subject (Java source code) which forbiddes a reuse in other domains. As our needs concern deployement features or underlying plug-ins relationships, those tools can not be used and we must reinvent the wheel once again.

These obstacles emphasize the need of a generic approach of visualization in order to capitalize the knowledge about dependencies viewing and offer its features and abilities to all domains which are facing dependencies issues. Such an independant tool will benefit of every effort and advance in the visualization domain with ability to apply them on all customer application domains.

Model-Driven Approach

As seen previously, dependencies management is a recurrent problem in software engineering and requires visualization to help. Many tools have been develop to visualize corresponding data relationships. Despite those tools are dedicated to a specific domain, we would like to reuse their main functionalities to display our platform-related dependencies. To do such a reuse, we need to interoperate our platform data and those tools in an easy way. The Model-Driven Engineering (MDE) gives us the way to do that.

MDE is a software engineering approach considering models as first-class entities, with a strong underlying conformity of those models to metamodels (models defining the syntax of dedicated languages). Those metamodels can be multi-purpose like the Unified Modeling Language (UML), or dedicated to a specific application field (they are called Domain Specific Modeling Languages, or DSMLs). Given this conformity, models can be processed with transformations or computed in order to verify some properties on them. MDE uses models as first class entities with metamodels as sets of type definitions.

First we present our model-driven representation of platforms. Then we detail the generic dependencies visualization tool we build on it.

Megamodeling and Cartography

Megamodeling is a concept of Model-Driven Engineering (MDE) which goal is to provide over-modeling of MDE artefacts like models, metamodels, transformations that software engineers can produce when working on a given application domain or the whole company information system.

The AtlanMod MegaModeling Management (AM3) is a metamodel and dedicated tools to model and manage complex sets of (not only MDE) artifacts in a generic way. We use its metamodel (see figure 1) as a fondation for our cartography of Eclipse-like platforms.

P r e l i m i n a r y V e r s i o n AM3 is a generic model-driven manager but our need to specifically manage platforms implies deeper concepts like versionning or tools. The corresponding answer is a more specific metamodel which inherits the AM3 metamodel and specializes some of its concepts. It gives the Platform metamodel which types inherit from AM3 types.

Eclipse platform offers its versatility services through a plug-in mecanism which relies on OSGi standard (on its Eclipse implementation which is named Equinox). As OSGi concepts are more precise and restrictive than equivalent concepts in AM3 or Platform metamodels, we design a new wrapping OSGi metamodel which inherits from them.

The platforms under examination also include packaging (like the Eclipse P2 features) and modeling environment (defined in the Global Modeling Managment GMM metamodel) so our complete Cartography metamodel is a hierarchy of metamodels which redefine the most generic ones (see figure 2). they include modeling tools), taking full benefit of underlying concepts and corresponding types without Eclipse specificities.

Dependencies visualization

One of our main concerns facing software application platforms like Eclipse is the issues about dependencies between their components. One answer to this problem is a visualization displaying those dependencies in a graphical way.

Our hierarchy of metamodels from the most generic to the most specialized offers the capacity for specialized types inheriting from a generic type to be compatible with model-based tools built upon this generic type. We illustrate the benefits of this principle on the dependencies.

Relationship & DirectedRelationship concepts The AM3 metamodel includes a notion which is close to dependency: the DirectedRelationship type (defined upon the more generic Relationship type). It relies one or multiple source Entity(ies) to one or multiple target Entity(ies) (see figure 1).

DirectedRelationship extraction An AM3toGraphML model-to-model transformation has been written in ATL language to take any AM3 (compatible) model and extract all its DirectedRelationship and related Entity elements. It generates the corresponding graph edges and nodes in a model which conforms to the GraphML [START_REF]The GraphML File Format[END_REF] metamodel. When a source or a target of the relationship lacks (no source or no target), it creates the corresponding node with an error tag and the lack information is added to the node label: The resulting output is a GraphML model (conforming to the GraphML metamodel) which is transformed in the corresponding textual XML file (with the GraphML syntax) using the ATL XML extractor.

The ATL environment includes an extractor which generates an XML textual file corresponding to the XML model. GraphML2XML model-to-model transformation and XML extractor are generic tools made in a previous project.

The scheme of the whole model-driven chain is presented in figure 3. In the next section we demonstrate the easyness of this model-driven approach to interoperate tools by displaying DepAn data in the SIV tool through our cartography tools and concepts.

Model-Driven Interoperability of visualizations

As we have seen in previous section, any kind of dependency which could be modeled as an AM3 DirectedRelationship type can then be passed to our visualization tool. We will use this property to bridge our Cartography and some existing dependencies visualization tools. As such an approach uses models and their advanced properties in order to realize the corresponding gateways, it is called Model-Driven Interoperability (MDI).

What is Model-Driven Interoperability?

MDI is the third trend of concepts and solutions emerging from Model-Driven Engineering (MDE) as presented in section 3:

1. The first applications of MDE focused on code generation. The goal was to obtain final software artefact from design models. 2. A second generation of MDE techniques was concern by reverse engineering of existing systems. The purpose was to build models from software artefacts in order to use model-driven approaches on them. 3. A third trend is upcoming in MDE which uses model-driven approaches to build gateways between existing software applications. As exposed by Bézivin et alii [START_REF] Bézivin | Model engineering support for tool interoperability[END_REF], it relies on model transformations to transfer informations from a technical world into a distinct other world. MDE ability of tooling a given domain is used to write tools which:

extract models of the emitter data transform them in receiver equivalent models translate received models in the receiver kind of data A strong impact of Model-Driven Interoperability is the fact that it builds tools which automate data transfers between the two technical distinct domain applications. The bridges can be complex but their use is clear and could be easily integrated into the graphical user interface of the interlinked applications.

We will use this approach in order to realize bridges between existing dependencies visualization tools with the AM3 metamodel as a central root. A first gateway will enable export of our dependencies to the SIV tool. A second set of tools will be made in order to import DepAn visualizer data into our AM3 dependencies tool. The interest of using AM3 as a central root will then be demonstrated by easily realizing a complete chain between DepAn and SIV tools using previous bridges together.

P r e l i m i n a r y V e r s i o n

Display our data into an existing tool: Cartography to SIV

The goal is to export our Cartography dependencies to the SIV tool in order to take advantage of its existing visualization features [START_REF] Harel | Visualizing inter-dependencies between scenarios[END_REF].

As SIV tool use GraphML XML syntax as input, the chain of transformations between Cartography data and SIV tool is designed like the one which export AM3 relationships to our generic visualization tool (see section 3.2). The only change is the first step which is now realized by the AM3toSIV transformation: it takes an AM3 (compatible) model as input and generates a SIV model which is a dedicated GraphML model with SIV specific tags (k0, k1, k2, k3).

The scheme of this Model-driven chain is the same as the one presented in figure 3 The resulting GraphML (with SIV data) is transformed in a XML model and then extracted in the corresponding XML textual file which is opened and displayed by SIV application. Figure 5 is a sample of our plug-ins dependencies displayed in SIV viewer.

Import data from an existing tool: DepAn to AM3

The goal is to build a bridge from an existing dependencies tool to our generic AM3 metamodel and tools. The choosen DepAn tool could then be taken as input of our dependencies visualization tool.

The DepAn is a direct manipulation tool for visualization, analysis and refactoring of dependencies in the Eclipse environment (see figure 6 for a sample of its viewer). It includes a dependency discovery tool for Java applications which parse the .java files of a given directory (and all Java packages sub-directories) and generates the corresponding dependencies informations. The tool has its own XML file format with the .dpang extension.

We have to get data from DepAn files in order to visualize them. To reach this goal we built the Model-driven process below (similar to previous export chains but inverted):

P r e l i m i n a r y V e r s i o n As AM3 metamodel is a generic one, its types are mainly abstract. In order to process the DepAn tool data as AM3 elements, we defined a DepAnAM3 metamodel which types inherits from AM3 ones. Our goal is to display dependencies so we only use AM3 identifiers as data into the types (here JavaType inherits from Entity and uses its id and identifier attributes to store its name).

The transformation from DepAn effective model to the AM3 compatible model is a simple one-to-one translation.

Visualization The resulting AM3 compatible model can be process in our visualization tool chain. Figure 8 is a sample of the DepAn javascript library dependencies displayed in our viewer. Using the DepAn-to-AM3 chain and then the AM3-to-SIV chain as-is, we can display data from the DepAn analysis tool into the SIV tool. Figure 10 is a sample of the DepAn javascript library dependencies displayed in SIV viewer. We have seen the ability of Model-Driven Engineering to deal with many problems and requirements like interoperability and genericity in a simpler way than previous paradigms. The new flexibility of the MDI approach answers some of the issues a technical domain like visualization may encounter. Given this, it opens interesting paths the research on dependencies visualization may now explore.

Discussion -separation of concerns

Visualization can help managing dependencies but existing viewers are dedicated to a specific domain (e.g. Java classes). Our approach proposes Model-Driven Interoperability (MDI) to transfer data from one tool to another one with further features. As the central metamodel is generic, this approach is domain-agnostic and gives an access to tools which have been design originally for different concepts.

Previously, tools concerned separate domains and could not share any data. Each approach was rewriting the visualization concepts others had explored because they P r e l i m i n a r y V e r s i o n

were not reusable. Using resources for that redoing work, the progresses were only marginal. Now we have a way to pass dependencies data to a visualizer which can be domainagnostic. Such an independent tool could make easier all visualization enhancements and research relative to dependency problems however are the concerned domains. Ways of presenting dependencies (both in hierarchical and flat forms) as well as userfriendly navigation between them remain open subjects which could be investigated for themselves without specific domains mind-focus.

Conclusion

We investigate in this paper a more flexible way for interconnecting visualization tools. For this purpose, we propose a binding tools chain relying on the recent Model-Driven Interoperability approach.

This paper brings a domain-agnostic solution which opens perspectives about a generic approach of dependencies problem. Using MDI approach could drive to enlarged experiments and sharing of knowledge about visualization specialized concepts.

Fig. 1 .

 1 Fig. 1. AM3 Core metamodel (subset)

Fig. 2 .

 2 Fig. 2. Cartography hierarchy of metamodels

5 edges 9 t h e n thisModule . createLackingNode ( 10 ' 11 e l s e 12 thisModule.(

 59101112 : d i s t i n c t GraphML ! Edge f o r e a c h ( pair i n 6 thisModule . STPairs ( dr ) ) ( 7 id <dr . __id , 8 source <-i f ( pair . source = OclUndefined ) source lacking for ' + dr . __id ) NodefromEntity ( pair . source ) 13 e n d i f , 14 target <-i f ( pair . target = OclUndefined ) 15 t h e n thisModule . createLackingNode ( 16 'target lacking for ' + dr . __id ) s . sourceOf->size ( ) > 0 27 or s . targetOf->size ( ) > 0 ) 28 t o 29 node : GraphML ! Node ( P r e l i m i n a r y V e r s i o n id <s . identifier . value , 31 datas <-S e q u e n c e { 32 thisModule . createData ( 'label' , 33 s . identifier . value ) , 34 thisModule . createData ( 'error' , '' ) } , 35 graph <-thisModule . graph 36 ) 37 }

Fig. 3 .

 3 Fig. 3. AM3 to viewer bridge

Fig. 4 .

 4 Fig. 4. A sample of our dependencies visualizer P r e l i m i n a r y V e r s i o n

Fig. 5 .

 5 Fig. 5. Cartography plug-ins dependencies in SIV

Fig. 6 .

 6 Fig. 6. A DepAn view of its javascript library

Fig. 7 .1 r u l e Root { 2 from 3 r : XML ! Root ( 4 r 8 root : DepAn ! Root ( 9 elements 10 ' 11 -

 7234891011 Fig. 7. DepAn to AM3 bridge

Fig. 8 .

 8 Fig. 8. DepAn dependencies in AM3 visualizer

Fig. 9 .

 9 Fig. 9. Cartography to SIV bridge

Fig. 10 .

 10 Fig. 10. DepAn dependencies in SIV

Acknowledgements The present work is being supported by the CESAR European ARTEMISJU project and the French ANR IDM++ project, and relies on the AM3 tooling developed within the MODELPLEX European IST FP6 research project.


Hugo Bruneliere

Frédéric Jordi Cabot

Jouault Atlanmod

Frédéric Madiot
email: fmadiot@mia-software.com

MoDisco: A Generic And Extensible Framework For Model Driven Reverse Engineering

Keywords: D.2.7 [Distribution, Maintenance, and Enhancement]: Restructuring, reverse engineering, and reengineering, Documentation, Portability. D.2.13 [Reusable Software]: Domain Engineering, Reuse models Management, Measurement, Documentation, Design, Experimentation, Standardization, Languages

Nowadays, almost all companies, independently of their size and type of activity, are facing the problematic of having to manage, maintain or even replace their legacy systems. Many times, the first problem they need to solve is to really understand what are the functionalities, architecture, data, etc of all these often huge legacy applications. As a consequence, reverse engineering still remains a major challenge for software engineering today. This paper introduces MoDisco, a generic and extensible open source reverse engineering solution. MoDisco intensively uses MDE principles and techniques to improve existing approaches for reverse engineering.

INTRODUCTION

Nowadays, many companies depend on a huge amount of heterogeneous legacy systems. Due to the critical importance of these legacy systems and the high cost of replacing them through modernization/migration processes, most of them are still heavily used today in production, limiting the benefits these companies could obtain from applying newer technologies and frameworks in their information systems. Situation gets worse when considering the current fast pace of evolution of technologies which implies that developed applications become rapidly obsolete.

As a consequence, the ability of quickly reengineering existing systems is still a major problem in software engineering, More specifically, the major challenge is to be able to discover and understand the functionalities, architecture, data, etc of the legacy systems and reverse engineer them into a meaningful representation that can be later on manipulated and reimplemented. The current growing adoption of Model Driven Engineering (MDE) principles and techniques, which generally consider models as first class entities in all processes, offers concrete opportunities for getting the general benefits of MDE when designing new reverse engineering solutions. Contrary to many development tools which are often specialized on generating UML models from a specific technology and viceversa (e.g. Eclipse JDT for Java [1], Visual Studio for .NET [START_REF]Microsoft Visual Studio[END_REF]), the idea is to provide generic support for different target metamodels/formats (i.e. not only UML) and extensibility capabilities to other technologies (XML, SQL, COBOL, etc).

The MoDisco open source project [START_REF] Modisco | From "Information Systems Transformation: Architecture-Driven Modernization Case Studies[END_REF] fills this gap by providing a generic and extensible MDE framework dedicated to reverse engineering. First, Section 2 generally describes what is Model Driven Reverse Engineering (MDRE) in MoDisco: the application of MDE in the context of reverse engineering. Then, Section 3 presents the MoDisco project as a concrete implementation. Finally, Section 4 concludes the paper.

MODISCO MODEL DRIVEN REVERSE ENGINEERING APPROACH

The main issue in reverse engineering comes from the heterogeneity of the legacy applications to be considered, contrary to MDE where data is uniformly represented as models. Thus, Model Driven Reverse Engineering (MDRE) is about switching from the heterogeneous world of implementation technologies to the homogeneous world of models. The overall idea is to retrieve one or several models from a given system, depending on the needed viewpoints, and then to work directly on these models.

Figure 1. The two phases ("discovery" and "understanding")

When the system to be reverse engineered is represented as model(s), we are then more easily able to: 1) (re)use generic metamodels and related transformations to handle it and perform the required computations; 2) extend the support to several different kinds of technology (or tool) as both inputs and outputs of the reverse engineering process. As shown in Figure 1, we have identified two systematic consecutive phases for MDRE: "Model Discovery" and "Model Understanding".

Model Discovery

This is the initial step of every MDRE process: it consists in obtaining a model that represents a view on the legacy system (or at least parts of it) from its source code, raw data, available documentation, etc. This model provides a uniform representation of the system, which conforms to a given metamodel expressing the chosen viewpoint. This metamodel can be technology-specific or more generic, according to the expressed needs. The actual building of the model is realized thanks to a software component called "discoverer" and is always guided by the metamodel. A discoverer can have various and varied natures depending on the type of system to be reverse engineer. It can be either fully hardcoded or (preferably) partially generated (e.g. using model transformations) thanks to the metamodel.

Obviously, in real cases, several models are sometimes necessary to fully reverse engineer a given system. This often involves the use of several different discoverers, based on distinct metamodels, which can be later combined to get a unified view.

Model Understanding

This is the second phase of a MDRE process: once we have the legacy system represented as models, these models can be exploited to effectively achieve the targeted reverse engineering scenario which can be retro-documentation, metrics computation, quality analysis, refactoring, code generation, etc.

During this phase, the content of these models is analyzed and computed, in particular (re)using (generic) model transformations or chains of transformations each time possible, until we obtain the final desired representations/data (i.e. source code, documentation, structured data, etc) of/on the system. Several intermediate representations, i.e. models and corresponding metamodels, are usually necessary during the process before reaching the targeted objective. Of course this process (or at least parts of it) can often be largely automated for some common already identified scenarios, and then specialized in the context of more specific use cases.

THE MODISCO ECLIPSE PROJECT

MoDisco has been implemented as an Eclipse open source project which provides an extensible and customizable MDRE framework to develop model-driven tools supporting different reverse engineering scenarios such as legacy migration or modernization, quality assurance, retro-documentation, etc.

The goal of MoDisco is to offer an open source generic and extensible MDRE framework, as shown by Figure 2. Considering as inputs all kinds of possible legacy artifact (e.g. source code, databases, configuration files, documentation, etc), MoDisco aims at providing the required capabilities for creating models and allowing there handling, analysis and computation. As outputs, the framework targets the production of different types of artifact depending on the selected reverse engineering objective(s) (e.g. source code, data, metrics, visualizations, documentation, etc).

Initially created as an experimental research framework by the AtlanMod Team (EMN & INRIA), the project has now evolved to an industrialized solution thanks to our collaboration with the MIA-Software company. This active joint work has resulted in an efficient and usable set of tools for the discovery, query and manipulation of reverse engineered software models.

Figure 2. The MoDisco MDRE Framework

MoDisco is now fitted with generic and customizable core components such as a model browser (for large models), a model extension and customization mechanism, a model query manager, a discoverer manager and associated workflow, and some metrics visualization facilities. It also provides and uses concrete implementations of two OMG standard metamodels: Knowledge Discovery Metamodel (KDM) and Software Metrics Metamodel (SMM), which are both generic (technology-independent) metamodels. Moreover, it also offers extended technologyspecific support for Java reverse engineering (including a full Java metamodel, corresponding discoverer and transformation to KDM) and XML reverse engineering (for some JEE framework configuration files such as Struts or Hibernate ones).

CONCLUSION

MoDisco, as a generic and extensible framework dedicated to MDRE, is a concrete proof that MDE principles and techniques can be efficiently applied in the context of important and complex domains such as reverse engineering. Moreover, as an Eclipse open source project, it shows an example of a successful joint effort between a research team and a technology provider (i.e. company) which results in the emergence of an interesting project and associated growing community.

In addition to the effective use of the MoDisco framework for new experimentations on various MDRE topics, its core components may be enhanced and the support for other implementation technologies such as C/C++, C# (.NET) or COBOL may also be developed as extensions for potential industrial applications.

ACKNOWLEDGMENTS

This work has been initially supported by the ModelPlex European integrated project FP6-IP 034081 [4].