| Re: [mdt-papyrus.dev] multiple inheritance in profile |
|
Hi (Pictures are nice to complement a discussion, but the project is the unarguable truth.) We need to avoid getting meta-levels confused. For regular features duplicates must be resolved. base_XXX is a meta-feature, just like eClass(). There is only one. Multiple eClass()es do not need renaming because they have a virtual method to unify them. base_XXX must also be unified at the implementation level. This can be achieved by correct declarations/implementation of e.g. getBase_XXX(). Using a regular feature gen-option to fudge a meta-feature may find a fortuitous one that works at the expebse of imposing that fudge on regular features. Using your model, the *.uml looks good but there is an embedded Ecore profile definition which provides excellent opportunities for confusion. Your TestProfile.ecore is clearly bad; there is no derived unifying base_Element. After deleting the embedded profile, the genmodel fails to load. Reloading the genmodel reveals a disturbingly large number of warnings against UML and also 2 relevant base_Element warnings.
This is because your genmodel has numerous "DISCARD"/"IGNORE". This demonstrates that tweaking options to suit base_Element breaks other UML functionality. After changing to PROCESS all in the hope that this will be
'sensible', it loads fine and the *.ecore looks better; it has a
Child duplicates, but Stereo2 is corrupted. Generating code gives errors. The attached ZIP has my manual attempt at correcting the generated code. Removing irregularities from Stereo2/Stereo2Impl is easy. Correcting ChildImpl is a bit harder. The inheritance is already ok. ChildImpl extends Stereo1Impl implements Child (extends Stereo1, Stereo2). It inherits exactly one base_Element from Stereo1Impl. Just need to fix up the Stereo2 interface to re-use the Stereo1. I think that the eBaseStructuralFeatureID/eDerivedStructuralFeatureID changes solve this. (Not tested.) Aargh. Removing the corruption at the Ecore level and we have the two "baseElement" problem, which persists even if they are declared to be derived; arguably an EMF bug, but not the kind of thing that will change in EMF now; I think I raised it a while ago. But it's not an EMF bug, its a UML2 oversight. When UML2Ecore adds the "duplicates" annotation, it should also override the EMF validation so that the spurious duplicate diagnosis is not reported. Once the Ecore corresponds to the UML, the UML templates can generate the correct code. NB. The corrupt Stereo2 approach doesn't work in general. Suppose
Stereo1 is defined by UML, Stereo2 by MARTE, both should be
generated uncorrupted. Now when My-UML-MARTE has a double
inheritance I cannot suddenly require that the generated MARTE
code is changed. Only the My-UML-MARTE generation can change. Regards Ed Willink
|
Attachment:
org.eclipse.papyrus.test.multipleinheritance.profile.zip
Description: Zip compressed data
