Eclipse Community Forums: UML2 » uml2ecore, ecore attributes marked as volatile

Help

Home

Home » Modeling » UML2 » uml2ecore, ecore attributes marked as volatile

Show: Today's Messages :: Show Polls :: Message Navigator

uml2ecore, ecore attributes marked as volatile [message #476401]

Fri, 19 October 2007 13:13

Javi

Messages: 23
Registered: July 2009

Junior Member

Hello,

Could anyone tell me when/why some properties (of a class for instance)
are marked as volatile in the conversion?
As a result, no field is created when generating the model code.

It happens to me several times in my model, and I cannot find an
explanation for any of them. In all the situations the property defines an
association end.

Thank you.

Report message to a moderator

Re: uml2ecore, ecore attributes marked as volatile [message #476402 is a reply to message #476401]

Fri, 19 October 2007 20:28

james bruck

Messages: 1724
Registered: July 2009

Senior Member

Hi Javi,

volatile attributes have no storage or implemenation code generated.
The UML2Ecore converter uses volatile when creating unions or derived
features for example.
In these cases, the result can be computed thereby saving space in the
serialized model and it avoids having to update the value.

Did you have a specific example in mind?

- James.

"Javi" <jfbriones_tech@yahoo.es> wrote in message
news:75967367b135d76bebee8f3245590fb3$1@www.eclipse.org...
> Hello,
>
> Could anyone tell me when/why some properties (of a class for instance)
> are marked as volatile in the conversion?
> As a result, no field is created when generating the model code.
>
> It happens to me several times in my model, and I cannot find an
> explanation for any of them. In all the situations the property defines an
> association end.
>
> Thank you.
>
>
>
>
>

Report message to a moderator

Re: uml2ecore, ecore attributes marked as volatile [message #476410 is a reply to message #476402]

Mon, 22 October 2007 16:59

Javi

Messages: 23
Registered: July 2009

Junior Member

Hi James,

I came across this post:
http://dev.eclipse.org/newslists/news.eclipse.modeling.mdt.u ml2.uml/msg00141.html
"The logic for whether to generate a field is fairly complex, but
generally
one is generated iff it meets the usual EMF criteria and such a field does
not already exist in the class hierarchy, ..."

After finding it, I understood the process a bit better.

Nevertheless, the following is an example where I could argue about the
behavior of the transformation process. The uml text is at the end of the
post

AParent <|--- AChild
AParent.refB[0..*] redefinedBy AChild.refBChild[0..1]

BParent <|--- BChild
BParent.refA[0..1] redefinedBy BChild.refA[1]

A. If both redefinitions have different names (refBChild, refAChild)
- New fields are used
- No trouble with the code that redefines the multiplicity

B. If both redefinitions have the same name (refB and refA):
- The fields of the parent are used
- How does an EList limit the size to 1 is still mysterious to me. But I
have faith.

C. The problems arrives when one end has the same name and the other does
not, as in my case (refChildB, refA).
- No fields are created in the children
- Two methods need to be completed (throw new UnsupportedOp....)
AChildImpl.basicGetRefBChild()
AChildImpl.setRefBChild(BChild newRefBChild)

And the questions:
Why is not a field 'refB:BChild' created?
- I could implement the methods using it
If no field can be created, why is not an strategy like in A implemented?
- Even better, no need to implement anything

Thank you.

The uml file:

<?xml version="1.0" encoding="UTF-8"?>
<uml:Model xmi:version="2.1"
xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
xmlns:uml="http://www.eclipse.org/uml2/2.1.0/UML"
xmi:id="_F_nBYICCEdyLYqeob6-Ojg" name="Issues">
<packagedElement xmi:type="uml:Package" xmi:id="_O5zx4ICmEdymJLG7EvIPnA"
name="DerivationNames">
<packagedElement xmi:type="uml:Class" xmi:id="_TGemoICmEdymJLG7EvIPnA"
name="AParent">
<ownedAttribute xmi:id="_eKIhUICmEdymJLG7EvIPnA" name="refB"
type="_U7AfUICmEdymJLG7EvIPnA" association="_BonzMICnEdymJLG7EvIPnA">
<upperValue xmi:type="uml:LiteralUnlimitedNatural"
xmi:id="_KoZ3AIC6EdymJLG7EvIPnA" value="*"/>
<lowerValue xmi:type="uml:LiteralInteger"
xmi:id="_JBIXMIC6EdymJLG7EvIPnA"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Class" xmi:id="_TtN2gICmEdymJLG7EvIPnA"
name="AChild">
<generalization xmi:id="__IduIICnEdymJLG7EvIPnA"
general="_TGemoICmEdymJLG7EvIPnA"/>
<ownedAttribute xmi:id="_tuRkoICmEdymJLG7EvIPnA" name="refBChild"
type="_WHvYMICmEdymJLG7EvIPnA" redefinedProperty="_eKIhUICmEdymJLG7EvIPnA"
association="_BFJ5wICnEdymJLG7EvIPnA">
<lowerValue xmi:type="uml:LiteralInteger"
xmi:id="_OZgKEIC6EdymJLG7EvIPnA"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Class" xmi:id="_U7AfUICmEdymJLG7EvIPnA"
name="BParent">
<ownedAttribute xmi:id="_weHPAICmEdymJLG7EvIPnA" name="refA"
type="_TGemoICmEdymJLG7EvIPnA" association="_BonzMICnEdymJLG7EvIPnA">
<lowerValue xmi:type="uml:LiteralInteger"
xmi:id="_NY1XQIC6EdymJLG7EvIPnA"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Class" xmi:id="_WHvYMICmEdymJLG7EvIPnA"
name="BChild">
<generalization xmi:id="__yosgICnEdymJLG7EvIPnA"
general="_U7AfUICmEdymJLG7EvIPnA"/>
<ownedAttribute xmi:id="_xmhokICmEdymJLG7EvIPnA" name="refA"
type="_TtN2gICmEdymJLG7EvIPnA" redefinedProperty="_weHPAICmEdymJLG7EvIPnA"
association="_BFJ5wICnEdymJLG7EvIPnA"/>
</packagedElement>
<packagedElement xmi:type="uml:Association"
xmi:id="_BFJ5wICnEdymJLG7EvIPnA" memberEnd="_tuRkoICmEdymJLG7EvIPnA
_xmhokICmEdymJLG7EvIPnA">
<generalization xmi:id="_fkpFkICoEdymJLG7EvIPnA"
general="_BonzMICnEdymJLG7EvIPnA"/>
</packagedElement>
<packagedElement xmi:type="uml:Association"
xmi:id="_BonzMICnEdymJLG7EvIPnA" memberEnd="_eKIhUICmEdymJLG7EvIPnA
_weHPAICmEdymJLG7EvIPnA"/>
</packagedElement>
</uml:Model>

Report message to a moderator

Re: uml2ecore, ecore attributes marked as volatile [message #476642 is a reply to message #476410]

Fri, 16 November 2007 18:17

james bruck

Messages: 1724
Registered: July 2009

Senior Member

Hi Javi,

Some comments below ...

- James.

"Javi" <jfbriones_tech@yahoo.es> wrote in message
news:976802c78f8f67d155197c1d41fef68d$1@www.eclipse.org...
> Hi James,
>
> I came across this post:
> http://dev.eclipse.org/newslists/news.eclipse.modeling.mdt.u ml2.uml/msg00141.html
> "The logic for whether to generate a field is fairly complex, but
> generally one is generated iff it meets the usual EMF criteria and such a
> field does not already exist in the class hierarchy, ..."
>
> After finding it, I understood the process a bit better.
>
> Nevertheless, the following is an example where I could argue about the
> behavior of the transformation process. The uml text is at the end of the
> post
>
> AParent <|--- AChild
> AParent.refB[0..*] redefinedBy AChild.refBChild[0..1]
>
> BParent <|--- BChild
> BParent.refA[0..1] redefinedBy BChild.refA[1]
>
> A. If both redefinitions have different names (refBChild, refAChild)
> - New fields are used
> - No trouble with the code that redefines the multiplicity
>
> B. If both redefinitions have the same name (refB and refA):
> - The fields of the parent are used
> - How does an EList limit the size to 1 is still mysterious to me. But I
> have faith.

I tried generating code from your model and this does aspect of the code
generation does seem to work.. AChild.getRefBChild() returns one item
whereas the property that it redefines is a collection. I don't think
there is an issue here.

>
> C. The problems arrives when one end has the same name and the other does
> not, as in my case (refChildB, refA).
> - No fields are created in the children
> - Two methods need to be completed (throw new UnsupportedOp....)
> AChildImpl.basicGetRefBChild()
> AChildImpl.setRefBChild(BChild newRefBChild)

That does seem like an issue. It should be possible to create bodies for
these as opposed to throwing an exception.
Please raise a defect and it will be looked into.

>
> And the questions:
> Why is not a field 'refB:BChild' created?

.... do you mean refBChild::BChild inside AChild?

> - I could implement the methods using it
> If no field can be created, why is not an strategy like in A implemented?
> - Even better, no need to implement anything
>
> Thank you.
>
> The uml file:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <uml:Model xmi:version="2.1"
> xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
> xmlns:uml="http://www.eclipse.org/uml2/2.1.0/UML"
> xmi:id="_F_nBYICCEdyLYqeob6-Ojg" name="Issues">
> <packagedElement xmi:type="uml:Package" xmi:id="_O5zx4ICmEdymJLG7EvIPnA"
> name="DerivationNames">
> <packagedElement xmi:type="uml:Class" xmi:id="_TGemoICmEdymJLG7EvIPnA"
> name="AParent">
> <ownedAttribute xmi:id="_eKIhUICmEdymJLG7EvIPnA" name="refB"
> type="_U7AfUICmEdymJLG7EvIPnA" association="_BonzMICnEdymJLG7EvIPnA">
> <upperValue xmi:type="uml:LiteralUnlimitedNatural"
> xmi:id="_KoZ3AIC6EdymJLG7EvIPnA" value="*"/>
> <lowerValue xmi:type="uml:LiteralInteger"
> xmi:id="_JBIXMIC6EdymJLG7EvIPnA"/>
> </ownedAttribute>
> </packagedElement>
> <packagedElement xmi:type="uml:Class" xmi:id="_TtN2gICmEdymJLG7EvIPnA"
> name="AChild">
> <generalization xmi:id="__IduIICnEdymJLG7EvIPnA"
> general="_TGemoICmEdymJLG7EvIPnA"/>
> <ownedAttribute xmi:id="_tuRkoICmEdymJLG7EvIPnA" name="refBChild"
> type="_WHvYMICmEdymJLG7EvIPnA" redefinedProperty="_eKIhUICmEdymJLG7EvIPnA"
> association="_BFJ5wICnEdymJLG7EvIPnA">
> <lowerValue xmi:type="uml:LiteralInteger"
> xmi:id="_OZgKEIC6EdymJLG7EvIPnA"/>
> </ownedAttribute>
> </packagedElement>
> <packagedElement xmi:type="uml:Class" xmi:id="_U7AfUICmEdymJLG7EvIPnA"
> name="BParent">
> <ownedAttribute xmi:id="_weHPAICmEdymJLG7EvIPnA" name="refA"
> type="_TGemoICmEdymJLG7EvIPnA" association="_BonzMICnEdymJLG7EvIPnA">
> <lowerValue xmi:type="uml:LiteralInteger"
> xmi:id="_NY1XQIC6EdymJLG7EvIPnA"/>
> </ownedAttribute>
> </packagedElement>
> <packagedElement xmi:type="uml:Class" xmi:id="_WHvYMICmEdymJLG7EvIPnA"
> name="BChild">
> <generalization xmi:id="__yosgICnEdymJLG7EvIPnA"
> general="_U7AfUICmEdymJLG7EvIPnA"/>
> <ownedAttribute xmi:id="_xmhokICmEdymJLG7EvIPnA" name="refA"
> type="_TtN2gICmEdymJLG7EvIPnA" redefinedProperty="_weHPAICmEdymJLG7EvIPnA"
> association="_BFJ5wICnEdymJLG7EvIPnA"/>
> </packagedElement>
> <packagedElement xmi:type="uml:Association"
> xmi:id="_BFJ5wICnEdymJLG7EvIPnA" memberEnd="_tuRkoICmEdymJLG7EvIPnA
> _xmhokICmEdymJLG7EvIPnA">
> <generalization xmi:id="_fkpFkICoEdymJLG7EvIPnA"
> general="_BonzMICnEdymJLG7EvIPnA"/>
> </packagedElement>
> <packagedElement xmi:type="uml:Association"
> xmi:id="_BonzMICnEdymJLG7EvIPnA" memberEnd="_eKIhUICmEdymJLG7EvIPnA
> _weHPAICmEdymJLG7EvIPnA"/>
> </packagedElement>
> </uml:Model>
>

Report message to a moderator

Re: property redefinition: implementation (association generalization) [message #476651 is a reply to message #476642]

Tue, 20 November 2007 12:44

Javi

Messages: 23
Registered: July 2009

Junior Member

Hello James,

It took me a while to get back to this post. And just to clarify, I see 3
test cases (3 different models):

For the 3 test cases we have a base model with two generalizations
AParent <|--- AChild
BParent <|--- BChild

1. (add 4 properties and 2 associations to the base model)
AParent.refB[0..*] redefinedBy AChild.refB[0..1]
BParent.refA[0..1] redefinedBy BChild.refA[1]

2. (add 4 properties and 2 associations to the base model)
AParent.refB[0..*] redefinedBy AChild.refBChild[0..1]
BParent.refA[0..1] redefinedBy BChild.refAChild[1]

3. (add 4 properties and 2 associations to the base model)
AParent.refB[0..*] redefinedBy AChild.refBChild[0..1]
BParent.refA[0..1] redefinedBy BChild.refA[1]

Possible issues:
Test case 1. (I cannot see the answer from the generated code)
- Do "AChild.getRefB():EList" and "BChild.getRefA():EList" limit the
number of elements? These methods override the parents' ones using the
parents' fields (ELists). Although the parent's fields are used, the
returned lists NEED to internally limit the number of elements. (Note that
in this test case there are no methods: "AChild.getRefBChild():BChild"
neither "BChild.getRefAChild():AChild")

Test case 2.
- Four get methods need to be created in the children:
"AChild.getRefB():EList", "BChild.getRefA():EList",
"AChild.getRefBChild():BChild", and "BChild.getRefAChild():AChild". The
question for test case 1 is applicable to the methods returning EList
which override the parents' ones (the returned lists NEED to internally
limit the number of elements).

Test case 3.
- Three get methods need to be created "AChild.getRefBChild():BChild",
"AChild.getRefB():EList", and "BChild.getRefA():EList". If I remember
correctly the three methods need to be implemented, some generated code
could be done though. But the generated code should be aware of the
potential issue of the previous test cases.
- Yes, my question was whether a field in AChild called refBChild of type
BChild could be created. This field must be an end of an association and
should behave as such. This is a tentative implementation, there could be
others, as using the field (of type EList) of the parent BUT limiting the
size.

Is it any clearer now? I really hope so.
Let me know which ones are actually issues to raise the defect as you ask
me for.

Notice I described here potential issues for the get methods but there
could be similar issues for the *set* and *isSet* methods. Fairly complex
scenario, the redefinition of properties, or generalization of
associations as called in the other post ("Generalization of an
Aggregation"
http://dev.eclipse.org/mhonarc/newsLists/news.eclipse.modeli ng.mdt.uml2/msg01632.html)

Regards,
Javi

Report message to a moderator