This project has been archived.

Model Driven Development Integration

This Eclipse project proposal (refer to the Eclipse Development Process Document) is posted to declare the intent and scope of a Technology PMC Project called the Model Driven Development integration project (MDDi). In addition, this proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and join the project. Please send all feedback to


Model Driven Development (MDD) is increasingly gaining the attention of both industry and research communities. MDD stresses the use of models in the software development life cycle and argues automation via model execution, model transformation and code generation techniques. The OMG is promoting a model-driven approach for software development through its Model Driven Architecture (MDA™) initiative and its supporting standards, such as UML, MOF and QVT. Model Driven Development is the specific application of MDA to software development.

The Eclipse MDDi project is dedicated to the realization of a platform offering the integration facilities needed for applying a MDD approach. This project will produce extensible frameworks and exemplary tools, designed to support various modeling languages (UML, Domain-Specific Languages) and methodologies. The MDDi platform will provide the ability to integrate modeling tools, as well as tools supporting other technological spaces, to create a fully customizable MDD environment.

Project outline


The Eclipse platform is an excellent basis for building and integrating development tools. The MDDi project aims at extending it to enable an additional level of integration for Model Driven Development. It will make available an extensible MDD platform, based on frameworks dedicated to integration of modeling technologies and their supporting tools. The platform will provide a foundation that can be leveraged and extended for the development of future modeling environments, whether they are open-source or commercial.

The MDDi project will ensure integration of services designed for the platform as well as external tools. Eclipse Modeling Framework (EMF)-based tools are good candidates, although other modeling tools, including those supporting other technological spaces, can be considered as well. Other technological spaces such as XML or graph transformation provide solution to MDD issues. For example, the space of formal technologies provides a number of good practices and tools to validate models. The problem is that these technological spaces rely on heterogeneous support tools that usually need to be manually or programmatically linked using specific bridges. The MDDi project will address this issue in the context of MDD.

Figure 1: An instance of a MDD environment based on MDDi.

Integration of modeling technologies is not trivial to achieve, although standard languages and exchange formats (such as XMI) already exist. As illustrated on Figure 1, one has to deal with different languages (standard or proprietary, general-purpose or domain-specific), as well as different tools and their related limitations (interoperability constraints, compliance to standards, deployment…).

In that context, three different levels of integration can be considered:

  • A technological integration level – ensures the interoperability of tools providing model-oriented services, but also provide connectivity capabilities to other non-modeling tools (e.g. requirement tool, formal validation), provided they can be adapted to be driven by meta-models. It allows tools supporting a common execution model to be compatible.

  • A semantics integration level – ensures the complete description of languages, as well as interchange mechanisms to ease comparison and translation of these semantics between tools. Explicitly mapping the semantics used by tools is a requirement in order to support fully executable models.

  • A methodological integration level – provides extension and customization capabilities to support an unbound number of development practices based on modeling languages and model-driven methodologies.

The end goal is to allow methodology experts to design modeling languages and development processes, and then to integrate existing tools (or build new ones) to provide a dedicated supporting environment. Application developers can then use the platform tailored according to the expert’s specifications for performing modeling tasks. The platform developed within MDDi will be therefore an integrated environment with modeling and meta-modeling capabilities, where MDD principles apply at both levels.

Example user scenario

Why would a developer want to use the facilities provided by the MDDi project? Because different tools used in the same development cycle can rely on different meta-models and models of execution. Moreover, some services (validation, transformation…) may be needed but not available in the modeling tool currently used. Consider this scenario to be performed by a developer:

  1. Model the structure of a system. The developer uses a UML modeler, and in particular class diagrams.

  2. Model the behavior of the same system. The developer uses a particular kind of Petri nets within a dedicated tool. (A Petri net tool will have a meta-model that is clearly different from that of UML.)

  3. Check consistency between the two models built at Step 1 and Step 2.

  4. Generate code for the whole system from both modeled parts.

This scenario uses different tools with different underlying conceptual and semantic models. Putting them together is the essence of model integration. This is just the simplest of scenarios. Step 4 could be replaced by a transformation into another model, for example, and there are many elaborations of this.

At the next level of abstraction up, we need a way to define precisely what is in a given modeling language easily. If tool support is required for domain specific language, a solution is to use an existing UML modeler and to map this language onto the UML meta model. This is normally performed by a profile, and there needs to be tools to define them easily. With those profiles, we can also enable user-defined concrete languages. This allows us to integrate existing tools and tools with specialized languages.

