Re: [mdt-ocl.dev] UML-Profile support

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi Fabian

I'm sorry, no good write-up.

The traditional 'Ecore-based' Eclipse OCL has had profile support for 
many years. The support is a little blurred since base_xxx is actually 
created by MDT/UML2 rather than MDT/OCL code.

The new 'Pivot-based' Eclipse OCL used a UML to Ecore to Pivot 
conversion until very recently. The Juno release has direct UML to Pivot 
but no profile support. Profile support has been added since then and is 
in GIT master.

Adding this support has required me to think hard about quite what the 
OCL status of 'base_xxx' and 'extension_xxx' are.

The challenge is that OCL has many normal metamodel characteristics but 
a few metameta oddments.

Ocl'something'::allInstances is a metatype rather than an instance method.

OCL 2.2 added UML static operations and properties, in principle, 
without any explanation as the semantic implication.

CollectionType::elementType is a metatype property.

Stereotypes and the 'base_xxx' and 'extension_xxx' are at an extra 
meta-level.

oclType() somehow should preserve the metatype of its source.

-----

I have been rationalizing these by migrating all the metameta stuff to 
static features so that everything is potentially declarable at a single 
meta-level in an OCL Standard library. (See 
GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.library\model\OCL-2.4.oclstdlib; 
this is a prototype for OCL 2.5 for which I have an auto-generated draft 
chapter.)

So elementType is a static property of Collection, and allInstances() is 
a static operation of OclElement and Boolean and ...

'base_xxx' and 'extension_xxx' are static properties and the missing 
metaclass ElementExtension is introduced to the pivot model to represent 
the instantiation of an applied Stereotype.

[In the Pivot model, many anomalies are normalized; all Associations are 
bidirectional and all Properties are Type-owned, the base_xxx and 
extension_xxx are navigable properties.]

My current thinking on the semantics of static features:

PropertyCallExp and OperationCallExp probably have a null source, (but a 
static class might be necessary to support static overloading.)

In the concrete syntax static features can only be invoked on type 
arguments, unlike Java where they can also be invoked on type instances. 
(This is probably necessary since OCL has no distinctive type literal 
syntax, unlike Java's ".class" suffix.) So 
anInstance.oclType().staticFeature in OCL.

----

My OCL 2011 workshop presentations provide an explanation of how OclSelf 
resolves the declaration of oclType().

Hope to see you at the OCL 2012 workshop and/or EclipseCon.

    Regards

        Ed Willink





On 20/09/2012 15:13, Fabian Tolkmitt wrote:
> Hello ocl dev Team,
>
> my name is Fabian Tolkmitt and I’m IT student at TU Dresden. I’m 
> writing an extension to Dresden OCL for UML-Profile support. For my 
> „Related Work“ section i’m planning to analyze the Eclipse OCL 
> solution, if there is one .My question is, if there are some documents 
> or web-resources of Eclipse OCL concerning UML-Profile support, which 
> go further than just looking into the source code. It would be realy 
> nice if you can help me at this point.
>
> Thanks,
> F.Tolkmitt
>
> _______________________________________________
> mdt-ocl.dev mailing list
> mdt-ocl.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2221 / Virus Database: 2441/5278 - Release Date: 09/19/12