An element several times on a diagram?

[PeterHeintz]

Maybe it is because of my age. I am certain to have read somewhere that with V12.1 it is possible to have e.g. a class several times on a diagram.

But searching the home page and the EA GUI I do not find anything.
Did I just dream?

[Geert Bellekens]

No you were not dreaming, there is a sort of weird feature that does that.
See Virtual Connector Ends

But I recommend not to use it.

Geert

[PeterHeintz]

Is there a concrete problem with that?
I am up to create a Fault Tree profile having events and gates, and events are sometimes several times on a tree. In this case I am looking for a graphical solution not breaking the tree layout.

[Geert Bellekens]

No, not a concrete problem, just a crutch for a problem that shouldn't exists in the first place.
If you have to use this then there's probably something wrong with the way you are modelling things.

Geert

[PeterHeintz]

If you have to use this then there's probably something wrong with the way you are modelling things

In Principle I agree. But a fault tree connects events with gates (and, or, ..) to other events. And an event can be connected to several gates.
Of cause that can be done without having a some kind of shape several times on a diagram, but this how a fault tree looks like and I cannot be to "innvative"  for my users.
 

[Paolo F Cantoni]

If you have to use this then there's probably something wrong with the way you are modelling things

In Principle I agree. But a fault tree connects events with gates (and, or, ..) to other events. And an event can be connected to several gates.
Of cause that can be done without having a some kind of shape several times on a diagram, but this how a fault tree looks like and I cannot be to "innvative"  for my users.

We had a similar issue with "Bow Tie" diagrams (Risk Analysis).  The same Control can be part of multiple "Control Chains" since for the same Threat Event, it might mitigate more than one Threat or Consequence.

So a Bow Tie is (effectively) two back-to-back trees (anchored at the common root - the Threat Event).

Initially we thought we had the same problem as you, but further analysis (as Geert suggests) showed that each instance of the control in each chain could have slightly different property values (Run States, so to speak) and so we created an "Instance "of the Control for each "chain".  We use a special form of the Specialization relationship to link the common Control (base)  to the "instances" in each chain.

If each "instance" of the the"same" event could have different property values from other instances, then you may have an analogous situation.

HTH,
Paolo

[Glassboy]

No, not a concrete problem, just a crutch for a problem that shouldn't exists in the first place.
If you have to use this then there's probably something wrong with the way you are modelling things.

I disagree, it's a problem where one element has a lot of connections and you don't want to display a spaghetti junction.  Showing too little on a view is as bad as showing too much.

[qwerty]

I concur with Geert. Having elements that wind connectors like a fork winds spaghetti are a sign of bad design (can we call it de-sign?).

q.

[PeterHeintz]

Thank you Paolo,
I also thought about using instances or objects however I have (only sometimes) just exactly the same thing on different possions in the tree.

I agree with both Geert and Glassboy even they argue somehow in opposite direction.
A diagram is not the model, it is a view on model content for humans and it should be as understandable as possible.

Having the same thing several times on a diagram introduces the risk to get the humans confused (maybe just by not realizing the two boxes are the same thing). One the other hand having lost of connector going all around the diagram makes reading/understanding difficult as well (I know there is Suppress Line Segment).

A fault tree is a technic to answer the question what can cause something undesired. This can be modeled and shown in many ways but a fault tree is just a graphical representation of that information expected to be in a tree. The users more focus on what causes what and there is not so much focus on what is the same and what is different.

[Glassboy]

I agree with both Geert and Glassboy even they argue somehow in opposite direction.
A diagram is not the model, it is a view on model content for humans and it should be as understandable as possible.

I'd say it is because Geert is thinking of a particular diagram type and isn't considering that some diagrams have dimensions like time hidden implicitly in them.  The more important point tho', is you generate diagrams from a model to communicate with an audience.  That diagram should work for that audience, you shouldn't force the audience to have to cling to a rigid methodology.

[Paolo F Cantoni]

