[news.eclipse.modeling.mdt.ocl] Re: How to check the types of containmen

["Christian W. Damus" <cdamus@xxxxxxx>]

Hi, Gilbert,

See some more comments in-line.

HTH,

Christian


On Wed, 2009-09-16 at 13:03 +0200, Gilbert Mirenque wrote:
> Hi Christian,
> thanks for your patience
>
> > 
> > But, you said in your post that you were getting error messages from
> > expressions and "activated level M1" etc.  If you weren't doing this in
> > the OCL interpreter example (the "interactive console") then I don't
> > know what you were using.  AFAIK, the only UI that uses labels like "M2"
> > and "M1" is that example.
> I was doing it in the console but I'm not using the example.

Ah, but you are.  The interactive console *is* the example.  :-)


> > The MDT OCL SDK provides a "New Example" wizard that creates the
> > interpreter/console example as a source project in your workspace.  You
> > can edit the code to customize the parser behaviour, if you need to, as
> > in this case.
> Ok thanks for the hint with the wizard. I will have a look. But at the
> moment I don't need any code for running OCL statements or so. I just
> need a way for developing some ocl expressions for my meta model. After
> creating correct expressions I want to add them as EAnnotations on my
> meta model elements in hope that the bug 255786 [1] will be solved soon.

Yes, the console example is primarily intended as a scratchpad for development and testing of OCL constraints, in the manner that you intend to use it.


> And therefore I thought that I can use the OCL console just to see if
> the expressions are correct - not more. And that's why I don't
> understand why I have to switch M2 and M1 if I want to get code
> completion in the console for this element or for that element. Thought
> when I develop a new ecore meta model I am on the M2 level because it's
> a meta model for my DSL.

In the "M2" mode, your expressions are in the Ecore (metamodel) context, so they are generally expected to be queries on the model that you are editing.  The context of any _expression_ that you type is the metaclass of the selected element.  Thus, in "M2" mode you have expressions on EClass, EDataType, EReference, EPackage, etc.  The idea is that you can query your model to analyze its structure (e.g., are there any abstract EClasses that have no concrete subclasses?).

In the "M1" mode, your expressions are boolean constraints in the context of your model (as an Ecore instance).  The kind of constraint depends on the selected element:  when an EClass is selected, the console treats your _expression_ as an invariant constraint.  When an EOperation is selected, as a postcondition (as its syntax is a superset of the possible operation constraints).  When an EStructuralFeature is selected, as a derivation _expression_.  You want to use "M1" mode to author the model constraints for your annotations and eventual execution at run-time.

Note that, for "M1" mode, the interpreter only parses the constraints and reports syntax problems if necessary, because there is no model instance to evaluate the constraint on.  In "M2" mode, you are really defining queries on your model as an Ecore instance, so the console evaluates them on your model.

You can create a dynamic instance of any EClass in your model, of course, and then evaluate expressions on that.  These might be invariants that you parsed in "M1" mode in the model, but then you need "M2" mode on the dynamic instance because it is at a lower meta-level.  This is why the M1/M2 labeling in the UI is unfortunate.


> > No, this snippet pertains to the UML metamodel.  In UML models you can
> > use allOwnedElements because it is defined by the uml::Element
> > metaclass.  
> Ok I assumed that.
>
> >   self.exportedEvents ->forAll(ev |
> >       ev->closure(eContainer())->contains(self))
> > 
> Neither on level M1 nor M2 the code assist shows me the closure(..) on
> ev. The same with contains(..). And if I let this _expression_ interprete
> by the console in level M1 I get this output:

Sorry ... too much Java.  This should, of course, be "includes" instead of "contains."

Content assist may not show you the "closure" iterator because it is not OMG-standard OCL.  However, it should parse.


> illegal operation signature: (eContainer())

That is only because you need to update the console to set EObject as the implicit root class when parsing, unless your EClasses explicitly extend EObject (which I generally wouldn't recommend).


> and in level M2:
>
> Unrecognized variable: (exportedEvents)

Because EClass does not have an exportedEvents feature.  Your model class does.  You need the M1 setting to author model constraints.


> It's just not very comprehensible for me why I have to switch always.

It's just a way to tell the parser whether the context of an _expression_ is the *metaclass* of the selected element (M2 case) or the selected element, itself (M1).  For what you are doing, M2 is not interesting.

For background on this nomenclature, you might read the chapter on the OMG's MDA architecture and the 4-layer modeling stack (M0 through M3) in the Meta-Object Facility (MOF) 2.0 specification.


> > Unfortunately, this again requires that either you explicitly extend
> > EObject in your model or you use the implicit root class option, in
> > order to access the eContainer()) operation.  
> Thought that when I create a new ecore meta model all the elements
> inherit from EObject. At least the generated classes extend EObject. But

Yes, the Java *implementation* of your model extends EObject, but in abstract terms your model classes do not.  The EMF run-time requires the features of EObject but your business logic does not.  OR, if it does, then your model may benefit from explicitly extending EObject.  The point is whether your EClasses actually list EObject as an eSuperClass or not.

>  one does not have to generate classes at all. Isn't it possible at all
> to use the OCL console in this case because no classes are generated?
> Can't imagine.

Yes, it works equally well with dynamic EMF as with generated models.  You can try it right in the model editor on a dynamic instance!  Evaluate one of your invariant constraint expressions on a dynamic object and you'll see.


> > Alternatively, perhaps
> > your model already has some feature that generically returns the
> > containing element?
> Ok I can consider this. Until now I don't have any operations in my meta
> model because I wanted to let it open if it will be used with Eclipse or
> any other platform.
>
> Thanks in advance Christian.
>
> best regards,
> Gilbert
>
> [1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786