[news.eclipse.modeling.mdt.uml2.ocl] Re: Using OCL to specify derived Re

[JG <jguni@xxxxxx>]

Kenn,

what you describe appears to be what I need. Alas, I am a little bit
overwhelmed by the number of projects, tools and plugins for Eclipse
which in one way or the other deal with modeling. This becomes even
worse, when some of these projects have apparently some
overlapping/supplemental functionality (like the OCL and Validation
projects, I still need to figure that out).
What the Eclipse community would need is a "meta documentation"... i.e.,
documentations about the different projects and their interdependencies
(and if my intuition was true, their overlaps).
I have been using the basic EMF (i.e., codegen from Rose models) for
quite some time, but I still feel totally lost.

Enough whining, back to the topic at hand:

I am unsure, if and how I can use these features that are in the UML2
project with my EMF/Ecore models.
If I understand things correctly, UML2 is an implementation of the UML
metamodel. But how does it relate to EMF (besides that it extends parts
of Ecore, but in a way I would not have expected)? It is apparently not
an "advanced" EMF with features missing in Ecore.

So, would I have to migrate my Ecore model to UML2? If so, how?

> 
> This kind of subsetting is quite common in UML; in the metamodel 
> implementation we identify the feature as a derived and volatile and 
> implement it like this (for example):

You say "we implement"... I read this as "We do it by hand, as there is
no facility to annotate an Ecore or UML model so that a derived
reference is generated like this". Is this correct? Since I have these
kinds of associations/references everywhere in my model, I would not
like that idea too much. I already considered modifying the code
generation of EMF to build something like this by hand if an annotation
indicates that a relationship is a subset of another.

> 
> protected static final int[] OWNED_TYPE_ESUPERSETS = new 
> int[]{UMLPackage.PACKAGE__PACKAGED_ELEMENT};
> 
> public EList getOwnedTypes() {
>     return new DerivedSubsetEObjectEList(Type.class, this, 
> UMLPackage.PACKAGE__OWNED_TYPE, OWNED_TYPE_ESUPERSETS);
> }
> 
> Here the accessor returns a changeable list for the Package::ownedType 
> feature, which derives its contents from the Package::packagedElement
> feature (based on type, i.e. instances of the Type metaclass) and which
> automatically delegates changes to the superset feature
> (Package::packagedElement).


So this EList for the derived reference is changeable... this is nice. I
figured that I could be using OCL to describe derived references, but
that I would not be able to change them.
Let me try if I understand things correctly:
If I had a "content" relationship between classes "A" and "B", and a
"columns" relationship between classes "Table" and "Column", where
"Table" extends "A" and "Column" extends "B", I could specify the later
relationship as derived using the implementation you suggest? And if I
would add a "Column" instance to a "Table" via the "columns" reference,
this Column would also show up via the "content" reference? And if I add
a special kind of B (a Column) to an A via the content relationship,
this Column, due to being a Column, would also show up in the "columns"
relationship.

Is this halfway correct?

Regards

Jürgen