Model Driven Development integration

Requirements

Version 1.01 - December 1st 2005

Also available as a PDF document.

Overview
Model-Driven Development (MDD) provides more and more modeling tools supporting specific domains and activities across the development lifecycle. However, their integration in a single modeling platform is difficult to achieve because of technological heterogeneity: different meta-model facilities and exchange formats usually support various modeling languages (UML or Domain-Specific Languages), which requires specific tool adaptation.

The MDDi project produces an extensible framework and exemplary tools dedicated to integration of modeling tools in Eclipse. This framework simplifies tool interactions by formalizing the operations applied on models (e.g. model transformation, model validation) as "modeling services". It also supplies means to exchange model semantics, providing the ability to maintain consistency of elements defined in different modeling languages.

This document defines an initial list of high-level requirements, organized according to the identified use cases. Requirements are associated to a priority criterion and release information (the first release R1 is scheduled TBD, future releases are indicated as R+).
High-level requirements

  • General requirements
Identifier Description Priority Release
REQ_1 MDDi provides an extensible framework built on top of Eclipse to integrate modeling tools used across the development lifecycle. High R1
REQ_2 MDDi is interoperable with modeling frameworks developed as part of others Eclipse projects, such as: EMF, UML2, GMF, GMT, and EMFT. High R1
REQ_3 MDDi is compatible with the latest releases of the Eclipse platform and related projects. High R1
REQ_4 MDDi supports integration of any modeling tool, which models are accessible via their meta-model. Both EMF and non-EMF tools are targeted. High R1
REQ_5 MDDi supports integration of local Eclipse tools, as well as remote modeling tools accessible over the Internet. High R1
REQ_6 Integration of modeling tools in MDDi does not require changing their source code. High R1
REQ_7 MDDi makes use of standard-compliant technologies. Reference standard bodies are: the OMG, in the area of modeling technologies; the W3C, in the area of web technologies. High R1

  • Modeling requirements
The use cases and related requirements presented in this section involve a developer using integrated modeling tools and services provided by the platform. It includes invocation of modeling services on model artifacts, creation and build of modeling projects, as well as validation, compare, merge and synchronization features relying on the services provided by integrated tools. Figure 1 illustrates these modeling use cases.

Figure 1: Modeling use cases

  • Create a modeling project
The developer creates a modeling project. The project will contain the models and related artifacts he will work with.
Identifier Description Priority Release
REQ_8 Models and related resources are stored in a dedicated type of project called a "modeling project". Med R1
REQ_9 Modeling projects are created from the new project wizard. Med R1
REQ_10 Modeling projects can reference one another by dependencies, enabling related models to be spread over several projects. Med R1

  • Build a modeling project
The developer defines a build sequence by chaining the modeling services he wants to invoke. Later on, changes on models or an explicit build command triggers the project builder. The modeling services are executed then.
Identifier Description Priority Release
REQ_11 A project builder supervises invocations of modeling services on model artifacts. High R1
REQ_12 A build operation applies to a modeling project or several dependent ones. Med R+
REQ_13 The project builder can be run in an interactive mode. It makes use of the Eclipse incremental project builder support. High R+
REQ_14 Interactive builds are triggered by changes on models or an explicit build command. The builder follows, as much as possible, the same principles as the JDT and CDT builders. High R+
REQ_15 The project builder can be run in a batch mode. It can make use of the Eclipse Ant support. Med R1
REQ_16 A build script drives the project builder in both interactive and batch modes. High R1
REQ_17 Build scripts are defined in a language, which references models and modeling services. Examples of build languages are: Ant, Maven or OMELET. High R1
REQ_18 The builder supports the interchange of data between tools by automatically choosing a common meta-model to allow registered services to exchange data. This operation is referred as "metamodel negotiation". High R1
REQ_19 Build scripts can be edited using a dedicated build sequence editor. Med R1
REQ_20 The build script editor provides a support for syntax checking. Low R1
REQ_21 When editing the build script, the editor shows an error to the developer if the current service configuration does not allow exchanging models. The editor warns the developer if more than a given number of semantic mappings is required to exchange models. Med R1
REQ_22 Based on meta-model negotiation, the builder executes the relevant semantic mappings on models provided in input/output of modeling services. A failure during the negotiation breaks the build. Med R1

  • Use a modeling service
