Sparx Systems Forum
Enterprise Architect => Suggestions and Requests => Topic started by: AlexY on November 29, 2015, 09:16:15 am
-
Feature Diagram > Properties > Connectors > Show Stereotype Labels does not work on InformationFlow connectors - I guess this is because InformationFlow is NOT a stereotype.
The <<flow>> labels however often need to be removed to reduce clutter in diagrams. At present, I am forced to hide the labels one by one with Hide Label from the context menu on right click on a label.
Suggest to add feature Diagram -> Properties -> Connectors -> Show InformationFlow <<flow>> Labels, in "checked" state by default.
-
Removing the <<flow>> would make it appear as a dependency which is something completely different. So not a good idea at all.
q.
-
Following your logic, not showing a stereotype label on a connector makes it to appear as something completely different too. Sparx EA however supports 2 ways already that allow to hide connector stereotype labels.
So, I would suggest that whether to use hiding of labels or not is a different subject for discussion, and of course a modeller need to be careful not to confuse the reader.
-
YMMV, but extending a bad concept is not a good idea. Maybe others have different ideas and you find applause.
q.
-
Whether it is bad idea or not depends on context where/how the tool is used. In your context it might be bad (and I am perfectly fine with that), in my context hidden <<flow>> labels is exactly what is often needed and it makes a lot of difference!
Imagine a diagram with 10 elements and 20 flows connectors and _only_ flow connectors in it. You present this diagram to an audience that does not expect any connectors other than flows. Having <<flow>> labels in such diagram causes only nuisance -- the labels clutter the diagram and distract the audience. Someone in the audience usually picks on the labels and asks what they are for? And you need to explain that this is the tool that forces the labels to be there... And then someone picks on subject of tools and so it goes on distracting from the subject of the presentation. And if someone mentions that this is actually a UML tool and that <flow>> is a standard representation of an abstract concept called InformationFlow that in this diagram we mean what you (in the meeting) understand anyway... it is almost guaranteed that by that time majority of normal people out there in the offices (not the UML nerds in this forum) will be already confused to the extend that ruins the meeting. And you think hey I'd better remove these labels next time. So, in such context hiding these labels is actually a very good idea.
Hopefully this explanation is convincing enough? :)
-
Hi Alex,
I have great sympathy for your position, but also Thomas's.
We have come to the view that you need two types of diagrams - - Normative Diagrams to produce correct, rich, interconnected models showing the true complexity of the Universe of Discourse.
- Explanatory/Communicative Diagrams to explain/reduce the complexity to more simple, but still valid terms.
In the latter models, which I think you are basically describing, you can switch off the stereotype labels globally for the diagram (see under connectors).
Now, as Thomas (qwerty) says; if you have BOTH dependencies and Flows on the same diagram, then switching off stereotype labels can lead to confusion due to the limited number of variants in the formal methodology.
We have taken the view that Sparx EA, as delivered is a framework on which we hang our modelling. We have taken COMPLETE control of our MDG (based,initially on the Sparx ArchiMate2 MDG). In our MDG, EVERY element and relationship has its unique shape and icons - consequently, we actively remove the stereotype displays since they no longer provide any distinction between the vertices or arcs.
We have also standardised behaviour - for example, ALL vertices display Rectangular Notation (and therefore can have compartments), ALL arcs can display whether they are derived or not (and how they are derived - to an extent). Associations can display whether they are materialised into an AssociationClass etc.
You may want to consider doing something similar.
HTH,
Paolo
-
Hi Paolo, I do not disagree with Thomas nor with you. Seems however the world you model is more complicated than the one I am talking about here, and this causes misunderstanding. I will make another attempt to explain.
Information Flow is the only relationship concept in the DSL I am talking about. Nothing needs to be done to implement this DSL in Sparx EA. The diagrams are understood consistently without special labels, stereotypes, MDG, etc.
The <<flow>> labels is the only issue - need to hide them one by one.
-
I think that you impose your DSL to become a standard in EA. That will for sure be useful for your domain. But will it be for others too?
q.
-
I do not impose anything on anyone. I suggest a convenience feature that (a) will allow to achieve something, that I already can achieve in Sparx EA, but with less hassle and (b) will make Sparx EA to appear more useful and Sparx UI features more consistent from perspective of a wide customer segment (think new licence buyers) who do not know UML well enough to tell a difference between stereotype of a connector and <<flow>> label of an InformationFlow.
-
Not addressing the semantics or usage for specific situation. The linked thread had a discussion and script on how to toggle the <<flow>> off and on by diagram.
http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1398959952/9#9
-
Thank you, smendonc.
-
I agree 100% with the statement below! Showing <<flow>> labels (or any labels at all) should be optional. And you should be able to hide them in a script!
Whether it is bad idea or not depends on context where/how the tool is used. In your context it might be bad (and I am perfectly fine with that), in my context hidden <<flow>> labels is exactly what is often needed and it makes a lot of difference!
Imagine a diagram with 10 elements and 20 flows connectors and _only_ flow connectors in it. You present this diagram to an audience that does not expect any connectors other than flows. Having <<flow>> labels in such diagram causes only nuisance -- the labels clutter the diagram and distract the audience. Someone in the audience usually picks on the labels and asks what they are for? And you need to explain that this is the tool that forces the labels to be there... And then someone picks on subject of tools and so it goes on distracting from the subject of the presentation. And if someone mentions that this is actually a UML tool and that <flow>> is a standard representation of an abstract concept called InformationFlow that in this diagram we mean what you (in the meeting) understand anyway... it is almost guaranteed that by that time majority of normal people out there in the offices (not the UML nerds in this forum) will be already confused to the extend that ruins the meeting. And you think hey I'd better remove these labels next time. So, in such context hiding these labels is actually a very good idea.
Hopefully this explanation is convincing enough? :)
-
+1
-
UML 2.5 states on p. 668:
An InformationFlow is represented using the same notation as Dependency, with the keyword «flow» adorning its dashed line.
q.
-
UML 2.5 states on p. 668:
An InformationFlow is represented using the same notation as Dependency, with the keyword «flow» adorning its dashed line.
q.
UML was NOT designed for communicating with Executives or SMEs. michielper's comment is 100% "spot on"!We need to be able to vary ANY part of the rendering to communicate the message in the most appropriate way.
Paolo
-
Which is why profiles like BPMN were invented?
q.