Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search

MDT/New and Noteworthy/1.0

< MDT(Redirected from MDT 1.0 New and Noteworthy)

Model Development Tools Release 1.0 New and Noteworthy Items.

For more details about the development plan, see the MDT 1.0 draft plan.

Back to Modeling Development Tools.


EMF Ontology Definition Metamodel (EODM) Component

Release 0.9.0RC3

  • 191537 Release version is changed from 2.0.0 to 0.9.0

Release 2.0.0M7

  • Bug 185001: Nested jars problem is fixed.

Release 2.0.0M6

  • EODM 2.0.0 code is checked in after CVS access rights problem is solved.
  • EODM 2.0.0 code has big changes in package structure and API to adapt/conform to the latest ODM specification.
  • EODM 2.0.0 code also introduces the new "dynamic typing" capability.
  • Use Modeling project logo instead of default Eclipse logo in features

Release 0.8.0M5

  • Javadoc is compiled and added to the doc plugin
  • All plugins are named mdt-eodm-* and all their version numbers are upgraded to 0.8.0.
  • Two bug fixes:
    • 174254 A bug in loading sub ePackage
    • 174253 OWL files from inputstream cannot be parsed successfully
  • Code base is moved to MDT CVS and the new MDT build system is used to produce this release.

Object Constraint Language (OCL) Component

Release 1.1 M4

LPG Java Runtime Restructuring

In the OCL 1.0 release, the SourceForge LPG Java Runtime library was embedded in the OCL bundle JAR. It has now been contributed to Orbit as a distinct bundle net.sourceforge.lpg.lpgjavaruntime.

Stand-alone Deployment Support

The OCL Downloads page now includes a stand-alone ZIP containing just the JARs required for deployment in a non-Eclipse environment. The EMF stand-alone deployment that is also required is available separately.

Stand-alone deployment

Other Bug Fixes

For other bug fixes, see the 1.1 M4 release notes.

Release 1.1 M5

EMF 2.3 Adoption and Generics

This milestone introduces a significant refactoring of the OCL Parser/Interpreter API, with the adoption of EMF 2.3 and its support for generic types. Using Ecore's generics, a new generic Abstract Syntax model for OCL is defined in the org.eclipse.ocl plug-in:

Generic OCL Abstract Syntax

This new model, and the OCL Parser/Interpreter core API, are thus freed from the dependency on the Ecore metamodel. The org.eclipse.emf.ocl plug-in is now deprecated and is supplanted by an Ecore binding (and environment implementation) of the generic model in the org.eclipse.ocl.ecore plug-in. The deprecated API delegates to the new Ecore binding for parsing of constraints, translating the resulting ASTs to the old Ecore-centric model. Utilities are also provided to convert existing ASTs in the old model to the new. The org.eclipse.emf.ocl API remains fully supported.

OCL Document Parsing API

The new org.eclipse.ocl.OCL generic class is the focal point of OCL parsing and evaluation. Besides creating org.eclipse.ocl.helper.OCLHelpers for parsing embedded constraints and org.eclipse.ocl.Querys for evaluating constraints, it can also parse OCL documents (text files external to the model). The content of an OCL document is encapsulated by the org.eclipse.ocl.OCLInput class:

OCL Document Parsing API

The parser supports the package and classifier context declarations, as well as all of the kinds of constraints supported by the OCLHelper for embedded constraints:

  • classifier invariants
  • operation pre-, post-, and body conditions
  • attribute initial and derived values
  • def: expressions for additional attributes and properties

For example:

package ocltest
    context Fruit
        inv not_black: self.color <> Color::black
        def property_helper:
            otherFruits : Set(Fruit) = Fruit.allInstances()->excluding(self)
        def operation_helper:
            getOtherFruits1(fruit : Fruit) : Set(Fruit) = Fruit.allInstances()->excluding(fruit)

    context Apple::preferredLabel(text : String) : String
        pre text_not_null: not text.oclIsUndefined()
        pre text_not_label: text <> label
        body compute_label: if text = label then '' else text endif
        post label_is_changed: label <> label@pre
        post label_is_set: label = text

    context Apple::name : String
        init: ''
        derive: if label.oclIsUndefined() then '' else label endif

OCL Constraints on UML Models

The new generic OCL implementation lays the ground-work for support for the UML metamodel (as opposed to Ecore). This is implemented in the new org.eclipse.ocl.uml feature (and plug-in of the same name). This consists of

  • UML bindings for the generic parameters of the core OCL API, including a UML implementation of the Environment
  • a specialization of the OCL Types package for OCL metatypes that are consistent with UML
  • UML models of the abstract syntax model, UML binding, and OCL Standard Library (works in progress)

