[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.modeling.mdt.uml2.ocl] Re: Using OCL to specify derived References (NOT attributes)

Jürgen,

Responses below.

Kenn

"JG" <jguni@xxxxxx> wrote in message news:ekmt9p$h6p$1@xxxxxxxxxxxxxxxxxxxx
> 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?
>

The derived list implementations are in org.eclipse.uml2.common (which only 
has dependencies on basic EMF plug-ins), so you could implement your methods 
by hand to use them. If you want partial generator support for subsets like 
this, you would need to use a UML model as the source for your EMF project 
(it is possibe to convert an Ecore model to a UML model).

>>
>> 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.
>

The code snippet I showed was only partially generated by the UML2 code 
generator. That is, the subset information (the constant) was generated, but 
the body was not. This is because, without better integration between the 
UML2 code generator and OCL, it's difficult to tell the generator what code 
it should generate for derived features... mind you, deriving values by type 
is, as I mentioned, a common occurrence in UML, so we hope to provide 
automated for that at some point (perhaps in response to 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=105199).

>>
>> 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?

Yes, it sounds like you understand things correctly - the lists 
implementations in UML2 would support this example exactly as you described.

>
> Regards
>
> Jürgen
>
>