EA 10: Loss of data in Element Details Window

[Patrick Julian]

Hi,

this is just for your information.
Sparx has confirmed the issue already.

=========


Subject:  

Element details dialog alert message: loss of data


Details:  

Upon the alert "Name is a required field and must be filled in", EA
really shall NOT close the ("element details") popup window and
especially NOT throw away - i.e. revert - all changes that had been made
by the user to the element.
Especially the edits in the "Notes" field may have taken substantial
work time for editing.

Instead, clicking "ok" should IMO just simply lead the user back to the
element details window. Then he can just set a name for the element and
will lose no data.


Steps to Reproduce:  

open EA.
double click any element on a diagram (tested with a requirement
entity).
enter various words in the notes field.
Leave name field empty.
Click ok.
Watch how your previously crafted notes disappear.

==========

[qwerty]

Interestingly a class does not require to have a name (?!) and thus keeps the notes when clicking OK.

q.

[RoyC]

This affects the Requirement element type and its clones - Task, Feature, Change and Issue.

It's a curious problem, because all elements have a default name when you create them - either <elementType><n> or whatever you have set the autonaming/numbering to. So to have a blank Name field you'd have to deliberately delete the name, and why do that without replacing it at the same time?

[qwerty]

Yes, of course its a move to deceive the system. However, it's also a simple bug in the GUI that should be corrected.

Btw: Does someone know what Superstructures says about naming? From my practical approach I'd say that all elements need to be named. Except: fork/join, activity start/end (and maybe a few more that don't come to my mind immediately).

q.

[Eve]

Most UML elements inherit from NamedElement which optionally contains a name.

name: String [0..1]
The name of the NamedElement.

The only element type I see that specifies (in OCL) that it must have a name is ExtensionPoint.

[1] An ExtensionPoint must have a name.
self.name->notEmpty ()

Having said that, Requirement, change et al, don't figure in the UML specification at all, so it's not invalid for us to say that they must have a name.

[qwerty]

Having said that, Requirement, change et al, don't figure in the UML specification at all, so it's not invalid for us to say that they must have a name.

In that case we should take Superstructures as not too serious.

OTOH it would be more consistent if you could omit the name (almost) anywhere.

I wonder what the semantics of a use case (or a requirement) without name would be. Probably the null-operation 'coffee break' (resp. the null-requirement).

q.

[Eve]

Not sure what you mean. When the Superstructure covers something, it is the expected behavior. Given that Requirements aren't in the spec, it's reasonable for us to apply a constraint on the name.

I just tested a few element types, and the only one that disallowed an empty name (other than the requirement based types) was package. Personally I think that's reasonable. So, it sounds to me like we already have what you propose as the consistent behavior.