The UML environment supports the following UML-specific OCL concepts that the Ecore environment does not:

  • isQuery property of operations
  • qualified association navigation
  • association-class navigation
  • state expressions (using UML state machines)
  • constraints defined on stereotypes

The UML evaluation environment (for evaluation of OCL constraints) supports two kinds of instance models: instance specifications in the UML model (as InstanceSpecification elements) and run-time instances (as EObjects) of an API generated by the UML2 code generator. Evaluation on instance specifications supports association-class and qualified association navigation but not operation calls (except where those operations have body conditions specified in OCL).

As a special case of the evaluation on EObjects, for the UML metamodel itself, the UML environment allows constraints defined on stereotypes to be evaluated on Elements to which they are applied, as well as on the stereotype instances. In either case, the constraint must be expressed in the context of the stereotype, navigating the appropriate metaclass extension(s) to access the base element.

Other Bug Fixes

For other bug fixes, see the 1.1 M5 release notes.

In particular, additional operations and attributes defined by def: expressions (parsed from OCL documents or via the helper) are no longer "global" (attached to the model context classifier). They are now local to the org.eclipse.ocl.OCL environment in which they were parsed.

Release 1.1 M6


In M6, the generic Abstract Syntax model binding strategy was completed by implementing metamodel bindings for the Expressions package as was done for the Types package in M5. This allows the OCLExpression, Variable, TupleLiteralPart, and CollectionLiteralPart metaclasses that all specialize TypedElement to specialize the definition particular to the target metamodel. For more details, see the OCL 1.1 API Changes page for more details of what this means for clients.

Expressions Package Binding

The platform:/plugin/org.eclipse.ocl.uml/model/OCLUML.uml model was regenerated from its Ecore counterpart using the final version of the Ecore-to-UML converter's support for Ecore generics in the MDT UML2 component. Thus, it is now sufficiently "clean" to serve as the source model for code generation. This model was also updated with the feature subsets required to define ownership of operations and attributes in metaclasses such as MessageType, for which the Classifier metaclass only provides derived unions. With these changes, the entire UML binding implementation is now generated from the UML model.

MessageType Metaclass

Other Bug Fixes

For other bug fixes, see the 1.1 M6 release notes.

Release 1.1 M7

The major theme of this milestone was improvements to the SDK documentation. This includes both the Programmer's Guide documentation and the examples.

Programmer's Guide Enhancements

The OCL Programmer's Guide is much expanded, covering all major aspects of the OCL APIs from a parser/interpreter client perspective, and even some advanced subjects for extenders of the APIs. The documentation includes UML class diagrams for easy reference and plenty of code snippets providing code snippets.

OCL Programmer's Guide Topics

Interactive OCL Console Enhancements

The Interactive OCL Console example plug-in (org.eclipse.emf.ocl.examples.interpreter) now demonstrates the content-assist support provided by the OCLHelper API:

Content-Assist in the OCL Console

It is also reworked to use the generic parsing APIs (OCL, OCLHelper, Query) instead of their Ecore specializations. With this change, the example now also demonstrates using the UML metamodel binding in addition to Ecore, to show how applications using OCL can make their own APIs likewise generic, so that their clients can use either metamodel implementation.

UML in the OCL Console

A final enhancement demonstrates how to use the OCL APIs to parse constraints on Ecore and UML models rather than the meta-models. The new Modeling Level selection on the action bar toggles between M2 (the metamodel), which is suitable for querying the model and printing the results of a query, and M1 (the model), which parses a constraint in the context of the selected element.

Modeling Levels in the OCL Console

The input expression is parsed as a constraint, and a success or error message printed in the console, according to the selected context element:

  • when a class is selected, the OCL expression is parsed as an invariant constraint
  • when an operation is selected, a post-condition constraint (being a superset of the syntax of pre-conditions and body expressions)
  • when an attribute is selected, a derivation expression

Other Bug Fixes

For other bug fixes, see the 1.1 M7 release notes.

Unified Modeling Language 2.x (UML2) Component

2.1 M4

Eclipse 3.3 / EMF 2.3 Compatibility

In keeping with the “Release Currency” theme, the UML API has been given a facelift. Many methods within the UML API are now specified using Java 5.0 generics and are consistent with EMF’s changes for Java 5.0.

This could have potential impact on users calling the UML API, for example when working with lists of a specific meta-type. For details see bug 160679

