
h2(#Extensions). Extensions (in the Unified/Pivot OCL prototype)

This section highlights some of the OCL extensions prototyped by the Pivot OCL.

h3. Models

The Abstract Syntax classes and interfaces are autogenerated from Pivot.ecore using standard EMF tooling. Pivot.ecore is auto-generated by custom QVTo transformations from OMG's UML.xmi and prototype OCL.uml models. This gives some degree of UML alignment.

The Standard Library is defined by OCL-2.5.oclstdlib for which an OCLstdlib Xtext editor is available. The library is therefore modelled.

The Concrete Syntax classes and editors are also autogenerated from Ecore modesl using standard EMF tooling. Autogeneation of the Ecore models from UML modesl is still work in progress.

The grammars are defined by Xtext models.

The run-time Value classes and interfaces are partially generated from Values.ecore. Full auto-generation is still work in progress.

There is also a model of the code generation intermediate.

h3. XMI

The abstract syntax models are fully persistable as standard XMI using the *.oclas file extension. Pivot.oclas and OCL-2.5.oclas models form part of the Eclipse OCL distribution.

The problem of interchange of synthetic types such as Sequence(String) is solved by an orphan package in which a singleton copy of every singleton is maintained.

The problem of Complete OCL's open classes allowing additional features is solved by CompleteModel/CompletePackage/CompleteClass additions to the abstract syntax so that a CompleteClass may aggregate many ordinary Classes; one from the primary user (UML/Ecore) model, any number of further (Compete OCL or OCLstdlib) over;ays.

The problem of references to unnavigable opposites is solved by an OppositePropertyCallExp class.

The problem of references to modelled Iterations is resolved by adding a referredIteration property to IterateExp/IteratorExp.

The problem of references to Stereotype properties is resolved by normalizing the UML representation to exploit regular Class/Property usage.

The problem of references to Association properties is resolved by normalizing the UML representation to exploit regular Class/Property usage.

h3. Templates

In OMG OCL, types such as Sequence(String) magically associate String and an ill-defined concept of T. In UML and consequently the UML-aligned pivot OCL, String is a TemplateParameter for which further classes such as TemplateParameterSubstitution define bindings. The use of magic T for library classes is genertalized to arbitrary user
classes and operations; jusr like UML. Template types of cource conform and since in OCL all values are immutable a
Set(Integer) is conformat to a Sert(Real) and a Set(OclAny). This can bew slightly surprising since typos may not lead immediately to type errors, rather an expression with inferred OclAny errors. Use the hovertext to inspect your expression types.

h3. Extensibility

The Pivot OCL is extended by the Eclipse QVTd project to support QVTc and QVTr. The models are therefore extensible, but not readily so. Rather too mauch Java programming is required. True extensibilitty and in partocular a modular OCL Standrad Library is still work in progress.

h3. Operation Overloading

The buck passing between UML and OCL in regards to operation overloading is resolved in the Pivot OCL by implementing a Java-style dynamic dispatch to the most derived implmentation with a matching signature.

h3. Stereotypes

The UML specification hinyts in regards to base_XXX and extension_XXX properties are followed through in conjunction with an ElementExtension lass to model  the instance of a Stereotype. Typesafe stereotype navigation is therefore possible without resorting to the proprietary getXXX Java API of Eclipse UML2.

h3. Safe Navigation

The UML [ 1 ] and [ ?  ] multiplicities are exploited to distinguish nullable and non-null objects and diagnose unsafe navigations. To make this useful an extension to null-free collections is possible by defing e.g Set(String[*|1]) as
a Set of String with unbounded [ * ] collection multiplity and never-null [ 1 ] element multiplicity. The additional ?. and "?->" safe navigation operators avoid nullhazards. See "Safe Navigation in OCL":http://www.eclipse.org/modeling/mdt/ocl/docs/publications/OCL2015SafeNavigation/SafeNavigation.pdf for more details.

h3. Reflection

In the Pivot OCL the oclType() libary method has a pivot::Class return type allowing further navigation to make reflective access to the user metamodel.

h3. Lambda Expressions

OCL has always had hidden lambda expressions in order to define iteratpr bodies. The Pivot OCL reifies these so that the Standard Library uses a templated LambdaType as part of its modelling. Variables and Parameters may use LamabdaType and so ooffer full lambda expression capability.

h3. Map(K,V)

The Map type provides a familiar functionality comprising a set of keys with associated values.

Like all other OCL types, the Map type is immutable; there are therefore no *put* or *set* operations, rather a new Map may be created by *including* a key-value pair tigether with an old Map.

The content of a Map may be accessed using *at*, which returns invalid for an unknown key in the same way as an ordered collection returns invalid for an unknown index.

A Map may be created explicitly using the new Map Literal Syntax. Thus *Map(Integer,String){1 <- 'one',2 <- 'two'}*
creates a Map of Integer to String with *'one'* bound to *1* and *'two'* bound to *2*. The type *(Integer,String)*
parameterisation can be omitted. *null* but not *invalid* values are permitted as keys and values.

The new *collectBy* iteration may be used to construct a map from a collection or map. The iterators of the *collectBy* define the keys and the value of the body of defines the values. For instance *Sequence{1..10}->collectBy(i | i+i)}* builds a map from the values 1 to 10 to the even values 2 to 20.

Most standard collection iteration operations are available for Maps using the map keys as the (primary) iterator. A secondary value iterator may be specified using the new binds-to syntax. Thus *Map{1<-1,2<-4,3<-9}->reject(k<-v | k = 2 or v = 9}* defines a reject iteration over the three entry map, with a primary iterator *k* over the set of keys and a secondary co-iterator *v* over the values bound to each key. The body causes the second entry with key 2, and the third entry with value 9 to be rejected leaving just a one entry map.

h4. Details

The OCL metamodel is extended by a MapLiteralExp and MapType. A new abstract IterableType captures the iterable commonality of CollectionType and MapType without making map a collection.

The OCL standard library defines the new Map operations and the new Collection::collectBy itetation.

The OCL syntax is extended by the MapLiteralExp syntax and the binds-to co-iterator syntax for all iterators.

The OCL run-time is extended by a MapValue and an abstract IteravleValue to capture the commonality with CollectionValue.

