SimpleOCL is a new addition to our OCL tool list. SimpleOCL is a proof-of-concept implementation of the OCL standard, built on top of theEclipse Modeling Framework (EMF)and EMFText.

It started as an embeddable OCL implementation for inclusion in transformation languages for the EMF Transformation Virtual Machine (EMFTVM). EMFTVM allows integrated execution of heterogeneous model transformation languages. EMFTVM is currently part of the Eclipse ATL project, and also provides a compiler for ATL.

To know more about the tool (and as usual the “why’s” behind the tool development) I exchanged some emails with the Dennis Wagelaar (the tool creator) to learn why he didn’t reuse one of the existing OCL parsers in eclipse, why SimpleOCL is easier to embed in transformation languages (we all know that OCL plays a key role in most transformation languages, e.g. to define the source patterns of transformation rules) and what are his future plans for the tool. Find his answers below:

SimpleOCL grew out of the need to have an ATL-style implementation of OCL for
inclusion in the EMFMigrate DSL (www.emfmigrate.org), much like this was done
for MoScript. EMFMigrate is a project set up by the University of l’Aquila,
and I worked with them to build an EMFMigrate-to-EMFTVM compiler in ATL. We
plan to submit a paper to this year’s ICMT about this.

The early version of EMFMigrate is built on xText, so we looked at Ed
Willink’s MDT-OCL grammar implementation, which is also based on xText.
However, xText turns out to be rather complex and verbose to use, and we did
not get any results within our timeframe of two weeks. MDT-OCL also uses a
pivot approach, with a concrete syntax metamodel and a pivot metamodel, but we
had already given up at this point.

That’s when we considered other parser generators, such as TCS and EMFText.
While TCS has exactly the OCL implementation we need, it is a liability in
terms of maintenance: TCS is no longer maintained, and already doesn’t work
with the latest Eclipse anymore. EMFText is a viable candidate, as I already
did the SimpleGT language
with it. It’s really concise for defining textual grammars: standard
situations require one line of EBNF-style text per meta-class.

This is where Dresden-OCL comes into the picture, because that is implemented
with EMFText (which also happens to be from Dresden). When taking a closer
look, it turns out to use two metamodels: a concrete syntax metamodel and a
pivot metamodel. The first is for parsing, the second for representing the
standard OCL metamodel. That makes things more complex for higher-order
transformations (HOT), as you need to first transform to the pivot metamodel,
do the HOT, then transform back to the concrete syntax metamodel. Also, for
embedding Dresden-OCL you need to follow through on the pivot approach by
providing two metamodels for your language, as well as adapted transformations
between your concrete syntax metamodel and your pivot metamodel.

A closer look at the OCL.cs grammar specification unveiled — apart from
things I didn’t need, such as “inv”, “pre”, and “post” — some lacking parts:
no “self” vs. “super” expressions (Dresden-OCL uses implicit “self”), which
are fairly essential for using OCL as a programming language, and no support
for model element types. That means there’s an impedance mismatch for using
Dresden-OCL (or standard OCL?) as a navigation language for model transformations.

That’s when I decided to do OCL in EMFText myself. It is based on ATL’s OCL
metamodel, and uses patterns from Dresden-OCL’s grammar definition.
Adaptations still had to be made to the metamodel to make up for EMFText’s
grammar definition limitations, so the resulting metamodel differs from the
standard here and there; it became SimpleOCL, not OCL.

 

EMFText already provides support for importing existing grammars, but so do
other parser generators. The difference here lies in the fact that SimpleOCL
comes with a compiler for EMFTVM. EMFTVM is a reusable runtime engine for
model transformation, so that is what you would use for defining the
executable semantics of your transformation language. The SimpleOCL compiler
can be used stand-alone, and other languages that target EMFTVM — currently
ATL and SimpleGT — can already use SimpleOCL modules by importing them. In
addition, the SimpleOCL compiler, which is written in ATL, can be imported in
your own compiler definition. ATL module superimposition means you can reuse
and redefine the transformation rules that generate EMFTVM code. The process
for defining your own transformation language based on SimpleOCL would look
like this:

1. Define your language’s metamodel on top of SimpleOCL’s metamodel (in Ecore).
2. Define your language’s grammar on top of SimpleOCL’s grammar (in EMFText).
3. Define your language’s compiler on top of SimpleOCL’s compiler (in ATL).

Because SimpleOCL is specifically targeted to EMFTVM, a number of special
features have been added:
– SimpleOCL code is organised in modules, which can import other modules.
SimpleOCL’s module/module import construct interacts with ATL’s module
superimposition mechanism, and allows you to redefine OCL features of imported
ATL or SimpleOCL modules.
– EMFTVM supports first-class closures (“code blocks”), so SimpleOCL adds
(limited) support for closures (“Lambda” expressions): you can define your own
iterator expressions, on top of the pre-defined “select”, “collect”, etc., by
defining an operation that takes a “Lambda” parameter.

 

As was said at the beginning, SimpleOCL grew out of the need to have OCL
support within EMFMigrate, so we’ll probably rework EMFMigrate to sit on top
of SimpleOCL. Also, SimpleGT could use OCL support for things like primitive
data type manipulation (String, Integers, etc.), which is relevant for EMF
models. As SimpleGT is already built with EMFText, this is an even closer target.

Within SimpleOCL itself, closure support could be extended: assigning closures
to variables, and passing those to other functions, or
continuation-passing-style programming, etc. At MoDELS 2011, Bran Selic
mentioned that OCL’s iterators were inspired by Smalltalk’s block closures, so
they can further inspire SimpleOCL’s closure support. C# can also serve as an
example here, as it demonstrates how statically typed closures can be done
(“Func”).

Finally, SimpleOCL could serve as the basis for an “integrated” transformation
language for EMFTVM that makes available all EMFTVM functionality within a
single language. This is definitely a long-term ambition, as it is much more
complex than what I mentioned before.