Release 1.2 M6

A few small-ish improvements are made in this milestone, along with a number of bug fixes.

Improved Collection Flattening

The intent of collection flattening in the OCL 2.0 Specification is to produce collections in the same form as OCL 1.x, in which collections could not nest. OCL 2.0 does allow collections to contain
other collections, so the flatten() operation is provided to reduce a nested structure to a flat collection.

Through the 1.1 release, the flatten() implementation in MDT OCL has been incorrect: only the first level of nesting is flattened. A
Set(Set(Set(Apple))) would be reduced to a
Bag(Set(Apple)) instead of a
Bag(Apple). This is corrected by
bug 217461. After all, a partially-flattened collection isn't
really of any use at all.

Implementing an EValidator

The OCL.uml model was updated to add all of the well-formedness
constraints specified by OCL for the Types and Expressions packages of the Abstract Syntax.
These are documented using the OCL expressions included in the OCL 2.0 Specification. From these constraint specifications, the
TypesValidator and ExpressionsValidator
are generated as per the EMF validation framework.

This provided the basis for resolving two bugs in the Ecore binding plug-in:

bug 213936 for validation extensibility (the currrent visitor design is not extensible) and

bug 213096 to override the ENamedElement::WellFormedName constraint from Ecore, which doesn't apply to OCL.

The latter is accomplished by overriding the inherited constraints in an
EcoreValidator generated in the OCL binding for Ecore.

The well-formedness rules implemented in the ValidationVisitor are not yet ported to the new validators. This is planned for the next milestone, in
bug 224731.

Other Bug Fixes

Release 1.2 M5

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

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.

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:

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:

ProblemOption, an enumeration of parsing problems for which clients can choose the severity (reported as Diagnostics or as ParserExceptions

Other Bug Fixes

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.

Release 2.2 M4

This milestone consisted mostly of fixing some defects and making few small enhancements.
A few changes are worth noting.

Code template changes

The Javadoc for the UML2 API now contains information about subsetting and redefinition. Such information is useful when trying to navigate the maze of properties and how the UML meta-model is put together.

For example, Package::nestedPackage subsets Package::packagedElement

Profile registry

A new profile registry has been added making the discovery of profiles easier.