Jump to: navigation, search

Difference between revisions of "MDT/New and Noteworthy/1.1"

< MDT
m (OCL Tools Component)
(OCL M4 content)
Line 11: Line 11:
  
 
== Object Constraint Language ([[MDT-OCL|OCL]]) Component ==
 
== Object Constraint Language ([[MDT-OCL|OCL]]) Component ==
 +
 +
=== Release 1.2 M4 ===
 +
 +
This was not an ambitious milestone, for the most part simply fixing defects and making one or two small enhancements.
 +
A few changes are worth noting because of their impact on API and, in some cases, compatibility with the 1.1 release.
 +
 +
==== Disposing OCL Environments ====
 +
 +
A new disposal API is defined for the
 +
<tt>[http://download.eclipse.org/modeling/mdt/ocl/javadoc/1.2.0/org/eclipse/ocl/OCL.html#dispose() OCL]</tt> fa&ccedil;ade
 +
that does whatever is necessary to "clean up" the objects created by the parser, such as constraints, collection types, and
 +
variables.  More specifically, disposing an <tt style="color:green">OCL</tt> instance currently does the following:
 +
 +
* if the resource in which the environment (variables, collection types, etc.) is persisted was created by the environment and not by a client (to load an existing environment), then that resource is unloaded
 +
* all <tt style="color:green">Constraint</tt>s that are not contained in a resource have their adapter lists cleared, recursively over their contents
 +
 +
These measures are particularly important for the UML metamodel binding.  In the course of parsing and evaluating OCL expressions, the UML2 API's
 +
[http://download.eclipse.org/modeling/mdt/uml2/javadoc/2.2.0/org/eclipse/uml2/common/util/CacheAdapter.html CacheAdapter]
 +
will become attached to constraints and other objects created by the parser.  It is important that this adapter be removed again from any object that is no longer in use, because otherwise it will retain that object indefinitely (the
 +
<tt style="color:green">CacheAdapter</tt> is a singleton).
 +
 +
==== Additional Look-up Exceptions ====
 +
 +
Two specializations of the <tt style="color:green">LookupException</tt> are added to distinguish between ambiguous look-ups and
 +
invalid look-ups.  The
 +
[http://download.eclipse.org/modeling/mdt/ocl/javadoc/1.2.0/org/eclipse/ocl/AmbiguousLookupException.html AmbiguousLookupException]
 +
signals a look-up that resulted in multiple matches that the parser cannot distinguish and the
 +
[http://download.eclipse.org/modeling/mdt/ocl/javadoc/1.2.0/org/eclipse/ocl/InvalidLookupException.html InvalidLookupException]
 +
signals a look-up that resulted in an unambiguous match that is of the wrong metatype than what is required.  For example,
 +
a qualified-name look-up for a <tt style="color:green">Classifier</tt> or a QVT <tt style="color:green">Transformation</tt> might
 +
find a <tt style="color:green">Package</tt> instead of an instance of the expected metatype.
 +
 +
The Ecore and UML implementations of the <tt style="color:green">Environment</tt> are updated to throw these more specific exception types.
 +
 +
==== Changes in Parsing Behaviour ====
 +
 +
Two further changes were implemented in the OCL parser's behaviour that have an impact on compatibility with the 1.1 release.
 +
These address
 +
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197396 Bug 197396] and
 +
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=212804 Bug 212804].
 +
The former improves the parser's compliance with the OCL specification of definition constraints; compatibility with the 1.1 release is available by enabling the
 +
[http://download.eclipse.org/modeling/mdt/ocl/javadoc/1.2.0/org/eclipse/ocl/options/ParsingOptions.html#DEFINITION_CONSTRAINS_FEATURE ParsingOptions::DEFINITION_CONSTRAINS_FEATURE] option.  The latter eliminates an obsolete mapping of the relational operators
 +
(<tt style="color:green">&lt; &lt;= &gt;= &gt;</tt>) to the Java-ish <tt style="color:green">compareTo()</tt> operation; compatibility with the 1.1 release is available by enabling the
 +
[http://download.eclipse.org/modeling/mdt/ocl/javadoc/1.2.0/org/eclipse/ocl/options/ParsingOptions.html#USE_COMPARE_TO_OPERATION ParsingOptions::USE_COMPARE_TO_OPERATION] option.
 +
 +
==== Other Bug Fixes ====
 +
 +
For other bug fixes, see the
 +
[http://www.eclipse.org/modeling/mdt/news/relnotes.php?project=ocl&version=1.2.x&types=R,S#1.2.0M4 OCL 1.2 M4 release notes].
  
 
=== Release 1.2 M3 ===
 
=== Release 1.2 M3 ===

Revision as of 11:12, 18 December 2007

Model Development Tools Release 1.1 New and Noteworthy Items.

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

Back to Modeling Development Tools.

EMF Ontology Definition Metamodel (EODM) Component

TBD

Object Constraint Language (OCL) Component

Release 1.2 M4

This was not an ambitious milestone, for the most part simply fixing defects and making one or two small enhancements. A few changes are worth noting because of their impact on API and, in some cases, compatibility with the 1.1 release.

Disposing OCL Environments

A new disposal API is defined for the OCL façade that does whatever is necessary to "clean up" the objects created by the parser, such as constraints, collection types, and variables. More specifically, disposing an OCL instance currently does the following:

  • if the resource in which the environment (variables, collection types, etc.) is persisted was created by the environment and not by a client (to load an existing environment), then that resource is unloaded
  • all Constraints that are not contained in a resource have their adapter lists cleared, recursively over their contents

These measures are particularly important for the UML metamodel binding. In the course of parsing and evaluating OCL expressions, the UML2 API's CacheAdapter will become attached to constraints and other objects created by the parser. It is important that this adapter be removed again from any object that is no longer in use, because otherwise it will retain that object indefinitely (the CacheAdapter is a singleton).

Additional Look-up Exceptions

Two specializations of the LookupException are added to distinguish between ambiguous look-ups and invalid look-ups. The AmbiguousLookupException signals a look-up that resulted in multiple matches that the parser cannot distinguish and the InvalidLookupException signals a look-up that resulted in an unambiguous match that is of the wrong metatype than what is required. For example, a qualified-name look-up for a Classifier or a QVT Transformation might find a Package instead of an instance of the expected metatype.

The Ecore and UML implementations of the Environment are updated to throw these more specific exception types.

Changes in Parsing Behaviour

Two further changes were implemented in the OCL parser's behaviour that have an impact on compatibility with the 1.1 release. These address Bug 197396 and Bug 212804. The former improves the parser's compliance with the OCL specification of definition constraints; compatibility with the 1.1 release is available by enabling the ParsingOptions::DEFINITION_CONSTRAINS_FEATURE option. The latter eliminates an obsolete mapping of the relational operators (< <= >= >) to the Java-ish compareTo() operation; compatibility with the 1.1 release is available by enabling the ParsingOptions::USE_COMPARE_TO_OPERATION option.

Other Bug Fixes

For other bug fixes, see the OCL 1.2 M4 release notes.

Release 1.2 M3

OCL Grammar and Parser API Refactoring

This milestone delivers the long-awaited refactoring of the OCL LPG grammar and associated parser API, contributed by Ed Willink from the GMT project's UMLX component.

The major new API in this contribution is defined in the org.eclipse.ocl.lpg and org.eclipse.ocl.parser packages. Included is an implementation of an EssentialOCL grammar (EssentialOCL.g) which is included in the full grammar (OCLParser.g). The former OCLParser class (which was internal) is refactored to separate the concrete syntax and abstract syntax parsing phases, implemented by the public classes OCLParser and [1] OCLAnalyzer, respectively.

Abstract LPG-parsing API is provided by the org.eclipse.ocl.lpg package, with abstract definitions of lexers, parsers, and analyzers. These are accompanied by a BasicEnvironment interface that provides core services such as a new pluggable ProblemHandler for flexible reporting of parsing/analysis problems.

See Bug 176110 for further details.

Navigation of Unnamed Association Ends

The UML metamodel binding now supports parsing and evaluation of OCL expressions that navigate unnamed association ends. The OCL convention for unnamed ends defines an implicit name which is the name of the classifier at that end with the initial letter in lower case. MDT OCL supports evaluation of such navigation expressions, where the implicit end name is unambiguous, on:

instances of UML2-generated metamodels:

Navigating unnamed metamodel association ends

and on instance specifications in UML models:

File:Unnamed-assoc-ends-M1.png
Navigating unnamed model association ends


Other New API

As part of the refactoring of the parser API, this milestone introduces some new optional interfaces that environments may choose to implement. To maintain API compatibility, OCL employs an optional Adaptable interface similar to Eclipse Platform's IAdaptable that is available is stand-alone deployments. The OCLUtil class provides utilities to obtain adapters from parsing and evaluation environments for these optional interfaces.

One noteworthy new optional interface is Customizable, which defines a protocol for customizing the parsing and evaluation of OCL constraints via Options. Parsing options available so far include:

Evaluation options available so far include:

Other Bug Fixes

For other bug fixes, see the OCL 1.2 M3 release notes.

OCL Tools Component

OCL Tools is a recently added component to the Model Development Tools (MDT) Project aiming at providing first-class support to modelers working with specifications containing expressions written in OCL, the Object Constraint Language. Such support includes editing, refactoring, code generation, execution, and interactive debugging of the OCL constraints given for some underlying (Ecore or UML2) class model. The functionality of OCL Tools builds upon the MDT OCL component, and has been seeded with two initial contributions:

  • an OCL -> Java compiler, that as of now takes as input an .ecore and a textual file containing OCL constraints (handling UML2 is in the ToDo list). This compiler extends EMF code generation, producing Java 5 source code with side-effects-free methods for the given OCL invariants, pre- and postconditions, and derived attributes and operations.
  • an OCL text editor, supporting usability features such as AutoCompletion, navigation by means of hyperlinks, structured views (for the outline of a document and for the Abstract Syntax Tree of an OCL constraint), among others. Although MDT OCL itself is completely fluent in both Ecore and UML2, only the Ecore binding is supported by the OCL text editor at this time.

A longer intro to OCL Tools can be found at

Unified Modeling Language 2.x (UML2) Component

TBD

UML2 Tools Component

TBD

XML Schema Infoset (XSD) Component

TBD