Specification of a set of tools and how they interact implies a development process. We also need the ability to examine existing tools and decide how well they fit, and make explicit the process. Orchestrating an automated development process is important, but we do not plan to build support for this as a part of the core proposal.


The MDDi project makes available the core frameworks and services providing modeling integration facilities on top of Eclipse. The project will be initially broken down into two main components enabling technological and semantics integration.


ModelBus will enable transparent interaction between model-aware tools. It will allow end users to easily assemble heterogeneous tools, and let them interoperate without having any direct knowledge of the specifics of other tools. ModelBus will take advantage of XMI, EMF, and protocols such as SOAP from the W3C.

ModelBus can be compared to a middleware as it offers facilities for managing modeling services interoperability. The particularity of ModelBus is that it is dedicated to models. It mainly offers facilities at the model layer (M1 in the four layers architecture). It has the charge of model representation (including translation of XMI versions), and model transmission (based on local method invocation or SOAP messages). The ModelBus architecture is composed of three high-level components: Adapter, NotificationService and Registry. Those components offer added value to tools that want to consume or provide modeling services. They fully rely on the Eclipse platform and extend it for managing modeling service interoperability.

ModelBus provides a generic infrastructure that needs to be extended by tool-specific adapters. When a tool that wants to consume or provide modeling services, it only has to interact with its corresponding adapter plugged in the bus. A tool provider (or an integrator) who wants a tool to be connectable to ModelBus will therefore create a related adapter using the ModelBus toolkit, which offers added value for extending the basic Adapter component. Adapters are deployed then manually configured and linked to the tool. The end user is able to use them thanks to the Adapter component API.

Semantic binding

In order to support model execution interoperability requirements, it is necessary to address the question of interchange of the semantic aspects of meta-model artifacts. That is, the exchange of execution semantics data. The MDDi project will meet this requirement by supporting the negotiation of a common meta-model to be used when exchanging semantic data between co-operating tools (e.g. a UML modeler and a Petri nets tool). This negotiation is based on services registered by tools on the ModelBus and can be easily automated.

In the case where no matching meta-model can be found then the user should be able to define his own mapping from/to a default meta-model used as a pivot. The OMG QVT standard will be used to describe such a mapping. The default meta-model is still to be defined but the UML 2.0 standard appears to be a good candidate for the exchange of execution semantics data, as it is extensible (thanks to profiles) and comes with an action language, which can be used to express the semantic part of the underlying modeling languages used by tools.

The Semantic binding component implemented on top of ModelBus will therefore provide:

  • a common interchange meta-model enabling a complete description of modeling languages semantics,
  • a dedicated meta-model negotiation service,
  • a tool to ease the description of user-defined "QVT mappings" between meta-models.

The Profile Design tool and the Action Semantics Modeling tool will be provided as initial contributions addressing the issue of describing precisely modeling languages.

Exemplary tools

The exemplary tools listed below will be also developed as part of the project to validate the platform components. The project especially needs a sufficient number of adapters to ensure a successful adoption. We will provide an initial set of adapters for several modeling tools and we will also propose additional ones depending on our resources and what the Eclipse community needs. A generic client for the ModelBus will be made available as well; it will provide an Eclipse Menu for consuming modeling service connected to the ModelBus.

  • ModelBus adapters (ATL, EMF, MOF, UML2…),
  • ModelBus generic client,
  • Others…

Relationships with other Eclipse projects

The MDDi project aims at providing, in collaboration with GMF, GMT and other future projects, a comprehensive approach to MDD in the Eclipse Technology project. MDDi will make available integration capabilities for the tools developed as part of these projects and will provide complementary technologies (e.g. action semantics modeling). MDDi is also related to other Eclipse Tool projects such as EMF. Detailed relationships are presented below:

  • Application Lifecycle Integration and Interoperability Framework (ALMIIF) is a project that addresses the integration and interoperability of existing tools covering the application lifecycle. Overlaps with the ALMIIF proposal are currently being investigated.

  • Eclipse Modeling Framework (EMF) is the reference framework in the Eclipse environment for defining and generating model repositories based on meta-models. The MDDi platform will fully support EMF-based editors and allow model repositories to be plugged in ModelBus.

  • Graphical Modeling Framework (GMF) aims at enhancing the editors generated by EMF to support graphical editing. We will support any GMF-based editors. The "tool generation" feature of GMF provides an exciting opportunity to automatically include the MDDi-provided integration capability as part of what gets generated. MDDi will provide those tools with a) the ability to integrate with other tools through services and events, and b) the ability to be customized (e.g. using wizards) to support specific development tasks/processes.

  • Generative Model Transformer (GMT) consists of a set of research prototypes dedicated to model-driven software development. It provides, among others, model weavers and transformation engines that will be plugged onto the MDDi platform to provide modeling services. It is felt that there is no overlap between the MDDi and GMT project, as MDDi focuses on technology integration aspects. An adapter to connect the ATL transformation engine to the MDDi platform will be especially provided.

  • OMELET provides a framework for integrating models and model transformations. This project has demonstrated the ability to build upon a set of transformations and the technological integration aspects of MDDi may have some overlap with it. A possible integration of the OMELET project’s work within MDDi will be evaluated to benefit from the lessons learned.