The project builder, or the developer using a client tool, is able to list the registered modeling services. Then it invokes one of these registered services.
Identifier Description Priority Release
REQ_23 A modeling service abstracts operation applied on models (e.g. model transformation, model check) and formalizes the accepted and produced model types. High R1
REQ_24 A modeling service can abstract an Eclipse-based or an external tool operation. High R1
REQ_25 A modeling service can abstract a local or remote tool operation. Connectivity to local tools relies on the Eclipse plug-in mechanism whereas connectivity to remote tools is provided by Web Service technologies. High R1
REQ_26 A modeling service can be invoked in a synchronous or asynchronous mode. Low R1
REQ_27 A modeling service can be programmatically invoked using a dedicated API. High R1
REQ_28 A modeling interface defines a namespace for a set of related modeling services. Low R1
REQ_29 A modeling service is defined by a name, a series of input, output, input/output parameters and a return value. High R1
REQ_30 A modeling service can be overloaded based on the parameter types and return value types. Low R+
REQ_31 Parameters and return values can be models (e.g. a UML model), model elements (e.g. a UML Package), primitive types (String, Integer, Boolean...), or files. High R1
REQ_32 Exchange formats can be translated to enable access to models and model elements provided by non-EMF tools. High R1
REQ_33 Model and model elements are typed according to their metamodel. A model type references a meta-model Uniform Resource Identifier (URI). High R1
REQ_34 A modeling service can be described by meta-data, providing additional information about its operation mode (e.g. service category: transformation, validation...) High R1
REQ_35 Several tools can implement a given modeling service. Configurable policies are defined to manage selection of modeling services in that case. Med R+

  • Execute a semantic mapping
A series of semantic mappings is registered in the platform (see use case "manage semantic mappings"). Relying on these mappings, the developer imports/exports a model from/to the Eclipse workbench. Inside the workbench, the developer can also import/export a model from an Eclipse tool to another.
Identifier Description Priority Release
REQ_36 A model bound to a registered meta-model (e.g. ".uml2" file extension -> "UML2.0" model type) can be transformed using a semantic mapping while it is imported in the workspace. Low R1
REQ_37 A model bound to a registered meta-model can be transformed using a semantic mapping while it is exported from the workspace. Low R1
REQ_38 A "new model" wizard is added to the Eclipse extension framework. When instantiated, this wizard comes with built-in import features based on the registered semantic mappings. Low R1
REQ_39 Inside a modeling project, a model bound to a registered metamodel can be transformed (exported) to be edited by other Eclipse tools, using the registered semantic mappings. Med R1
REQ_40 If several mappings are available when importing / exporting a model, the candidates are presented to the developer for selection. Med R1

  • Validate a modeling project
Validation tools supporting given meta-models are integrated in the platform, providing modeling services. Relying on the registered semantic mappings, the developer checks consistency between related models. Semantic mappings are executed and produced models are validated against each validation service. A marker indicates whether validation succeeded or not. Inconsistencies between model elements are presented to the developer.
Identifier Description Priority Release
REQ_41 Consistency of models bound to registered meta-models is checked using the registered semantic mappings and validation modeling services. Med R+
REQ_42 Validation results are indicated by a marker and a series of inconsistencies between model elements. Med R+
REQ_43 Consistency checking applies to a modeling project or several dependent ones. Med R+

  • Compare / merge models
Compare and merge tools supporting given meta-models are integrated in the platform, providing modeling services. Relying on the registered semantic mappings, the developer selects a set of related models inside a modeling project then compare or merge them. He is also able to keep them synchronized using an event-based merge feature.
Identifier Description Priority Release
REQ_44 Models bound to registered meta-models can be compared using the defined semantic mappings. The Eclipse compare framework may be used for that purpose. Low R+
REQ_45 The output of the compare is a series of differences between model elements, based on the semantic mappings. Low R+
REQ_46 Models bound to registered meta-models can be merged using the defined semantic mappings. The model merge relies on the output of the model compare feature. Low R+
REQ_47 Models bound to registered meta-models can be kept synchronized. The synchronization is meant to be two-way. Changes on models will trigger a model merge accordingly. Low R+

  • Platform configuration requirements
The use cases and related requirements presented in this section involve a tool integrator, who adapts modeling tools, registers meta-models and semantic mappings, and then packages these configuration elements for deployment in another instance of the Eclipse platform. An administrator deploys these configuration elements, enabling automatic registration of modeling services, metamodels and semantic mappings. Figure 2 illustrates these platform configuration use cases.

Figure 2: Platform configuration use cases

  • Manage meta-models