Sparx has provided a less than optimally implemented solution to this problem.  The virtualized connector end.  The current solution is less than optional in three VERY IMPORTANT ways:
1)  The doppelganger vertex does not look like the master vertex it is derived from.  (I have suggested that the same shape script be applied with the place normally occupied by the connected diagram chain link replaced with another glyph to indicate this is a doppelganger).  As Peter points out it is IMPORTANT the the viewer - typically NOT the modeller - recognise the vertex as the same item as the master.
2)  The doppelganger cannot be manipulated (sizing etc) separately from the connector.  This is apparently by design, which I contend is less than useful.
3)  Sparx's current view is that if the connector is not visible, the virtualized end is not visible.  This too, in my view, is less than useful. 

The objective from the modeller/communicator's point of view is NOT so much to emphasise the connector, but the end-points.  So we are just after a solution that allows us to have multiple "instances" of a vertex on the same diagram WITHOUT breaking the model by creating (what should really be unnecessary) actual doppelganger objects (with the maintenance nightmare that creates), just because the implementation is less than optimal.

Paolo

[Paolo F Cantoni]

Thank you Paolo,
I also thought about using instances or objects however I have (only sometimes) just exactly the same thing on different possions in the tree.

[SNIP]

Hi Peter,

If I understand you correctly, you are saying that (only occasionally) you have the same object more than once in the same diagram (hierarchy).

I'm going to define some terms because even in English most people don't make correct distinctions between them and thereby cause confusion.

Hierarchy:  A directed graph where each node may have superordinate level nodes (parents) and may subordinate level nodes (children).  Hierarchies come in two possible forms:  Trees and Lattices.

Tree: A hierarchy where each node has at most one superordinate (parent) node.
Lattice: A hierarchy where each node may have more than one superordinate (parent) node.

With those definitions in mind, if the same node appears more than once in the graph (which is your model) then you don't have a tree, you have a lattice.  Why is this "pickyness (pedantry)" important? Because it gets tot he heart of what we are doing.

We should not be trying to render a tree if we don't have one.  That's "lying"!  (Or at least a form of Stephen Colbert's "Truthiness")

As I said in the earlier post, we initially thought (in our Risk Analysis case) we had the same item multiple times but we eventually UNDERSTOOD that we didn't.

So my strong suggestion is that you have another look at the theory of what you are trying to do and determine if (because of the the theoretical first principles you are using) you will always have tree or if you actually have a lattice that most often reduces to a tree.  If the latter, then you shouldn't force the lattice to look like a tree when it actually isn't.  If the lattice reduces to a tree (in any arbitrary case) then so be it.

Let us know how you go, as I'm likely to want to do something similar as we expand our risk analysis aspect.

HTH,
Paolo

[PeterHeintz]

Hello Paulo,
I appreciate those discussions, sharing opinions, agreements and disagreements very much.
According to your definition I have not tree and probably even not a lattice as well.

This is because I do not have a parent child relation (at least from my perspective), it is basically boolean algebra connection events to logical gate (and, or,...).

In some other thread I read something like “Any model is wrong but some are useful” what fits very much to my mind set. According that, we could say on a very dogmatic way, all of us are lying.
So for instance what the project browser shows of EA is wrong as well, but useful.

For me a diagram arranging elements in a tree style way even if the elements do not have a tree relation, is ok as long as it is useful instead of confusing.

I decided to arrange the elements tree style but allowing cross branch connections is the way I intent to go (only one element link per diagram).

[Paolo F Cantoni]

[SNIP]
In some other thread I read something like “Any model is wrong but some are useful” what fits very much to my mind set. According that, we could say on a very dogmatic way, all of us are lying.
[SNIP]
I decided to arrange the elements tree style but allowing cross branch connections is the way I intent to go (only one element link per diagram).

That quote was from one of my posts.  It's from George E. P. Box (the statistician).  I DO want to distinguish between a model being "wrong" - because it cannot be totally accurate (it MUST, after all, be an abstraction for it to be a model) and wrong because of a deliberate distortion of the model or its rendering.

Your final solution is the best, I feel.   There is no problem with laying out the element in a tree style; but by allowing the cross-links you are indicating that the underlying model (in those instances) is not actually a tree.  If you didn't do that, that would be wrong... 

Paolo