Tools from other Eclipse projects such as UML2, Data Tools, Web Tools and XSD are good candidates for integration in the MDDi platform as well. We plan to evaluate existing components and reuse them every time it is possible and it meets our needs.

Development plan

A roadmap will be defined as soon as the project gets started. We plan to focus on technological and semantics integration during this first stage of the project; future work will address methodological integration aspects, to support multiple development processes. The development of the MDDi platform will be an interactive process involving contributors to the project, as well as actual tool developers willing to help defining the requirements and experiment the developed technologies.

The MDDi project has an initial goal, which is to build an extensible integration platform, dedicated to MDD, inside the Eclipse Technology project. A longer perspective for the project shall be to drive, in collaboration with GMF, GMT and others, the creation of a top-level Eclipse project dedicated to modeling tools.


The MDDi proposal is endorsed by tool vendors, industrial companies, researchers and academia, interested in the realization of an open MDD platform. The project will have initial committers among them. We encourage others to participate in all the aspects of the project. If you are interested, please take part in the newsgroup discussions or ask to be added to the list of interested parties.

Board members

  • Mariano Belaunde (France Telecom)
  • Jean Bézivin / Freddy Allilaire (INRIA Nantes)
  • Xavier Blanc (Laboratoire d'Informatique de Paris 6)
  • Andy Evans / James Willans (Xactium)
  • Pete Rivett / Nick Dowler (Adaptive)
  • Madeleine Faugère / Sébastien Demathieu (Thales)
  • Pierre Gaufillet (Airbus France)
  • Jean-Marc Jezequel (INRIA Rennes)
  • Keith Mantell (IBM UK Limited)
  • Stephen Mellor / Campbell McCausland (Mentor Graphics)
  • Miguel A. de Miguel (Universidad Politécnica de Madrid)
  • Jon Oldevik (SINTEF)
  • Yann Tanguy (CEA)
  • Régis Vogel (Enabler Informática, S.A.)
  • Wolfgang Wieser (Imbus AG)

Initial Committers

  • Freddy Allilaire
  • Mariano Belaunde
  • Xavier Blanc
  • Nick Dowler
  • Madeleine Faugère
  • Stephen Mellor
  • Miguel A. de Miguel
  • Jon Oldevik
  • Yann Tanguy

Initial Contributions

  • ModelBus and ModelBus toolkit (MODELWARE - LIP6)
  • ATL adapter for ModelBus (MODELWARE - SINTEF, INRIA Nantes)
  • Front-End QVT adapter for ModelBus (MODELWARE - France Telecom)
  • Model repository adapter for ModelBus (MODELWARE - Adaptive)
  • ModelBus Generic Client (LIP6)
  • Action Semantic Modeling tool (CEA)
  • Profile Design tool (CEA)
  • QoS and Safety Analysis tools (UPM)

Interested Parties EU FP6-IP MODELWARE Project (
Thales, Adaptive Limited, Enabler Informática, S.A., France Telecom, IBM UK Limited, Imbus AG, Institut National de Recherche en Informatique et en Automatique (INRIA Nantes), Laboratoire d’Informatique de Paris 6 (LIP6), Stiftelsen for industriell og teknisk forskning ved NTH (SINTEF), Universidad Politécnica de Madrid (UPM)

CARROLL Program (
CEA, INRIA, Thales

Other interested parties:
Airbus France, Xactium, Versata, Communications and Systems, MetaMatrix, inStream, Laboratoire d'Informatique Fondamentale de Lille (LIFL), Philips Medical Systems, Financial Toolsmiths AB, Politecnico di Milano, Mentor Graphics