**MDI**

Integration (from the Latin integer, meaning whole or entire) generally means combining parts so that they work together or form a whole. In information technology, there are several common usages:

- Integration during product development is a process in which separately produced components or subsystems are combined and problems in their interactions are addressed.
- Integration is an activity by companies that specialize in bringing different manufacturers’ products together into a smoothly working system.

(from WhatIs def.)

**Integrate**

- Make working together, in a whole corresponding to a precise objective, elements that were not initially designed to achieve this objective.

**Exemple:**

- Enterprise Application Integration (EAI)
- The process of adapting a system to make applications work together when they would otherwise be incompatible.

(from Dictionary Of Database And Related Technology)

**System Integration**

- system integration: The progressive linking and testing of system components to merge their functional and technical characteristics into a comprehensive, interoperable system.
- Note: Integration of data systems allows data existing on disparate systems to be shared or accessed across functional or system boundaries.

**Data Integration**

*A broad spectrum of data is available on the Web in distinct heterogeneous sources, stored under different formats. As the number of systems that utilize this data grows, the importance of data conversion mechanisms increases greatly… A key observation is that, often, the application programs used by organizations can only handle data of a specific format… To enable a specific tool to manipulate data coming from various sources, a translation phase must take place…The naive way to translate data from one format to another is writing a specific program for each translation task… A sound solution for a data integration task requires a clean abstraction of the different formats in which data are stored, and means for specifying the correspondences between data in different worlds and for translating data from one world to another.*

Serge Abiteboul & al.

Tools for data translation and integration

Data engineering Vol. 22,N.1, march 1999.

**Interoperability (def.)**

**The goal of Integration**

The goal of integrating two systems Sa and Sb is not always to replace these two systems by an equivalent ssytem Sc. Very often it is to keep these ssytems as is, but to add another communication system between them.

**Two steps solution to integration: MDI**

Interoperability and Integration are issues covered by computer science since the beginning. The main question is what is MDE bringing to the field.

The idea is that with models we are able to apply a two-step integration process. In the first step, heterogeneous systems are represented by homogeneous models (possibly conforming to different metamodels). In the second step, these models may be interoperated by model transformations.

**Language (Metamodel) Driven Integration**

The general method to solve interoperability problems between two heterogeneous systems *Sa *and *Sb *is thus becoming quite clear. Instead of considering each such problem as an *ad hoc* problem, we may follow a general method. For each system, we consider a metamodel capturing the nature of the heterogeneity we want to resolve. Assimilating each system to a model conforming to a specific metamodel allows us to solve a first level of interoperability (probably the most difficult). Then the remaining alignment between the two models is solved by classical exogeneous model transformaions (i.e. transformations between models conforming to different metamodels). This two step process may be applied to virtually any heterogeneous ssytem integration problem.

**General Model Driven Integration method**

If this two-steps method for solving integration problems is becoming clearer, a lot of difficulties lie ahead. How to define the metamodels, how to define the two categories of transformations, etc.

In particular, the *system to model *and the *model to system *transformations are much more difficult to define than the *model to model *transformations. The reason is that they essentially depend on the nature of the systems and of their deep characteristics. We must perform an analysis of the real nature of the systems and, according to the result, use different sets of solutions. For example, the systems to be integrated may be:

- Source Code
- XML
- Data Bases
- Raw data
- Business sytems
- Platform
- Tool
- Enterprise
- Requirements
- Static systems
- Dynamic systems
- etc.

Let us take for example the first situation which is quite typical in the case of software modernization. We know that in this situation the source code conforms to a given grammar. Thus, with these kinds of systems, we have to align a grammar and a metamodel. Seems simple, but only this simple step is quite complex. In the Eclipse system, solutions like *XText *or *TCS *have been defined to achieve this particular goal. In simple situations of model to system transformations, we could even use proprietary or standard so-called *model to text *transformations.

As we see, each situation has to be independently analysed and, if possible, generic tools should be used. In the previously defined problem, we have assumed that the grammar describing the source code is readily available. But even this simple hypothesis is not always verified. Sometimes one would have to build the precise grammar before starting to align the grammar and the metamodel.