2.1 M5

Eclipse 3.3 / EMF 2.3 Compatibility

Starting in 2.1M5 users can convert UML models with templates to Ecore models with generics and vice versa. UML concepts such as templates, template bindings, etc., have a direct impact on the resulting Ecore model and ultimately the generated code. Likewise, Ecore models with EGenericTypes or ETypeParameters (new meta-types in the Ecore metamodel) can be converted to UML models that make use of the corresponding UML concepts.

For a more detailed explanation of generics in EMF and updates to the EMF metamodel see EMF 2.3 Generics.

Consider the following Ecore model and corresponding UML model.


In the Ecore model above we have a simple ETypeParameter and property typed by that parameter. The corresponding UML model has a template signature with classifier template parameter, and property typed by the corresponding parametered element.

UML Generics1.gif

Next, we have a generic supertype with eClassifier set to FourWheelCar. Also, we have two parameters of an operation with a bound templated classifier specified.

Ecore Generics2.gif

The corresponding UML model results in a bound classifier as follows.

UML Generics2.gif

In order to capture generics-related concepts in Ecore that have no counterpart in UML, the Ecore profile (Ecore.profile.uml) has been updated with new stereotypes, EGenericType and ETypeParameter. The EGenericType stereotype captures upperBound and lowerBound information not expressible in UML, and the ETypeParameter stereotype captures bounds on type parameters. In addition to capturing missing information, the EGenericType stereotype acts as a marker that such classifiers, although required in the UML model, are not required in the Ecore model and can hence be discarded.

Ant Task for Ecore Importer

In keeping with the “completeness” theme, a new Ant task has been created that allows users to generate code based on a UML model. From the Ant task, users can provide UML-specific code generation options for the generator model, generator package, and converter, in addition to passing an input UML model. The user is then one click away from running the Ant task and generating code directly from a UML model. Details can be found in bug 160680

Other Bug Fixes

For other bug fixes, see the 2.1 M5 release notes.

2.1 M6

Create Child/Sibling Menu Reorganization

The 'Create Child' and 'Create Sibling' menus have been reoganized so that items are grouped by feature. This allows for quicker creation and easier navigation.


Static Profile Definition

In the "classical" approach to profiles, users typically create an Ecore representation by calling Profile#define(). When applying stereotypes from such a profile, a dynamically-generated EMF representation of the stereotype is retrieved from an annotation on the profile.

In M6, the ability to use statically defined profiles has been introduced. Users now have the option to convert their profiles to Ecore just as they would any other model. They can then generate code from that model and provide implemenations for operations and derived features. If the model is then registered in the EPackage registry, the UML API will discover the Ecore definition instead of looking for it in an annotation. In such a scenario, the "define" step on the profile is not needed - the conversion to Ecore replaces it.

Details on how this all works will be provided in a future article.

As part of this work, the Profile#define() method has been overloaded to accept options. New UML-to-Ecore conversion options have been introduced, including the ability to specify whether comments should be converted to code generator documentation in the resulting Ecore representation.


New API to Create Usage Dependencies

An additional convenience method has been introduced to create usage dependencies on named elements. Although the ability to create usage dependencies existed in the past, this new convenience method makes it even easier.

Other Bug Fixes

For other bug fixes, see the 2.1 M6 release notes.

2.1 M7

OCL Integration

Now users can specify invariant constraints or operation bodies in OCL and have code generated from the expressions entered in the UML model.

To demonstrate how this works, consider the following model:


The first constraint constraint1 on Car is specified in OCL in the following way:


The second constraint is a body condition on the operation getTires().


This body condition tests the parameter p1 on the operation getTires() in the following way:


  • Two new converter options have been introduced to take into account body conditions or opaque behaviors when converting from UML to ecore.


  • Ecore representation now contains new annotations which will eventually be used in the code generation stage. This is the resulting ecore version.


  • UML custom code generators take the new annotations into account and add dependencies on OCL components. The resulting code is as follows.


And for the getTires() body.


Dependencies to OCL plugins will also automatically be generated, of course, users will have to have the ocl plugins in their workspace for this to work.


Note: There is also a runtime dependency on the LPG Java Runtime v1.1 from

Details can be found at: 105199

Updated Schema for Metamodel Changes

