Extensions (in the Unified/Pivot OCL prototype)

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.

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.

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.

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.

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.

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.

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 for more details.

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.

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.

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.