Bug 212765

Description Javi 2007-12-12 10:21:11 EST

This bug is result of two newsgroup posts:
- subject: "uml2ecore, ecore attributes marked as volatile"
http://dev.eclipse.org/newslists/news.eclipse.modeling.mdt.uml2/msg01540.html
- subject: "Generalization of an Aggregation"
http://dev.eclipse.org/mhonarc/newsLists/news.eclipse.modeling.mdt.uml2/msg01632.html

To implement association generalizations in EMF, the use of properties redefinitions is needed. The implementation of this redefinitions may have some defects that could be fixed.

The bug has to do with the following attributes of redefined/redefining properties:
 - names (redefined name equal/different to the redefining one)
 - multiplicities
 - derived


3 test cases (3 different models):

For the 3 test cases there is 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.


Notice I described here potential issues for the get methods but there could be similar issues for the *set* and *isSet* methods.

I noticed as well some issues happening when the property to be redefined or/and the property redefining were derived. This caused generated code of derived properties to have an associated field, what I do not consider correct.
 - redefined derived, redefining not derived
 - redefined not derived, redefining derived
 - redefined not derived, redefining not derived
I cannot precise right now which of the 3 cases was wrong.