The namespace URI for the UML metamodel in UML2 2.1 has been changed to (

  • IMPORTANT: Key values for annotations such as those used to store dynamic ecore representation of defined profiles still use the original annotation (

This change was required to reflect changes to the metamodel. The metamodel changes address issues with bidirectional associations between Vertex#incoming/outgoing and Transition#source/target in addition to the bidirectional association between ConnectableElement#end and ConnectorEnd#role.

At the OMG, issues 10537 and 10536 have been raised.

The underlying motivation behind this issue has to do with fixing problems that were discovered while trying to implement redefinition, however, there is a more fundamental problem regarding the impact that bidirectional associations in the metamodel have on modeling in practice.

The goal of these changes is to break the requirement for bi-directional associations. Currently, when we modify the source and target of a transition, we do not directly modify the incoming and outgoing properties of Vertex which could be in another model.

Details can be found at: 185602

Export Wizard Improvements

The UML export wizard used to output new resources for every nested EPackage in a model. This no longer is the case.

Also, if the ecore model that is being converted contains references to types in other metamodels, the corresponding UML representation of that referenced metamodel will also be generated.

Details can be found at: 172503

Validate action should validate stereotype applications

Since stereotype applications were moved to the root level since UML2 2.0.x the validation of stereotype applications stopped working. This functionality has now been restored.

Details can be found at: 176995

Migration issue for ActivityGroup.subgroup

A migration issue between UML2 2.0 and UML2 2.1 was resolved in this iteration.

The older version ActivityPartition.subgroup should get migrated to ActivityPartition.subpartition but previously did not work. The repair of this defect might affect those migrating Activies to the latest version.

Details can be found at: 181639

Other Bug Fixes

For other bug fixes, see the 2.1 M7 release notes.

UML2 Tools Component



UML2Tools stereotype-related functionality resembles UML2 Editor actions. You can define Profile, apply Profile to Package and to apply Stereotype to Element in UML Diagram Editors.

The possible workflow looks like:

-Create Stereotype which extends some Metaclass. Define containing Profile by using Action Profile->Define in popup menu of Profile.

-Apply Profile to appropriate Package by use of "Apply" action in the context menu of the Diagram.

-Apply needed Stereotype by checking Apply-><stereotype_name> action in the context menu of the element. Element with applied Stereotype is now decorated.

Applied stereotype.PNG

You can manage your applied Profiles/Stereotypes by checking or un-checking an appropriate action. Several stereotypes may be applied to element at a time.

Navigation to Package

Double-click the package on Class Diagram to open it in a new editor.

Detail Levels

Three Detail Levels are available for Class Diagram (as shown at 06-04-02:F7.28):

Details implementation.PNG Details analysis.PNG Details suppressed.PNG

Implementation - Default level. All the details are shown.

Analysis - Only public attributes/operations/literals are shown.

Details Suppressed - All compartments of Classifiers are hidden

To manage Detail Levels use ‘Detail Level’ group in the context menu of the diagram.

Details action.PNG

Icon Styles

Two icons styles are available now - 'cheerful' and 'eclipse classic':

Icons cheerful.PNG Icons classic.PNG

To choose preferred style use ’Icon Style’ Preferences Page.

Association Link Usability

All kinds of association decoration are shown now: owned ends, aggregation, navigability. Three displaying options are available for navigability: Show all arrows and X’s; Suppress all arrows and X’s; Show one-way navigability only.

File:Association decorations.PNG

These options are located in the main preference page of UML Class Diagram. The option to show all arrows is set by default.

Some subsidiary actions are implemented to improve association usability. These actions are:

'Create Association from Property…' in the context menu of typed property. It creates an association, source end of which is the selected property.

'Association Type…' changes the aggregation type of Association. One can choose None, Composite or Shared type.

Generalization Set

Elements of Generalization Set metaclass are shown on the UML2Tools diagrams. Try to create Generalization to another Generalization then Generalization Set will be created, it will be shown as a dashed line on the diagram.


Diagram Decoration on Class Diagram

Diagram decoration is shown on the top-left of the diagram. Package name and imported elements are editable there. Element Imports are shown in accordance with its notation (UML 06-04-02, 7.3.15): {<qualified-name> ‘ as ’ <alias> ‘}’


Accessible Profiles Configuration

It is easier to work with Stereotypes in Class Diagram now. Some Profiles may be loaded by default. To configure such profiles use ‘UML Class Diagram/Pathmaps’ preferences page. *.profile.uml files will be loaded automatically by its paths variables.

New Diagram Wizard Usability

New Diagram Wizard was improved. Diagram file name is used as a default name of a domain file.

XML Schema Infoset (XSD) Component

XSD is currently being built and maintained as part of EMF 2.3's builds.

See EMF 2.3 New and Noteworthy for details on this component.

Back to the top