The integrator lists the meta-models registered in the platform and inspect their content. Provided UML2 is installed, he is also able to list the defined UML2 profiles, inspect their content and register or deregister existing ones.
Identifier Description Priority Release
REQ_48 A meta-model registry lists the meta-models available in the platform. This registry can be browsed using a dedicated Eclipse GUI. High R1
REQ_49 A registered meta-model can be inspected using a dedicated Eclipse GUI. High R1
REQ_50 A UML2 profile registry lists the profiles available in the platform. This registry can be browsed using a dedicated Eclipse GUI. High R1
REQ_51 Registered UML2 profiles can be inspected from a dedicated Eclipse GUI. High R1
REQ_52 UML2 profiles can be added or removed from the registry. High R1

  • Manage semantic mappings
Exchanging model semantics between tools requires a definition of mappings between meta-models. These mappings are bidirectional and are implemented in the platform by QVT transformation definitions. The tool integrator lists the semantic mappings registered in the platform. He is able to define a new semantic mapping between meta-models, deregister an existing semantic mapping or edit it using dedicated tools.
Identifier Description Priority Release
REQ_53 A semantic mapping is defined by name, references to metamodels and transformation definitions High R1
REQ_54 A bidirectional transformation definition or a pair of unidirectional transformation definitions is required to implement a semantic mapping. High R1
REQ_55 Transformation definitions are expressed using the MOF QVT standard. QVT Operational and QVT Relations are supported. High R1
REQ_56 A mapping registry stores the semantic mappings available in the platform. High R1
REQ_57 Registered semantic mappings can be inspected from a dedicated Eclipse GUI. High R1
REQ_58 Semantic mappings can be added, edited, removed from the registry. High R1
REQ_59 A dedicated QVT editor eases definition of transformation definitions. Med R1
REQ_60 Templates of QVT definitions are created from a dedicated mapping wizard. Med R1
REQ_61 Complex semantic mappings may require the use of a common interchange meta-model, as well as a related tool support. Low R1

  • Manage modeling services
The integrator lists the modeling services registered in the platform. He is able to register or deregister a service from a registry. He is also able to specify and implement new modeling services using a dedicated toolkit.
Identifier Description Priority Release
REQ_62 A registry lists the modeling services available in the platform. Each entry in the registry relates to a modeling service description. High R1
REQ_63 A modeling service description defines the interface (e.g. name, parameters, model types) of a modeling service. High R1
REQ_64 Registered modeling services can be inspected from a dedicated Eclipse GUI. Low R+
REQ_65 A modeling service can be added or removed from the registry. High R1
REQ_66 A modeling service description can be edited with a dedicated editor. Med R1
REQ_67 Stubs of implementation classes can be generated from a modeling service description. These stubs are implemented to adapt a specific tool operation. Med R1
REQ_68 Tooling implemented to support modeling service development is integrated in Eclipse. Dedicated wizards, editors, project structures are developed for that purpose. Low R+

  • Package platform configuration
The tool integrator packages the current platform configuration elements (meta-models, semantic mappings, modeling services) in exportable assets.
Identifier Description Priority Release
REQ_69 A modeling service is packaged as an Eclipse plug-in to be deployed locally, or as an archive (JAR, WAR) to be deployed in some external tool. Med R1
REQ_70 Tooling is provided to support packaging of modeling service implementation (e.g. checking dependencies on model definitions). It can make use of the Eclipse export features. Low R+
REQ_71 Meta-models and semantic mappings are packaged using a dedicated archive format. The RAS standard can be used for that purpose. Med R1
REQ_72 Deployment scripts can be included in this archive to enable automatic execution of configuration actions upon deployment. Med R1
REQ_73 Tooling is provided to support packaging of meta-models and semantic mappings. It can make use of the Eclipse export features. Low R+

  • Deploy platform configuration
The tool integrator packages the current platform configuration elements (meta-models, semantic mappings, modeling services) in exportable assets.
Identifier Description Priority Release
REQ_74 A packaged modeling service is automatically registered upon deployment in Eclipse. Med R+
REQ_75 Tooling is provided to support deployment of modeling service. It can make use of the Eclipse import features. Med R+
REQ_76 A packaged meta-model or semantic mapping is automatically registered upon deployment in Eclipse. Med R1
REQ_77 Tooling is provided to support deployment of meta-models and semantic mappings. It can make use of the Eclipse import features. Low R+
REQ_78 Deployment scripts are automatically executed upon deployment. Med R1

Exemplary tools

  • Modeling services and semantic mappings will be developed to integrate a UML2 modeler and a Petri nets modeler, and validate the project proposal scenario.
  • Repository services will be provided to map EMF resources and provide connectivity to the Adaptive Repository tool.
  • Model transformation services will be provided to map the ATL and QVT tools features.
  • A generic client will be developed to use modeling services from a dedicated Eclipse GUI.
