Menu
▾
▴
#301 Denote removed attributes in UML by coloring just box
closed
5
2016-02-04
2015-12-07
No
SBML L3v2 has a lot of changes to UML diagrams contingent on the fact that 'id' and 'name' were moved to SBase, meaning they were removed from being explicitly defined for other elements.
When Mike created the new figures, he colored the box and all the attributes in it red, so that readers know that something has changed--you can't color removed text because it's gone ;-)
However, when Andreas read the spec, this was confusing to him, since he assumed that the red-texted attributes meant that the attributes themselves had changed in some way, when in fact they had not.
As an alternative, Andreas suggested that we color just the UML box itself red if something has been removed from it. Will this work?
It could, but seems like a waste of time for something that has to be changed again anyway. I suggest leaving it as it is.
Wait--when would this have to be changed again? The next time it would be changed would be for L3v3, right?
Right, true :-) I don't really mind either way.
I agree that having the box red if something has been removed will convey a change and if nothing inside the box is red then it means the change means something was removed.
However this will also mean that when perhaps another attribute has changed/been added and so there is red inside the box it will not be clear that something has also been deleted.
What about having a second colour for the box if it has deletions.
So
red box + red inside = only red things have changed
green box = something has been deleted but all other remain same
green box + red inside = red things have changed AND something has been deleted
Note I only suggest this since it seems to me that someone will have to go through all the UML and adjust them anyway.
I do like the idea of differentiating between changed/added vs. changed/removed, but I don't think 'green' will say that to people, especially since green means something different in package spec UML.
What about this: a red box always means something has been removed. Red text always means something has been added or changed. So, red text in a red box means something has been added and something else has been removed; red text in a black box means something has been added; black text in a red box means something has been removed.
I do not mind either way. The people spending their time and effort doing should decide this one.
Contrary to expectations, this turned out to be a relatively simple thing to edit: I've now checked in a version to SVN that uses red boxes for classes with deleted attributes, but leaves the text of the unchanged attributes alone.
There was one issue I made a sort of executive decision on: in l3v1, all required 'id' attributes were written:
id: SId
and now they are written:
id: SId {use=required}
because now each class inherits the 'id' attribute from SBase, and must change it to be required. However, I felt that changing '{use=required}' to be red text would confuse people into thinking that it used to be optional, and now is required, which is not the case at all: zero semantic changes have been made.
I also added a description of what 'red' means in UML diagrams to the section on what red means in general:
"In UML diagrams, a red box is used to indicate a deletion, and red text to indicate a semantic change or addition."
(Hoping to skate under the wire with the 'semantic change' there ;-)
All opinions welcome!
Thank you Lucian for doing that! This makes the specification much easier to understand.
Seems reasonable!
OK, I'm marking this as resolved and closed. I won't add it to the list of changes to the spec (unless someone thinks we should), since it's not a change that actually affects L3v1, but merely how we present the L3v2 changes, which (obviously) have not existed in the past.
However, the changes are now part of SVN, and will be part of the forthcoming L3v2 specification.