Community
Participate
Working Groups
Created attachment 253584 [details] repro Given a stereotype definition with a stereotype with an Integer[0..1] or Real[0..1] multiplicity and no default, the *.uml seems good. However applying the stereotype results in the properties view showing 0 or 0.0 for unspecified values. Surely it should show blank. The XMI correctly shows no attribute in the stereotype application. Manually changing the value to 0 or 0.0 appropriately in the Properties VIew gives no visual change, although the setting is now explicit. The XMI does not show the explicit 0 entry. (Repro, using the attached model apply the FixedPoint stereotype to a DataType and observe the many erroneous 0 entries in the Properties View.)
These types (assuming you were using the ones from the built in types library) are mapped to primitives when converted to Ecore and, per the EMF implementation, have intrinsic default values whether one is specified or not. If you make the properties in questions "unsettable" using the Ecore profile, it will be possible to tell (programmatically) whether the values have been explicitly set or not.
(In reply to Kenn Hussey from comment #1) > not. If you make the properties in questions "unsettable" using the Ecore OK. But I consider that my UML declarations already do that. The [0..1] multiplicity says the permitted values are [0] not a value, i.e. null [1] a value In the case of a [1] multiplicity, the default value must be used when no explicit value is available. Arguably for [0..1], a default value could be a validation warning regarding redundant information. So, IMHO, UML2Ecore should use unsettable to faithfully represent the UML specification. (NB. For Enumerations too!.)
(In reply to Kenn Hussey from comment #1) > If you make the properties in questions "unsettable" using the Ecore > profile, it will be possible to tell (programmatically) whether the values > have been explicitly set or not. Using unsettable doesn't seem to work. You cannot tell visually in the Sample UML Model Editor. (Unset values are displayed indistinguishably from set). Setting a 0.0 value explicitly in the Properties View and saving, does not save the explicit default LiteralReal value to the XMI stereotype application.
(In reply to comment #3) > (In reply to Kenn Hussey from comment #1) > > If you make the properties in questions "unsettable" using the Ecore > > profile, it will be possible to tell (programmatically) whether the values > > have been explicitly set or not. > > Using unsettable doesn't seem to work. > > You cannot tell visually in the Sample UML Model Editor. (Unset values are > displayed indistinguishably from set). It won't change what you see in the editor, unfortunately, but programmatically you would be able to tell the difference. > > Setting a 0.0 value explicitly in the Properties View and saving, does not save > the explicit default LiteralReal value to the XMI stereotype application. Hmm, I don't know what's happening here. The serialization behavior is from EMF, so if you're not seeing the expected result there must be a problem in EMF.
Hello What is the status for this issue? I think EMF need to treat missing input values for for numeric, booleans and enums. I tried oclIsUndefined() and oclIsInvalid() but they are happy with the unspecified default values being assigned when the XMI is loaded, e.g. 0 for numerics. Then I tried to find an invalid value for EFloat to use as default. I tried with, 'null', 'invalid' and 'infinity', not accepted. Next I tried with a big value, e.g. 1e10 and check for it in a rule, works but a kludge. It would be good if the default value 'null' or 'invalid' are assigned to attribute values not appearing in the input XMI instead of 0 for numerics and first element in enums and booleans. A new 'undefined' flag could be added to EStructuralFeature, the XMI reader updated to set it for missing data in XMI and oclIsUndefined() updated to test it. Another solution could be to hijack EStructuralFeature.transient (or some other flag) instead of adding EStructuralFeature.undefined, and do the same as above. Would something like this be possible? Br / Lars-Ola
(In reply to Lars-Ola Osterlund from comment #5) > What is the status for this issue? Probably awaiting enthusiasm / funding. You may be able workaround the problem by applying the Ecore stereotype and specifying the appropriate EXxxxObject as the Ecore type. If you try to hijack some facility, you are just digging a deep hole for you or a colleague to fall into later. It shouldn't be too hard to debug and fix the problem and certainly be less risky and probably less time-consuming than your suggestions.
I have no deep knowledge of EMF but I could make a try if I get some support. I don't know about the "Ecore stereotype", can you give a reference I can explore? Thanks / Lars-Ola
The Ecore Stereotype is provided as part of Eclipse UML2, just apply it in your UML model. If you want to debug, you need to - use OOMPH to create a workspace with UML2 and EMF sources. This will enable you to add 'printf' debugging, which is more productive than using breakpoints and pen and paper. Eventually, it will also enable you to fix the bug. - write a JUnit test, based on the UML Stereotype tutorial to load your model and do something repeatable that is unsatisfactory. - then set breakpoints on e.g. the setXXX actions to home in on the unsatisfactory functionality. - you will get on better if you code generate your model as Java that you can step and edit.
