|Re: [mdt-ocl.dev] UML-Profile support|
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
Back to the top