Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
MDT/New and Noteworthy/1.0
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.
Contents
EMF Ontology Definition Metamodel (EODM) Component
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:
- 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.
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:
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.OCLHelper
s
for parsing embedded constraints and org.eclipse.ocl.Query
s
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:
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: result = 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 endpackage
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 EObject
s) 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 EObject
s, for the UML metamodel itself, the UML
environment allows constraints defined on stereotypes to be evaluated on
Element
s 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, attitional 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.
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.
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.
The corresponding UML model results in a bound classifier as follows.
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 here: Bugzilla 160680
Other Bug Fixes
For other bug fixes, see the 2.1 M5 release notes.