[pivot] Introduce Contextual Package/Class/Property etc

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 427727 | | Status | NEW | | Importance | P3 normal | | Reported | Feb 08, 2014 07:07 EDT | | Modified | Feb 12, 2014 13:38 EDT | | Reporter | Ed Willink |

Description

The current Pivot representation works hard to respect the claim that Complete OCL properties are just the same as ordinary properties. This leads to a TypeServer/TypeTracker/Type architecture for multiple peer types and some uncertainty as to which is the primary, particularly after deletion of a primary object.

QVTo has ContextualProperties that also claim to be just the same as ordinary properties, but they clearly are not since their container is an OperationTransformation rather than the 'ordinary' Class.

The pivot representation could be simplified, if at each level we have a primary Xxxx and optionally many secondary ContextualXxxx.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Feb 12, 2014 08:30

H Ed,

I hardly grasp which are the directions of this bug/enhancement. Apologies in advance if I'm taking this in the wrong direction.

Some comments:

• OperationalTransformation ARE Classes
• ContextualProperties ARE Properties
• That's why an OperationalTransformation may contain ContextualProperties
• I agree that ContextualProperties are not 'ordinary':
  • They are not contained by the Class to which they are 'defining a property'
  • They are not 'defining a property' to the Class in which they are contained.

Although in words this contextual properties sound great, I don't know how the magic is internally done by Eclipse QVTo. When executing a transformation, there is only one transformation (which contains the contextual property) instance, and there could be many instances of the Class (context, to which we are 'defining a property') of a ContextualProperty. Maybe, how it's internally done is irrelevant, specially when this contextual properties are meant to be "temporal".

[NB But, are they involved in the transformation traces?]

Regarding OCL, I'm not sure which is the proposal here. Some comments/thoughts:

• I've had a look to the AS of OCL documents. and they model properties definitions as ordinary Package/Class/Properties ?. Do you want to get rid of them by introducing in the AS the concept of ContextualProperties ?
• ContextualProperties (and also Operations, so maybe ContextualFeature could make sense) seem something useful for OCL. However the title is confusing. Are you also suggesting ContextualPackages and ContextualClasses? Why ?.
• In the serialised AS there is also a $$ package in which constructed types are placed. I guess you could create a sort of $$ Class, which contains those ContextualFeatures (properties and operations). Once this contextual features are modelled, there should be some magic by the OCL interpreter to exploit these contextual/properties: the same kind of magic that the Eclipse QVTo transformation engine is comprising to deal with the already defined ContextualProperties.

Regards,\ Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Feb 12, 2014 09:45

I would expect all properties to still be Property, but the container might be ContextualType rather than Type.

Currently in the pivot each Type has a TypeTracker eAdapter and a TypeServer thereby minimizing the UML/OCL difference. (Similarly for Packages)

I'm suggesting that the primary Type, TypeTracker and TypeServer are merged into Type. Secondary Type and TypeTracker are merged into ContextualType. There is a new Type::contextualTypes to access the secondaries explicitly.

This is similar to what QVTo and Classic OCL do in their propretary ways.

Modeling the OCL functionality explicitly in the OCL pivot and removing another pretense that OCL and UML are identical, makes the OCL model clearer and provides an opportunity for QVTo to exploit it.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Feb 12, 2014 11:30

Hi Ed,

I think your are mixing implementation related APIs (TypeChecker, TypeServer, etc) and AS (Type). But I think I'm getting the good point of the approach.

Please, let's try to make this work in terms of AS. At least, I'm only focusing on them:

QVTo only mentions ContextualProperty referring to the "context" Class. This bring us the problem I mentioned before:

"...I don't know how the magic is internally done by Eclipse QVTo. When executing a transformation, there is only one transformation (which contains the contextual property) instance, and there could be many instances of the Class (context, to which we are 'defining a property') of a ContextualProperty"

Having real "contextual types" containing the defined properties/operations rather than contextual properties on an predefined type (The own transformation in case of QVTo) makes the magic vanish: If a type has an associated "contextual type" extending it, the latter is used when creating instances. Much better than any magic performed by the Eclipse QVTo implementation.

Some thoughts about the approach:

• I'm not sure if "ContextualType" is the better name. Anyway you are the native English speaker, so I leave you the decision about it.
• To me it looks like there should be only ONE associated ContextualType. If we are combining multiple OCL documents which are contributing properties/operations to the same real Type, the ContextualType should be the same and all the different Properties/Operations should be added to it:

Type::contextualType [0..1]

• That said, it looks like that the concept of ContextualType is not needed by the pivot neither. Type should be enough, since no extra features are required, just adding Type::contextualType[0..1] (and the opposite) which indicates to OCL that there is a "secondary type" which should be used since additional features are available to it.

Thoughts ?

[eclipse-ocl-bot]

By Ed Willink on Feb 12, 2014 12:46

I hate 'Contextual' but QVTo uses it. It is associated with a Complete OCL context so it makes sense.

If you have five Complete OCL documents you may have five ContextualTypes. In fact you may have more since you may have the ssame context more than once.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Feb 12, 2014 13:38

(In reply to comment #4)

I hate 'Contextual' but QVTo uses it. It is associated with a Complete OCL context so it makes sense.

What is associated to with the Complete OCL context is the property, not the type, so indeed is the context of the property.

what about using your terminology:

Type::primaryType (opposite of Type::secondaryType)\ Type::secondaryType ((opposite of Type::primaryType)

I'm not sure it's much better, but in my opinion it makes a little bit more sense than contextualType. Again, I'm still assuming there is not need to a real Contextual(or whatever)Type. For which I don't know if you agree or you don't.

More suggestions:

Type::extendedType (opposite of Type::extendingType)\ Type::extendingType (opposite of Type::extendedType)

Also note that:

context Type\ inv : not extendingType = null implies extendingType.superClass->includes(self)

so that the secondary Type extends the primary Type and inherits all their features.

If you have five Complete OCL documents you may have five ContextualTypes. In fact you may have more since you may have the ssame context more than once.

That's troublesome... I'm going a little bit further in terms of easing the implementation:

Think of having metaClass A, and some OCL documents (I've removed some bloating package related stuff)

Doc1.ocl:\ context A\ def : newProp1 : String = 'foo'

Doc2.ocl:\ context A\ def : newProp2 : Integer = 0

And a third document with some OCL constraint:\ Doc3.ocl:\ import Doc1.ocl\ import Doc2.ocl

context someClass\ inv : let a : A = A {newProp1 = 'bar', newProp2 = 1}\ in ...

Seems to be a sensible/desirable let variable initialization. Which A is created here ? Probably an instance of the secondary A, and everything is easier and consistent (in modelling terms) as long as there is only one secondary type A aggregating all the defined properties (and operations and invariants). Otherwise you will require some magic similar to what QVTo does with respect to the ContextualProperties contained by a transformation.

Regards,\ Adolfo.