Exemple scenarios
These scenarios present a walk-through of the steps of integrating some modeling tools and making use of them. They illustrate the requirement defined above.

  • Structural – behavioral consistency

A tool integrator is interested in creating an Eclipse-based modeling tool that addresses domains where behavioral modeling takes an important part of the system design (e.g. real-time embedded). Based on end-user requirements, the platform will support UML for structural modeling and a dedicated language: Petri nets (Petri nets have been chosen, as they have no obvious relationship with UML) for behavioral modeling. It will be initially composed of tooling supporting UML: an UML2-based modeler, an OCL checker for UML2, as well as tooling supporting Petri nets: an EMF-based Petri nets modeler and a legacy Petri nets checker.

Step 1: Integrate the modeling tools

  • The tool integrator installs the UML2-based (UML2) and Petri nets (PN) modeler plug-ins, as well as the OCL checker for UML2 plug-in.
  • He installs the legacy Petri nets checker outside of Eclipse.
  • The tool integrator launches Eclipse and creates a "Modeling service" project. The project will store the different modeling service descriptions, as well as the related implementation stub.
  • Using a dedicated wizard, the tool integrator creates a new modeling service description for the OCL checker.
    • He defines a modeling interface: "ValidateModel".
    • He defines a modeling service name: "executeValidation".
    • He defines a model type and references the UML2 package URI.
  • He generates the stub classes based on the modeling service description. Then, he implements the stub to adapt the OCL checker.
  • Using a dedicated wizard, the tool integrator creates a new modeling service description for the legacy PN checker.
    • He references the existing modeling interface: "ValidateModel".
    • He defines a modeling service name: "executeValidation".
    • He defines a model type and references the PN package URI.
  • He generates the stub classes based on the modeling service description. Then, he implements the stub to adapt the PN checker (e.g. external tool API calls).
  • He packages the UML2 "executeValidation" service as a plug-in, to be locally deployed.
  • He packages the PN "executeValidation" service as an archive, to be remotely deployed.

Step 2: Define semantic mappings

  • Using a graphical wizard, the tool integrator defines a coarse-grain mapping between the UML2 and the Petri nets meta-models. The wizard generates a pair of templates of QVT Operational definitions (UML-to-PN, PN-to-UML).
  • The tool integrator uses a QVT editor to complete the transformation definitions.
  • The tool integrator registers the semantic mapping when the transformations are defined.
    • He creates a new entry in the registry for UML2 from/to PN.
    • He defines a location of the QVT definition file.
  • Finally, he packages the UML2 and PN meta-models, as well as the semantic mapping, inside a dedicated archive.

Step 3: Deploy platform configuration

  • An administrator deploys the UML2 and PN meta-models, as well as the semantic mapping, in a new instance of Eclipse.
  • He deploys the UML2 "executeValidation" service in the same instance of Eclipse.
  • He connects an adapter to the legacy PN checker and deploys the "executeValidation" modeling service.
  • He starts the PN checker adapter. The remote validation service is available.

Step 4: Use the platform

  • The end-user launches the configured Eclipse platform.
  • Using the MDDi new wizard, he creates a new Modeling project.
  • Using the UML2 new wizard, he creates a new UML2 model.
  • He edits the UML model with the UML2 editor.
    • He creates a package.
    • He defines a class diagram and creates several classes with OCL constraints.
    • He may check intra-model consistency with an OCL checker integrated in Eclipse.
  • Using the PN new wizard, he creates a new Petri nets model.
  • He edits the PN model with the dedicated editor.
    • He defines a diagram and creates several places and transitions.
    • He may check intra-model consistency with remote "executeValidation" service.
  • He validates the modeling project consistency.
    • Warnings appear if the models are inconsistent (e.g. a Petri nets transition without a related method in the UML class diagram).

  • Building a modeling project

Extending the initial platform features, the tool integrator wants to provide end users the ability to merge UML and PN models, and then generate C code. He integrates a compare tool supporting UML2, a compare tool supporting PN and a C code generator from UML2 models. All of these tools provide modeling services. The end user is able to compare changes between UML and PN models. At some point, he merges the PN changes to the UML model. Then, he kicks off the code generator using the UML2 model in input. This sequence of operations on models can be defined in a build script, to automate code generation when building the modeling project.

[To be detailed and completed]

References

Quick links

Documentation

Getting started
What's new
  • November 20th - Updated ModelBus builds are available.
  • August 1st - ModelBus V2 builds available.
  • February 8th - MDDi talk accepted at EclipseCon 2006!
  • February 2nd - ModelBus builds available.
Project Status